!!! Please note that the repository link has changed. Links in this blog post are updated. Sorry for any inconvenience.

If you´ve already taken a look at Git-Enabled Change and Transport System (gCTS), you might have found that despite all efforts, the development processes for ABAP still differ from what you might be used in other environments. For some parts, this is not easy to change. An ABAP system is a big thing. It is hard to provide it as a development environment to all developers on their own machines. If you work in big ABAP projects involving many modules, you will most probably rely on a central development system that is used by many developers.
For other aspects, we try to get closer to what working with Git is expected to look like. In gCTS, you currently use virtual SIDs and transport layers to determine the repository where a certain object shall be pushed to. What if that was no longer necessary? What if you could abstract a bit from the classical CTS entities?
Up to now, gCTS creates new commits when you release a transport request. This might for many of you be a big entity in your development processes. Developers might work with their own tasks but are part of one big transport request. This implies that e.g., tests of individual developments in a test system can only be done when the transport request is released as only this will create new commits. It might be more helpful if commits were created on task basis.
In this blog post, we would like to describe how you could adapt your development processes accordingly by the help of a sample BAdI implementation.
This sample BAdI implementation can be used for two purposes: enabling task-based committing and making use of the Registry as part of the release process for a task to find the correct repository for a certain object or commit.

Basics about the Registry

The registry is the latest enhancement of gCTS that moves us further into this direction. It is made for distributing objects to the intended repositories.

How the registry works

So how does it work?
One system in your landscape has to become central gCTS registry server – it´s the system ANY in the picture above. Development systems that will work with gCTS then need to get informed about this registry. This way, you can assign objects to a repository on any of the systems involved.
The system that serves as central gCTS registry server should be as much available as possible. At least, it should always be available, when developers are at work and are expected to push their changes. In addition, the system should be stable. This means that a system that might be refreshed regularly is not an option. So. for example, if you think about a test system that gets refreshed e.g. via a system copy from production to have new testing data available, this system cannot be used as central gCTS registry server as the system copy will overwrite the registry configuration and what is registered, as well. If you would like to use a system as the central registry server where it can (easily) happen, that it is overwritten or where for other reasons data might be overwritten, then you should save registry information. This could be done by the help of a transport request: Create a transport request with dummy a target and add to it the content of all registry tables. These are the tables that start with SCTS_AVCS_R*.

Configuring the Registry

The registry is part of the standard delivery starting with SAP S/4HANA 2020 FPS2. But it is not directly visible after the upgrade or installation. You need to activate it first. This is done by creating a connection in SM59 on the system that hosts the registry which points to the server itself. In addition, you have to add the name of this connection to the configuration parameters of your system in the gCTS app. For this, you need to add the parameter VCS_REGISTRY_DESTINATION.

Registry destination

After you did both steps, the Registry tab is shown.

Registry tab

All other systems that will use the registry need to get connected. This means that an SM59 connection has to be created in these systems, too. This time, the destination has to point to the server that hosts the registry. Again, you also need to add the parameter VCS_REGISTRY_DESTINATION with the name of the destination as value to the system configuration. The configuration of the registry is described in detail on the SAP Help Portal at Configure the gCTS Registry.
Afterwards, you could start registering your objects and tables and all other parts of your ABAP development and customizing that you would like to manage via Git. What has been described up to now is part of the standard delivery starting with SAP S/4HANA 2020 SPS03.
However, we suggest that you do not start registering objects right now, but first read on to learn how you can better integrate the registry into your development processes.

How to Enable your Development Processes for the Registry

The integration of the registry into your development – or better, into your transport release process – is something that you need to do yourself by implementing a Business Add-In (BAdI). In this blog post, we would like to explain how this can be done. You implement the BAdI CTS_REQUEST_CHECK for that. We offer a sample implementation in the SAP-samples repository on GitHub. Please check the license and warranty in there before you decide whether you would like to use this sample implementation.
The sample implementation that we provide works based on tasks. Whenever you release a task, a new commit is created in the correct repository. The assignment to the correct repository was prepared by registering the repository and the objects in the registry.
The following figure shows how this process works after the registry has been enabled and the BAdI has been configured and activated.
What is shown in the green circle is provided as part of the standard delivery, the steps shown in the blue circle are enabled with the help of the BAdI implementation.
At first, an administrator or a developer –named Registry Manager in the figure- needs to register the repository and the objects.
Afterwards, developers can use the registry. They change objects and release tasks as they are used to. This is the known development process in ABAP – nothing special because of gCTS or the registry. The BAdI is called when a task is released. This is the point in the development process, where the registry comes into play. If an object that is part of a released task is registered in the gCTS registry, the new commit containing this object will be added to the repository for which it is registered.

