Keep Core Clean for SAP Fiori

[AdrDen]

Hi,

I have read multiple documents on how to keep the core clean for S/4HANA and BTP, but they're mostly related to the backend stack (OData, APIs, enhancements, etc.). All these documents mention some stuff about the UI part (e.g. available extension options), but they're not that detailed and lack the view from the architectual perspective.

I have a couple of questions related directly to SAP Fiori and how to keep the core of UI5 clean in BTP + S/4HANA architecture:

1. Let's say we have a Launchpad in BTP, connecting to multiple on-premise S/4HANA systems (hybrid architecture). In one of S/4 systems we have a standard Fiori Timesheet application. A new requirement is to perform some modifications, which can be achieved by extension project only (no option to adapt the UI as a key user). Where should an extension app be built? Should it be deployed to BTP (to decouple from the backend) or sit together with an original app on-premise (and then be exposed in BTP)? Is there any general rule for adaptation/extension projects? Is BTP first a right rule?
2. Similar case, but with a completely custom Fiori app. Let's say we have installed a new role in S/4HANA, enabling Users to consume standard set of applications in HR area. Then we realize we need some new app that consumes data from the same S/4 system. Should new freestyle UI5/Fiori Elements app sit in BTP or on-premise? When to decouple and when to keep together? From the User perspective it shouldn't matter, as Launchpad can expose apps from different sources. I think backend shouldn't play a significant role too, as we can build both CAP and RAP.
3. Are there any documents related to keeping the core clean for Fiori apps (related to frontend stack)? It would be really nice to have a guide explaining various architectures and SAP's recommendations.

BR,

Adrian

[Joseph_BERTHE]

I personally find the theory to be excellent, but the implementation is hellish. If we start from the principle that no code should be written in the backend, then we must use standard APIs, which are ultimately quite poor. For instance, if we want to retrieve the text of a data element, how do we do it in the BTP? If, to meet my extension needs, I have to create client APIs, where is the benefit? In the past, we have seen that service-oriented infrastructures were a nightmare for CIOs in terms of maintenance. The concept that SAP wants to implement increases complexity, and I have doubts about the long-term performance.

In my S4HANA OnPrem project, every time we wanted to use the extensibility framework, we faced unacceptable limitations (for example: adding a field in a standard application via Key User Extensibility, and wanting to make it mandatory during saving... impossible. If we want a match code... impossible. Maybe in the next versions, this will be possible, but it was not available in 2021. Then we tried Custom Business Objects... great for Hello World, but if we want to make a join (association) with table T001 for a match code on the Company Code... impossible.

My assessment is very negative, especially since each new feature is only available in future versions and is very rarely if ever backported to older versions. For example, for RAP, attachment management is only available in 2022... not in 2021. SAP forgets that not all customers migrate every six months and perform automated tests on all business processes. Another example is My Inbox, where every time the user validates an action, there is a popup to add a comment, even if we don't want to. This behavior has been there forever, and it's only with the 2022 version that we can finally manage to remove this comment. A note is available... but not for other versions.

So, 'Keep the core clean' is great for sales presentations and to make clients dream, but in reality, we are very far from it. You will note my disappointment, especially as there are not many new features added in this area according to SAP's notes.

[rpalotai]

Hi Adrian,

The extension app (which is a new app in customer namespace!) can be always deployed to S4, just like the adaptation project (which is a new layer in the layered repo!). They both have to be deployed into S4!

I would use BTP for copletly new apps that could extend existing functionaity not just to extend a particular app.

Br

Richard