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

[rpalotai]

Hi Adrian,

I think it might be not clear for you that when you do an extension project for a given standard app, you have to deploy it to the S/4 HaNA ABAP system!!! This deployment will create a new layer in the onprem layered repository of that app. Then you have to configure your tile to use this new layer.

https://help.sap.com/docs/bas/developing-sap-fiori-app-in-sap-business-application-studio/developing...

With side-by-side extension you will create a brand new fiori app which will be deployed to BTP. Such an app can use however custom backend service(s) created via RAP or CAP model, or you can just simply use the existing standard S/4 HANA oData services.

Br

Richard

[AdrDen]

rpalotaiebc - but we have two options when it comes to extensibility:

- adaptation project (layering): here I understand you are forced to push it to S/4HANA system, which is clear,

- older component configuration extension (using app extension points): not all standard apps are possible to be extended with adaptation, so you have to develop an extension app.

Here I'm not sure where the extension app should be deployed.

[AdrDen]

joseph.berthe regarding your comment - I agree with you it might be annoying at some parts and it's far from the ideal state. I'm trying to understand how to manage Fiori extensions from the frontend perspective as mentioned in my questions. It's still a bit unclear when to build extensions in BTP directly or push them on-premise.

[SugguSandeep]

Hi dengi7,

SAP Fiori Overview | SAP S/4HANA | 2023

https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/22bbe89ef68b4d0e98d05f0d56a7f6c8/4c1048feb4ea4f7d81c...

#fiori

Thank You,
Suggu Sandeep.

[AdrDen]

Thanks for your response sandeepsuggu. I already know the document. It's unfortunately not answering my questions. I just want to understand what is the recommended way of developing & deploying SAP Fiori extensions in hybrid landscapes (BTP Work Zone as entry point + multiple S/4HANA on-premise systems) to make the core of SAP Fiori apps clean (as described in my questions).

[Ashok_KumarM]

Hi Adrian,

Hope my comments below help provide some clarity to your asks:

Question: 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)?

Ans: For the scenario you mentioned here which is about extending std delivered fiori app, I see two options: a. if the std fiori app has extensibility placeholders (typically in view and controllers), you can use SAP Business Application Studio (BAS) in BTP to extend and add your flavor in those placeholders. Refer How to Extend an SAP Fiori app for SAP S/4HANA and SAP S/4HANA Cloud for more info. b. you can explore UI adaptation approach using SAP BAS. Refer to SAP Fiori Elements: Adaptation Project – Adding a Custom Filter to the List Report and openSAP microlearning (if you like video).

Question: Is there any general rule for adaptation/extension projects?

Ans: There be some std published literature on this but usually I approach it based on the availability of extensibility hook points natively in the app and UI adaptation approach as another option - in the same order.

Question: Should it be deployed to BTP (to decouple from the backend) and Is BTP first a right rule?

Ans: Not mandatorily but... if you can extend the app or 'adapt' the UI using SAP BAS, you have the option of deploying the extended (or a custom built fiori app for that matter) into BSP repo back in the ABAP system or deploying it as an app in SAP BTP. Latter helps with the larger theme of keeping your core clean, decoupling extension/custom apps from main business system - but still leverage backend odata services and its authorizations underneath.

Question: 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.

Ans: answer for first part of your question is in previous ans. Technically, you have the option of deploying the custom fiori app (freestyle or fiori elements based) into backend or in BTP. The approach you take depends on what is your overall extensibility approach, development guidelines you adopt for keeping your core clean. It's quite common for many of our customers take the route of deploying custom fiori apps in BTP and then provision it to end users through SAP Build Work Zone (Std/Adv) along with other std S/4HANA apps (i.e. std and extn apps in one place) to end users.

Question: 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.

Ans: I'd point you to these two links. S4HANA Extensibility Explorer and Custom Extensions in SAP S/4HANA Implementations - A Practical Guide for Senior IT Leadership. Between them you should be able to find additional info on extensibility in general, Fiori and UI adaptation specific stuff, what does it mean to keep core clean, our general recommendations, things to consider, pros and cons of certain approaches etc.,

Regards,

Ashok.

[AdrDen]

Thanks for your reply ashok.kumarm

#1 - I already know the way to build the extension and how to perform it (extension project using standard app extension points, done in BAS). The question is where the extension UI5 project should be deployed? Should we decouple extension (BTP) from standard app (S/4 on-premise) or keep them together on-premise? Probably there's no clear answer for that, as we should consider the roles setup, etc.

But in overall thanks for your valid takes.

[Ashok_KumarM]

If I were you I'd deploy the custom fiori app in BTP - for one simple reason that your central entry point is SAP Build Work Zone Std and not backend Launchpad. Also, with managed app router option there will not be any cost to run the custom fiori app in BTP as well.

Hope this clarifies.

[rpalotai]

Hi Adrian,

Keep the core clean means to me that you can't deploy any custom development on the backend S4.

So You have to create the UI5 app and its backend logic deployed to BTP. The backend service of the app should communicate with your onprem S4 through cloud connector using the S4's available APIs. If the app should store any data that you can't store in S4 using standard API, than you'll need a HANA Cloud tenant also.

If you are allowed to do ABAP development on the onprem S4 (which I think it is reasonable choice from clients when they count with the license and operation costs of the SAP cloud services...), then you have multiple choices.

I usually recommend to use the onprem S4 to store data and use as much standard APIs as you can. This way you can be quite close to "keep the core clean" concept. This way clients can optimize their costs of devops and required BTP service licenses (eg. they don't need to use expensive HANA cloud just to store some data in the cloud...)

Br

Richard

[AdrDen]

rpalotaiebc thanks a lot for your response. So, basically whenever we have a greenfield developemnt, we just go and do that in BTP. Would you recommend the same for case #1 that I described in my original question? Should we decouple Fiori extension project (BTP) from Fiori standard app (S/4)?