BAdI implementation

You can also find a detailed diagram that shows the process flow inside the BAdI implementation in the repository on GitHub.
In the description of the configuration toggles for the BAdI you can find more details about how you can influence the BAdI and find out more about the options that you have.

Scope of the BAdI Implementation

The basic idea of the sample implementation that we provide is to make it possible to use the registry when releasing a task. This means that you no longer have to care for transport layers. If an object is registered for a certain repository, this registration will determine the target of the commit – not the transport layer. The entire implementation is based on tasks. Releasing transport requests does not trigger any additional action. The BAdI implementation does not change the process for that. If all tasks of a transport request are handled via the BAdI, then releasing the transport request will not create any additional commits in any repository. Using the registry on transport request level is not possible since this would not allow a proper error handling in case an object is not registered. When you try to release a task that contains objects that are not registered, the BAdI implementation stops the release process, the task remains open, and you can easily correct the missing registry entry and then restart the release of the task. If the registry was only checked when the transport request is released, it would no longer be possible to change any registry assignments since the tasks would already be released and the release process could no longer be stopped.
The sample code that we provide includes a view that you can open with transaction SM30. With this, you can set options and define to a certain degree how you want the BAdI implementation to work, for example, for whom or which coding it is relevant. Please check the details for the different toggles further down.
You can also make use of this implementation to just enable task-based committing without using the registry. By default, gCTS creates commits, when a transport request is released. If you would like to create commits whenever a task is released, you can do so. Please check the description of the toggles that come with the deployment of the sample code to get the details how you can use the implementation to enable task-based committing even without using the registry.

Points to be Considered Before You Start

• You can adapt the coding provided in the SAP-samples repository according to your needs. The coding is provided without any warranty for damages and is not part of any support contract that you might have with SAP.
• Please make sure that the implementation that we provide fits with other implementations for the same BAdI or methods that are part of this BAdI that you might already have in use. For this sample implementation, the CHECK_BEFORE_RELEASE method is implemented.
• If you already use gCTS when you start implementing the BAdI, we recommend that you first implement the BAdI before you start registering repositories and objects.
• If you haven’t used gCTS before, you should have at least one repository available to test the BAdI implementation later on.
• In the sample implementation of the BAdI, you can find some comments that explain the coding a bit. This could give some hints in case you want to adapt the coding. The sample coding should be good for most use cases.
• When you have the BAdI implementation in use, full objects will be committed if an object is not part of the respective repository, yet. This will also happen if you task only contains partial objects and this commit might then include partial objects that are part of another task.

Prerequisites

The process described above, and the implementation instructions below require the following:

• Your system is on SAP S/4HANA 2020 FPS02 at least.
• Your system uses R3trans 27.06.2022 at least. Check SAP Note 3218051 – Cannot load class in gCTS – anonymized fields AUTHOR, CREATED_ON and CHANGED_BY after pull from git repository
• gCTS is configured (this blog post does not explain gCTS configuration). See: Configuring Git-Enabled Change and Transport System
• Check SAP Note 3046346 – gCTS Registry: Central Note and make sure that the latest updates and fixes for the registry are available in your system.
• (Optional): Configuration of the registry as described on the SAP Help Portal at Configure the gCTS Registry.
• Implement SAP Note 3204481 – gCTS: Fix for missing objects when importing into a repository with a subdirectory

Constraints

• The registry cannot be used together with Change Request Management of SAP Solution Manager.
• Error message texts issued by the BAdI are provided in English only. These texts are directly integrated in the coding. If you need to translate the message, you need to convert the texts in the BAdI into text elements and then translate them yourself.
• The BAdI implementation changes the behavior of gCTS to creating commits when a task is released. Committing on transport request level and using the registry entries for committing at the same time is not possible.
• It might happen if you use ADT for releasing tasks that some exceptions under special conditions are displayed properly.
• When you have the BAdI implementation in use, full objects will be committed if an object is not part of the respective repository, yet. This will also happen if you task only contains partial objects and this commit might then include partial objects that are part of another task.

