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:
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:
- Checkout the GIt repository containing the integration package
- Install npm tools for custom validation
- Run a SonarQube PR analysis
- Check SonarQube quality gate
- Run custom validations
- 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.