Trigger the Build Framework out of the SAP System
Discover how to seamlessly trigger a CI/CD pipeline directly from your SAP system, such as when a transport is released. In this guide, we will walk you through the configuration process and demonstrate how to implement various filters to control pipeline triggers. Learn how to restrict access to specific user groups or development packages, ensuring secure and efficient pipeline management. Additionally, we will show you how to supply your pipeline with additional information using parameters, optimizing your development workflow.
Note
This configuration is required only in the development system and is client-independent.
Accessing Pipeline Trigger Configuration
- Run transaction
/BUILD/ENTRANCE - In the Pipeline section, click on Pipeline Trigger Configuration.
- The subsequent screen will be in display mode. To switch to edit mode, click on the top-left icon above the ALV Grid. You can save your changes from this point, too.
Managing Configurations
You can work with multiple configurations, referred to as “configs,” to separate different scenarios. When multiple configs are present, the BAdI process determines which config is valid. If more than one config is valid, the first one is selected.
Create a new configuration using the Append Row button.
Required Configuration Details
Each configuration must include the following:
| Field | Description |
|---|---|
| Configuration Name | Free text |
| HTTP Destination | Must exist in SM59 (refer to Interacting with the ABAP Build Framework) |
| URL Path in Jenkins | Since the HTTP destination only contains the host, this field requires the path to the pipeline itself. For example, if the URL is https://jenkins/job/pipeline/the HTTP Destination Host is https://jenkinsand the path is /job/pipeline/ |
Do not forget to save your settings via the top-left icon above the ALV Grid.
Note
If any entry is missing, the configuration cannot be saved.
Checks to Control Pipeline Triggers
You may want to set up checks to restrict or filter pipeline triggers, ensuring activation only under specified conditions for improved control and security.
By clicking the Parameters button, you can include additional checks such as:
| Parameter | Description |
|---|---|
| BUILD_SCRIPT | No input needed. If no script exists for the objects the BAdI will stop. This also verifies that at least one repository object is included in the transport and that no TADIR (header) data is present. |
| CLIENT_CHECK | Single value like 000 or multiple values separated by ; like 000;001;100Enter the client in which the config is relevant such as 000 or 001 |
| CWB_RELATED_CHECK | Enter CWB_OK if CWB transports can be released or CWB_NO_PIPELINE |
| EXCEPTION_EXISTS | No input needed. If exception is given the BAdI will stop. |
| LOCAL_TRANSPORT | No input needed. If transport is local the BAdI will stop. |
| OPEN_TASKS | No input needed. If tasks are open the BAdI will stop. |
| TRANSPORT_TYPE_CHECK | Enter the allowed transport types in without separation like KW for K and W |
| USER_MEMBER_OF_GRP | Add the allowed user groups separated by ; like Group1;Group2 see section below: Maintaining User Groups |
Defining URL Parameters
This option allows you to map a desired build parameter, such as the transport owner, to a value that your CI Server can use. In this manner, you provide your pipeline with more data that it can process.
Example
The Jenkins Parameter transportOwner needs to be set.
In the URL configuration, you would select TR_OWNER and map it to transportOwner.
Disabling a Configuration
The last editable field is the Inactive field. This allows you to disable a configuration without deleting it.
Enhancing Check or URL Parameters
You can enhance checks or URL parameters by navigating to the menu of the Pipeline Trigger Configuration:
- Admin → Adjust URL Parameter
- Admin → Adjust Check Parameter
This allows you to maintain the table with the checks and classes. Customers can also add additional checks.
Adding New URL Parameter Classes
New URL parameter classes can be created by implementing the interface/BUILD/IF_PIPELINE_URL_PARAM.
For examples, you can refer to the classes /BUILD/CL_URL*.
Adding New Check Classes
New check classes can be created by implementing the interface /BUILD/IF_PIPELINE_PARAMETER.
For examples, you can refer to the classes /BUILD/CL_PARAM*.
Check Class Method Requirements:
The check class must implement the method equals_current_and_expected.
The BAdIs will behave as follows based on the method’s result:
| Result | Action |
|---|---|
abap_true | The pipeline will be started. |
abap_false | The pipeline is not utilized, and the transport follows the standard release process. |
Raises exception /build/cx_build | The export will be canceled. The end user will need to try again. |
Maintaining User Groups
If you want to restrict the usage of the pipeline to certain users, you can activate the USER_MEMBER_OF_GRP check. This ensures that the configuration will only be applied if the user is part of the specified group.
To utilize the USER_MEMBER_OF_GRP check, you need to maintain the list of allowed user groups. Follow these steps:
- Navigate to the Pipeline Trigger Configuration
- Go to Admin → Main. Allowed User.
Editing User Groups
The report initially opens in display mode. To make changes:
- Click on the leftmost icon at the top of the ALV to switch to Edit mode.
- In Edit mode, you can add or remove multiple users.
- Save your changes once you are done.
All modifications are logged in the database, even if the log fields are not visible.
If the check is activated and the user is not part of the specified group, the configuration will not be applied.
Handling Generic Users
Generic users can disrupt the check process, particularly the user check. To address this, the table /BUILD/P_IGN_USR (maintainable only via SE16) has been introduced. You can add users to this table, and instead of the generic user, the owner of the transport will be used.
What’s Next
Next, learn how to configure the BAdI that triggers the pipeline from your ABAP system.
Triggering a pipeline from within the SAP system is just one option—there are several others!
You can trigger the pipeline via a remote function call (RFC), enabling a more centralized approach. This setup allows one system to coordinate deployments across multiple systems, similar to how Change Request Management (ChaRM) works in SAP Solution Manager.
Alternatively, you can trigger the pipeline from any external system using an OData call. The ABAP Build Framework gives you full control over the entire transport workflow through a tool of your choice. For example, you could implement a custom change process within an issue tracking system that initiates the pipeline and communicates with your SAP system.