Get the Coding into Your System

To be able to start using the registry in your development process, you can use sample coding that is provided in the following SAP-samples repository on GitHub: https://github.com/SAP-samples/s4hana-gcts-badi.
You only need to implement the BAdI in your development systems.
Note that this coding is provided without any warranty and is not part of SAP standard support. If you find issues or have ideas about how to improve the implementation, please feel free to implement that and create a pull request. This is an open source implementation and we are looking forward to your contributions. You can create issues also inside the repository. Please check the Readme for details.
The repository is public. You can connect your system directly to it. If you plan to adapt the coding, we recommend that you create your own fork of the sample repository. To get the coding into your systems, proceed as follows:

1. (only if you plan to adapt the coding) Create your fork of https://github.com/SAP-samples/s4hana-gcts-badi.
2. Connect your development system to this (forked if needed) repository. Use an own vSID that you don’t have in use for any of your existing repositories and don’t plan to use in the future. Do not use SAP as vSID when you create the repository.
3. Clone the repository to your system. (Remember to store credentials in the gCTS app for your Git provider so that the forked repository can be accessed from the ABAP system if you use a fork of the sample repository).
4. (only if you plan to adapt the coding) Set the VCS_AUTOMATIC_PULL and VCS_AUTOMATIC_PUSH parameters for this repository to false. Before committing your changes, you must make sure that you have the latest coding available from the sample repository merged into your forked repository. If changes that you did and the updates that you receive from the sample repository concern the same coding, the resulting conflicts should be detected.
5. (only if you plan to adapt the coding) When you clone the forked repository, the coding for an implementation of the BAdI CTS_REQUEST_CHECK will be imported into your ABAP system. To find it, open transaction SE18 and enter CTS_REQUEST_CHECK as the BAdI Name.
6. (only if you plan to adapt the coding) Click on Display.
   
7. (only if you plan to adapt the coding) Choose Implementation -> Display.
   
8. (only if you plan to adapt the coding) You will most probably see several implementations of this BAdI in your system. Select the ZGCTS_BADI implementation.
   

When you´ve cloned the repository, the implementation has been imported in an inactive state. Don’t activate it right after cloning it. You first need to do some configurations for this BAdI implementation, and maybe you also might want to adapt the coding. If you activate the implementation directly after the deployment, it will not affect your release process. But as soon as you set any toggle, this will have immediate effects. We therefore recommend that you first go through the toggles, decide on the settings that you need and only activate the implementation as the last step.

Configure the BAdI Implementation to Your Needs

After having cloned the repository to your system, you will find the view ZGCTS_BADI_TOGGL in transaction SM30. In there, you define how you want the BAdI to behave before you use it. The view provides the following options:

List of toggles

You can turn different features on or off. Some require additional parameters, if turned on. Some are mandatory to make the implementation work at all. The following list explains what the features are made for and how you can set them:

BADI_GCTS_ENABLE_TRIGGER:

Toggle to activate the BAdI implementation .
You must define the prerequisites that need to be fulfilled so that the BAdI is executed. If you don´t set the flag and don´t provide a scope, the BAdI implementation won´t have any effect on your development process – even if you activate the implementation in SE18.
You have three options to name conditions that will trigger the execution of the BAdI by setting the scope parameter with one of the following values:

• USER: With this parameter, you can add an array of names of users that will use the BAdI in the format “user”:[“<USER1>”,”<USER2>”], and you can use a table in which you store user names in the format “table”:”MY_TABLE”. If you use table, the table needs to have a hard-coded column: Use BNAME from the usr02 table. For example, you could have a table called ZUSER_TABLE_BADI:
  
  The entry in the configuration would look like this (with all possible options to define which users will use the BAdI):

  {"scope":"USER","user":["ME","AND","YOU"],"table":"ZUSER_TABLE_BADI"}

  You can add 255 characters into this field directly in the view. If you need more characters (more users), then you can maintain the table. You can also create a program that provides the user names. But if you need to enter many users, we recommend that you use the table option instead. If you name single users, write them in upper case.

