In the last year I’ve been part of a project where we merged SAP systems of two companies into one. Eventually we ended up with one main S/4 HANA 2020 system, an SAP Business Suite for SRM and one for HR. During this project I was involved with the Fiori Launchpad setup. As we still had multiple backend systems, we had the strategy to provide a single point of access for all end-users. The end-user should not care about the backend system! With the on-premise launchpad we were not able to provide one single launchpad to the end-user, we would have one for each backend. Even with a central Front-end Server this was not possible because of the different version of the backend systems. Therefor we decided to go for the SAP Build Work Zone, standard edition (also known as BTP Launchpad Service) to provide a central Launchpad.
In this blog post I want to share some insights on our strategy, architecture and lessons learned.
Strategy
For this project we’ve chosen to use the SAP Build Work Zone, standard edition (also known as BTP Launchpad Service) to be able to provide one single launchpad to our end-users. With this Launchpad you can configure multiple backend systems to one Launchpad. An end-user will access the launchpad, open an app and will not know which system he is accessing behind the scenes. One could navigate back to the homepage and open another app which is loaded from another backend without noticing. One launchpad with multiple backends without the end-users has any clue, isn’t that not just great?!
How does this work in the SAP Build Work Zone, standard edition (also known as BTP Launchpad Service)? Compared to on-premise and NEO it will load the apps from a content provider. In NEO you could activate business packages and the apps are available as part of the launchpad. With the new BTP Launchpad service this is not the case anymore. You must connect all your backend systems as a content provider at design time. While at runtime it will load the full app from the backend and bring it to the end-user.
The Launchpad supports content providers to automatically federate apps to the launchpad but also supports manual integration:
I have this image from the following resource:
As part of our Fiori strategy, we installed/activated the embedded gateway on all backend systems. This makes our central gateway redundant, one system less in the landscape. On the other hand, we needed to upgrade the backend systems with FES 6.0 SP04 to be able to integrate it into the launchpad as a content provider and use the federation service.
Prerequisite for federation:
https://launchpad.support.sap.com/#/notes/3057822
General Restrictions:
- The integration of SAP Launchpad services with Business Suite requires Fiori Frontend Server 6.0 with a minimum SP04 or Fiori Frontend Server 2020.
Architecture
With this project we are providing more than 500 Fiori apps to our business coming from 3 backend systems. Most of them are coming for the S/4 HANA 2020 systems, some from the SRM backend and some from the HR backend. For this we configured the following architecture, 3 backend systems with embedded gateway connected to the launchpad as a content provider so we can use the federation service:
Connecting systems is one thing, we also have different application types which we all want to show together in the Launchpad Service. Depending on the type of an app we must take different actions for activation but also define a different strategy. We categorized the apps based on the type of app:
- Standard apps (WDA, GUI and Fiori) è provided by SAP
- Extensions è Our own developments part of the customer
- Custom WDA + Gui apps è Also own developments part of the customer
- Custom Fiori native è Developments part of the customer
For each type of application, we had to decide the source system. Some types of apps did not give us options while others could be deployed to multiple places. Each category has the following options:
- Standard apps (WDA, GUI and Fiori) è can only run on-premise (or steampunk but that would be too much effort. We activated the required apps on the related backend systems and exposed it to the BTP Launchpad using the federation service.
- Extensions è close to standard app so we can only keep this on the related on-premise system
- Custom WDA + Gui apps è needs to run on-premise
- Custom Fiori native è can run in many places, on-premise or BTP, we needed to make decision here.
In the end we decided to keep standard apps, extensions and WebDynpro apps on-premise (not many other options). While for custom Fiori apps we went for BTP for the following reasons:
- No dependency with backend
- We can use the latest version of UI5 independently from the backend. No dependency when the backend is being updated.
- Apps connected to multiple backends
- The apps can fetch data from multiple backend systems.
- Keep the core clean strategy
- It is not completely keeping the core clean but a good first step by keep the UI5 outside of the backend.
This results in the following architecture:
As we merged two launchpads into one, we had to migrate all custom apps from on-premise and NEO to CloudFoundry. For this we made small script to migrate all apps in mass to CloudFoundry, more details coming soon 😊 .
This also requires a good architecture of the BTP landscape. You’ll have to provide developers access with the possibility to deploy to the Development account with the right authorizations. Developers need to be able to transport to your test environment but maybe not production. We configured the BTP landscape in a way that we separate administration tasks from developer tasks and still make sure the developers can do all their tasks. I’ll share more insights in another blog post about this.
This is our go-to strategy but unfortunately the roadmap of SAP has changed which means Spaces and pages are only supported in our S/4 HANA 2020 system but not in the other business suites and BTP. Therefore, we deployed all custom apps to the backend so we can assign them to spaces and pages. We plan to completely switch back to BTP with our custom apps as soon as Spaces and pages are supported by BTP across multiple backends.
For apps in the business suite systems, we came up with a work around. We use a proxy page in the S/4 system that navigates to the apps in the business suite systems. With this, tiles from any system can be made available in Space and Pages on the S/4 HANA system. We will also share more details later on this.
Lessons learned
During this setup we learned some interesting lessons 😊. First and most importantly, do not rely on the roadmap of SAP… it changes not in a positive way. We counted on the BTP spaces and pages which is still not available. In the meanwhile, we have a workaround which makes everything even more complicated.
Besides that, the performance is not as good as our current on-premise launchpad… This is because the on-premise launchpad loads a part of the resources during startup while the BTP Launchpad Service has to load everything the first time you open an app for a specific backend. At least, this is the feedback I received from SAP.
From technical point, I understand that performance is slower than on-premise. But how do you explain this to the end-user?
We also faced a lot of connection problems because of timeouts. Eventually we were able to solve this by adding the launchpad as a trusted domain in BTP:
Would you not expect this happens out of the box when activating the Launchpad Service? We opened an SAP note for this and if I would not have told them they would still be searching for it….
In the end, nothing can beat a single point of entry with the user not knowing that one is accessing multiple backends from in the same launchpad!
More to come…
With this setup also comes a good BTP landscape setup for the deploying the UI5 apps. In one of the next blogs posts I will share more details on the landscape.
I will also share the proxy script to be able to use spaces and pages even if it is not available in BTP.
Last but not least, I’ll share some details on the migration scripts for UI5 apps from on-premise to BTP.
