A case for frontend based UI annotations

[Mattias]

We've started working with Fiori elements, it's an exciting journey and I see lots of possibilities- and challenges ahead. It's really a group effort where you need to involve everyone from the business, UX to the dev.

But one thing leaves me especially puzzled; in all examples and tutorials the CDS views are annotated with  @ui-annotations, to control the UI of our fiori apps.
​

Except in the most simple cases this makes no sense to me. I've always believed, and still believe, that we should separate business logic from the UI.

The option would be to annotate the UI in the Fiori app, and I can see almost only advantages with this.

• ​You seperate UI logic from the business logic


• We can use CI/CD pipelines and GIT to version control and deploy our frontend. Although we all love our transport system this enables faster turnaround, better versioning and ability to easier peer review with Pull Requests


• Front end developers don't have to learn a new skillset, they can work with well defined OData services.


• Guided Development in BAS helps alot for simple cases, and code completion with the rest


• No Dev-key needed in the backend systems for "simple gui changes"


• It's much easier to write unit tests when we can test front ends with mock data. This is my pet peeve and an area where I feel the SAP community in general lags behind.

The only advantages I see with the CDS based approach is

• ABAP developers don't have to learn a new toolset . The actual annotations are the same in CDS or the frontend, so the only difference is where to write the annotations, not how to write them


• You can transport both back and frontend together, avoiding dependencies between transports.

Please enlighten me why the CDS based approached seem to be favoured by SAP themselves.

[mvoros]

Hi Mattias,

I think it can work fine if cost of developing services is really low. I believe the main idea is that you model your business objects and then create multiple services on top of them. Some of the services will be consumed by Fiori apps (with UI annotations), some of them will be just simple APIs called by 3rd parties (no UI annotations needed).

I am not sure about ABAP implementation but in SAP CAP, you can easily separate UI annotations into a separate file so it behaves like CSS file for HTML file. The cost of having different services for same entities is low as well.

I am not sure if I can enlighten you but I see these motivations from SAP:

• Large pool of ABAP developers that can build "nice" UIs without having any UI skills (Your first advantage point). This should be doable for large portion of business apps as they are all the same. Fiori elements should cover most of these uses cases. The idea of not needing UI developer and still providing consistent UI experience.


• Speed of development: there is no need of coordination between frontend and backend developers.


• Extensibility story: you can easily add new fields and then expose them in UI without extending the UI (the idea of metadata driven UI)

But I agree that being stuck in ABAP world brings some negatives.

Cheers

 

[former_member14709]

Hello Mattias,

Thanks for sharing your views. However, when you say separate business logic from UI, I don't fully agree.

For example, for RAP based apps, we write UI annotations in CDS Projection views or CDS Meta Data Extensions, which are again built on top of CDS Projection view. In Projection views, we don't have business logic. Business logic reside in the underlying behavior implementation of the BO and not in the Projection layer. This way, business logic is separated from the UI.

Thanks,

Aman Garg

[Mattias]

We're still on Netweaver in this specific app, so we unfortunatly cannot use RAP; I'm very much looking forward to that, and then I agree, the business logic is separated in BOs.

I'm still not sure how you could write for example front end unit tests on mock data in a good way, but maybe that's also possible. CDS Unit testing is something we are exploring at the moment.

[Mattias]

Hi Martin,

CAP I think is a different beast, then all my points more or less are moot. Then you can indeed separate the annotations in a different file, and also you have access too all CI/CD goodiness. Maybe this is my holy grail 🙂

I have also seen the other points, and maybe it's possible to use Metadata driven UIs on more apps than I think. But as you know the business usually have that extra requirement that need an extension.
Cheers

[Siarljp]

Hi Mattias,

I think you are right, and its an interesting read as I dont usually think at things from a front end perspective 😉

I think SAP are working along the idea that they want to have next to no development in the UI - just generate it from the annotations. So then they do this from the CDS annotations, but you are totally right in that it violates the separation of concerns principle.

So SAP are coming at this from the back-end perspective (not the front-end).

Dev-Keys incidentally go away totally in S/4 (leading to other issues... that I once blogged on).

Paul Hardy in his ABAP to the Future book (2018) dropped some hints that SAP were working on  a visual editor tool to allow you to drag around screen changes for ABAP (similar to what is available for CAP) and then generate an annotation file... I dont think this exists yet (5 years on...) I would be happy to be proved wrong... In 2018 Paul said he was helping to test a prototype...