• TRANSPORT: When a task is released, it is checked in Transport Management System (TMS) whether the target system of the transport request is a non-ABAP system of type VCS, that is, the parameter NON_ABAP_SYSTEM has the value VCS. Only if this is the case, the BAdI will be executed. It doesn’t matter which user releases the transport. You can set this scope to enable task based committing for all users. Do not enable the toggle REPOSITORY_RELATION_IDENTIFIER in that case – you can find more details about this toggle further down in this blog post.
  
  The syntax would look as follows:

  {"scope":"TRANSPORT"} 

• OBJECTS: With this parameter, the BAdI will only be executed for certain objects. You need to provide details where you want the objects to be looked up. You can use the registry or the object list of the repositories (localObjectList). If you use localObjectList, the object lists of all local repositories will be checked and the objects will be committed into the repository into which they were committed previously. If you provide both, the registry is checked first. The syntax could look as follows:

  {"scope":"OBJECTS", "registry":true, "localObjectList":true} ​

  For sure, you can leave out either “registry”:true or “localObjectList”:true.
  We recommend that you use the scope Objects when you make use of the BAdI implementation for your development process with the registry integrated in it. Use it without the parameter localObjectList whenever possible as this influences the performance a lot

BRANCH_CREATE_TOGGLE

Toggle to create a new branch if no branch exists that matches the criteria provided by the BRANCH_HANDLING_ENABLE toggle. The new branch will be named as defined in the BRANCH_HANDLING_ENABLE toggle.

BRANCH_HANDLING_ENABLE

Toggle to switch to the branch that is defined in the Additional Feature column. The switch is done if a branch exists that matches with what is defined in the Additional Feature column. If there is no branch available that fits to that, the branch switch is only done if the toggle BRANCH_CREATE_TOGGLE is activated.
You have the following options to provide a value for the branch name:

• A static/hardcoded value in the Additional Feature column, for example: Rel-756
• • Dynamic ways of providing branch names:
  • rel-{release}: release will be automatically filled with the SAP_BASIS version of the current ABAP system.
  • rel-{attribute}: attribute will automatically be filled with the GIT_BRANCH attribute in the transport request. This attribute GIT_BRANCH is available in the standard starting with SAP S/4HANA 2021. If you work with SAP S/4HANA 2020, you can create that transport request attribute yourself in transaction SE03
  • {“syntax”: “rel-{parameter}-<HARDCODED>”, “parameter”: {“table”:”CVERS”, “column”:”COMPONENT”, “key”: “HARD_CODED_CVERS_Component_name”} }: A dynamic way of providing a json string so that a component can be chosen from the CVERS table of the current ABAP system.

CHECK _PERMISSION:

Toggle to a check if the user releasing the transport is a valid user on a Git provider. This requires that credentials for the Git provider exist in the credentials store of the gCTS app.

CHECK_REPOSITORY_CHANGES_PULLED

Toggle to check that the status of the repository is not CHECKOUT before committing the released transport. Before pushes are possible again, you must pull the latest commit from the remote repository (for example, by using Update to Latest Commit) to get the repository in status READY. Only after that, commits are possible again.

CHECK_REPOSITORY_OBJECT_LIST

Toggle to check if the objects that are part of the transport request are activate and if one or several objects are part of different transport requests. This check needs to be executed by the BAdI implementation, as well – not only by the Transport Organizer to make sure that the check is done before commits are created.

CHECK_REPOSITORY_STATUS

Toggle to check the following for the repository:

• Check if the repository status is ‘READY’. Pushes are only possible if the repository is in status ‘READY’ in the ABAP layer.
• Check the technical status of the local Git repository on the operating system/file system. (Communication between ABAP layer and Git client will also be evaluated for exceptions). Pushes are only possible if the status is SAFE. This status is provided by the Git client (abap2vcs.jar).
• Check, if there are any open (that is, unresolved) conflicts in the repository. It is not checked whether the task that you are going to release will cause new conflicts.

CHECK_REPOSITORY_TARGET_SYSTEM

Toggle to check whether the transport request and the repository to which the objects are to be committed have the same target system (in case of synchronous commit). In case of an asynchronous commit, along with the above check an additional check will make sure that the target system specified in the transport request is unique in a repository. If the transport request has no target system (local transport requests) then the check will be passed.

CHECK_REPOSITORY_USER_PERMISSION

Toggle to check, when you release a task, whether you have the permission to push objects to the repository to which you want to commit the objects. This means that on the Git side, you are either the owner of a repository or a collaborator. If you are not authorized, an error will be shown and the task will remain open.

