Guide to SAP Build Scripts

Understanding the Build Framework: Automated Execution of Build Scripts

The ABAP build script is a development object that is stored in the same manner as any other referenced source code. This means that in every SAP ABAP system, not only is the source code present, but also the necessary information on how to build it, making it independent of any fixed configurations.

Like other development objects, this structure allows for the continuous improvement of the build script. The script is available in every SAP system that contains the source code to be built, ensuring there is no reliance on a single central infrastructure.

The Build Script Editor

All actions related to the Build Script must be performed using the Build Script Editor. You can access the editor via Report: /BUILD/SCRIPT_WORKBENCH

Actions:

1. Create/Edit Script:
   • If a script does not exist, an empty screen will appear.
   • When you save the edited script, the JSON syntax is checked. If there are any issues, you will receive an error message.
   • The build script is saved, but no TADIR entry is created at this time.
2. Upload Script:
   • Use this option to add a new build script or overwrite an existing one.
   • The build script is saved, but no TADIR entry is created at this time.
3. Download Script:
   • Download the build script to your local machine.
4. Delete Script:
   • This action removes the TADIR entry R3TR BLSC <script name> as well.
5. Transport Script:
   • A TADIR entry for R3TR BSLC <script name> is created.
   • If the namespace of the build script is not changeable or available, you will receive an error message.
   • This action brings up the transport selection dialog to add the R3TR BLSC object to a transport.

Troubleshooting Tips:

• Ensure the JSON syntax is correct to avoid errors when saving.
• Check the namespace availability to prevent errors during transport.

Components of Build Scripts

The build script is divided into two main sections: Phases and Configurations.

Phases

In the Phases Array, you define a phase name (any name is possible) and specify the plugins to be used within that phase. The following information can be included:

• plugin_class: The name of the ABAP class to be executed.
• disabled: Default is false. If set to true, the class will not be executed (useful when inheriting from other build scripts).
• config: The name of the configuration section to be used. If omitted, the nameless default configuration is used (which must exist).

Configurations

In the Configurations Array, you need to set the values relevant for the Build Plugins to run. It is crucial that the plugin is available in the system. Typically, all plugins provided by the Build Framework include class documentation with an example of the script content. An overview of all classes, along with links to their documentation, is available via Report /BUILD/PLUGIN_OVERVIEW.

You can use different configurations within the same build script. Simply duplicate the configuration section and assign a new name.

Build Script Example

To provide an initial overview, here is an example of a simple build script:

{
  "phases": [
    {
      "phase_name": "ExamplePhase",
      "plugin_class": "ExampleClass",
      "disabled": false,
      "config": "ExampleConfig"
    }
  ],
  "configurations": [
    {
      "config_name": "ExampleConfig",
      "parameter1": "value1",
      "parameter2": "value2"
    }
  ]
}

Annotations:

• phase_name: The name of the phase (can be any name).
• plugin_class: The name of the ABAP class to be executed.
• disabled: If set to true, the class will not be executed.
• config: The name of the configuration section to be used.
• config_name: The name of the configuration.
• parameter1, parameter2: Example parameters required for the plug-in.

Assigning Build Scripts

Build scripts are essential for defining the processes involved in a build phase. They can be flexibly assigned to multiple packages (P) or software components (C) by creating corresponding entries in the table /BUILD/SCRIPT_2E.

Field	Description
BUILD_SCRIPT	The name of the build script
ENTITY_TYPE	Either ‘C’ for Software Components or ‘P’ for Development Packages
ENTITY_NAME	The name of the Development Package or Software Component

Example: To assign a build script named “ExampleScript” to a development package named “ExamplePackage”, you would create an entry in /BUILD/SCRIPT_2E with the following details:

• BUILD_SCRIPT: ExampleScript
• ENTITY_TYPE: P
• ENTITY_NAME: ExamplePackage

Define a Default Build Script

You can set the default Build Script through the Build Script Editor by navigating to Menu → Scripts → Set Default Script. This feature activates a Build Script across the entire system, enabling comprehensive system checks without the need to add a script to each individual package.

Note: This should only be done if you intend to check the entire system with the same configuration. Activating it for a typical CI scenario will require every user in the system to use the Build Framework and pipeline.