# gCTS gCTS is an offering from SAP that allows us to manage ABAP (Advanced Business Application Programming) change and transport management processes using Git as an external version management system. By integrating Git with the traditional SAP transport system, gCTS enables developers to leverage Git's powerful version control capabilities, branching strategies, and collaboration features in the context of SAP ABAP development. ### **Key Features** * **Git Integration:** gCTS integrates Git repositories with SAP systems, allowing ABAP developers to store their source code, configurations, and other development artifacts in Git repositories. * **Version Control:** Developers can take advantage of Git's version control features, such as branching, merging, and code reviews, to manage ABAP source code changes more efficiently. * **Continuous Integration and Delivery (CI/CD):** By using Git and gCTS, SAP customers can set up CI/CD pipelines for ABAP development. This enables automation of testing, deployment, and release processes, leading to faster and more reliable software delivery. * **Collaboration:** Developers can collaborate more effectively by using Git's collaboration features, such as pull requests and code reviews, to review and discuss code changes before they are merged into the main codebase. * **Traceability and Auditing:** gCTS provides traceability and auditing capabilities, allowing organizations to track changes made to the SAP systems and ensuring compliance with regulatory requirements. ### **gCTS Integration with ReleaseOwl** The integration of gCTS (Git-enabled Change and Transport System) with ReleaseOwl is a powerful combination for SAP customers. By integrating gCTS with ReleaseOwl, organizations can leverage the functionalities of Git repositories and establish robust Continuous Integration and Continuous Delivery (CI/CD) processes for their ABAP (Advanced Business Application Programming) development. The integration of gCTS with ReleaseOwl offers a streamlined and efficient approach to managing ABAP development, enabling organizations to deliver high-quality SAP applications faster, with reduced risks, and improved collaboration among team members. To enable gCTS we require a Git platform host, an ABAP system in which code will be developed, and a CI server (which is optional) which can be used to automate development cycle. ### **Prerequisites** Before starting the gCTS configuration, ensure the following prerequisites are met: * An **SAP S/4 HANA 1909 or 2022 system** * An **SAP machine** (with version **11 or higher**) or comparable **JRE** * Import the **relevant SAP Central Note** (based on the SP level of your system) * Create **gCTS-related working directories** at the OS level ### **Configuration Steps** Once the prerequisites are met and the ABAP system is ready, proceed with the configuration which consists of **three major steps**: 1. **gCTS Configuration on ABAP System** 2. **Git Enablement** 3. **CI/CD Pipeline Configuration in ReleaseOwl** ### **Steps in the ABAP System to Complete the gCTS Configuration** 1. Validate Required SAP Notes 2. Authorizations 3. Validate Required Ports 4. gCTS Fiori UI Enablement 5. Set Parameters and Initialize Systems ### **Systems in use here to guide the user the steps involved** * Access to either GitHub or BitBucket * Access to the gCTS environment of SAP (S4 2022). Here – S4D (main Dev system), S4Q (QA system) and S4V (virtual system for production). * Each package should be linked to one repository. ### **Steps Involved in gCTS Configuration with GitHub** 1. Create a new repository in GitHub. (Example: `ZKRK_GCTS_SALES.` ) 2. Open the **gCTS environment** for SAP using the **Fiori app URL**. 3. Log in using your **SAP gCTS ABAP system credentials**. 4. A **blank screen** is displayed by default upon successful login.

5. **Search for:** `gcts` in the Fiori Launchpad. 6. **Select:** **Git-enabled CTS – Manage Repositories**.

7. All **existing repositories** linked to the current gCTS environment are displayed.

8. Click on **Create** to initiate repository creation.

9. Fill the required details as follows: | **Field** | **Description** | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **URL** | Enter the URL of the GIT repository you want to link with the SAP gCTS environment. | | **Description** | Enter a relevant description, or keep the default description text. | | **vSID** |

Enter any name of your choice. A virtual system with this name will be created in the Transport Route.

Note: Each unique GIT repository requires its own virtual system in SAP gCTS.