CHECK_REPOSITORY_VSID

Toggle to check whether the parameter NON_ABAP_SYSTEM is set to VCS in the TMS configuration of the target system of the transport request. It is also checked whether the target repository of the transport request is the same as the repository for which an object is registered. If this is not the case, an error will be shown. With this, an object will not be committed into two different repositories. You should always set this toggle if you make use of the registry. You can then use the same vSID for all your repositories. If the target system is empty for the transport request this check is skipped even if the check is turned on in the configuration. The transport layer of the package or the target system of a customizing transport request is ignored in this case.

REPOSITORY_ASYNC_COMMIT

Toggle to decide whether the push to the remote repository is done synchronously or asynchronously. This includes that the target system is checked whether it is unique . This check is needed to make sure that the objects are committed to just one repository. For asynchronous commits, the observer job is executing the commit and would accrete the commit in all repositories that sue the respective vSID.
If you do not set that flag, a synchronous commit will be executed. The commit will be executed by the current user. In case of asynchronous commit, the user who runs the observer job will execute the commit. Asynchronous commits are what you might know if you´ve already worked with gCTS before, without the registry. This includes that the observer job is called when you release a task. If you already used that way of committing and have set up the observer job in the recommended way, which is using a technical user to run the observer job etc., you can set this toggle.
If you are new to gCTS and you start immediately with the registry, we recommend that you do not set this option and start with synchronous commits.
Synchronous commits may fail due to a timeout if many large objects are to be committed at once because they are part of the same task. The assumption is that tasks normally don’t contain a lot of objects and therefore synchronous commits should be ok as a default, and timeouts should not be an issue. If you nevertheless experience timeouts, you can switch on that toggle at any time. If you still would like to use synchronous commits (e.g. because in this case, the commits are done by the ‘real’ user and not by the one who runs the observer job), but expect to have many objects in tasks so that synchronous commits cannot be done, you would need to implement a detection of broken commits and a possibility to resume them. This is not part of this sample implementation. Another issue may be that you must ensure that for each repository only one commit runs at a time, so concurrent commits must be either avoided or serialized.
This toggle is also used for the target system check. It is checked if the system represented by the vSID is in TMS is a virtual non-ABAP system (TMS parameter NON_ABAP_SYSTEM) of type VCS. If you enable this asynchronous commit and you have also enabled the toggle CHECK_REPOSITORY_TARGET_SYSTEM, the uniqueness of the vSID is also verified.

REPOSITORY_RELATION_IDENTIFIER

Toggle to define the strategy to decide about the object-to-repository relationship. If the toggle is turned off, then the transport layer of the transport request will be evaluated to determine the target repository.
You can define the log level for the strategy. Info or error are possible. If you set the log level to info , a task will be released even if the object is not found in the registry. This would mean that the task is closed, but no commit will be created if the strategy that you defined cannot find the object and the related repository. In this case, you must change the respective objects again to have a new task available that you can release so that the changed objects are pushed to the repositories. If you choose log level error, then an error message will show up if the object cannot be assigned to a repository, when you release the task. No commit will be created, and the task will remain open. We recommend that you use the log level error. Otherwise, changes will not be pushed when a task is released
The following strategies are possible:

• SINGLE: Checks if the objects in the task exist in the registry.
• PACKAGE: Searches for objects and their related upper packages in the registry.
• RECURSIVE_PACKAGE: Searches for objects or related super packages, or all parent packages of the objects in the task.
• FULL: Searches for objects, packages, or all parent packages on the local system if the object does not exist in registry either. This is a very intensive check and could lead to long checking times.
• STATIC: You have to provide the name of the package (just one package is possible). If you want to use this option, you need to adapt the coding of the BAdI.

Recommended Settings to Start with the Registry for Your Own Workbench Development

When you are new to the registry, we recommend that you first test your settings for the BAdI and how the development process works. The easiest way to do so is to start with one (playground) package. For this, you can use the following settings for the different toggles:
BADI_GCTS_ENABLE_TRIGGER: TRANSPORT
BRANCH_HANDLING_ENABLE: turn off
BRANCH_CREATE_TOGGLE: turn off
CHECK_PERMISSION: turn on
CHECK_REPOSITORY_CHANGES_PULLED: turn on
CHECK_REPOSITORY_OBJECT_LIST: turn on
CHECK_REPOSITORY_STATUS: turn on
CHECK_REPOSITORY_TARGET_SYSTEM: turn on
CHECK_REPOSITORY_USER_PERMISSION
CHECK_REPOSITORY_VSID: turned off
REPOSITORY_ASYNC_COMMIT: turn on
REPOSITORY_RELATION_IDENTIFIER: {“strategy”: “PACKAGE”, “level”: “error”}
After making these settings you can register the package with all its objects (FULL PACKAGE) in the registry.

