A modern workflow for SAP Cloud Integration with CAP and Azure DevOps

Introduction

As of July 2023 the development workflow for SAP Cloud Integration (SCI) is limited to what the SAP Business Technology Platform (SAP BTP) respectively the SAP Integration Suite offers. Some of these limitations are

• no version control management via Git
• no static code and vulnerability analysis of script code
• no CI/CD pipeline
• no simple code review process

We are convinced that overcoming these limitations will help us to develop integration scenarios on SAP BTP faster, with higher quality and even more secure.

Our solution

Thanks to the openess and extensibility of SAP BTP – in this case the Integration Content API of the SCI – we were able to implement the following solution, which will be explained in detail in the subsequent sections:

Build Workzone

Since there are many tools involved in the development workflow a Launchpad is introduced that serves as a central entry point for all SCI developers. Thanks to SAP Build Work Zone, standard edition (a.k.a. Launchpad Service) – setting this up is just a matter of minutes.

Sync App

At the heart of our development workflow is a CAP application with a Fiori Elements UI that serves two purposes:

• link an integration package on SCI to a Git repository on Azure DevOps
• synchronize the content from an integration package to the corresponding Git repository

As we want to establish a pull request (PR) workflow with a simple code review process and leverage many of the cool features Azure DevOps is offering (build validation, PR comments, PR decoration) the Sync App is not just downloading the integration package from SCI and pushing it to the main branch of the repository.
Instead the Sync App creates a new branch, pushes the integration package and opens a pull request targeting the main branch. In case a PR is already created the corresponding source branch will be just updated.

For the implementation of this functionality two npm packages are worth to mention:

• Azure DevOps Client for Node.js
• SCI REST Client

The latter is an open-source package we developed to simplify the access to the Integration Content API by hiding technical implementation details like url construction, xsrf token handling, authentication and so on. By now we are supporting the following artifact types

• Integration flows
• Message mappings
• Value mappings
• Script collections

Feel free to checkout the sources – feedback and contributions are always welcome 👨‍💻

For both – the connection to SCI and Azure DevOps – technical users are used. The credentials of these users are stored securely using the SAP Credential Store  and read at runtime via a REST API.

Build Pipeline

Every time a new PR is created or updated a so called build validation is triggered due to a configured branch policy on the main branch. The build pipeline includes the following steps:

1. Checkout the GIt repository containing the integration package
2. Install npm tools for custom validation
3. Run a SonarQube PR analysis
4. Check SonarQube quality gate
5. Run custom validations
6. Publish content to be consumed in a release pipeline

If the SonarQube quality gate or one of the custom validations fail, the overall build will fail and prevent the PR from being merged to the main branch. All findings will be written as comments to the PR (pull request decoration), so the SCI developer will get feedback about quality and security aspects immediately and can fix possible findings before a colleague is doing the review.

Release pipeline

When all findings were fixed, the build validation was successful and the reviewer approved the PR, a release pipeline is triggered. This pipeline consumes the integration package published in the build pipeline and uploads it to different SCI tenants using the SCI REST Client. Since a SCI dev can change the content of the integration package in the Git repository directly (e.g. via a local IDE or the Azure DevOps UI) the integration package is always uploaded to the SCI development tenant (from where it was downloaded during sync step) automatically. Uploads to the prod stage are triggered manually with a strict adherence to a 4-eye-principle.

Developer docs

As a “traditional” SCI developer is most probably not familiar with tools and concepts like Azure DevOps, SonarQube, CI/CD and pull request, we wrote an extensive documenation explaining the whole development workflow and the tools involved in detail. As we often heard about VitePress – a static side generator powered by Vite and Vue we gave it a try and are really impressed how fast and easy one can write a well-structured and good-looking documentation.

As the output VitePress generates is just a static website, we simply deployed it as HTML5 application to BTP and configured an App tile inside the central Launchpad.

BTW: The CAP team also seems to be very happy with VitePress. CAPire – the offical CAP documentation –  is powered by VitePress as well.

Demo

This topic will be presented on reCAP 2023 including a live-demo of the development workflow. The link to the recorded session will be published here once available.

Conclusion

This blog post should show how you can leverage the openness and extensibility of SAP BTP to completely rethink and redesign whole development workflows, extend them with tools and concepts widely used inside and outside your company and by that further increase the overall developer experience on the platform.