SAP Community - SAP Continuous Integration and Delivery

Configure cTMS in combination with CHARM and CI/CD

2024-04-28T22:47:32.487000+02:00

Introduction

The BTP Cloud Transport Management Service (cTMS) is mostly used in combination with the CI/CD service (or any other non-SAP CI/CD tool) when you need to transport applications from one Sub Account to another Sub Account. This combination is well documented in the SAP help documentation. CI/CD deploys to your DEV Sub Account and uploads the MTAR of your application to cTMS. From here, cTMS taks over to deploy to ACC and PRD Sub Accounts. You can find the details in the documentation here:

https://help.sap.com/docs/continuous-integration-and-delivery/sap-continuous-integration-and-delivery/configure-sap-fiori-in-cloud-foundry-environment-job-in-your-repository#(optional)-integrate-sap-cloud-transport-management-into-your-pipeline

Besides integration with CI/CD, you want to integrate cTMS with your existing transporting system, which is for most customers Charm. This setup allows you to transport ABAP objects and BTP applications together. You could also consider using ALM as transporting system but at the moment this has not all the functionalities that you have in Charm today.

Connecting cTMS nodes to Charm require enabling the configuration “Controlled By SAP Solution Manager”:

When you enable this, you might face some of the problems listed below and the solution might might be helping you to have a clean cTMS landscape integrated with Charm.

Problems

DEV node in cTMS without destination cannot be saved

Setting a destination doesn’t make sense as the CI/CD service already deploys to the DEV Sub Account but it allows you to continue with the configuration.
The flow described for Cloud ALM cannot be applied exactly the same way when using Charm as it does not require to enable “Controlled by SAP Solution Manager”, see documentation.
- https://help.sap.com/docs/cloud-alm/setup-administration/cloud-transport-management

All cTMS Nodes after DEV need to be controller by SAP Solution Manager if you want to integrate it with Charm BUT import to cTMS Nodes “Controlled By SAP Solution Manager” is not possible. This will cause an error in the logs of cTMS

Uploading to the DEV Node in cTMS only forwards to ACC after successful import. Importing/Deploying to DEV via cTMS is not needed as this is already done by the CI/CD service
- This is only causing overhead which is not needed

This means that you need to upload to cTMS Node for ACC BTP Sub Account BUT this is not possible because it is controlled by SAP Solution Manager

Solution

Make the DEV nodea Virtual Node
In SAP CI/CD, use export from “DEV-NODE” instead of "Upload to":
- This will upload the mtar to cTMS and immediately forward it from DEV to ACC so it ends up in the queue of ACC.

In any other CI/CD tool, use the export api: “/v2/nodes/export”
- https://api.sap.com/api/TMS_v2/path/NODE_EXPORT_BY_NAME_V2
- See blog post with an example: https://community.sap.com/t5/technology-blogs-by-members/integrate-ci-cd-with-ctms-as-part-of-sap-cloud-alm/ba-p/13653010

In the end, DEV is a virtual node and all others are controlled by Solution Manager

Configuration of the DEV Node:

Upload to Node is allowed
Node is flagged as a virtual node

Configuration of all nodes after DEV:

“Conntrolled By SAP Solution Manager” enabled

Overview

In the end, your transport landscape with CI/CD, cTMS and Charm will look like this:

Developers will push their code from BAS or VSCode to GIT
GIT will trigger CI/CD through a webhook
CI/CD will
- deploy to the DEV Sub Account
- export to cTMS dev node
cTMS will move the transport to the queue of ACC
From here it can be transported using Charm

I used a separate Sub Account for the CI/CD service but this could be as well in the DEV Sub Account.

For the integration with Charm I recommend following this blog post: https://community.sap.com/t5/technology-blogs-by-sap/how-to-use-the-integration-of-sap-cloud-platform-transport-management-into/ba-p/13443259

DevOps with SAP BTP

2024-05-06T14:26:48.640000+02:00

As my initial blog post series around DevOps with SAP BTP is already some years old, I thought it would be about time to come up with a new article - to reflect latest changes about how you can enable your teams to benefit from it for developing and running their apps on the platform.

DevOps is a key enabler for achieving high-level agility and quality in development projects – also in SAP enterprise environments. If you should be new to DevOps, the DevOps | SAP Community topic page does offer a lot of information.

Although DevOps is mainly a cultural approach, tools can help to foster agile development principles along the lifecycle of applications. In this article, I will sketch the setup recommended by SAP for agile development projects on SAP BTP, using corresponding SAP BTP cloud services and offerings. The platform does offer several different development approaches and runtime environments, so details of this setup might slightly differ per use case, but the goal is to offer a similar concept fitting for the most important ones.

The following figure outlines the recommended approach on the example of SAP BTP, Cloud Foundry environment:

Recommended approach to apply DevOps on SAP BTP

As most of the depicted SAP BTP cloud services are also part of SAP Build Code, this does also reflect the recommended approach around this offering.

Let's go through those four phases in the remainder of this article.

1. Set Up Continuous Integration

One driver of the agility and built-in quality that DevOps brings is the automation of large parts of the deployment pipeline. For this, a Continuous Integration / Continuous Delivery (CI/CD) pipeline is involved that automatically gets executed whenever your development teams do submit changes to their source code management system, to qualify them. The pipeline automatically performs certain actions along different stages, such as to build your changes and to test them on different levels. With this, it provides feedback to the developer on the quality of his/her changes:

Using Continuous Integration and Delivery to automate large parts of the deployment process

So, the first challenge is to set up CI/CD for your SAP BTP development use cases. Here, SAP BTP does offer a two-fold approach:

Option 1: Pipeline as a Service with SAP Continuous Integration and Delivery
- Opinionated, highly integrated setup that allows to benefit from agile methods without having to bring expertise
- Brings pipeline templates for typical SAP BTP development use cases, such as to develop a side-by-side extension using Cloud Application Programming model (CAP) or a compelling UI using SAP Fiori on Neo/Cloud Foundry/ABAP Front-End Servers; with this, it allows to come up with a running build, test and deploy pipeline for those SAP BTP specific use cases in minutes – where the pipeline can be configured completely via UI (configuration as code is optionally also possible)
- No need to build up and especially operate an own CI/CD infrastructure – only prerequisite: bring your own Git as source code management system
- SAP product, with direct support from SAP
- With this, addressing also those partners and customers that do not bring experience or that are looking for a CI/CD setup recommended and provided by SAP, reducing the overhead and cognitive load of their developers

Easy process to set up pipeline in SAP Continuous Integration and Delivery service

Option 2: Toolbox with open source offering project ‘Piper’
- Building blocks that allow you to build an own pipeline for SAP-specific use cases easier: pipeline templates (for Jenkins only), a library of pipeline steps (in Golang, which allows you to use them also for non-Jenkins CI/CD infrastructures), scenarios (end-to-end descriptions with sample code snippets), and Docker images you can easily add to your pipeline (example for usage with Azure DevOps)
- As it is an open source offering, there is no direct support provided by SAP – only community support, you have to create and then own your pipeline
- With this, the offering is addressing those partners and customers that need full flexibility and already bring expertise or infrastructure (or are willing to build it up and operate it) and now want to know how to best expand it also for SAP-specific use cases

2. Develop

This CI pipeline is then used by your development teams to qualify their changes – here, changes get pushed to a central source code repository based on Git, which then can automatically triggers a run of the corresponding pipeline via webhook. This pipeline run performs a build and executes automated test cases. The developer then gets informed about issues with the performed changes and can react on those directly. Also, compliance checks, such as for security flaws with used third-party libraries, can be tested as part of the pipeline run.

Example of agile development process

Of course, there are many frameworks available for automated testing – SAP Continuous Integration and Delivery service does provide an opinionated proposal for corresponding frameworks, which then have to be set up accordingly. If you want to use alternative frameworks, SAP Continuous Integration and Delivery allows to extend the predefined pipelines with scripting (for more information, see this blog post).

For the creation of the actual test cases, a step-wise approach is recommended, where you start with first test cases and then evolve by time, by adding additional cases, also based on the issues that come up later and on the latest compliance requirements you might face.

As implied above, the actual development process will slightly differ per development environment. For example, on Cloud Foundry, you might use SAP Business Application Studio (where you would benefit from a direct integration of SAP Continuous Integration and Delivery, allowing to set up and monitor corresponding pipelines directly from the IDE), on Neo SAP Web IDE Full-Stack and on SAP BTP ABAP development tools in Eclipse. Still, the general approach for these environments could be similar, as depicted above.

3. Deliver

When your teams come up with a qualified release candidate, they can either perform a direct deployment out of the pipeline (when all tests are “green”, a direct deployment can be triggered) – or you benefit from a standardized central transport and change management approach, using SAP Cloud Transport Management. The later is our recommended approach for most enterprise environments, where you normally want to have additional control of your production subaccounts.

The actual transport concept is quite similar to what you might be used to from development in on-premise and private cloud environments, with a centrally defined delivery landscape:

With the option to control who is allowed to handle changes where (that is, on which SAP BTP subaccount),
With a central log file for auditing,
With the option to synchronize the propagation of changes from different environments (such as from private cloud/on-premise together with related cloud changes), where change and deployment management capabilities of SAP Cloud ALM or Change Request Management (ChaRM) of SAP Solution Manager could orchestrate SAP Cloud Transport Management service, in addition to orchestrating then also private cloud/on-premise transport mechanisms.

Still, here with the option to combine it on SAP BTP with CI principles, so that your development teams can benefit from tight feedback loops enabled by an automated pipeline, to verify single developer changes - while you still have full control for the propagation of those changes towards your production environment, with the automated hand-over from the pipeline into a controlled, centrally managed and pre-defined delivery landscape. Then to verify the release candidate, potentially consisting of changes from different environments and typically done with a manual confirmation.

Hybrid change management

SAP Cloud Transport Management service can cover more and more content types, such as:

SAP Fiori content (in Neo and Cloud Foundry)
CAP applications (in the form of MTA archives),
Objects from SAP BTP ABAP environment,
Content from SAP Build (SAP Build Process Automation, SAP Build Work Zone, …),
App-specific content types, such as iFlows from SAP Integration Suite and Network Package content from SAP Analytics Cloud
See the full list here

With this, you can establish a standardized transport management process for more and more development use cases around SAP BTP - with the option to integrate all those content types into your central change and delivery management process, such as provided by SAP Cloud ALM.

SAP Cloud Transport Management service is out-of-the-box integrated with SAP Continuous Integration and Delivery - just switch on the corresponding option of the Release stage:

Screenshot from 'Release' stage of SAP Continuous Integration and Delivery

It can also be integrated into other CI stacks via a step of the library from project Piper into third-party pipelines or open APIs (for example, see this blog post on using Azure DevOps with transports).

4. Operate

With SAP Cloud ALM, SAP is providing a central observability platform for all SAP products, including SAP BTP (in interplay with several local SAP-BTP-specific observability capabilities). To operate your apps on SAP BTP, you can therefore use its unified monitoring, alerting and analytics offering based on telemetry data exposed by SAP BTP (and other SAP solutions), to reduce the meantime to detect any issues. SAP is using OpenTelemetry as unified and open instrumentation approach for SAP BTP use cases, allowing you for example to instrument your custom apps for central observability.

Functional overview of SAP Cloud ALM for Operations

For more information, see SAP Cloud ALM for Operations.

To resolve issues, you can then navigate from SAP Cloud ALM to the local expert tools on SAP BTP, to perform a use-case-specific root cause analysis. For example, from an error message in Exception Monitoring of SAP Cloud ALM, you could directly jump to SAP Cloud Logging service to perform a detailed analysis, for which the service stores and visualizes log files, metrics, and traces from your apps running in different SAP BTP environments.

For the execution of corrective actions on SAP BTP, events in SAP Cloud ALM could automatically trigger the execution of corresponding commands on SAP Automation Pilot. This service offers a low-code and no-code automation engine and brings catalogs of automated actions that you can use to compile the best-fitting command for automating your recurring DevOps-related tasks and for remediation of alerts from your individual SAP BTP applications.

Automate recurring ops tasks with SAP Automation Pilot

This way, you can optimize your operation efforts and increase the resilience of your business scenarios.

In case you want to apply Infrastructure-as-Code principles based on an industry standard, consider to use the Terraform Provider for SAP BTP to automate provisioning, management and configuration of resources on SAP BTP.

Summary

SAP BTP offers a low-entry approach to verify the value a more agile development process can bring - also for your SAP applications. It does comprise highly-integrated DevOps services along the complete lifecycle - from CI/CD to development, delivery and operations, with a smooth integration option into SAP Cloud ALM, as SAP's strategic operations and central observability platform. SAP Cloud ALM allows the central operation of your holistic business scenarios spanning several environments. If you should have special needs or third-party frameworks already in use around DevOps, benefit from open APIs of the DevOps services of SAP BTP and of SAP Cloud ALM.

If you want to learn more, check out the information from the DevOps | SAP Community topic page and consider to take the learning journey Discovering DevOps with SAP BTP. If you want to try it out, all DevOps services are part of SAP BTP free tier, so the above setup can be experienced without charge. Otherwise, SAP Build Code is a good starting point as well, as it does comprise most of the DevOps-related SAP BTP services.

Configuring SAP CI/CD pipeline for Deploying ReactJS application in Cloud Foundry

2024-05-07T09:59:07.961000+02:00

In this blog, we will discuss how to integrate SAP CI/CD pipeline for deploying ReactJS application on SAP Cloud Foundry environment.

You will learn,

How to create and build a ReactJS application.
How to configure and run SAP CI/CD Pipeline service.
How to create GitHub Webhook for automatically build, test and deploying the code changes.

Prerequisites