Register package

Recommended Settings to Start With the Registry for Customizing

When you are new to the registry and would like to test the process of changing Customizing objects, the easiest way to do so is to start with some Customizing settings that you plan to change but which don’t have big impact. Changing some customer addresses might be an example. For this, we recommend the following settings for the BAdI toggles:
BADI_GCTS_ENABLE_TRIGGER: TRANSPORT
BRANCH_HANDLING_ENABLE: turn off
BRANCH_CREATE_TOGGLE: turn off
CHECK_PERMISSION: turn on
CHECK_REPOSITORY_CHANGES_PULLED: turn on
CHECK_REPOSITORY_OBJECT_LIST: turn on
CHECK_REPOSITORY_STATUS: turn on
CHECK_REPOSITORY_TARGET_SYSTEM: turn on
CHECK_REPOSITORY_USER_PERMISSION
CHECK_REPOSITORY_VSID: leave turned off
REPOSITORY_ASYNC_COMMIT: turn on
REPOSITORY_RELATION_IDENTIFIER: {“strategy”: “SINGLE”, “level”: “error”}

After making these settings, register the existing customer addresses. You can register them by registering older transport requests that contain Customizing entries of the customer addresses.
The strategy SINGLE is the only one that can directly be used for customizing as there are no packages in customizing. Nevertheless, you can also use e.g. PACKAGE to work with customizing. This includes al individually registered objects. So strategy SINGLE is part of strategy PACKAGE

Recommended Settings for Productive Usage of the Registry for Development and Customizing

BADI_GCTS_ENABLE_TRIGGER: {“scope”:”OBJECTS”, “registry”: true}
BRANCH_HANDLING_ENABLE: turn off
BRANCH_CREATE_TOGGLE: turn off
CHECK_PERMISSION: turn on
CHECK_REPOSITORY_CHANGES_PULLED: turn on
CHECK_REPOSITORY_OBJECT_LIST: turn on
CHECK_REPOSITORY_STATUS: turn on
CHECK_REPOSITORY_TARGET_SYSTEM: turn on
CHECK_REPOSITORY_USER_PERMISSION
CHECK_REPOSITORY_VSID: leave turned off
REPOSITORY_ASYNC_COMMIT: turn on
REPOSITORY_RELATION_IDENTIFIER: PACKAGE

Recommended Settings for task-based committing only (no use of the Registry)

If you plan to use this sample BAdI implementation for task-based committing only, you, for sure, do not need the configure the registry (e.g. no destination in SM59 needed) and you do not need to register any repository or object. Still, you have to add the sample implementation to your development system, and you have to set the parameters in the view ZGCTS_BADI_TOGGL in transaction SM30. For the purpose of task-based committing, we recommend the following settings:

BADI_GCTS_ENABLE_TRIGGER:true. Scope: USER, TRANSPORTS and OBJECTS are possible, for OBJECTS, only the local object list is possible. ‘registry’ cannot be used
BRANCH_CREATE_TOGGLE: (as needed)
BRANCH_HANDLING_ENABLE: (as needed)
CHECK _PERMISSION: true
CHECK_REPOSITORY_CHANGES_PULLED: true
CHECK_REPOSITORY_OBJECT_LIST: true
CHECK_REPOSITORY_STATUS: true
CHECK_REPOSITORY_TARGET_SYSTEM: true
CHECK_REPOSITORY_USER_PERMISSION: true
CHECK_REPOSITORY_VSID: true (but only to check whether the target system is a VCS-System; Registry Check is not relevant)
REPOSITORY_ASYNC_COMMIT: (as needed)
REPOSITORY_RELATION_IDENTIFIER: false (this is the only thing that is really different if you use the sample BAdI implementation for task-based committing only)

Activate the BAdI

When you are done with the configuration, you can activate the BAdI. To do so, open again SE18 and the BAdI implementation ZGCTS_BADI. In there, click on Implementation in the menu bar and choose Activate.