10. Click **Save**. A new repository gets created. 11. Upon repository creation: * A new **transport layer** is automatically created. * This transport layer appears under the **Configuration** tab parameters. * The naming convention used is `Z` where `` is the system ID. * It is also visible in the **Transport Routes** screen.

### Repository Authorization and Configuration 12. **Authorization is required to clone the repository:** * Navigate to the **Configuration** tab. * Click **Create**.

* Add the following two parameters: * `CLIENT_VCS_AUTH_USER`: Enter the GitHub user ID in the **Value** field. * `CLIENT_VCS_AUTH_TOKEN`: Enter the GitHub personal access token.

13. Both parameters will appear in the configuration list.

### GitHub Branch Setup 14. Create required branches in GitHub: * `dev` branch from `main` * `qa` branch from `dev`

### Repository Cloning and Development in SAP 1. Navigate to the **SAP gCTS** application.

2. Clone the ABAP system repository with the one created in **GitHub**. * This creates a **local copy** of the GitHub repository in the SAP ABAP system. * The **latest commits** from GitHub become visible in the local repository.

3. For every repository: * The **default active branch** in SAP gCTS is `main`. * Any changes made in SAP will be saved to this branch by default. * Based on the requirement, the **active branch** can be changed (e.g., set to `dev` instead of `main`).

4. Create the **same package** in the SAP ABAP system as defined in the gCTS environment.

5. Enter all the required details: * Select the **transport layer** created during the repository creation in gCTS. * Click **Save**.

6. The system prompts the user to **create a transport request**: * Create a new transport request. * Click **Save**.

7. Now, **create a class** in the same package: * Enter all the required details. * Choose the appropriate package. * Click **Save**.

8. The system prompts to associate the class with a **transport request**: * Select the newly created transport request. * Save the changes. * Make required changes to the class. * Save and **activate** the objects.

9. **Release the task** associated with the transport request in use.

### Integration of SAP gCTS with ReleaseOwl and GitHub 1. Register the **Transport Manager Credential** in the Credential Manager section in **ReleaseOwl**.

2. Register the **Transport Domain Controller** in ReleaseOwl: * Click **Get Repositories** to fetch all systems available in the system landscape. * The newly created SAP system ID (e.g., **RKS**) will be listed.

3. Register the **GITHub** credential in the **Credential** **Manager.**

