Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

One Central Launchpad – BTP Architecture

WouterLemaire
Active Contributor
‎04-20-2023 8:19 AM

Introduction


As described in my previous blog post about “One Central Launchpad” we used BTP Work Zone, standard edition to create a single point of access to all our backend systems without the user noticing, you can read the full story here: https://blogs.sap.com/2022/11/15/one-central-launchpad/

Work Zone, standard edition (also known as Launchpad service) allows you to integrate standard Fiori apps from different on-premise business suites and S/4HANA systems but also custom Fiori applications deployed on BTP. Deploying to BTP instead of on-premise backend systems has the following advantages:

  • You can use the latest UI5 version available without dependencies of your backend system

  • Connect the UI5 app to multiple backend to show data from different data sources in one and the same app

  • Keep the core clean, it’s only related to the UI but it is one part of custom code that is not in your backend anymore.


As pointed out in my previous blog post about providing “One Central Launchpad”, deploying custom UI5 apps to BTP requires a good architecture of your BTP landscape. In this blog post I’ll share some more insights on how to do this.

 

Subaccounts


First step is to configure sub accounts, you need at least a dev, acc and prd + one for administration purpose (basis tools, like ci/cd, tms , …). The administration account is used for services that require access to all subaccounts like DEV, ACC and PR. This account will be used to avoid cross access between dev, acc and prd.

The subaccounts for dev, acc and prd are used for running the launchpad and the custom apps.  Until now it is not possible to use other btp subaccounts as content provider for the launchpad, you can find more information about this here: https://help.sap.com/docs/build-work-zone-standard-edition/sap-build-work-zone-standard-edition/fede...  . Nevertheless, it is fine to keep the apps in the same subaccount as the launchpad.

Now, you also want to transport code changes in custom apps or customizing of the launchpad from DEV to ACC and eventually to PRD. This is where the “Administration” Sub Account comes in. This will be used to run the Continuous Integration and Delivery Service to deploy to DEV together with the Transport Management Service to access ACC and PRD.

With this approach, DEV will have no direct connection to ACC or PRD. The same applies for ACC and PRD as well.



Development, Acceptance and Production Sub Account


The Sub Accounts for DEV, ACC and PRD are quite similar. All stages will have the same services but also the same structure. When using the Transport Management Service, it requires to have an identical setup of the Spaces. In case you prefer to keep things simple, one Space could do the job. My recommendation would be to separate into Spaces according to your development teams. Do you have a different team for each project or rather one team for each module? Organizing CloudFoundry Spaces accordingly to your development teams allows you separate access so one developer of a certain project has no access to another project. In case of big development teams where security and access are important, separating into different Spaces is the way forward.

The DEV, ACC and PRD Sub Accounts requires the following service to run custom apps and the launchpad:

  • HTML5 App Repo for running custom UI5/Fiori apps

  • BTP Work Zone, standard edition for the launchpad itself


  • Destination & Connectivity service to configure a secure connection to the backend

  • Auth & Trust Management to enable SSO through IAS with your corporate Identity Provider

  • Business Application Studio: You can consider to have a dedicated Sub Account for Business Application Studio (also known as BAS) but it can be inside the DEV Sub Account, it doesn’t harm.


Optional, CloudFoundry runtime can be useful if you have applications that come with additional logic and their own BTP backend.


 

Administration Sub Account


The Administration Sub Account on the other hand is used for BTP services that help a Basis Administrator and for services that require cross access between Sub Accounts of other stages (eg.: DEV, ACC and PRD).

In our case, it is mainly used for the following services:

  • Transport Management Service (cTMS)

  • Continuous Integration and Deployment Service (CI/CD)

  • Destination & Connectivity service to connect other Sub Accounts

  • Auth & Trust Management to enable SSO through IAS with your corporate Identity Provider to the CI/CD and cTMS services.


This could also be a perfect place to activate Business Application Studio.

Besides the listed services, it can also be used for the Alert Notification Service and Automation Pilot which are great tools for the administration of your Sub Accounts.



Bringing it all together!


Let’s put it all together! This BTP landscape allows us to develop applications in Business Application Studio or VSCode. As soon as one of the developers pushes anything to GitHub, CI/CD will start a new job that does the following:

  • Build the application

  • Deploy it to the DEV Sub Account

  • Upload the MTAR to the Transport Management Service


From here on the Transport Management Service takes over:

  • For deploying to ACC, the MTAR needs to be imported into the ACC Sub Account. This can be done in the cTMS Queue for ACC.

  • Once it is imported in ACC, it will be added by cTMS into the queue for PRD. Here it can again be imported but this time into PRD.


This approach will protect your BTP system because of the following two reasons:

  • Developers do not need access to BTP itself, it is all handled by CI/CD and cTMS.

    • Avoiding direct deployment from in BAS to BTP and forcing developers to go through CI/CD for DEV will make sure that it will also work when importing into ACC and PRD.

    • Besides that, developers do not have access to the keys of services. Just in case someone leaves for a different project but still has the keys of an xsuaa service instance can be dangerous.



  • Importing in ACC and PRD can be protected with authorizations to make sure that only a release manager can import in PRD while any developer can import in ACC.

    • Here again the setup of the spaces is important. If you separate the BTP Sub Account in multiple Spaces, you’ll have different routes in cTMS which allows you to manage authorizations on Route level and also on Space level, eg.: a developer of one space will not be able to import apps in ACC for other spaces.




You can follow this blog post to configure your landscape like this: https://blogs.sap.com/2022/03/02/sap-ci-cd-integration-with-transport-management-service-tms/


In our case, the CI/CD job is configured to deploy to DEV in the acceptance step and uploaded to tms in the release step:




Conclusion


This gives you an example on how a BTP landscape can be configured, this is not the one and only way. Depending on your needs this can be different with more or less Sub Accounts using more or less services.

This setup can be improved by connecting cTMS with Solution Manager which allows to transport UI5 code in BTP together with ABAP changes in S/4HANA, this is something we have planned!

Hope this gives you some insights on the possibilities of organizing your BTP landscape!

 

Kr, Wouter
3 Comments
Labels in this area
Popular Blog Posts