Activate BAdI Implementation

If you need to adapt settings that can be changed using the ZGCTS_BADI_TOGGL view, you can do so at any time.
After completing the configurations (and coding changes, if required) for the BAdI, you can start working with the registry. First, register the repositories as described on SAP Help Portal at Register Git Repositories in the gCTS Registry, then register the objects as described Register ABAP Objects in the gCTS Registry and then: Go ahead with your development!
Yes, you got that right, you can register objects before they even exist. But you can for sure add objects to the registry at any time after they´ve been created.
When the toggles are set, the BAdI implementation is activated and the objects or packages are registered, you can tell your developers that now the registry is on use for the development process. The developers can develop as they are used to. Commits will be created when they release a task. You can set up for example pipelines that start a deployment to a test system and execute tests whenever a new commit is created. This would provide an option to get early feedback or test results during the development phase.
We recommend that you start slowly. Choose a simple development project. Set the toggles in a way that e.g., only some users make use of the registry and gain some experience how the development process now feels like.

Adapt the Coding

You can adapt the coding of the BAdI implementation according to your needs at any time. The following are some points to consider before you start:

• When we described how to get the coding into your system, we recommended that you create your own fork of the sample repository. You can use this repository to commit your coding changes. Please note that the implementation class is currently assigned to the package $TMP for user SAP. Search the class in ADT or transaction SE24 to be able to change it. Change that to the vSID of the forked repository in your system.
• Whenever you change the source code of the BAdI implementation, you need to restart the Transport Organizer (SE09) afterwards. Only after that, the changes will become active in the release process. To get the changes active in ABAP development tools, you need to close the project and reopen it.

Troubleshooting

Issue: When you open the view ZGCTS_BADI_TOGGL in SM30 in edit mode, it is (partly) not editable.
Solution: Generate the view again. To do so, proceed as follows:

1. Open transaction SE11.
2. Enter the table name ZGCTS_BADI_TOGGL and click Change.
   
3. Choose Utilities -> Table Maintenance Generator.
   
4. Click on Change and then Expert Mode.
   
5. Click Select all and then Continue
   
   This will re-generate the maintenance view. Afterwards you should be able to set the options for the different toggles.
   

Issue: Error messages that you tried to fix are still showing up either in transaction SE09 when you release a task or in transaction SLG1 when you look into user logs to find issues. As a result, (depending on your log level) it is possible that tasks cannot be released.
Solution: Restart transaction SE09 and try again to release the task. To get the changes active in ABAP development tools, you need to close the project and reopen it.

Issue: You did changes to the configuration of the BAdI (in SM30 in the view ZGCTS_BADI_TOGGL) or you pulled a new commit. Nevertheless the old configuration or previous coding version still seems to be used when you release a task.
Solution: Make sure that you always restart SE09 when changes had been done. To get the changes active in ABAP development tools, you need to close the project and reopen it.

Issue: you have set the parameters VCS_AUTOMATIC_PULL and VCS_AUTOMATIC_PUSH to false for a repository that you would like to use in the development process as described in this blog post. But when you do so, you get error messages when releasing a task in ADT like com.sap.adt.communication.exceptions.SystemFailureException: System failure: ” Status check failed for repository me-myrepo”; Destination data=XYZ_000_userx_en {client=000, language=EN, user=USERX, systemConfiguration={Name={null}.
Solution: First, you need to make sure that you have activated at least the commit ‘Fix for authentication problem and enable use of auto push and pull’ for the repository s4hana-gcts-badi

Commit required to use conflict resolution

In addition, to be able to use the BAdI implementation in conflict resolution scenarios, parameters in the SM30-view GCTS_BADI_TOGGLE have to be set in a specific way. You have to turn off the checks CHECK_REPOSITORY_CHANGES_PULLED and CHECK_REPOSITORY_STATUS.

Parameter settings required for conflict resolution

Issue: error messages that you can see e.g. when releasing a transport task are very short and not all the relevant information seems to be provided.
Solution: check in transaction SLG1 if you can find more information. Enter CTS as Object and ABAPVCS as Subobject.

Transaction SLG1

More information how to find issues is also available in a Guided Answer

Links

Documentation on SAP Help Portal: gCTS Registry

Repository in SAP-Samples: https://github.com/SAP-samples/s4hana-gcts-badi