As an add-on administrator, you have two options for triggering the add-on build process. The recommended approach is to use the Build Product Version app in the Landscape Portal to configure and execute an add-on build pipeline, leveraging the CI/CD service on SAP BTP. Alternatively, you can implement your own pipeline manually and run it on an existing CI/CD server. In both cases, a successful pipeline execution will result in a new product version that can be installed.
The add-on build pipeline runs through multiple steps:
-
For the add-on assembly, an assembly system is created in the 03 Build/Assemble subaccount. All software components that are part of the add-on product are imported into the system.
The import in the assembly system is enabled by communication scenario Integration (SAP COM 0510).
-
During the add-on build, delivery packages corresponding to included software component versions are created. For the add-on product version, a target vector is created and published in test scope. See Target Vector
The build process is enabled by communication scenario Software Assembly Integration (SAP COM 0582.
-
To ensure that the add-on provisioning works correctly, an installation test system is provisioned in the 04 Build/Test subaccount. The new product version is installed using the target vector published in the build stage.
The installation test system uses the service plan
saas_oem, enabling the add-on installation. -
Once the build and test installation have been completed successfully, the target vector is published in production scope.
-
After a successful build, all ABAP systems used are deprovisioned (unless otherwise specified) and the add-on is technically available for deployment to the ABAP environment.
With any new add-on, it is required that you first register the add-on product and any global accounts you wish to use before building your initial product version.
For in-depth information about the ABAP environment pipeline used for add-on build, check out ABAP Environment Pipeline.
-
Using the Build Product Version app requires an existing CI/CD subscription in the same subaccount as the Landscape Portal subscription (recommended option). If you used the Booster for Landscape Portal to set up your landscape, then this is already configured.
-
Using a custom pipeline configuration and Jenkins server requires the following (not recommended):
-
To execute the pipeline, you have to set up a Jenkins CI/CD server that is provisioned using the Cx server and you need an S-user in SAP One Support Launchpad with user management authorization. SeeJenkins , Cx Server, and SAP note 1271482.
-
To configure the pipeline, you need to create a configuration repository and implement the add-on build scenario. See Build and Publish Add-on Products on SAP BTP, ABAP Environment.
-
The following section explains how to build the initial version of the add-on product. The result is a delivery of type AOI (Add-on Installation) for the initial release 1.0.0 of both the software component and the add-on product.
The add-on build process is orchestrated by an automated pipeline. Before the pipeline can be configured, the following steps need to be performed.
As an operator, assign a technical Cloud Foundry platform user as a space developer in subaccount 03 Build/Assemble. This technical user will be used to provision the assembly system. See Creating New Space Members and Assigning Space Developer Roles to Them.
If you used the Booster for Landscape Portal to set up your landscape, then this is already configured.
As an operator, assign a technical Cloud Foundry platform user as a space developer in the space in subaccount 04 Build/Test. This technical user will be used to provision the installation test system. See Creating New Space Members and Assigning Space Developer Roles to Them.
If you used the Booster for Landscape Portal to set up your landscape, then this is already configured.
As part of the add-on build process, the Add-on Assembly Kit is used. With AAKaaS, the on-premise tooling is now available as a cloud service that is used by the build pipeline.
To access the service that is offered via SAP Support Launchpad, a technical communication user is used. See SAP note 2532813.
In the Support User Management app in SAP ONE Support Launchpad, as an S-user, request a new technical communication user. After the technical communication user has been generated, activate the user.
To create technical communication users in SAP Support Launchpad, you have to assign the user administrator function to the logged on user.
Make sure that this technical communication user is assigned to the customer number under which the ABAP environment tenants are licensed and for which the development namespace was reserved.
Ensure that this technical communication user is assigned to the customer number under which the ABAP environment tenants are licensed and for which the development namespace was reserved.
See SAP note 2174416 for more information on how to create and activate technical communication users.
The credentials of the three technical communication users need to be maintained in the Build Product Version app. See Maintain Credentials.
If you are using your own Jenkins server, the Jenkins administrator needs to add the credentials of the three technical communication users to the Jenkins Credentials store.
The registration of a new add-on product is a manual step. Your add-on product should only be installed in ABAP systems in your global accounts for development and production. Therefore, the product needs to be created and global accounts need to be registered with SAP using Landscape Portal.
SeeRegister Product.
As a DevOps engineer, you have the choice between using the Build Product Version app in the Landscape Portal or creating a pipeline configuration for the add-on build scenario from scratch.
We strongly recommend using the Build Product Version app, as it greatly reduces both the initial configuration and the maintenance effort:
-
the user-friendly tooling hides the complexity of configuring a pipeline definition and removes the need for an external repository,
-
the app automatically delegates the execution of the pipeline to the CI/CD service on SAP BTP, removing the need for a partner-owned Jenkins server.
Creating a custom pipeline configuration allows you to modify parameters of the ABAP Environment pipeline that are not exposed in the Build Product Version app; however, the app should cover all common use cases.
Currently there are two features available in the pipeline that the app does not support:
-
It is not possible to define a manual confirmation step before the target vector is published productively. This option allows you to perform integration tests in the ATI system before your final release decision. The pipeline executed by the app will simply check if the new version was installed successfully and will then automatically proceed to the publishing step.
-
It is not possible to work with a permanent build system. This option allows to save on execution time, as no new system has to be provisioned. The app will always provision a new build system.
The Build Product Version app allows you to configure the pipeline directly in a Fiori UI. See Build Product Version.
As a Landscape Portal Administrator, configure the Release Delivery pipeline template to be able to build your initial version. You can also configure the Test Release Delivery template in case you wish to perform a test execution, without releasing the new version.
As a Jenkins administrator, create a new pipeline in Jenkins pointing to the Jenkins file of the pipeline configuration for the add-on build scenario. See Configuration.
The add-on build scenario of the ABAP environment pipeline is described in detail in Build and Publish Add-on Products on SAP BTP, ABAP Environment.
Create Maintenance Branch
For each release and support package level, as an add-on admin, create a maintenance branch that is used for development of bug fixes and maintenance deliveries. See Versioning and Branches.
In test system TST, create branch v1.0.0 that is based on the main branch.
Build New Product Version
Each version contains an add-on version number – 1.0.0 for the initial delivery – as well as the included software components, such as the corresponding names, branches, and software component versions to be used for the add-on build. You may also choose specific software component commit IDs (as seen in the Manage Software Components app) and select which languages should be included in the new product version. Add-on version numbers may not be used more than once.
Build Product Version app (recommended)
New product versions for your registered add-on products can be defined directly in the Build Product Version app. The initial product version will always be of type “Release Delivery”. See Create New Product Version.
The corresponding pipeline is executed automatically when the Build Product Version button is clicked on in the app. If the execution is successful, the initial version of the add-on will then be available for installation.
Manual Configuration
If using a custom pipeline configuration and your own Jenkins server, create an add-on configuration file (addon.yml) in the corresponding Git repository. This file includes the metadata of the add-on product that is being built, such as versioning information and the included software component versions. Please follow the best practices on how to define the addon.yml file. See Add-on Descriptor File.
Once the repository is updated, trigger the pipeline execution on your Jenkins server. If your pipeline includes manual confirmation steps, you will have to follow its progress and react accordingly. You may use the add-on installation test system ATI to confirm the success of the add-on installation before confirming its release. You can also use the system for additional tests, similar to the steps described in Test in the ABAP Environment SAP Fiori Launchpad. For testing in a consumer-like environment, you can create tenants of type Partner Test using the Landscape Portal application. See Use Test Tenants.
For in-depth information about versioning and branches, check out Versioning and Branches.
To learn how software lifecycle management in the ABAP environment works with software components, see Basic Concepts and Terms.
Please make sure that the add-on product version to be published is properly tested before confirming the release decision. This includes testing in SAP Fiori launchpad and the ABAP Test Cockpit. See Test in the ABAP Environment SAP Fiori Launchpad and Test in the ABAP Test Cockpit.
Check Add-on Build Result
Use the Check Product Version app in Landscape Portal to check whether the product version, its components, and respective packages are ready for delivery. SeeCheck Product Version.