ABAP Continuous Integration with Jenkins

Short read

In this blog I describe how to set up a first minimal Continuous Integration environment for ABAP with Jenkins.

Therefore an Odata-Service on the Netweaver system is created which returns whether all tests of a package are successful or not. A step by step documentation of the creation with SAP Gateway can be found here.

On the Jenkins side you need on top of the default installation only additionally the HTTP Request plugin. The fiels of the request plugin are filled with the url of the created Odata-Service, valid credentials to connect to your SAP system and a simple configuration to process the received response.

After completing this you can use the standard features of Jenkins to setup a daily test run and notify for example a group of people if tests are broken. Welcome to the world of CI 🙂

Long read

In the recent years there were a lot of helpful things introduced in the ABAP universe. ABAP in Eclipse as the new development environment and also cool new language features like table expressions or enums.

One important thing I am still missing is a tooling for a Continuous Integration environment (short CI). Unit tests are there in ABAP since a long time and also frequent commits to a common repository are moreless standard when developing in ABAP.

Having Unit tests is great but do you really continuously check
if they aren’t broken? 

The first step in a Continuous Integration environment is mostly a daily build and testrun. Therefore the open source tool Jenkins is perfect.

The necessary steps to get your ABAP packages continuously tested by Jenkins are:

1. Create an OData Service on the SAP Netweaver OData Service
2. Installation of Jenkins
3. Add the HTTP Request plugin
4. Add a Jenkins user with the SAP credentials
5. Configure the HTTP Request plugin inside a build
6. Initial run and scheduling

OData Service on the SAP Netweaver OData Service

The creation of an Odata service which delivers the result whether all unit tests of a package are valid or not is described here.

Installation of Jenkins

The installation of Jenkins is rather straightforward. The latest version can be downloaded from https://jenkins.io/. Download, install and it is already up and running.

Add the HTTP Request plugin

To access the Odata Service from Jenkins the HTTP Request plugin is used. The plugin can be installed in Jenkins via the Plugin Manager. On the tab “Available” the plugin can be found in the endless list by using the filter tab on the right side.

Add a Jenkins user for the SAP access

To access the Odata Service of the SAP system a valid SAP user is needed. The user is configured as Jenkins user under the Credentials menu. The important fields are username and password.

Configure the HTTP Request plugin inside a build

The main feature of Jenkins is configuring different jobs which perform certain  tasks called build steps and deliver a message if all build steps where completed successfully.

In our case only one build step is needed. Calling of the Odata-Service for test execution with the Http Request plugin.

As parameters the plugin has to be packed with

1. Url – the entire url of the Odata Service with the package as key (in the case below the name of the ABAP package is ZABAP_CI
2. HTTP mode – GET
3. Authenticate – select the jenkins credential which holds the SAP-credentials
4. Response code expected – you can stay with the default values, I prefer to use the status code 200 only.
5. Reponse content expected – this is important. The value has to be as shown in the screenshot, exactly the string TESTRUN_OK.

Initial run and scheduling

You can run the build manually on the right side with the menu entry build. The usual way is to configure a scheduling with cron expressions – thus the job is run automatically each day, each hour or …

Below you see the cron expression to start the Job each day at 7 am. But there are infinitive configuration possiblities like starting more times a day or only on weekdays.

On the bottom of the job configuration you can setup notifications, for example that an email is sent in the case the build did not deliver the expected result, in this case if the build does not contain the string “TESTRUN_OK”.

Enjoy your daily build. 🙂