Discover the insights of your SAP BTP extension with SAP LeanIX

[Marco_Dorn]

When joining SAP LeanIX in Q2 this year, the mission I was sent on was creating transparency on your custom-built applications and extensions on SAP BTP. As SAP LeanIX helps you not only to plan your landscape transformation, but as well to proactively identify and manage obsolete technology in your IT landscape, you need to have as much transparency as possible. That’s not only true for your standard software, but also the artefacts which make your company unique.

I’d like to bring together the story of what the great team I work with has provided throughout the year in the context of SAP BTP and combine it with what was already available in regard to self-build software, as all now comes together:

• See what’s going on in SAP Build,
• Know what has been deployed in SAP BTP, Cloud Foundry environment,
• Dig into the tech stack of these deployments

See below how you can follow along.

Create an application with SAP’s Cloud Application Programming model

This is nothing new in the world of SAP BTP developers and inside this community. Thus, I simply followed https://developers.sap.com/tutorials/hana-cloud-cap-create-project..html which gave me an application based on https://cap.cloud.sap/docs/about/. Two things I did which are important for moving along:

1. I synced the artifacts to github.com,
2. I deployed the CAP application to SAP BTP, Cloud Foundry runtime.

Both should bring this closer to reality of non-tutorial-based developments. So far, for the typical SAP BTP consumer, this is an old hat, right? Therefore, I’d like to bring in the angle of the enterprise architects (EA), who want to see what custom applications are built and which technologies are being used, so that it’s easier to keep track of these details. This is where SAP LeanIX Application Portfolio Management (APM) comes into the picture.

Keep track easily

Your EAs want to keep track of what’s going in your company's technology stack. Continuing on the flow, connect your SAP Build instance which is used for production-related extensions to SAP LeanIX APM. This will provide you transparency on what SAP Build projects exist and will suggest modeling your SAP BTP account structure along LeanIX’s BTP modeling best practices.

The SAP Build Code project is suggested to being created as an “Application” fact sheet. It is based on SAP Build Code, hence two related “IT Component” fact sheets are suggested. SAP BTP, your global account, and the subaccount are recommended as 3-leveled ”Platform” fact sheets. Let’s wait with its creation though.

While this is nice, it won’t give you any insights into the actual Cloud Foundry applications and the SAP BTP services you use. This is where you want to connect SAP BTP, Cloud Foundry environment of your global account to SAP LeanIX APM. The good news is that you only need to setup one integration per global account to APM and it will enable you to crawl all the Cloud Foundry spaces and organizations inside of it. As long as you use the same platform user + IAS certificate + password, the integration will fetch details about deployed applications and their bound SAP BTP services.

Following the above tutorial, the discovery inside my Cloud Foundry space looks like this:

Diving into one application, it reveals you

• the deployed CF application,
• if it’s part of a multi-target-application, the recommendation is creating a fact sheet for that too,
• the bound SAP BTP services suggested as IT components
• the Cloud Foundry buildpack including its version.

Go ahead and create the two “application” fact sheets and the IT components. The fact sheet for the actual deployment will be of the subtype “Microservice” and its MTA will be the “Business Application” subtype.

To combine the SAP Build Code “application” fact sheet with the MTA, you can edit the suggested line item of the SAP Build Code discovery item to point to the MTA fact sheet. That will give you the transparency of the used SAP BTP services as part of your deployment and the SAP Build project details.

After creating the other two applications of the CF MTA to your inventory and linking it to the MTA-fact-sheet, you have the insights into your CF-based & SAP-Build-Code-created application:

Knowing the inside

This takes you already quite far when it comes to making your SAP BTP, Cloud Foundry deployments transparent for the enterprise architecture team. With this modeling, it’s easy to identify which applications across all deployments in BTP use which build pack version. Once the build pack ages, application owners can be asked to update.

This might not be enough though for mitigating technology risks and compliance upfront. An add-on to SAP LeanIX APM addresses exactly this gap. Let’s explore how to extend the above use case with SAP LeanIX Technology Risk and Compliance.

Add the Software Bill of Materials (SBOM) to the mix

“Software Bill of Materials (SBOM) files play a vital role in managing and understanding dependencies among microservices. These files, typically adhering to the widely-used System Package Data Exchange (SPDX) or CycloneDX format, provide a comprehensive inventory of all software components, libraries, and modules used by a microservice.” (source)

Let’s blend these into the above Node.js tutorial. For the three deployments, I used CycloneDX to generate three individual SBOMs (there are more open source tools to check out):

• for “MyHANAApp-srv” one in the folder “gen/srv”,
• for “MyHANAApp-db-deployer” in “gen/db”, and
• for “MyHANAApp” in “app/router”.

In the end, the mta.yaml tells you where to generate these SBOMs. Run cyclonedx-npm -o sbom.json in each folder to store the SBOMs in separate JSON files. After setting up your LeanIX workspace for the self-build software use case, you can push it to the fact sheets of each application created beforehand with the path:

https://{SUBDOMAIN}.leanix.net/services/technology-discovery/v1/factSheets/{factSheetId}/sboms

The exact details are well documented. Pushing these to your fact sheets will give you insights into which libraries and frameworks are being used inside every application (see details in the tech stack discovery documentation). This allows you to proactively address technical risks. Here is how it looks like for the above “MyHANAApp” in the LeanIX relations explorer:

It blends the SAP BTP services, the used Cloud Foundry buildpack, and used libraries inside the deployment. All the details of the Node.js dependencies can be listed in the SBOM explorer:

Update (20.11.25): Tracking the CAP-versions

This might be telling the obvious, but I want to highlight it after my first discussions on the blog post: when you follow along this tutorial and you analyze the SBOM components e.g. of “MyHANAApp-srv”, you can see the version of CAP.  In the side panel, you can then see which other microservice applications are based on that version, hence identify who's still using outdated CAP versions. Just saying...

Mission accomplished

That’s it. It’s quite a bit indeed, but now I have the full insight into

• where did I create the CF MTA app,
• where is the app deployed, and
• which tech stack is this built on.

For regular updates of the SBOMs, you can integrate their generation and push to the API endpoints in your CI/CD pipeline. For CI/CD, use the SAP BTP CI/CD service or create a Github-actions-based flow and the transparency of your tech stack will stay up-to-date.

Let me know of your comments and feedback here in the community! The team and I are now looking into the same storyline for SAP BTP, Kyma runtime. Furthermore, I want to bring in the transformation flow for classical on-stack extensions.

For both, I’d love to hear your thoughts!