Since its first announcement, SAP BTP, ABAP environment (a.k.a. Steampunk) has been using git-based repositories for customer lifecycle management under the hood. However, customer developers have hardly ever noticed this in daily work, and despite gCTS being used internally, it was hard to tap into the benefits of a git-based lifecycle. This now changes with the 2402 release of SAP BTP ABAP Environment.
You will be able to choose your own git service provider and thus also connect CI/CD pipelines (cf. CI/CD Tools for SAP BTP ABAP Environment) of your choice directly to the commit hooks of that service.
Prerequisites
First, you need to create a new git repository with an initial commit and branch at the git service of your choice. We have used GitHub in our example below. The repository must be accessible from the internet, i.e., not hidden behind a firewall. You need a user with permissions to clone, pull, and push the chosen repository. Lastly, the SAP BTP ABAP systems you want to connect (e.g., dev, test, prod) all need to belong to the same global account.
Create and clone a new Software Component
You log on to the SAP Fiori Launchpad of your development system with a user holding a business role from template id SAP_BR_ADMINISTRATOR and go to the Manage Software Components app to create a new software component. With release 2402 you will notice the additional, optional Repository URL field on the New Software Component dialog:
As the name suggests, here you enter the URL of your initially empty git repository that your software component shall be connected to. The repo must already have an initial branch, usually „main“. Otherwise the user cannot clone the repository. In this case the user will see a „No branches were found. Please create a branch before cloning.“ message in the clone popup.
You will see the resulting software component as available in the Manage Software Components app. The connection to your git repository is registered but not yet locally cloned.
Next step is to clone the remote git repository to your app server’s local filesystem from where the objects will be imported into the ABAP runtime. You need to provide user credentials with sufficient privileges for this purpose on the first page of the Clone Software Component dialog. After the credentials have been validated, you must select a branch to be checked out and decide on the local role of your repository. For development systems, choose the role “Source” so that you can also push from your system to the remote repository.
Once you are done, you will see a new commit on your remote repository that has written a new file “.gcts.properties.json”. This file must not be deleted because it stores essential configuration data for gCTS.
Branching
Afterwards you need to pull the branch of your choice using the Manage Software Components app. It is important that your branches always contain the aforementioned “.gcts.properties.json” file created by the commit titled “Modify repository layout”. Otherwise, you will not be able to pull this branch to your system. Then you are ready to start some development.
Develop and release transports
As a developer you can now create some objects in ABAP Development Tools for Eclipse (ADT) underneath the structure package corresponding to the name of your software component. Changes will be recorded in tasks of transport requests as usual. Release them when you are ready with your development.
As soon as you have released a transport request, a new commit will become visible in your remote git repository on the active branch that you have chosen. You will notice that new files and folders have been created there.
Pull into target system
To import your released transport into a target system (e.g., your test or production system), your administrator must clone the same software component to the desired system. The only difference is the “Repository Role”, which now must be set to “Target”. After pulling the corresponding commit to the system, the changes will be imported to the ABAP runtime.
Fingerprints and external changes
Now let’s have a closer look at the details of the files written to git.
Besides the metadata and sources, a file FINGERPRINT.json is written for every transported object. It contains fingerprints for every include file of the object, which will be validated in the target system during pull from git.
This fingerprint is calculated from the content hash of your file and a secret that is only known internally to ABAP Cloud systems of your global account. The following picture gives an overview.
This ensures that only commits pushed (and validated) from ABAP Cloud systems can be pulled to target systems. Otherwise, stability of target systems could be jeopardized when external changes from git that have not passed ABAP Cloud allow-list checks and consistency rules are inadvertently imported. This is especially important for production systems.
Now let’s check what happens when you try pull an external commit. Therefore, let’s arbitrarily change some file directly in your git service.
When trying to pull this into one of the ABAP Cloud systems in your account via the Manage Software Components app, you will receive an error in the Execution Log.
You can further drill down into the transport logs to finally see that there was an exception when matching the fingerprints of pulled files.
To recover from this situation, you must revert the conflicting commit on your remote repository. It is important that the fingerprints match again to the files as originally exported from your development system, before pulling again to an ABAP Cloud system.
Outlook
Being able to edit ABAP sources with external tools would have a lot of benefits, e.g., for conflict resolution after merging or cherry-picking. For the future, the idea is to allow also external changes by falling back to an inactive import in case of mismatching fingerprints. This will ensure that all necessary ABAP Cloud checks are conducted when activating the objects again in the importing (development) system.
Another restriction is that there is currently no straightforward possibility to migrate existing applications to your own git repository, especially when it has already been deployed to production. This feature is of course also high on the wish list.
Further Information
- SAP Help on How to Configure Your Git Repository
- Tutorial on Transport a Software Component Between two Systems Using Any Git Repository (BYOG)
- SAP Managed Tags:
12 Comments