You have an SAP BTP Global or trial account.
Node installed in your system.
You have a GitHub account.

Setting up React Application

step 1: Create your react application using the create-react-app. The create-react-app is an excellent tool which allows you to create and run React project very quickly by wrapping all the required dependencies.

npx create-react-app reactcicd

step 2: To ensure that the application is running as expected, open the terminal and navigate to the application folder and type the below command. The application gets automatically hosted in the default server localhost:3000 and you’ll get the following screen.

npm start

step 3: Now create manifest.yml file for determining the Cloud Foundry app configurations and paste the below contents.

 ---
applications:
- name: your-app-name
path: build/
instances: 1
buildpack: https://github.com/cloudfoundry/staticfile-buildpack.git
memory: 256M

step 4: Build the application using the below command, you will see the build folder getting added to your project.

npm run build

Also create a Staticfile with the following content in the build folder as shown below

step 5: Now create a repository in your GitHub and push the changes. Make sure to remove build folder from the gitignore file since it is added default while creating the react project, we require it for deployment. For more details on how to deploy react application refer this link react-CF-deploy

Enable SAP Continuous integration and Delivery Service

step 1: Login into SAP BTP Cockpit and choose the subaccount to which you want to deploy your application.

step 2: Select Service Marketplace from the side pane and search for Continuous Integration and Delivery service. Click the create button.

step 3: Create popup will appear then choose the plan you want to and click create button at the bottom. Choose View Subscription and wait until the status changes to Subscribed.

step 4: Once the status is changed to subscribed navigate to Security → Role Collections from the left-hand pane. Choose role collection CICD Service Administrator and click edit.

step 5: Navigate to users section click edit then Add a new row in the Users section table, enter your user id, Keep the identity provider as default and click save.

Configure your credentials

step 1: Go to Services → Instances and Subscriptions from the pane. Choose the application icon located next to the Continuous Integration & Delivery subscription. Now we need to add credentials for GitHub, CF and Webhook.

step 2: Let’s first go with GitHub credentials. If your GitHub repository is private, you will need to provide with the necessary credentials to access it. You can skip this in case of public repository.

step 3: In Create Credentials popup make sure you give unique name within the subaccount. Select the type as basic authentication and provide your git credentials. Use personal access token as a password. Then choose create.

step 4: Now repeat the same steps for adding CF credentials. Here you have to provide your SAP BTP cockpit username and password.

step 5: For configuring webhook credentials change the type from Basic Authentication to Webhook Secret. Then generate the webhook secret copy it somewhere safe and finally choose Create.

Add a CI/CD job

step 1: Navigate to the Jobs tab and choose the icon to add a new job. Provide unique name for the job.

step 2: Click on the icon inside the Repository input field. You will get a popup then choose add repository., Enter your git repository clone URL. You can add any name of your choice. It need not to be matched with your repo. Choose your saved credentials for git and webhook.

step 3: For Branch, enter the GitHub branch of your repository from which you want to receive push events. In this example, master. Select Cloud Foundry Environment from the dropdown in the Pipeline field.

step 4: In the BUILD section choose npm as your build tool. For Build Tool Version, select the latest node version.

step 5: Under the Release section, switch on the execution of the Deploy to Cloud Foundry Space. Since we have already given name in the manifest file, we can skip the name field.

Replace the placeholders API Endpoint, Org Name and Space with the values in the Cloud Foundry environment to which you want to deploy. You can get the values from your subaccount overview in the SAP BTP cockpit.

step 6: For Deploy Type, choose standard and select your previously created CF credentials. Leave remaining fields default then finally choose create.

Create a GitHub Webhook

GitHub webhooks allow you to automate CI/CD builds. Whenever you push changes to your GitHub repository, a webhook push event is sent to the service to trigger a build of the connected job.

step 1: To create a webhook in GitHub, you need payload URL. Select your repository and choose Webhook Data from the right pane. You will see a below popup:

step 2: Now sign in into your GitHub account. In your project, go to the Settings tab.

step 3: From the left pane, choose Webhooks then Add webhook. Enter the Payload URL, Content type from the popup and the Secret that you had saved previously. For all other settings, leave the default values and add.

Verify your Build

You have to trigger your job manually the first time after creation.

step 1: In Jobs tab, select your job and choose Run. Verify that a new tile appears in the Builds view. This tile should be marked as running.

step 2: Wait until the job has finished and verify that the build tile is marked as successful.

step 3: Navigate to your space in the SAP BTP cockpit and check the list of installed applications. Now you can see your application got added.

step 4: Select your application and launch it with the application route. You can see the react application deployed.

You have now successfully created a CI/CD pipeline and deployed your ReactJS application to SAP BTP. From now on for every commit you can see the job getting triggered with commit id displayed under builds section.

Transform Your Teams to a Scaled Agile DevSecOps Factory to Deliver Clean Core Architecture

2024-06-26T16:07:47.616000+02:00

Let us begin by defining the vision statement for a Delivery Team when we have to adapt Clean Core:

Application Delivery Teams will deliver an industrialized way for the realization of custom development for ERP Digital Core and surrounding Ecosystems in a repeatable and cost-effective way, maintaining quality and clean core integrability.

To analyze this our scope of service for this article will look into how technical work is delivered in the Build phase in a System Integration and Application Development Project. We will leverage a factory model for delivering such work.

Defining the Scope

List your capabilities. Look at your historical data. Pick up multiple sample projects that are successfully delivered. Break up the project cycle into individual phases. Map people and skills that were mapped in each phase. This will identify the capabilities. Map capabilities in 2 Dimensional metrics of usage adaptation and impact. All that is P1 and P2 are candidates for adaptation as Capability Towers. P1 is the priority on which the pilot phase will be executed. Capabilities P3 are sparingly used and sometimes specialized skills. They are not a good fit for being treated as an independent Capability Tower, but to be considered as Subject Matter Expert (SME) pool. Capability Tower work as a factory, equipped with multiple hands of similar skills. They will be the factory. Their deployment to Epic is decided by demand forecast. Capability Towers will carry utilization targets. Each Capability Tower will have a Capability Leader who is responsible for Capability and Capacity functions. SME’s are investments and thus preferably multi-skilled and deployed on requisition. They are special forces para dropped into a Story for specific purposes. The delivery factory ecosystem is led by a Service Delivery Manager (SDM).

Usage↓ Impact→	HIGH	MODERATE	LOW
HIGH	P1	P2	P2
MODERATE	P2	P2	P3
LOW	P2	P3	P3

Metrics to Prioritize Capability Tower Investments

Prioritize Capabilities

It is important to test that a factory-style model will work for your organization. We need to test it through a pilot. This needs us to prioritize one capability area to invest in. A big bang adaptation of all capabilities is generally too fast a change, which fails, as there is too much inertia to traverse. It is better to start small, bite-size, through a pilot factory adaptation. Start where you have high usage adaptation and high impact. A selection of high-impact scope is important to stress-test the tools, processes, and change management. One should thus do this pilot with P1 capabilities. It is too critical an impact to fail, and if this model is to fail, let's fail early. Once the pilot capability factory is up and running, other P2 capabilities can follow the model swiftly. For most software-related programs, code development is the capability that is most used and has the highest impact. But this is not a rule.

Process Adaptation

Let us assume the code development factory as an example to understand the process adaptation. The requirements will be for multiple programs, that will come all together or spread out over time. Each requirement is captured into Epic. The factory architects will work on defining the Features and Stories and defining the Backlog. The development team will work on the Sprint, do unit testing, and send integration tests to the Quality system. Once the System integration test is done for the configurable item, a customer demo will be done. A story will be sent to a user acceptance and planned for release or deployment. The defect management, backlog, debt, and burndown will need to be done by a tool. A developer focuses on developing the enhancements or features while the tester will do an integration test. Deployments in ERP estates are done by cutover go-lives. The project ends with a transition to support the team in operations. Knowledge management is going to be the key, where assets are harvested and estimates are improved. The below diagram pictorially represents this idea.

Agile Factory Delivery Flow

Defining the Scope

Continuing with the code development capability, we see that this capability gets engaged in various kinds of activities. Listing some of them would be as below.

• Configuration

• Documenting the solution, including business process models

• System change management and transport management

• Data loads and data migration

• Testing

• Delivery of training and enablement

• Managing the project work

• Extending the solution

• Integration

Again, going by the way to address it, we need to break each activity down to its individual artifacts. This will help prioritize the adaptation. For a large team, this exercise will help. The priority action is the minimum the team should start with and then go to the follow-up activities. The chart below is representational of one such assessment. Every scope assessment story will be unique to its organization.

Representation of Capability Scope Assessment

Qualification of Factory Work Package

Eventually, everything in the organization that needs to be built through the Application Development team needs to go through the factory. But till then, when we are in transition (that could take me many months to stabilize), we need to have a mechanism that stands in as a gatekeeper. This workaround is called Solution-led Due Diligence.

Solution-led Due Diligence will determine and qualify the work package that will be delivered by the Factory-led Delivery team. A factory-assigned architect will need to be part of the diligence team. The diligence exercise will be signed off by the service delivery manager of the factory. The factory will define the input and exit criteria at every phase, adapt the factory tool chain and conduct quality gates.

Solution-Led Diligence Approach

Deployment of Virtual Squads

Factory PMO will deploy virtual squads comprising of a manager, architect, subject expert, developer, and testers. The factory will maintain a team based on capabilities towers. Monitoring and measurement of backlog and debt will be done by the project manager assigned for the engagement.

Demand forecasting would be done and capabilities towers will staff up for it. Resource utilization will be the key measure and job scheduling will be managed centrally. a program management office will be there to support the team in operations, monitor, measure, and manage.

Applications Development Factory Organizational Structure with Virtual SQUADS

Application Development Factory Roles

Find below an indicative table with various roles in the application development factory and their responsibilities.

Factory Roles and Responsibilities

Conclusion

The constituents of what make any Application Delivery team are Process, People, and Tools. Traditionally we have a project staffed up to meet the purpose and the program management office is focused on the net outcome. We overlook or do not prioritize the right kind of focus on the utilization of our investments, be it people or tools. Over time this customization becomes legacy, too complicated, and gathers lathery. To address the needs of 21st Century IT, we need an Omni Speed IT.

People bring in business knowledge, skill, and continuity to a program. No process can replace all people. While we can automate, shift left, and fail early, people are still pivotal to any execution. Talent is also a huge cost. And over time their fullest utilization can speed up value realization many times over.

Tools are the foundation of any project team. They are also easiest to manage as tools OEM keeps pace with delivery methodology. Its adaptation in the organization is about tailoring or configuring it to the delivery process. This is not a big challenge. Its adoption and successful usage determine its success.

Process changes are the most difficult. While one can adapt to the change in the delivery unit, its adoption is not always up to our desired outcome. Thus, we will look into how we can redesign the process. Here we studied a typical agile delivery process, and how we adapt our application development teams to it at scale.

By embracing the SAP Clean Core design principle, organisations can achieve a more agile, maintainable, and cost-effective SAP landscape, ensuring long-term success and adaptability in a rapidly changing business environment. You would need a trusted partner, a system integrator, who can service you in each of these discussed areas. Click on the link to know more about SAP Clean Core Strategy.

SAP S/4HANA Cloud Test Automation Tool in SAP S/4HANA Cloud Public Edition 2408

2024-08-02T07:46:44.597000+02:00

A major theme for the SAP S/4HANA Cloud Test Automation Tool Public Edition, over the past year, was to enable customers to do automation testing for all the extensions they build as part of the SAP S/4HANA Public Cloud Implementation. With the 2408 release we complete this arc of development.

Support for Custom API

Starting with the 2408 release, custom API’s created as part of Key User Extensibility and Developer Extensibility(Embedded Steampunk) facets of SAP S/4HANA Cloud can also be tested in the Test Automation Tool.

Custom API Support in API Automation Framework

This feature enables our end users to cover even custom API's created via extensions. The process is similar to the way we create SOAP and OData API's we create from the SAP Business Accelerator Hub. Communication arrangement and user created for the API can be re-used in the tool as well.

ABAP Units Dashboard Tile in AATR

ABAP Units Dashboard for PUT Executions

2402 release enabled customers to add ABAP Units to Post Upgrade Tests(PUT) as well. While in the previous release the only way to access the results were through the "Track PUT Results" pop-up immediately after the PUT run, we now persist the data in the ABAP Units dashboard created specifically for PUT executions in 3SL systems.

The results now can be accessed in the Analyse Automated Test Results(AATR) applications, details about the error reason, and coverage statistics from ABAP Development Tool(ADT) is provided.

ABAP Units Detail View

Additional Innovations

Enhanced Auto-binding for Test Data Container(TDC)
The auto-binding feature is enhanced, to utilize additional intelligence available from the Object Repository(OR), to match fields even when they do not have an exact text match. Maintenance and setting up of TDC is further simplified with this approach
Intelligent Test Scoper (i-TS) Advanced Filtering
i-TS application filters can now be used to further refine optimized scope and create Execution Variants in the Manage Upgrade Tests(MUT) application. Optimized scope can be defined based on Application Area (Finance, Sales etc.) or even Scope Item (BDG, BD9, J11 etc.) and selected for Post Upgrade Test(PUT) execution.
Intelligent Test Scoper(i-TS) Application
Intelligent Test Scoper (i-TS) Scope Efficiency Indicator
The scope efficiency gained with each update or upgrade can be seen using the "View Scope Efficiency" button in the application.

SAP Delivered Standard Automates

The total list of SAP delivered automated test scripts are 443 for 2408 and can be accessed via link – Automated Test Scripts Index”. This includes 27 new scope items which were added this release, detail below:

R&D/Engineering :  
Authoring of Product Compliance Documents (7DO)

Retail :
Product Taxonomy Management (5FJ), Inbound Processing Distribution Center (5FU), 
Outbound Processing Distribution Center (5FV), Replenishment Planning - Store (3I7), 
Replenishment Planning - Distribution Center (3I8), Location Management (3I3), 
Empties Management / Processing (5FK), Retail Logistics with Embedded Warehouse Management (69L), 
Seasons for Retail (6DI), Merchandise Distribution and Collective Purchase order (71O), 
Assortments (3I5)

Further detailed change information about the standard automate is available in the “Automated Test Script Change History” and “Test Script Release Change Information”.

Important Links and Updates

We have created a new Learning Hub course for an overview of the tool. This is a good starting point for anyone who is new to the tool, or want to get an overview of the new features we have added over the past couple of years. [Before you can access the link, a one-time registration in the SAP Learning Hub, edition for SAP Enterprise Support, is required. A detailed step-by-step guidance can be found here]

As part of our PUT 2.0 Enablement also we have created a set of short videos which cover the most important aspects of the process. The video playlist can be accessed here.

Links to other important blogs:

Please bookmark the test automation community page to keep up with the latest updates happening in the test automation space.

For more details on the functionality please refer the links below:

Intelligent Test Scoper (i-TS)
Manage Upgrade Tests
Manage Your Test Processes
Test Your Processes
Test Data Container
Analyze Automated Test Results
Configure Conditional Authentication
Also refer FAQs

--------------------------------------------------------------------------------------------------------------------------------------------------

Don’t hesitate to leave a comment and check out our community page to ask your questions and engage with the experts. Follow the PSCC_Enablement tag to stay up to date with our latest blog posts.

📽️ Watch the Replays of Our SAP S/4HANA Cloud Public Edition 2408 Early Release Series!

From July 8 to July 12, we hosted a series of 20 compelling live sessions to highlight the exciting innovations shipped with the SAP S/4HANA Cloud Public Edition 2408 release. Missed the live sessions? We've got you covered! Take advantage of the entire series or pick and choose the sessions most relevant to you. You will find a 15-minute-long recording and a presentation for the topic of the SAP S/4HANA Cloud Test Automation Tool under the SAP Activate, SAP S/4HANA Cloud Test Automation Tool, and SAP Cloud ALM as well as 19 other topics of interest. Don't miss this chance and watch them on demand–anywhere, anytime.

🔎Find All of Our Assets

SAP S/4HANA Cloud is the foundation of the intelligent, sustainable enterprise and is an innovative, robust, and scalable ERP. We at Cloud ERP Product Success and Cloud Co-Innovation offer a service as versatile as our product itself. Check out the numerous offerings our team has created for you below:

Release Navigator for SAP BTP - What's New in Q3 2024

2024-09-11T12:33:46.687000+02:00

The Release Navigator for SAP BTP is always evolving to better serve our customers. With the latest update in Q3 2024, in addition to quarterly content maintenance and a new product page we've made significant improvements to the user experience:

New Side Menu for improved page navigation
New UI Elements for additional context
New Search Feature

Read more about the details of these enhancements in this blog post.

This section details the new UX features added to the release navigator for SAP BTP.

New Side Menu for Easier Navigation

We've implemented a new side menu on every page of the release navigator to provide a more intuitive user experience. This menu allows easy navigation to the four new main pages of the release navigator:

Product Specific
General
Get Assistance
User Feedback

Fig 1. The side menu on all new pages

As a result, some content previously found on the Home page has been rearranged. Let’s walk through what you can find on each of the new pages.

Product Specific Page

This page serves as the starting point for the release navigator and corresponds to the former Home page. It contains the core of the release navigator: curated release information for specific products and services of SAP BTP as well as information on release schedules.

Fig 2. The Product Specific page, formerly known as the Home page

At the top of the Product Specific Page you can find a message tile with helpful information and a Release Calendar. The calendar includes release dates for SAP BTP as a whole, links to product-specific release schedules and dates for upcoming release navigator updates.

Below you can find the section Products. The cards in this section are sorted alphabetically and each one takes you to a dedicated page with in-depth information and curated resources on the 27 SAP BTP products and services covered.

Product Page Navigation

Fig 3. Example of a dedicated product page

Once you are done exploring the resources on a product page and want to move on to the next product or service, you can either click on Product Specific on the side-menu or on the back arrow on the left of the page title to get back to the Product Specific page and navigate to other pages.

General Page

On this page you can find General Resources that are helpful across all SAP BTP products and services. If you can't find a certain product or service on the Product Specific page, we recommend you check out the resources on this page (and also feel free to let us know in our survey).

Besides the General resources, there are two more sections on this page:

Additional Resources contains non-release specific but nevertheless important resources one should be aware of.
Release Navigators by SAP Enterprise Support provide direct links to all currently available release navigators for other solution areas.

Fig 4. The General page

Get Assistance Page

This page contains resources to help you use the release navigator and to improve your experience. You can access it from all pages in the release navigator by either clicking on Get Assistance in the side-menu or by clicking on the red bar at the very top of the page.

At the top of the page, you can find the following elements:

Release Navigator Enablement:
- SAP Community Blog Posts: These blog posts go into detail about new features that are being added to the release navigator and provide other news.
- SAP Partner Masterclass: This recorded digital session is only available to SAP partners.
Translation Feature: Allows you to translate the release navigator (not the pages linked to) into 40 languages. The translation process takes a few moments and may impact layout and design of the navigator pages. Click on this card to sign in to the authenticated version with Universal ID or an S-user account to use this feature.
User Feedback: Click here to provide feedback in a quick 3 question survey.

Below you can find the Navigation Tips, detailed instructions on how to use the release navigator, similar to the blog post you are reading now.

Fig 5. The Get Assistance page

User Feedback Page

We've embedded a feedback survey on this page with three short questions to gather feedback and suggestions for improvement.

Your relationship to SAP.
Whether you found the release navigator helpful.
An open text field that allows you to let us know anything you liked, what you would like to see added, or what you think could be improved.

We strive to always improve the release navigator, so we really appreciate any feedback you submit.

Fig 6. The User Feedback page

Helpful UI Elements

We added two new types of UI elements that you will find throughout the pages of the navigator.

Lightbulb icon

Many pages come with additional information to guide you through the cards available on that page and provide more context on when to use which resource.

If you see a lightbulb icon next to a header, you can hover over it with your cursor to open a text bubble with additional information about that page.

The bubble can be moved around by clicking and holding your cursor and can be closed by clicking the on the top right.Fig 7. Demo of the lightbulb icon text bubble

On product pages, the information displayed in this bubble corresponds to the information formerly found on Release Guidance tiles.

About this Card

Some resource cards come with additional tips and contextual information.

If you see three dots on the bottom right of a card, you can open a tip with additional information about that particular card. To open the link of that card, you need to close this tip by clicking the three dots button again.

Fig 8. Demo on the About this Card tips

Due to the high demand for dedicated pages for products and services, the number of pages to navigate has grown significantly since launch of the release navigator one year ago and we aim to increase the number of pages even further in future updates. More pages mean more content but also more cards to browse, which can increase the time it takes to find what you’re looking for.

Our goal is for you to find what you need as quickly as possible. That’s why we implemented a new Search Feature, which allows you to search for keywords and find all pages associated with this topic, product or service name. Click on the Search icon at the shell bar and a pop-up will open. Once you enter key words, you will see which pages are associated to this term and you can jump directly to them. The search feature is optimized for product and service names.

Fig 9. Short demo of the Search function.

We collaborated closely with SAP BTP experts to add a new page for SAP Continuous Integration and Delivery. This page contains links to the release schedule, SAP Roadmap Explorer, What’s New Viewer in the SAP Help Portal and more. Check it out.

Fig 10. The new page for SAP Continuous Integration and Delivery.

Currently, the release navigator for SAP BTP covers content for 27 products and services on dedicated pages. For all products and services not featured with their own page you can find helpful resources on the new General page.

Expect more new pages dedicated to specific products and services in future updates and don't hesitate to let us know via our feedback survey, which products or services you would like to see added next.

Last update, we announced the new SAP Note Consolidated Release Schedules for SAP BTP and the corresponding initiative of communicating the release schedules of SAP BTP products and services.

We are happy to report that the number of products and services who are communicating their release schedules has further increased to more than 50 now thanks to close collaboration with various SAP BTP teams.

Check the schedules here and from the Release Calendar section of the navigator.

Tip: Did you know you can mark notes as a favorite? If you do so, you will be notified via email whenever the note is being updated. This way you can stay on top of new release schedule communication, like new dates or skipped waves. We recommend you mark all those notes as a favorite that you are interested in receiving updates for.

Fig 11. Where to click to mark a note as a favorite and receive notifications once it gets updated.

Please note: To access SAP Notes you need to log in to SAP for Me using your Universal ID or S-user ID. Read more about the required authorizations here.

Next updates are scheduled on a quarterly basis in alignment with the Harmonized Release Calendar for SAP Cloud Products.*Disclaimer: The schedule is subject to change without prior notice including, when necessary, delays or incorporating changes in subsequent update windows and not a commitment, promise, or legal obligation to deliver any material, code, or functionality.Looking ahead, 2025 updates will mainly focus on quarterly maintenance of release resources and a steady extension of product coverage. Currently, there are no plans for further mayor UI updates in the near future.

The Readiness@Scale team at SAP Enterprise Support is dedicated to ensuring release readiness across the SAP Enterprise Support portfolio. Our mission is to empower SAP customers to be prepared and ready to adopt and utilize innovations.

If you have any feedback or specific requests for content in the release navigator, please don't hesitate to reach out to us.

And don't forget to check out our team's blogs tagged with Readiness@Scale.

Happy navigating!

Readiness@Scale
SAP Enterprise Support

DevOps with SAP BTP hands-on videos now on SAP Learning

2024-11-12T11:34:37.212000+01:00

In 2021, our colleague @pmugglestone had created a series of hands-on tutorial videos that helped many learners to set up SAP BTP to apply DevOps principles for application development (announcement blog post from that time). As the videos provide a holistic end-to-end view on how to set up the involved SAP BTP services in detail, we still see value in providing those videos, even if some aspects might be outdated. As a result, we now migrated them to SAP Learning.

Please note that the videos were originally published on the SAP HANA Academy YouTube Channel and therefore may contain references to SAP HANA Academy and YouTube that are no longer valid. Also, updates and additional links are provided in the description of several of the videos, so please use them with caution and make sure to check out their full description, as marked in below's screenshot of an example video:

Example of additional information provided in video descriptions

Here the links to the videos on SAP Learning, in the right order:

Title and Link	Description
Introduction	Introduction to DevOps with SAP BTP, incl. SAP BTP service entitlements used during the scenario
Getting Started	Get an idea on how to configure a developer landscape in SAP BTP
Develop Application	Usage of SAP Business Application Studio, cloning of a Git repository
SAP Continuous Integration and Delivery service	Learn how to configure and use SAP BTP's Pipeline-as-a-Service offering
SAP Cloud Transport Management Pt 1	Here, transport management is getting set up, incl. subscription and creation of SAP BTP subaccounts
SAP Cloud Transport Management Pt 2	Creation of destinations to source and target nodes, setup of transport landscape, interplay of pipeline with transport management
SAP Cloud Transport Management Pt 3	Handling of the transport along the transport landscape
SAP Alert Notification service for SAP BTP	Learn how to use SAP Alert Notification service to automatically send a message to a selected Slack channel whenever transport management starts or finishes an import
SAP Automation Pilot Pt 1	Learn how to set up a smoke test using SAP Automation Pilot
SAP Automation Pilot Pt 2	Part two of setting up the smoke test that gets executed automatically whenever transport management finishes an import, incl. sending of a status message to your preferred Slack channel

Release Navigator for SAP BTP - What' s New in Q4 2024

2024-12-05T09:42:15.938000+01:00

The Release Navigator for SAP BTP is always evolving to better serve our customers. With the latest update in Q4 2024, in addition to quarterly content maintenance we have added new product pages.

We collaborated closely with SAP BTP experts to add three new product pages that consolidate links to all available release communication channels, like schedules, pre- and post-release communication, blogs, and more.

The new pages are:

SAP BTP, Kyma runtime
SAP Mobile Services
SAP Translation Hub

Read more about the details in this blog post.

1. SAP BTP, Kyma runtime

This page contains links to release schedule information, SAP Roadmap Explorer, What’s New information in the SAP Help Portal, links to the SAP Community, documentation on releases and available modules, the GitHub Kyma repositories, as well as a helpful learning journey and hands-on tutorials.

Check it out.

Fig 1. The new page for SAP BTP, Kyma runtime.

2. SAP Mobile Services

This page contains links to release schedule information, SAP Roadmap Explorer, What’s New information in the SAP Help Portal, links to the SAP Community, and helpful documentation.

Check it out.

Fig 2. The new page for SAP Mobile Services.

3. SAP Translation Hub

This page contains links to release schedule information, SAP Roadmap Explorer, What’s New information in the SAP Help Portal, links to the SAP Community, and helpful documentation.

Check it out.

Fig 3. The new page for SAP Translation Hub.

Currently, the release navigator for SAP BTP covers content for 30 products and services on dedicated pages. For all products and services not featured with their own page you can find helpful resources on the new General page.

Please note that the product page for SAP Data Intelligence Cloud has been retired as of this update. For more information, you can refer to this blog post.

For centralized information on when SAP BTP products and services release new features refer to the Consolidated Release Schedule for SAP BTP.

Regarding Release Navigator updates, you can refer to this update plan:

*Disclaimer: The schedule is subject to change without prior notice including, when necessary, delays or incorporating changes in subsequent update windows and not a commitment, promise, or legal obligation to deliver any material, code, or functionality.

Looking ahead, 2025 updates will mainly focus on quarterly maintenance of release resources and a steady extension of product coverage. Currently, there are no plans for further mayor UI updates in the near future.

If you have any feedback or specific requests for content in the release navigator, please don't hesitate to reach out to us.

And don't forget to check out our team's blogs tagged with Readiness@Scale.

Happy navigating!

Readiness@Scale
SAP Enterprise Support

Update of SAP Learning Journey on DevOps with SAP BTP

2025-01-07T15:31:28.880000+01:00

Happy to announce that the learning journey Discovering DevOps with SAP BTP has received a major overhaul that went live in SAP Learning end of December 2024. Besides applying the latest branding and style changes, updates of single services and their interplay have been considered.

Screenshot of learning journey

For example, concerning pipeline flexibility of SAP Continuous Integration and Delivery service, the new integration option of SAP Cloud Transport Management into SAP Cloud ALM, or the Generative AI assistant of SAP Automation Pilot service (described in a new lesson at the end of unit 3).

Example use case for GenAI assistant of SAP Automation Pilot

Although new content has been provided, we intentionally strived to keep the learning content on beginner level. Still, also more advanced leaners should be able to benefit from the update.

If you should be interested on how to make use of agile DevOps principles for your projects on SAP BTP, this would be the opportunity to get your jump start into the offering! You can go through the whole journey or only consume those lessons you are interested in. Give it a try here, free-of-charge.

SAP S/4HANA Cloud Test Automation Tool in SAP S/4HANA Cloud Public Edition 2502

2025-01-28T06:57:04.210000+01:00

We are excited to announce significant enhancements in Post Upgrade Testing (PUT) with the 2502 release of the Test Automation Tool for SAP S/4HANA Cloud, Public Edition. Key features include:

New Post-Upgrade Test Application

A new PUT app with an intuitive dashboard for clear test execution metrics.
One-click navigation between PUT-related applications.
Advanced comparison capabilities for different PUT runs.
Enhanced contextual information for triggering and tracking PUT executions.
Consolidated access to essential PUT actions like consent management and role maintenance.

Intelligent Test Scoper(i-TS) App Enhancements:

Improved analytics within the Intelligent Test Scoper (i-TS) app for optimized scope efficiency.

These enhancements aim to provide more efficient, user-friendly applications that facilitate smooth upgrades of the SAP S/4HANA Cloud environment.

PUT App - Dashboard view

PUT Results Comparator

The PUT results comparator enables detailed analysis between different PUT runs. Key features include:

· Compare execution variants within the same release or across different releases.
· View results side-by-side for easy comparison.
· Navigate to detailed logs of both failed and successful runs.

Trigger and Track PUT - Analytics

Post Upgrade Tests are triggered via the Trigger functionality and latest executions can be tracked via the Track functionality. Along with the Post Upgrade Test Execution summary, the following information can be viewed for the latest run.

Execution scope
Pre check status
Execution distribution with and without TDC
Distribution of test processes based on failure categories

Consent Management for Post Upgrade Tests

Enhanced user experience with the new change history feature introduced where the user can track consent change information such as

Release information
Consent changed by
Consent changed on

Please note: For a new customer the PUT Consent will be set to "Yes" by default.

Intelligent Test Scoper(i-TS) App Enhancements

End users will be able to quickly check the efficiency gains from utilizing the optimized test scope for PUT.
A more detailed application area-wise optimization gains is also provided.

SAP Delivered Standard Automates

The total list of SAP delivered automated test scripts are 448 for 2502 and can be accessed via link – Automated Test Scripts Index”. This includes 5 new scope items which were added this release.

Further detailed change information about the standard automate is available in the “Automated Test Script Change History” and “Test Script Release Change Information”.

Important Links and Updates

We have created a new Learning Hub course for an overview of the tool. This is a good starting point for anyone who is new to the tool or want to get an overview of the new features we have added over the past couple of years. [Before you can access the link, a one-time registration in the SAP Learning Hub, edition for SAP Enterprise Support, is required. A detailed step-by-step guidance can be found here]

As part of our PUT 2.0 Enablement also we have created a set of short videos which cover the most important aspects of the process. The video playlist can be accessed here.

Links to other important blogs:

Please bookmark the test automation community page to keep up with the latest updates happening in the test automation space.

For more details on the functionality please refer the links below:

Post-Upgrade Tests App
Intelligent Test Scoper (i-TS)
Manage Upgrade Tests
Manage Your Test Processes
Test Your Processes
Test Data Container
Analyze Automated Test Results
Configure Conditional Authentication
Also refer FAQs

------------------------------------------------------------------------------------------------------------------------------------------------

Don’t hesitate to leave a comment and check out our community page to ask your questions and engage with the experts. Follow the PSCC_Enablement tag to stay up to date with our latest blog posts.

🎥Watch the Replay of Our SAP S/4HANA Cloud Public Edition 2502 Early Release Series!

Between January 21 and January 24, we conducted a series of 21 engaging live sessions to showcase the thrilling innovations included in the SAP S/4HANA Cloud Public Edition 2502 release. If you missed the live sessions, don't worry! You can still access the whole series or select the sessions that interest you the most. Seize this opportunity to watch them on demand at your convenience–anywhere, anytime.

🔍Find All of Our Assets 

New Use Cases for SAP Connectivity in SAP Continuous Integration and Delivery

2025-02-24T10:24:39.474000+01:00

Developers today often face complex network topologies. You may be using a cloud service to run your continuous integration jobs, but important assets like source code or binary repositories could still be within your corporate network.

The SAP Continuous Integration and Delivery service was designed with this challenge in mind. From the beginning, we integrated the SAP Connectivity service to allow cloning of source code from on-premises repositories. Later, we added more features:

Connecting to on-premises Sonar code scanners
Deploying on ABAP systems

Now, we have taken it one step further, enabling you to use the connectivity feature in your own scripts and configurations. As an example, I will describe how to use an on-premises npm registry.

But before we dive into that, I would like to explain how Connectivity is integrated into the Continuous Integration and Delivery service.

Connecting It All

When your continuous integration (CI) build interacts with the outside world, whether to fetch a source file, download a dependency, post a report, or perform other actions, this interaction generally involves sending an HTTP request.

If your request needs to reach an on-premises system, certain requirements must be met for Connectivity to work properly. Assuming that your target system is configured in your cloud connector, the request must:

Be sent via a specific proxy.
Contain custom HTTP headers, allowing Connectivity to authenticate and route the request.

However, not every tool allows for the setting of arbitrary HTTP headers. Therefore, we decided to use a proxy whose task is to accept HTTP requests, add the required headers, and forward the requests to the Connectivity service.

If your job is configured to use Connectivity (via a credential representing a Cloud Connector), this proxy will run in a container within the run environment of your build and wait for incoming requests. Note that this environment is not accessible from the outside world, ensuring that only your containers can send requests to the proxy.

Here is a diagram visualizing this setup:

Example: Using an On-Premises npm Registry

Enough theory; let's work through a real use case. Consider the following scenario:

We want to build a JavaScript application using npm. The problem is that the application has dependencies defined in its `package.json` which are located in an npm registry hosted by your company, and this registry is not accessible from the internet.

We'll assume for this scenario that all the dependencies can be fetched from that corporate registry. It is a common practice to have corporate registries that mirror registry.npm.org. This setup allows you to maintain copies of your open-source dependencies which you can then scan. Additionally, your build process no longer depends on the availability of registry.npm.org.

Let's go through the setup step by step.

Prerequisites

You have a Cloud Connector running in your corporate network.
You have a subscription of the SAP Continuous Integration and Deliver Service.

Prepare the Cloud Connector

Add the account where the SAP Continuous Integration and Delivery service is subscribed to your Cloud Connector.
This is described in the Cloud Connector Documentation.
In the Cloud Connector, under "Cloud To On-Premise", add your private registry.
The configuration should look something like this:

Configure the Continuous Integration and Delivery Service

In the UI of the service:

Create a Cloud Connector Credential:
First, create a Cloud Connector credential containing the location ID of your cloud connector. Name this credential connector.
Create a Job for Building/Testing/Deploying Your Project:
Next, create a job to build, test, and deploy your project. We want to use the on-premises registry during the build stage. To achieve this, add the connector credentials as an additional credential to that stage.
This configuration will ensure that during the build execution, an environment variable CONN_PROXY will be available, holding the URL of the proxy.
Example Build Stage:
Configure Additional Variables:
In addition, configure the following additional variables:
- NPM_CONFIG_LOGLEVEL: info: This makes npm print more detailed information about what it is doing.
- NPM_CONFIG_USERCONFIG: .cicd_npmrc: This makes npm use an npmrc file named .cicd_npmrc located in the project root.
The last setting is particularly useful because it avoids altering the local build process of the project.

Prepare the Project

The only thing you need to do in the project is to add the npmrc file to be used in the central build. As mentioned above, the name should be .cicd_npmrc. Here is my file:

registry=http://on-prem-registry/
proxy=${CONN_PROXY}
replace-registry-host=always

Let's got through this line by line.

registry=http://on-prem-registry/: Here, I define the registry to be used. I refer to the registry by the virtual host name configured in the Cloud Connector. A port is not required because I used port 80, which is the standard port for the HTTP protocol. Note that I use HTTP and not HTTPS. This is due to a limitation of our current connectivity setup. However, it is not as bad as it sounds. Once the data reaches the proxy, it will be transmitted via an encrypted tunnel to the Cloud Connector.
proxy=${CONN_PROXY}: This defines that the proxy should be used. The actual URL is injected by the service. In practice, it will look like http://10.0.0.3:5003, where the port is mapped to the location ID of the Cloud Connector.
replace-registry-host=always: This is needed to avoid trouble with the package-lock.json files (in the project as well as in the dependencies). The package-lock.json is generated locally and contains registry URLs pointing to npm-registry.sap-dev.corp, the actual hostname of our internal registry. For the central build, another hostname (on-prem-registry) will be used, therefore the hostname has to be replaced.

That is all. Here is an excerpt from the build stage logs:

[2025-02-14T16:03:32.499Z] info  npmExecuteScripts - Discovered package.json file package.json
[2025-02-14T16:03:32.499Z] info  npmExecuteScripts - running command: npm config get registry -ws=false -iwr
[2025-02-14T16:03:32.500Z] info  npmExecuteScripts - npm info using npm@10.8.2
[2025-02-14T16:03:32.501Z] info  npmExecuteScripts - npm info using node@v20.17.0
[2025-02-14T16:03:32.501Z] info  npmExecuteScripts - npm info ok
[2025-02-14T16:03:32.501Z] info  npmExecuteScripts - Discovered pre-configured npm registry registry with value http://on-prem-registry/
[2025-02-14T16:03:32.501Z]
[2025-02-14T16:03:32.501Z] info  npmExecuteScripts - Running Install
[2025-02-14T16:03:32.501Z] info  npmExecuteScripts - running command: npm ci
[2025-02-14T16:03:32.762Z] info  npmExecuteScripts - npm info using npm@10.8.2
[2025-02-14T16:03:32.762Z] info  npmExecuteScripts - npm info using node@v20.17.0
[2025-02-14T16:03:33.688Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/@sap/xsenv/-/xsenv-4.2.0.tgz 725ms (cache miss)
[2025-02-14T16:03:33.688Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/@sap/e2e-trace/-/e2e-trace-4.1.0.tgz 766ms (cache miss)
[2025-02-14T16:03:33.948Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/@sap/logging/-/logging-7.1.0.tgz 910ms (cache miss)
[2025-02-14T16:03:34.204Z] info  npmExecuteScripts - npm http fetch POST 200 http://on-prem-registry/-/npm/v1/security/advisories/bulk 372ms
[2025-02-14T16:03:34.764Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/verror 739ms (cache miss)
[2025-02-14T16:03:34.764Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/ms 742ms (cache miss)
[2025-02-14T16:03:34.764Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/once 857ms (cache miss)
[2025-02-14T16:03:35.020Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/core-util-is 919ms (cache miss)
[2025-02-14T16:03:35.020Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/clone 932ms (cache miss)
[2025-02-14T16:03:35.020Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/wrappy 936ms (cache miss)
[2025-02-14T16:03:35.021Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/extsprintf 964ms (cache miss)
[2025-02-14T16:03:35.021Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/moment 967ms (cache miss)
[2025-02-14T16:03:35.021Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/once 973ms (cache miss)
[2025-02-14T16:03:35.021Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/assert-plus 983ms (cache miss)
[2025-02-14T16:03:35.021Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/next-line 988ms (cache miss)
[2025-02-14T16:03:35.021Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/next-line 986ms (cache miss)
[2025-02-14T16:03:35.021Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/wrappy 1025ms (cache miss)
[2025-02-14T16:03:35.022Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/wtfnode/-/wtfnode-0.9.1.tgz 1025ms (cache miss)
[2025-02-14T16:03:35.022Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/ws/-/ws-7.5.10.tgz 1026ms (cache miss)
[2025-02-14T16:03:35.022Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/request-stats 1030ms (cache miss)
[2025-02-14T16:03:35.022Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/yallist/-/yallist-2.1.2.tgz 1030ms (cache miss)
[2025-02-14T16:03:35.023Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/wrap-ansi/-/wrap-ansi-7.0.0.tgz 1036ms (cache miss)
[2025-02-14T16:03:35.023Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/wrappy/-/wrappy-1.0.2.tgz 1037ms (cache miss)
[2025-02-14T16:03:35.023Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/request-stats 1055ms (cache miss)
[2025-02-14T16:03:35.023Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/wrap-ansi/-/wrap-ansi-8.1.0.tgz 1051ms (cache miss)
[2025-02-14T16:03:35.023Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/which/-/which-2.0.2.tgz 1076ms (cache miss)
[2025-02-14T16:03:35.024Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/whatwg-url/-/whatwg-url-5.0.0.tgz 1076ms (cache miss)
[2025-02-14T16:03:35.024Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/winston-transport/-/winston-transport-4.9.0.tgz 1080ms (cache miss)
[2025-02-14T16:03:35.024Z] info  npmExecuteScripts - npm http fetch GET 200 http://on-prem-registry/webidl-conversions/-/webidl-conversions-3.0.1.tgz 1080ms (cache miss)

As intended, the dependencies are being pulled from our internal registry.

Outlook and Next Steps

At this point, you should have realized that Connectivity can now be used in each stage and even in your custom scripting through the Additional Commands feature.

From Continuous Integration and Delivery side, the next Connectivity related feature we will take on is supporting the SOCKS protocol. This will eliminate the current restriction against using HTTPS and enable advanced scenarios such as combining mTLS with Connectivity.

SAP BTP: Cloud Application Programming Model

2025-03-04T07:09:41.141000+01:00

SAP Cloud Application Programming (CAP) Model exposes the ability to extend standard Cloud, on-premises and hybrid application functionality with flexible custom business logic scripted using the developer’s choice of programing language (SQL, SQL Script, Python, Node.js and JavaScript) and exposing the functionality to various user interfaces (UIs) e.g. Microsoft Power Bi, SAP Fiori, Dataiku and Google Big Query using various integration frameworks e.g. OData v4,JDBC/ODBC depending on the case study.

The developer takes pride in delivering a scalable extended functionality, embedding robust real-time monitoring capabilities to ensure a health life cycle and protecting the functionality with secure authentication protocols e.g. OAuth 2.0, JWT Bearer, SAML version 2.0 and RFC Specification.

Furthermore, the developer ensures a reliable and robust solutions by implementing continuous integration and continuous delivery CI/CD pipelines that automates testing, building and deployment of code changes this strategy ensures a speedy development and delivery cycle.

Traditionally developers extended business logic directly on-premises on the ABAP application server. With the ever-changing world of technology, digital transformation has become essential for organization to say afloat of competitors and therefore the programming model paradigms and capabilities of extending SAP solutions have evolved drastically and provides a seamless experience into the cloud.

Figure 1:

Architectural Paradigm Shift from Classic ABAP App server to CAP App server

Source: Thomas Jung, SAP HANA Extended Application Services blog, URL: https://community.sap.com/t5/technology-blogs-by-sap/sap-hana-extended-application-services/ba-p/12963426/page/4

The SAP Cloud Application model comes with a rich set of languages, libraries, and tools for building enterprise-grade services and applications. It guides developers along a 'golden path' of proven best practices and a great wealth of out-of-the-box solutions to recurring tasks:

Figure 2:

SAP Cloud Application Model Architecture

Source HTTPS://Cap.cloud.sap , URL: https://cap.cloud.sap/docs/about/

The below diagram categories the skill set of SAP Cloud Developer based on the scope of the development either being ABAP or Non-ABAP. Each with its unique set of tools and methodologies:

Figure 3:

SAP Cloud Developer skill set

Source: Building side-by-side extensions on SAP BTP, URL: https://learning.sap.com/learning-journeys/build-side-by-side-extensions-on-sap-btp/identifying-the-need-for-side-by-side-extensibility_f1e838f0-f02a-43b4-8896-cedc25a7d5d0

The Cloud Application Programming model enables a collaboration of agile cross functional teams inclusive of but not limited, depending on the scope of the development: citizen developers (low-code/no-code), Professional developers (Scripting, OOP), business analysts, data engineers and application specialists to model robust data models:

Figure 4:

Agile cross functional team

Source: Investigating the Impact of Cross-Functional Teams on Business Success

URL: https://www.iienstitu.com/en/blog/cross-functional-teams

SAP Cloud Application Programming (CAP) Model enables a culture where people regardless of their title or background, work together to imagine, develop, deploy, and operate a solution. This strengthens the trust between employees and authentic healthy work relationships.

Thank you all for taking a glimpse into the above Content. Please don’t for get to like, comment and share.

Abbreviations:

APP: Application

CAP: Cloud Application Programing

CDS: Core Data Services

CI/CD: Continuous Integration and Continuous Delivery

JWT: JSON Web token

OData: Open Data Protocol

RFC: Remote Function Call

SAML: Security Assertion Markup Language

SQL: Structured Query Language

UIs: User Interfaces

SAP Master Data Integration (MDI): Architecture, Deployment, and Seamless Connectivity

2025-03-13T06:56:15.537000+01:00

In today’s digital landscape, businesses rely on multiple interconnected systems to manage operations, from finance and supply chain to customer relationship management. However, maintaining consistent and accurate master data across these systems can be challenging. SAP Master Data Integration (MDI) addresses this challenge by providing a unified framework for seamless data synchronization across SAP and non-SAP applications. By leveraging MDI, organizations can ensure data consistency, improve efficiency, and reduce integration complexities.

What Is SAP Master Data Integration (MDI)?

In the era of the Intelligent Enterprise, seamless data connectivity is essential for ensuring operational efficiency. SAP Master Data Integration (MDI) is a powerful, multi-tenant cloud service designed to act as a central hub for managing and synchronizing master data across various applications.

By integrating with SAP MDI, applications can maintain consistency by syncing their local master data repositories with a centralized master data database. Typically, each enterprise landscape is assigned a single MDI tenant, ensuring a unified and consistent view of master data across all connected systems.

Unlike traditional master data management solutions, SAP MDI focuses exclusively on integration. It facilitates the replication of master data records, allowing applications to perform initial data loads and continuously stay synchronized with the central database. Administrators have full control over data synchronization, enabling them to define integration rules, monitor replication processes, and ensure compliance with data protection and privacy regulations.

With SAP Master Data Integration, businesses can eliminate data silos, improve data accuracy, and create a streamlined digital ecosystem where applications communicate effortlessly.

Current Architecture

* Does not cause any additional costs for customers having a BTP Global Account integrating SAP-branded cloud solutions, ready-to-use integration, standard for SAP-branded cloud applications

** Utilize SAP Integration Suite when ready-to-use integration is not available

*** Current integration of CX solutions mostly via SAP Integration Suite (direct integration on roadmap)

SAP Master Data Integration (MDI) is designed to act as a central hub for seamless master data synchronization across various enterprise applications. Its architecture ensures that both SAP and non-SAP systems can efficiently exchange master data while maintaining consistency across the entire IT landscape.

Direct Integration with SAP Cloud Applications

MDI directly integrates with several SAP Cloud applications using pre-built SAP MDI Adapters. These adapters enable a smooth and standardized data flow between MDI and the following SAP solutions:

SAP Field Service Management (FSM)
SAP SuccessFactors
SAP S/4HANA (Public & Private Cloud)
SAP Master Data Governance (MDG) Cloud
SAP Fieldglass
SAP Ariba
SAP Customer Experience (CX)

Since these applications are built to work with SAP MDI, they can directly exchange master data without requiring additional middleware.

Integration with Non-SAP Applications and SAP ECC Systems

For legacy SAP ECC systems and non-SAP applications, direct connectivity to MDI is not available. Instead, SAP Cloud Platform Integration (CPI) acts as a middleware, facilitating communication between these systems and MDI. SAP CPI includes an MDI Adapter, which enables:

Secure and scalable integration of ECC and third-party applications with MDI.
Transformation and enrichment of master data before synchronization.
A flexible approach to integrate on-premise and hybrid cloud landscapes.

This hybrid architecture ensures that both modern cloud-based applications and traditional on-premise systems can participate in a unified master data strategy, reducing data silos and improving consistency across the enterprise.
Feature Scope Description can be found here: MDI Feature Scope
Information on Pricing can be found here: MDI Service Pricing
System Limitations can be found here: MDI System Limitations
More Feature info can be found here: MDI Features

What is SAP One Domain Model?

SAP One Domain Model is a standardized, common model for business objects across various SAP solutions. By aligning master data structures across SAP applications, ODM facilitates deep, out-of-the-box integration, simplified extensions, and consistent APIs for the SAP Intelligent Enterprise.

Key Features of SAP One Domain Model

✅Unified Data Structure: Provides a harmonized representation of business objects, ensuring consistency across different SAP applications.
✅Standardized Integration: Enables seamless data exchange between applications like S/4HANA, SAP SuccessFactors, Ariba, Fieldglass, and Customer Experience solutions.
✅Core Data Services (CDS) Based Definitions: The model definitions are written in Core Data Services (CDS), forming the foundation for a consistent data view across hybrid landscapes.
✅Foundation for Integration & Analytics: Aligns configurations, master data, and transactional data, enabling robust integration, extension, and analytics scenarios.

By adopting SAP One Domain Model, organizations can eliminate data inconsistencies, streamline integration efforts, and create a cohesive digital enterprise where applications interact seamlessly.

All supported Integration Models can be found here:
Integration Models

Getting Started with SAP Master Data Integration (MDI): A Simple Guide

SAP Master Data Integration (MDI) helps businesses ensure seamless master data synchronization across multiple applications. While the technical implementation requires expertise, understanding the initial setup helps organizations plan and prepare for MDI adoption.

Pre-requisites

Before setting up MDI, the following are required:
✅SAP BTP Global Account – This is the foundation for accessing SAP cloud services.
✅SAP BTP Sub-account – A sub-account in the appropriate region where MDI is available:

Europe (Frankfurt) – EU10, EU11
US East (Virginia) – US10
Australia (Sydney) – AP10
Singapore – AP11
China – CN40
✅Spaces in Sub-account – Organizational units where services like MDI are deployed.

Initial Setup Steps

1️⃣Create a Tenant

Each sub-account can have one MDI tenant.
A tenant is created when you subscribe to the SAP Master Data Integration Tenant application.
Each service instance within a sub-account connects to a client (e.g., S/4HANA, SuccessFactors).
Best Practice:
- For production, create one MDI tenant to ensure data consistency.
- For a three-system landscape (Development, Test, Production), use three separate tenants to prevent unintended data sharing.

2️⃣Create a Service Instance

For every application you connect, a dedicated service instance must be created from the SAP BTP marketplace.
After creating a service instance, set up a service binding to generate credentials for connectivity.
You can generate multiple credentials for an application by creating additional service bindings.

3️⃣Configure the Client

Define configuration details for each connected application.
Key attributes include:
✅Business System ID
✅Write Permissions
✅Global Tenant ID
✅logSys (Logical System)

4️⃣Generate Service Keys

After configuring the service instance, generate a service key.
The service key is needed for authentication and establishing connectivity between SAP MDI and applications like S/4HANA, SuccessFactors, or Ariba.

5️⃣Configure Master Data Orchestration/Business Data Orchestration

Use Business Data Orchestration to manage master data replication.
This allows you to:
✅Define distribution models for data replication.
✅Add extension fields to customize data attributes.
✅Monitor the distribution status of master data.

Please note, additional steps would be required to SOAP Applications, like additional distribution models in MDO, creating and configuring Destinations. This would be required for objects like Business Partners.
Also for connecting S/4HANA Cloud or Cloud Applications Based on the SAP BTP ABAP environment, we would require to create communication arrangements (SAP_COM_0659) , (SAP_COM_0594) , Create destinations for MDO and Setup Distribution Models.

What’s Next?

Once MDI is set up, your applications can start synchronizing master data efficiently. To ensure smooth operations, businesses should work closely with their IT teams or SAP partners for technical implementation, monitoring, and optimization.

More Blogs:
SAP MDI: SAP S/4HANA Business Partner Replication using DRF Customizing - SAP Community
SAP Master Data Integration (MDI) – Bank and Cost ... - SAP Community

How to Run Black Duck Scans in SAP Continuous Integration and Delivery Jobs

2025-03-18T10:44:35.063000+01:00

In today's software development landscape, integrating security scans into your continuous integration and delivery (CI/CD) pipelines is a best practice. An automated process quickly identifies vulnerabilities and ensures that your software is secure. One essential tool for achieving this level of security is Black Duck. This tool performs comprehensive scans of your codebase and its open-source dependencies, helping to identify potential security vulnerabilities, license compliance issues, and code quality problems.

In this blog, I'll walk you through the process of integrating Black Duck scans into your SAP Continuous Integration and Delivery jobs. By creating a custom command for Black Duck scans, you can actively detect and address risks before they compromise your software, ensuring a more secure and reliable product. Let's dive into the steps required to achieve this integration and enhance your CI/CD pipeline with robust security measures.

Prerequisites

SAP BTP Access:
Ensure that you have access to SAP BTP and verify that you have the necessary entitlements for the SAP Continuous Integration and Delivery service. See Initial Setup.
Black Duck Access:
Make sure you have access to a Black Duck server and have your API token available.
Git Repository:
You need a Git repository connected to SAP Continuous Integration and Delivery. See Add a Repository.

Procedure

1. Prepare Your Script

We'll use a bash script to run a Black Duck scan. This script installs the necessary Java Runtime Environment (JRE), downloads the Black Duck Detect tool, and then executes the scan.

Here’s the script we'll use:

#!/bin/bash
set -eu

# Runs Black Duck scan in current directory after downloading Java 
# and Synopsys Detect script.

JRE_VERSION="21.0.5" 
JRE_TAR="sapmachine-jre-${JRE_VERSION}_linux-x64_bin.tar.gz"
JRE_URL="https://github.com/SAP/SapMachine/releases/download/sapmachine-$JRE_VERSION/$JRE_TAR"

DETECT_URL="https://detect.synopsys.com/detect10.sh" 

install_jre() {
  echo "Downloading and installing sapmachine from $JRE_URL"
  
  wget --quiet $JRE_URL -O - | tar -xzf -

  export JAVA_HOME=$(pwd)/sapmachine-jre-${JRE_VERSION}
  $JAVA_HOME/bin/java -version

  echo "Java installation complete."
}

download_detect_tool() {
  echo "Downloading Black Duck Detect tool from $DETECT_URL"

  wget --quiet $DETECT_URL -O detect.sh
  chmod +x detect.sh
  
  echo "Black Duck Detect tool download complete."
}

run_blackduck_scan() {
  echo "Running Black Duck scan..."

  ./detect.sh --blackduck.url="$BD_SERVER" --blackduck.api.token="$BD_API_TOKEN" --detect.project.name="$BD_PROJECT_NAME" --detect.project.version.name="$BD_PROJECT_VERSION"
  echo "Black Duck scan completed."
}

# Main script execution
install_jre
download_detect_tool
run_blackduck_scan

2. Upload the Script to Your Repository

Add your script to the repository containing your project source code.

3. Add Additional Commands to Your Job

In SAP Continuous Integration and Delivery, either create a new job or navigate to the job to which you want to add additional commands and choose Edit.
In the Compliance stage section of your job, choose + next to Additional Commands. This allows you to introduce a custom script.
Choose either Run First in Stage or Run Last in Stage to execute the scan in relation to other tasks.
In the Command text field. enter the following command to execute your script:
```
bash path/to/your/blackduck_script.sh
```
Replace path/to/your/blackduck_script.sh with the actual path to your script in the repository.
Confirm your changes.

4. Add Additional Variables to Your Job

The script uses a couple of variables provided in the environment, so you don't need to adjust the script for your jobs. Instead, we will set these variables using the Additional Variables feature.

In the Compliance stage section of your job, choose + next to Additional Variables. This opens the Add Variables pop-up.
Add the following variables one after the other:
- BD_SERVER: Your Black Duck server URL.
- BD_PROJECT_NAME: The name of your project in Black Duck.
- BD_PROJECT_VERSION: The version of the project you are scanning.

These variables will be used as parameters for the detect.sh script.

5. Add Additional Credentials to Your Job

In the Compliance stage section of your job, choose + next to Additional Credentials and add the following credential to access your Black Duck server:

BD_API_TOKEN: Your Black Duck API token.

6. Test Your Configuration

Once the setup is complete, trigger your pipeline either manually or by committing new code to your repository. Monitor the pipeline to ensure the Black Duck scan executes properly and review the logs for any errors or output from the scan.

Conclusion

With these steps, you've successfully integrated Black Duck scans into your SAP Continuous Integration and Delivery pipeline. You've empowered your development process with a robust security mechanism that proactively identifies vulnerabilities and maintains code quality. By automating these scans, you can focus on delivering secure, reliable software faster. Stay ahead of potential threats and ensure your software meets the highest security standards with this seamless integration. Happy secure coding!

SAP Cloud Transport Management System Setup for Transporting SAP Build Work zone Objects

2025-03-20T18:30:58.113000+01:00

Overview :

The Cloud Transport Management System (cTMS) in SAP Business Technology Platform (BTP) automates software changes across different cloud environments. This tool streamlines the process of moving changes from development to testing and production environments, making it valuable for SAP customers using cloud-based development practices.

Overview of Setting Up Cloud Transport Management for SAP Build Work Zone:

SAP Build Work Zone (formerly known as SAP Launchpad service) creates personalized, role-based entry points for accessing SAP and non-SAP applications. When implementing Cloud Transport Management (cTMS) for SAP Build Work Zone, you can efficiently manage content transport—including roles, catalogs, and apps—across development, test, and production environments.

Example Transport Structure Scenario :

In this Blog, I have taken a setup of 2 tier landscape of Transport management for SAP Build Work zone Standard edition existing in Subaccounts that belong to different global accounts.

Implementation Steps for Cloud Transport Management with SAP Build Work Zone

Set Up SAP Build Work Zone Instances:
Subscribe to Cloud Transport Management Service (cTMS)
Configure Destinations
Create Transport Nodes in cTMS
Define Transport Route:
Prepare and Transport Content
Import Transport Request
Limitations and Key Considerations

Set Up SAP Build Work Zone Instances
In both the Development (DEV) and Production (PRD) subaccounts, subscribe to and create instances of the SAP Build Work Zone, standard edition. For a three-tier landscape, include Quality Assurance (QA) as well.

Generate service keys for the SAP Build Work Zone instances in both DEV and PRD environments.

Perform the same above steps in the PRD subaccount as welll.
Subscribe to Cloud Transport Management Service (cTMS)
In the source subaccount (typically DEV), subscribe to the SAP Cloud Transport Management Service.

Create an instance and generate a service key for the cTMS

The above step is applicable only for the source subaccount as cTMS is setup in one subaccount

Configure Destinations

Set up a destination for the Cloud Transport Management Service in both the DEV and PRD subaccounts.

Copy the service key details of the cTMS instance and create a destination named ctms_destination in both the DEV and PRD subaccounts respectively with the below config.

Name ctms_destination

Type	HTTP
Description	Destination to Cloud Transport Management
URL	uri from the service key of cTMS
Proxy Type	Internet
Authentication	OAuth2ClientCredentials
Client ID	Copy Client ID from the service key of the cTMS
Client Secret	Copy Client Secret from the service key of the cTMS
Token Service URL	copy from the service key and append /oauth/token to the URL
Additional Property
node-name	DEV

For PRD, Just change the Additional Property node-name to PRD

The check connection test will return the below message and you’re good to go!

In the subaccount where cTMS is hosted (DEV in this case), create destinations for both the source (DEV) and target (PRD) SAP Build Work Zone applications.

Navigate to the destinations page in the cTMS subaccount and create the destinations for DEV and PRD workzone with the below config.

Name DEV

Type	HTTP
Description	Destination to Workzone Application DEV
URL	Portal service URL from service key of workzone and append /cdm_import_service
Proxy Type	Internet
Authentication	OAuth2ClientCredentials
Client ID	Copy Client ID from the service key of workzone
Client Secret	Copy Client Secret from the service key of workzone
Token Service URL	uaa-url from the service key

Create another destination for PRD Application with the same details from the service key of PRD

The connection check will return the following message

Create Transport Nodes in cTMS:
In the cTMS application, create two transport nodes—one for the DEV Work Zone application and another for the PRD Work Zone application.
Navigate to the Cloud Transport Management Application and Create two nodes for DEV and PRD.
Under Transport Nodes, Click on + and create nodes with the below settings. The name of the nodes must be same as that of what maintained in node-name property of the cTMS_destination
Define Transport Route
Establish a transport route from the DEV node to the PRD node to enable the movement of content between the two environments.
Navigate to the Cloud Transport Management Application and Create Transport route DEV — PRD
Under Transport Routes tab, Click + to create a transport route.

Under Landscape Visualization you can see your nodes and transport routes of them
Prepare and Transport Content
In the DEV Work Zone application, create a sample site, along with associated roles and groups.
I have created a test application in the DEV Workzone application with an Application, Group and Role each assigned to the site.

To Transport a site along with all it’s assigned contents, you can transport the whole site using by selecting the Transport Site option under more options on the site directory.

Once you click on Transport Site, the site will be pushed as transport request to the cTMS system.

To Transport objects individually you can select the objects in the content manager and click on the Transport Icon.
Import Transport Request
In the PRD environment, access the import queue of cTMS and import the transport request to deploy the content.
Navigate to the Landscape visualization Tab in the cTMS application and you can see the initial/Repeatable object count changed to 1 in the PRD queue.

Go to the import queue of PRD by selecting the node and clicking on Go to this node’s import queue.

In the import queue you can see the Request waiting to be imported. Select the request and click in import selected to import it into PRD.

Approve the Import Request and proceed to start import.

You can see the import logs in the Transport Action Logs tab. You can see the import status there.

Now you can see the site transported with all it’s contents to the PRD workzone.
Limitations and Key Considerations
- Supported and Unsupported Objects:
  - Supported Objects:
    - Sites, pages, and content (e.g., widgets, apps, and catalogs).
    - Roles and groups.
    - Custom themes and layouts.
  - Unsupported Objects:
    - User-specific personalization or customizations.
    - Some dynamic content or configurations tied to specific environments.
    - Certain administrative settings or system-level configurations.
- Environment-Specific Configurations:
  - Some configurations (e.g., URLs, API endpoints, or destination settings) may be environment-specific and need to be adjusted manually after transport.
  - Hardcoded references to environment-specific details will not work in the target system without modification.
- Manual Adjustments in Target System:
  - After transporting objects, you may need to manually adjust certain settings in the target system (e.g., reassigning roles or updating app URLs, as some application URLs of DEV and other systems may differ).
  - This is especially true for integrations with external systems or custom configurations.
- Data Loss Risks:
  - If the target system already has content with the same names or IDs as the transported objects, there is a risk of overwriting or losing data. Always review and resolve conflicts during the import process.
- Transport of Large Objects:
  - Transporting large sites or complex content structures may result in performance issues or timeouts during the export or import process.
  - Break down large transports into smaller, manageable chunks if necessary.
- Content Federation/ Content Manager
  If you’re using content federation for content from backend systems, the content provider/ package name must be identical in all the tiers.

Deployments without passwords with SAP Continuous Integration and Delivery

2025-05-05T10:19:22.419000+02:00

This blog explains how to use BTP's capabilities to establish secure authentication between the SAP Continuous Integration and Delivery service and the Cloud Foundry runtime without sharing any kind of secret.

The blog comes in three sections:

Motivation: Why it is not a good idea to share secrets
Walkthrough: The steps to enable the scenario
Deep Dive: More technical details on security aspects

If you're only interested in the "doing" part, feel free to skip directly to the walkthrough section.

Motivation

Let's assume you have a development project that you want to build with the SAP Continuous Integration and Delivery service and then deploy to BTP Cloud Foundry.

For the deployment, some form of authentication is required between the SAP Continuous Integration and Delivery service and the runtime (Cloud Foundry). Often, this is done by sharing a secret piece of information with the SAP Continuous Integration and Delivery service. That can be a password, a service key, or a cryptographic private key.

But why is secret sharing actually a bad idea? Secret sharing is the little brother of the dreaded "secret sprawl". An organisation suffers from secret sprawl, if there are copies of secrets distributed over different places, leading to a loss of transparency and accountability. Secrets need to be changed, either in a planned way or (worst case) because of a security incident. To do so, one needs to know all the places where a secret is stored. Forget one, and an important technical user might be locked out.

You end up with an inventory of credentials and stored secrets, something which is—in my experience—hard to maintain.

How can we avoid this whole rigmarole? The best solution is to dispense with secret sharing altogether and to instead define a trust relation between two systems. Sometimes that is not possible, but if two services belong to the same platform, you should expect that it is.

Key Benefits

A solution based on configured trust without secret sharing thus provides:

No operational efforts for secret rotation.
Improved security: Instead of tracking use of secrets, there is only one trust configuration, which can be disabled if necessary.

Walkthrough

Enough chit-chat, let's do some work. Here is a step-by-step guide how SAP Continuous Integration and Delivery can gain access to Cloud Foundry in order to deploy an application.

Requirements

A Cloud Identity Services tenant which acts as a custom identity provider (IdP) for platform users.
A user within the Cloud Identity Services tenant who has the developer role on the target space (the space the application should be deployed to).
A subaccount with a subscription to the SAP Continuous Integration and Delivery service. You need the "CICD Service Administrator" role to configure jobs and credentials.
A project you want to build, test, and deploy.

Certificate-based Authentication Credentials

Let's start in the SAP Continuous Integration and Delivery service. Authentication in this service is modeled via credentials. We need a credential of type "Certificate-Based Authentication for Custom IdP":

The following data is required:

The email of the technical user.
The hostname of the SAP Cloud Identity Services tenant.
The origin key used when configuring the tenant as custom IdP for platform users.

That's it. No secrets here!

Once you hit "Create" the detailed view appears:

There is the information we just entered plus a pattern to match certificate distinguished names. Copy the pattern, because we will need it in the next step.

Configuring the SAP Cloud Identity Services Tenant

You want your SAP Cloud Identity Services tenant to trust certificates generated by the SAP Continuous Integration and Delivery service. To enable that, login to the admin console of your tenant and navigate to "Tenant Settings > Authentication" > "Trusted Certificate Configuration". Click "Add".

Enter a freely chosen name and past the pattern. With the pattern the user email is extracted and the origin of the certificate (your SAP Continuous Integration and Delivery Service subscription) is checked. For more details on this, see the next section.

For more information, see the SAP Cloud Identity Service documentation.

Use the Certificate-based Credential in a Cloud Foundry Environment Job

The rest is routine. Either create a Cloud Foundry Environment job for you project or change an existing one to use you credential during the deployment. Here is an example for a deployment in the Acceptance stage:

That's it. Trigger your you job, lean back, and let the pipeline work for you.

Troubleshooting

In case the build fails with "Unauthorized" before the deployment, please log in to the admin console of your Cloud Identity Services tenant and navigate to "Tenant Settings" > Authentication" > "Certificate Authentication". Make sure that all check buttons are in OFF state.

Deep Dive

Short-lived Certificates

To achieve secure authentication without secret sharing, we use asymmetric cryptography in the form of certificates. Here are the details:

Your SAP Cloud Identity Services tenant trusts a certificate authority (CA) called "SAP Cloud Root CA". Each SAP operated service can issue certificates signed by that CA, which are subject to certain technically enforced rules.
The SAP Continuous Integration and Delivery service uses this in the following way. Let's assume we have a job that uses a "Certificate-based Authentication for Custom IdP" credential. When a build is triggered for this job, the following is going to happen:

A key pair and a certificate signing request (CSR) are generated.
The CSR is signed by the SAP Cloud Root CA.
The resulting certificate and the private key are injected into the environment of the triggered build, so that the build can use them to authenticate against your SAP Cloud Identity Services tenant.

Because there is a fresh certificate for every build, the validity of the certificate is extremely short: only twelve hours.

Validation of Certificate Distinguish Names

Now let's shift our point of view to the SAP Cloud Identity Services tenant which has just received a certificate in a request for authentication. It will do the following:

Using cryptography, it verifies that the certificate was issued by a trustworthy authority (the SAP Cloud Root CA)
Then, it looks into the fine print, i.e. the distinguished name (DN) of the certificate. It will be matched against the pattern configured above. The matching must be exact, except where a placeholder is used. The pattern will look similar to this:
CN=${mail}, L=CICD-c47ae4ee-59f4-4fcd-a692-7454ac9b71b7, OU=9abd6d5c-8ea7-49d4-ab08-a8dc776ada09, OU=SAP Cloud Platform Clients, O=SAP SE, C=DE

Let's look at the individual parts:
- OU=9abd6d5c-8ea7-49d4-ab08-a8dc776ada09, OU=SAP Cloud Platform Clients, O=SAP SE, C=DE: These values in the DN are enforce by the CA. The UUID is the subaccount ID of the SAP Continuous Integration and Delivery service. The presence of this ID means that only certificates from that service will be accepted.
- L=CICD-c47ae4ee-59f4-4fcd-a692-7454ac9b71b7: This value is provided by the SAP Continuous Integration and Delivery service. The UUID is the ID of the subaccount (owned by you) where your subscription to the service resides. This means that only certificates from this subaccount will be accepted.
- CN=${mail:techUser@example.com}: This is a placeholder to extract the email of the technical user. That email address was provided by you when you created the credential. The pattern will only match, if the email address from the certificate is the email address after the colon. This mean that with this configuration, we only give access to one specific user.

Summary

There are checks in place that ensure that only certificates are accepted which originate from your SAP Continuous Integration and Delivery service tenant.
The generated certificates are short lived. That makes cryptanalytic attacks almost impossible and mitigates the blast radius in case a private key and certificate pair gets compromised.
However, if at any point in time you suspect that something fishy is going on, there is a clean opt-out: Just delete the Trusted Certificate configuration from your Identity Service tenant.

Thanks for reading. I am happy for any kind of feedback, so let me know what you think!

SAP Continuous Integration and Delivery and Checkmarx One

2025-06-16T15:10:29.490000+02:00

Enhancing SAP Continuous Integration and Delivery with Checkmarx One

In today’s fast-paced digital landscape, maintaining robust security and compliance is more crucial than ever. As users of SAP Continuous Integration and Delivery, you understand the importance of delivering high-quality code rapidly. But how do you ensure that your code is not just functional, but also secure? This is where Static Application Security Testing (SAST) comes into play.

SAST is a technique used to analyze an application’s source code, bytecode, or even binary code for vulnerabilities that could be exploited. By integrating SAST into your CI/CD pipelines, you can actively identify and mitigate potential security risks before code reaches production. This approach offers numerous benefits, including early detection of vulnerabilities, reduced technical debt, and improved overall code quality.

Checkmarx One is an advanced SAST tool designed to provide comprehensive security analysis across various stages of your software development lifecycle. Checkmarx One can integrate with CI/CD pipelines, automating the process of identifying and remediating security flaws. This not only minimizes the risk of vulnerabilities but also ensures that your applications comply with industry standards and best practices.

In this blog post, we’ll guide you through the process of integrating Checkmarx One into the Compliance stage of your SAP Continuous Integration and Delivery jobs. By following these steps, you’ll be able to enhance the security and compliance of your code, ultimately delivering more resilient and trustworthy applications. So, let’s get started and explore how Checkmarx One can be added to your CI/CD jobs!

Prepare the Script

We'll use a bash script to run the Checkmarx scan. This script downloads the command line client, and then executes the scan:

#!/bin/bash 
set -euo pipefail

# Define the URL to download the Checkmarx One CLI
CLI_VERSION="2.3.21"
CLI_BINARY_TAR="ast-cli_${CLI_VERSION}_linux_x64.tar.gz"
CLI_URL="https://github.com/Checkmarx/ast-cli/releases/download/${CLI_VERSION}/${CLI_BINARY_TAR}"

# Define the CLI filename
CLI_BINARY="cx"

# Download CLI and make it executable.
download_cli() {
  echo "Downloading Checkmarx One CLI version ${CLI_VERSION} from"
  echo "${CLI_URL}"
  
  if [ ! -f "${CLI_BINARY}" ]; then
    curl -L -o "${CLI_BINARY}.tar.gz" "$CLI_URL"
    tar -xzf "${CLI_BINARY}.tar.gz"
    rm "${CLI_BINARY}.tar.gz"
    chmod +x "${CLI_BINARY}"
  fi
  
  echo "Download complete."
}

# running the scan using env vars
execute_checkmarx_one_scan() {
  echo "Running checkmarx One scan."
  
  ./"${CLI_BINARY}" scan create \
    --project-name ${CX_PROJECT} \
    --file-source ${PWD} \
    --client-id ${CLIENT_ID} \
    --client-secret ${CLIENT_SECRET} \
    --base-uri ${CX_URI} \
    --base-auth-uri ${CX_URI} \
    --tenant ${CX_TENANT} \
    --branch ${GIT_BRANCH}
}

download_cli && execute_checkmarx_one_scan

The script will require certain variables and credentials. Specifically, we'll add

CLIENT_ID and CLIENT_SECRET as secrets
CX_PROJECT, CX_TENANT, CX_URI as additional variables to the configuration of our SAP Continuous Integration and Delivery job later.

If you want to run your script locally, make sure these variables are set in the environment. To run the script as part of your job, you need to add it to your source code repository. In our example, we'll store it as .cicd/cxone.sh .

Configure the SAP Continuous Integration and Delivery Job

Now let's work on the SAP Continuous Integration and Delivery job that executes this bash script.

In SAP Continuous Integration and Delivery, navigate to your jobs or create a new one. This procedure will work with the Cloud Foundry Environment pipeline.
In the Compliance stage, add an Additional Command by entering the following into the text field:
./.cicd/cxone.sh
The script will require certain variables and credentials, which you need to add to your job:
- Additional Credentials: CLIENT_ID and CLIENT_SECRET
- Additional Variables: CX_PROJECT, CX_TENANT, CX_URI
All of these credentials and variables can be acquired from your Checkmarx One instance or from your Checkmarx administrators.
Once your configuration is complete, save the job.
Run it and watch the magic.

Your CI job will now not only run the scan but also fail if your quality thresholds are not met. Visit the Checkmarx One web application or your build log for more information on the findings. If things don't work out immediately (well, they never do, don't they?), have a look at the following Troubleshooting section.

Error Handling and Troubleshooting

If you encounter errors while running the script, check the following:

Ensure that the required variables and credentials are set correctly. (In general, adding better error handling and error messages will improve the usability of the script in production environments.)
Check the build log for any error messages or clues that can help you diagnose the issue.

Tips and Best Practices

Make sure to update the CLI_VERSION variable in the script to match the latest version of the Checkmarx One CLI.
If you're using a different repository structure, update the job to point to the correct location of the script.

Now you have integrated Checkmarx One security scans into your SAP Continuous Integration and Delivery job. This will help you catch security vulnerabilities early in the development cycle and ensure that your code is secure and compliant with industry standards.

Please let us know what you think in the comments!

SAP Master Data Integration (MDI): SAP S/4HANA Business Partner Replication using DRF Customizing

2025-07-25T07:51:03.447000+02:00

Introduction

This blog builds on our earlier post on SAP MDI Architecture and Deployment. Here, we explore end-to-end configuration for replicating Business Partner data from an SAP S/4HANA system to SAP Master Data Integration (MDI) using SOAP-based communication and DRF (Data Replication Framework).

Prerequisites

Ensure the following are in place:

SAP MDI service instance and service key created in SAP BTP Cockpit
DRF enabled in the S/4HANA system
Role-based access to SOAMANAGER
Active connectivity between SAP BTP and On-Premises via SAP Cloud Connector

DRF Configuration

In DRFIMG, create a Business System with BO Type and Communication System "Replication via Services" for the object "986" for Business Partner including Relationships.
Ensure the Business System ID matches the one used in the MDO configuration to avoid integration errors.
Assign Outbound Implementation "986_3 Outbound Implementation for BP/REL via Services", Assign Target System and Outbound Parameters under "Define Replication Models".
Repeat steps above for Key Mapping as 1376 if the integration scenario requires key mapping replication.

WSDL Setup via SOAMANAGER

Download WSDLs

Download 6 WSDLs as per SAP Note 2987243

Customize and Upload

Now we have the below 6 WSDL Files:
BusinessPartnerSUITEBulkReplicateRequest_Out
BusinessPartnerSUITEBulkReplicateConfirmation_Out
BusinessPartnerRelationshipSUITEBulkReplicateRequest_Out
BusinessPartnerRelationshipSUITEBulkReplicateConfirmation_Out
KeyMappingBulkReplicateRequest_Out
KeyMappingBulkReplicateConfirmation_Out
Add the following elements at the end of each of the WSDL Files before the </wsdl:definitions> tag.
It is important to note that the below XML element contains a sample SAP Master Data Integration Endpoint.
<wsdl:service name="...">
<wsdl:port name="..." binding="...">
<soap:address location="https://<uri>:443/businesspartner/v0/soap/BusinessPartnerRelationshipBulkReplicateRequestConfirmIn?tenantId=<identity_zone>" />
</wsdl:port>
</wsdl:service>
You need to replace this with your Master Data Integration details for all of them.
The SAP Master Data Integration Endpoint is of the following pattern:<uri>:443/businesspartner/v0/soap/BusinessPartnerRelationshipBulkReplicateRequestConfirmIn?tenantId=<identity_zone>
In the above pattern:
URI is equal to the value of attribute “uri” in your Master Data Integration instance’s service key
identity_zone is equal to the value of attribute “identity zone” in your Master Data Integration instance’s service key
Example for 1 WSDL- https://one.mds.cfapps.sap.hana.ondemand.com:443/businesspartner/v0/soap/BusinessPartnerRelationshipBulkReplicateRequestConfirmIn?tenantId=mdibpconsumer1
Upload all 6 WSDLs in SOA Management

Publish WSDLs to Services Registry

Use Services Registry → Publication of External WSDL
Assign appropriate internal names, bindings, and physical systems
Reuse the physical system object across all WSDLs after first creation

MDI System Access Profile

Go to Technical Administration → Profiles
Create a new profile with:
Auth: User ID/Password
Transport: Secured communication
Link this profile to the provider system using the same Business System ID as DRF

Logon Data Management

Go to Service Administration → Logon Data Management
Create credentials using:
clientId as username
clientSecret as password from the MDI service key

Local Integration Scenario Configuration

Go to Local Integration Scenario Configuration
Add these service groups:
MDG_BS_SUPPLIERREPLICATEREQ
MDG_BS_SUPPLIERREPLICATECONF
KEY_MAP_REPLICATE_REQ
KEY_MAP_REPLICATE_CONF

Assign IBC Reference to each from the MDI system
Link all service groups to the created Logon Data

Activate Logical Ports

Go to Service Administration → Pending Tasks
Process all pending tasks
Validate port creation via Web Service Configuration

SOAP Endpoint Setup for MDI

Go to Web Service Configuration
For each of the 6 service definitions (e.g. BUSINESSPARTNERSUITEBULKREPLIC), create a service binding
Under “Transport Settings”, copy the Calculated Access URL
Final endpoint:
https://<host>:<port>/<calculated_access_url>
Example:
https://ldciemt.wdf.sap.corp:44322/sap/bc/srt/xip/sap/businesspartnersuitebulkreplic/405/mdibpconsumer11/binding8

This URL is then used to configure the BPOUTBOUND destination in your BTP subaccount.

Conclusion

With this setup complete, your S/4HANA system is now capable of replicating Business Partner master data to SAP MDI in real-time via push or pull mechanisms. You’ve established secure communication, configured service groups, and integrated SOAP endpoints — ensuring a robust and scalable MDI architecture.
Please note the Blog is to connect S/4HANA on-prem/Private Cloud system to MDI, there can be more scenario where the MDI would be then connected to other systems. For such scenarios, configuration is required in Master Data Orchestration or Business Data Orchestration.

More Blogs:
SAP Master Data Integration (MDI): Architecture, D... - SAP Community
SAP Master Data Integration (MDI) – Bank and Cost ... - SAP Community

The New Cloud Foundry Pipeline in SAP Continuous Integration and Delivery

2025-10-14T09:48:16.179000+02:00

Version 3 of the Cloud Foundry Environment Pipeline is Here

At the end of September 2025, the version 3 of the Cloud Foundry Environment pipeline was released in the SAP Continuous Integration and Delivery service. This means, in a nutshell:

New Cloud Foundry Environment jobs created with the UI will already have version 3.
Until January 15, 2026, version 2 jobs will function normally. It will still be possible to create them via the API.
Tooling is available to migrate from version 2 to 3.
On January 15, 2026, all remaining version 2 jobs will be migrated automatically.

This blog post describes our motivation for doing this change and highlights some key aspects. If you are more interested in using the new pipeline right away, check out the official documentation.

Why the Cloud Foundry Environment Pipeline needed an Update

The "Cloud Foundry Environment" pipeline is our most widely used pipeline. Hence, it was the focus of the development team to continuously provide improvements. The former version 2 of the pipeline was already quite dated and had acquired some historical baggage. So in order to further improve it, a fresh start was required--in other words: We needed to do incompatible changes.

That being said, we do understand that our customer base has made a huge investment into the existing version by configuring thousands of jobs. To safeguard this investment, we build migration functionality to allow a seamless transition to the new version.

But before discussing this, let's look at the most important changes.

Changes in Version 3

Removal of On/Off Switches

Previously, lots of configuration elements could be switched on or off:

These switches are now gone. That makes the UI less cluttered and more intuitive: Instead of switching on an element before configuring it, you now just add the element using the "+" button:

If you no longer want a configuration element, you will have to delete it. If you want to preserve the data you have entered, create a safety copy of the entire job using the copy button in the job details view.

API Redesign

Not only did we work on the UI, but also on the API, i.e. the structure of the payload data clients have to send to create/update a job. We improved field names and got rid of some inconsistencies.

If you want to use the API directly to create jobs, you can find the complete specification of the payload as a JSON schema document which is available in our API as a resource. To access it, open the front page of the SAP Continuous Integration and Delivery UI. Now, in the browser's address bar, remove everything after the hostname and replace it with /v2. Hit enter, and you get to the front page of our API. From here, you can browse the complete API by following links. The path /v2.1/pipelineDefinitions/cf-env/3.0/schema will get you to the schema document for the Cloud Foundry Environment version 3 pipeline.

In-repository Configuration Format

Previously, there was a special format to be used when providing in-repository configuration for a job via a .pipeline/config.yaml file. This format has been removed. Instead, the same format as in the API payload is to be used. In particular, what we said above about the JSON schema applies here as well. The only difference is that, for convenience, YAML can be used instead of JSON. Here is an example of a simple configuration for a job doing a build, deployment and test. To avoid ambiguity, the configuration file name in version 3 is .cid_service/config.yaml.

---
stages:
  build:
    buildTool: "mta"
    buildToolVersion: "MBTJ21N22"
    npmLint:
      failOnError: true
  malwareScan:
    scan: true
  acceptance:
    webdriverIoTests:
      npmScript: "wdi5"
      baseUrl: "https://www.test.com"
      credential: "test-cred"
    cfDeploy:
      credential: "test-cred"
      apiEndpoint: "https://www.test.com"
      org: "org"
      space: "space"
      strategy: "default"

If you are familiar with the old format, you will realize, that this is much more simple and concise than what we had before.

New Features

Build Descriptors

Every project has a build descriptor file. Depending on the technology, it could be a mta.yaml, a package.json or a pom.xml. Instead of assuming this file is always located in the project root folder, you can now specify a path relative to the project root. For example: code/mta.yaml. This allows for a more flexible project structure.

MTA Extension Descriptors

In the MTA use case, so-called extension descriptors are used for providing configuration that is specific for a certain deployment. For example, you might want to configure more application instances in the release stage for your productive deployment than in the acceptance stage for your test deployment.

This feature is now fully supported by the service, i.e., you can specify a list of extension descriptor files to go with each deployment.

Getting There: The Migration

First the good news: If you have a version 2 job which is configure with the Job Editor, the migration is basically just a click. Just use the "Migrate" button in the job details view, and the service is taking care of the rest. Since the migration cannot be undone, consider creating a "safety copy" using the copy button.

You can also decide to do nothing for now, since on January 15, 2026, all remaining jobs will be migrated automatically.

It is a bit more complicated for jobs with in-repository configuration, because we cannot just push a commit in your repository migrating the configuration. Instead, if you use the migration button for the in-repository configured job, you will be asked to paste the content of your .pipeline/config.yml file. The result will be the expected content of the new .sap_cid/config.yml file. Create this file in your repository, commit everything and finish the migration flow in the UI. Note that for jobs with in-repository configuration, you need take active steps to complete the migration. Otherwise, they will stop working on January 15, 2026.

For more details on the migration, check out our official documentation.

CI/CD & SCTM Setup on SAP BTP (NestJS + React Extensions)

2026-01-20T05:09:37.457000+01:00

In my previous post, I focused on developer productivity and measurable outcomes. This time, I’m switching gears to delivery engineering: how we build and ship two independent apps—a NestJS backend and a React frontend (behind Managed AppRouter)—as extensions on SAP BTP Cloud Foundry, using SAP Continuous Integration and Delivery (CI/CD) and SAP Cloud Transport Management (SCTM).

SAP CI/CD gives us predefined CI/CD pipelines we can configure and run as jobs.

SCTM adds controlled transport, an import queue, and manual approvals when needed.

What We Deliver (Two Apps, Two Lifecycles)

1) React Frontend (behind Managed AppRouter)

We package the React UI so it’s served through SAP BTP Managed Application Router, meaning we don’t maintain our own AppRouter runtime.

2) NestJS Backend

Standard Node.js service deployed to Cloud Foundry, independently released from the frontend.

The CI/CD Flow (End-to-End)

Merge happens into a tracked branch (we use test and master).
Bitbucket webhook triggers a CI/CD job.
CI/CD runs a Cloud Foundry pipeline and builds an MTA from mta.yaml.
In the Release stage, the job uploads the built artifact to a SCTM node.
SCTM puts the transport into the import queue, where we manually forward/import if the node is configured for manual control.

SAP BTP CI/CD service with jobs definition example.

SAP BTP Cloud Transport Management service with transport node detail.

Our Branch & Job Strategy (Simple and Explicit)

We keep it intentionally “boring”:

React repo
- Job for test
- Job for master
NestJS repo
- Job for test
- Job for master

This avoids “one job that behaves differently depending on branch logic” and makes it obvious what ships from where.

Our SCTM Strategy (Auditability Over Minimal Clicks)

To improve auditability and clarity for customers, we use separate SCTM nodes per environment and per domain:

TEST-FE, TEST-BE
PROD-FE, PROD-BE

That’s four upload nodes for two environments.

Why we do it:

Cleaner history (“frontend vs backend” separation without filtering gymnastics)
Easier review and approval flows when different people own FE/BE releases

What it costs:

More nodes = more configuration + more manual imports

SCTM supports manual control via Import Queue when the node’s forward mode is Manual.

SCTM Node configuration detail.

SAP CI/CD Setup (What We Configure)

1) Credentials

We create three kinds of credentials:

Bitbucket access (clone/pull)
Webhook credentials (to trigger builds from merges/pushes)
SCTM service key credentials (for “Upload to” in release)

CI/CD is designed around configuring jobs that run predefined pipelines.

Credentials definition section in SAP BTP CI/CD service.

2) Repositories + Webhooks

For each repo in CI/CD:

Add repository (Bitbucket Cloud)
Attach credentials
Configure webhook so merges trigger the job

Repositories integration section in SAP BTP CI/CD service.

3) Jobs

For each branch job:

Select repository + branch
Build tool: MTA
Build descriptor: mta.yaml (repo root)
Optional: lint, unit tests, scans (pre-transport quality gates)

Jobs definition section in SAP BTP CI/CD service.

In Release:

Release type: SCTM
Operation: Upload to
Node: one of TEST-FE/TEST-BE/PROD-FE/PROD-BE

Basic definition of a job including Cloud Transport Management service integration.

SCTM Destinations (Deploying to the Right CF Org/Space)

SCTM uses destinations to address deployment targets for MTA deployment on Cloud Foundry.

If you use OAuth2Password authentication via SAP Cloud Deployment service, SAP notes two critical details:

Client ID must be cf
Token Service URL must point to Cloud Foundry UAA

Example of a destination configuration needed for SCTM service.

What’s Shared vs. App-Specific

Shared Practices (React + NestJS)

These rules apply to both repos:

mta.yaml lives in the repository root (so CI/CD can reliably find it).
package.json and package-lock.json are in the root.
Dependencies install via npm ci for reproducibility.
Build step is always explicit (no hidden magic).
Only artifacts that passed CI checks get uploaded to SCTM.

React App (Managed AppRouter): Minimal MTA Wrapper

Our typical structure:

/approuter (Managed AppRouter module/config)
/ui (React app)
/mta.yaml (root)
/package.json (root)

Managed AppRouter is intended to run HTML5 apps without maintaining your own runtime.

Build logic (conceptually):

npm ci
npm run build
post-step: ensure a manifest.json is present for packaging requirements (even if the React runtime doesn’t “use” it)

Important configuration files:

mta.yaml

_schema-version: "3.2"
ID: mta_application_fe
version: 0.0.1
modules:
- name: mta_application_fe-approuter
  type: approuter.nodejs
  path: mta_application_fe-approuter
  requires:
  - name: mta_application_fe_html_repo_runtime
  - name: mta_application_fe-destination-service
    group: destinations
    properties:
      forwardAuthToken: false
      name: ui5
      url: https://ui5.sap.com
  parameters:
    disk-quota: 256M
    memory: 256M
- name: mta_application_fe_ui_deployer
  type: com.sap.application.content
  path: .
  requires:
  - name: mta_application_fe_html_repo_host
    parameters:
      content-target: true
  build-parameters:
    build-result: resources
    requires:
    - artifacts:
      - uionboarding.zip
      name: uionboarding
      target-path: resources/
- name: uiapplication
  type: html5
  path: ui_application
  build-parameters:
    build-result: dist
    builder: custom
    commands:
    - npm ci --include=dev
    - npm run build
    - ./ensure-manifest.sh
    - sh -c 'cd dist && jar cfM uiapplication.zip .'
    supported-platforms: []
resources:
- name: mta_application_fe_html_repo_runtime
  type: org.cloudfoundry.managed-service
  parameters:
    service: html5-apps-repo
    service-plan: app-runtime
- name: mta_application_fe_html_repo_host
  type: org.cloudfoundry.managed-service
  parameters:
    service: html5-apps-repo
    service-plan: app-host

parameters:
  deploy_mode: html5-repo
  enable-parallel-deployments: true

package.json

{
  "name": "application-fe",
  "version": "0.0.1",
  "description": "Build and deployment scripts",
  "scripts": {
    "clean": "rimraf resources mta_archives mta-op*",
    "build": "rimraf resources mta_archives && npm run prepare-ui && mbt build --mtar archive",
    "prepare-ui": "mkdir -p resources && cd ui_application && npm install && npm run build && ./ensure-manifest.sh && cd .. && npm run create-ui-zip",
    "create-ui-zip": "cd ui_application/dist && mkdir -p ../../resources && zip -r ../../resources/uiapplication.zip . && cd ../..",
    "deploy": "cf deploy mta_archives/archive.mtar --retries 1",
    "undeploy": "cf undeploy mta_application_fe --delete-services --delete-service-keys --delete-service-brokers"
  },
  "devDependencies": {
    "mbt": "^1.2.29",
    "rimraf": "^5.0.5"
  }
}

ensure-manifest.sh

#!/bin/bash
# Make sure manifest.json exists in the right place
if [ -f "dist/manifest.json" ]; then
  echo "manifest.json already exists in the dist folder"
else
  echo "Copying manifest.json to dist folder"
  cp public/manifest.json dist/
fi
# make sure that xs-app.js exists in the right place
if [ -f "dist/xs-app.json" ]; then
  echo "xs-app.json already exists in the dist folder"
else
  echo "Copying xs-app.json to dist folder"
  cp public/xs-app.json dist/
fi

NestJS App: Minimal MTA for a CF Node Service

Structure is standard NestJS:

/src
/test
/package.json (root)
/mta.yaml (root)

Build logic (conceptually):

npm ci
npm run build (which runs nest build)

This “thin MTA descriptor” is enough to let SAP CI/CD build it through the standard MTA path and hand off to SCTM.

Important configuration files:

mta.yaml

ID: application-be
_schema-version: '3.3'
version: 1.0.0

modules:
  - name: application-be
    type: nodejs
    path: .
    parameters:
      buildpack: nodejs_buildpack
      memory: 512M
      disk-quota: 1024M
      command: npm run start
    build-parameters:
      builder: custom
      commands:
        - npm ci
        - npm run build
      ignore: ["node_modules/", "test/", "e2e/", "coverage/", ".vscode/"]

    requires:
      - name: malware-scanner
      - name: postgresql-db
      - name: connectivity-service
      - name: destination-service
...

package.json

{
    "name": "zapka-parents-be",
    "version": "0.0.1",
    "description": "",
    "author": "",
    "private": true,
    "license": "UNLICENSED",
    "scripts": {
        ...
        "build": "npm install && nest build",
        ...
    },
    "dependencies": {
        ...
    },
}

General Outcomes: Why This Setup Works for Us

Predictable builds
Same entry points (mta.yaml, npm ci, explicit build scripts) across both stacks.
Clear audit trail
CI/CD builds, SCTM transports; SCTM import queue enables controlled promotion.
Better separation of concerns
Dev teams focus on code + CI quality gates; deployment approvals happen in SCTM when needed.

Conclusion: Control Without Killing Automation

This setup gives us a stable delivery backbone:

CI/CD handles automation and repeatability.
SCTM provides governance and auditability via nodes and import queues.

Yes, extra nodes create extra manual confirmations—but for customer-facing enterprise delivery, the clarity is often worth it.

Questions for Discussion (How Do You Do It?)

Do you use one SCTM node per environment, or do you split nodes by domain (frontend/backend) for auditability?
Do you chain nodes strictly (DEV → TEST → PROD), or allow direct uploads to higher environments?
Where do you enforce manual gates—only before PROD, or also between lower environments?
If you split FE/BE: how do you keep transport naming and history readable over time?
What’s your preferred balance between fewer nodes (less ops effort) vs more nodes (cleaner audit trails)?