{% hint style="info" %} **Note: GITHub APIs** can be **accessed** only via **Personal Access Tokens** and **not** by **username** and **password.** For further information on the **Personal Access Tokens, please refer to the link -** [**https://docs.github.com/en/enterprise-server@3.4/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token**](https://docs.github.com/en/enterprise-server@3.4/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) {% endhint %} 4. Register the **dev** **ABAP** **system** in **ReleaseOwl** as follows: * Ensure to select the role as **Development**. * Choose the appropriate credential for each repository. * The SAP system should be the actual **Development system** (e.g., **S4D**) and **not** the gCTS Virtual System (e.g., **RKD**).

5. Set up the **QA gCTS system** for transporting changes from Dev to QA: * Set up the QA gCTS system to enable transport of changes from **Dev** to **QA**. * Log in to the QA SAP gCTS system using SAP ABAP credentials and follow the same configuration steps as performed for the Dev gCTS system.

6. Create a **repository** in QA with the **same name** as in Dev. * Fill in the required details accordingly. | **Field** | **Description** | | --------------- | ------------------------------------------------------------------------------------------ | | **URL** | Enter the URL of the GIT repository that you want to link with the SAP gCTS environment. | | **Description** | Enter a relevant description, or keep the default description text. | | **vSID** | Enter the name of the virtual system that was created in the SAP gCTS **Dev** environment. | | **Role** | Select **Provided**. | | **Type** | Select **GitHub**. | | **Visibility** | You can choose either one: **Public** or **Private**. |

7. Add two configuration parameters in QA as done in Dev: * `CLIENT_VCS_AUTH_USER` * `CLIENT_VCS_AUTH_TOKEN`

8. Clone the repository in **SAP gCTS (QA)** environment to the ABAP system.

9. Switch the **active branch** from `main` to `qa`.

10. Register the same ABAP system in **ReleaseOwl** for QA: * Login to ReleaseOwl and add a new ABAP system. * Select the role as **Provided**. * Choose the appropriate credential for each repository. * The SAP system should be the actual **QA system** (e.g., **S4Q**) and **not** the gCTS Virtual System (e.g., **RKS**).

11. Add the appropriate **SAP ABAP environment** to the active project in ReleaseOwl.

12. Create a **User Story** in ReleaseOwl.

13. Add the **Transport Request** to the user story and save the changes.

14. **Release** the **transport** **request** from **ReleaseOwl**.

15. Once the transport request is released: * The associated **commits** can be viewed. * In GitHub, refresh the repository — the new objects will now be visible in the **dev** branch.

{% hint style="info" %} **Note:** Whenever a **transport request** which is **associated** with **gCTS** is **released**, all the **changes** will be **pushed** to **GIT**. {% endhint %} 16. The changes **will not be pushed to QA** until the transport request is imported into QA. 17. Create a **Release Pipeline** in ReleaseOwl: * Add a **Deployment Task**. * Save the pipeline.

18. Associate the release pipeline with the active **Project Settings** in ReleaseOwl.

19. Grant **Deployment Permissions** to the user: * Navigate to: **Project Settings > Users > Security**. * Without this, deployment will not proceed.

20. Promote the **User Story to QA**: * Click **OK**.

* Check for any **Approval Tasks** that may be pending for **deployment** to take place.

21. Once the **approver** **approves** the **task**, the **deployment** **starts**.

22. Click on **Go to Pipeline Activity**.

23. **Check** the **Deployment Logs.**

24. The gCTS task details are visible directly in the pipeline activity logs. This links the deployment to specific **gCTS tasks**, supporting traceability and audits.

25. When you click **“View gCTS Switch Details”** in ReleaseOwl (Pipeline Activity > Logs), you can view metadata related to the gCTS operation for the associated deployment.

26. **Validation Report:** * Click on the **Validation Report** button for the selected User Story. * After Validating, you will find two tabs: * **TR Report**: Displays the details of the Transport Requests linked to the User Story. * **ATC Report**: Displays the ABAP Test Cockpit (ATC) results, highlighting any code quality or compliance issues. * **Release Status Check** * Under the **TR Report** tab, you will find: * **Release Status Check**:\ Shows whether all the linked transports have passed the required checks. * **Status: Success** indicates everything is in order. * **gCTS Sequence Check (Beta)** * The **Sequence Check (Beta)** option is located beside the **Release Status Check**. * It is used to validate object-level transport sequences during the validation process for gCTS transports. * The system displays a detailed list of all associated transports along with an overall summary view, enabling easier analysis of transport dependencies. * If the sequence check fails due to dependency issues, the system displays the recommended transport sequence required for successful deployment.

27. When you click on the **gCTS Sequence Check (Beta)**: * You will see two sections: 1. **Transport Sequence Dependency** * This section shows the dependencies between different transport requests.

2. **Valid Transport Sequence** * This feature is used to validate the order in which SAP transport requests should be imported to avoid inconsistencies or errors in the target system.

28. Once deployment is successful: * Verify that changes are pushed to the **qa branch** in GitHub. * Login to **SAP gCTS (QA)** and confirm that the latest **commits** are available. 29. Login to **S4Q (QA) ABAP system**: * On the **first transport**, the package, class, and objects will be pushed to QA ABAP. * On **subsequent transports**, only the changed objects will be updated in both: * SAP QA **gCTS Fiori** * SAP QA **ABAP system** {% hint style="info" %} **Note:** * Without ReleaseOwl, changes must be **manually pulled** into SAP QA ABAP from gCTS Fiori. * With ReleaseOwl, this process is **automated**, pushing changes to both SAP QA gCTS and ABAP systems upon transport release. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://releaseowl.gitbook.io/releaseowl-docs/releaseowl-user-guide/sap-on-premise/gcts.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.