Introduction
This blog series is meant to help you to plan and set up your landscape and life cycle management in SAP Business Technology Platform (BTP) ABAP Environment - formerly known as SAP Cloud Platform, ABAP Environment - since this differs from the setup you are used to in on premise ABAP systems.
It is based on the blog post Software Lifecycle Management for SAP Cloud Platform ABAP Environment by thomas.schneider and on tests that we have performed in the integration team that is testing SAP BTP ABAP environment end-2-end.
You will learn which role software components do play here and which possibilities you have for transportation of your developments from your development system into your production system.
In a second blog post SAP Cloud Platform, ABAP Environment – Lifecycle Management - sample scenarios for three different system landscapes it is discussed how these can address the needs in your development project in the ABAP environment of SAP Cloud Platform.
Some examples for the most common use cases and setups will be explained as well.
Software Components
Your development, including transportation, is organized and managed in so-called software components. A software component is designed to contain all coding and development objects of at least one application and should be runnable itself.
Example:
I am using a software component to organize the development of my new tool The RAP Generator. For this I have created a software component called ZRAP_GENERATOR_SWC using the SAP Fiori app Manage Software Components.
The Manage Software Component app lets me search for the software component using a search field.
When a software component is created using the Manage Software Component app this in turn creates a top-level package ZRAP_GENERATOR_SWC of type structure in your ABAP system.
Within this structure package I have created two sub-packages of type development
- ZRAP_BO_GENERATOR (sub-package, type Development)
- ZRAP_NODE_PROXY (sub-package, type Development)
Note that your development can also be loosely coupled in different software components.
You must not create objects in the structure package. You have to create a sub-package of type development first to start developing.
You should consider the following restrictions:
- Objects of one software component cannot be used in another software component by default because software components provide their functionality via explicitly released APIs to other software components. This means you must set the API state of the object to “Released” if you want to use an object from another software component (see Released APIs , Finding Released APIs and Deprecated Objects).
- Software components should not have cyclic dependencies (objects in software component A use objects in software component B, and vice versa). If you create dependencies between software components, we recommend that you do this in a layered way, for example, for grouping basic re-use functions in a dedicated software component.
- You cannot move development objects from one software component to another. Thus, the introduction of software components should be planned carefully.
- You can use the same ABAP systems regarding development, testing, and production (your system landscape) for all your software components. Lifecycle processes for software components can even be independent from each other, as long as there are no development dependencies.
You create your software components in the development system:
- The software component ZLOCAL is available by default. It serves a similar role like $TMP in an on-premise system. Note that objects assigned to this software component cannot be transported or moved to your custom software component. In contrast to on-premise, changes of ZLOCAL objects are always recorded in local transport requests.
- Create your software components with the SAP Fiori app Manage Software Components (Business Catalog Lifecycle Management - Software Components SAP_A4C_BC_MSCL_PC). Afterwards, pull the software component into the ABAP system to start developing in it.
You can use an ABAP namespace in the ABAP environment. If you have registered a namespace at SAP, it is automatically provided during provisioning. For more information on namespaces, see SAP note How to reserve a namespace and ONE Support Launchpad application Development Namespace Application. A developer key and repair key are created and assigned automatically by the ABAP system. In the namespace application, you can search for your key assignments by filtering for installation number = “CLOUDSYSTM” . - If you want to transport business configuration content across ABAP systems, create a software component of type “Business Configuration”. For details on how to work with business configuration data, see Business Configuration for SAP BTP ABAP Environment.
Transportation Mechanisms
There are two git-based transport mechanisms in the ABAP environment.
Git-based CTS (gCTS) is the evolution of the classical Change and Transport Management System (CTS). It is the recommended approach for transporting objects between ABAP systems in your global account. It offers built-in and easy to use functionalities provided by the Manage Software Components app in your SAP Fiori launchpad.
abapGit is an open-source Git client that allows you to import existing code into your ABAP system. You should use it for the following use cases:
- Migrate on-premise code to the cloud. See Use abapGit to Transform ABAP Source Code to the Cloud
- Transfer your code from the cloud to on premise. See Transfer Your ABAP Source Code With SAP BTP ABAP Environment via abapGit
- Export your code when the development ABAP system is decommissioned
- Transfer your code from one cloud to another to share it with others, for example as open source, or from a partner to a customer account
- Implement mechanisms for distributed development and testing in dedicated development/test ABAP systems. This could be useful for special projects such as proof of concepts or features that are dependent on regular development of a solution but shall run independent from its lifecycle.
To learn more about abapGit, see Working with abapGit.
In this blog post, we focus on gCTS.
For a quick start on transportation, see tutorial Transport a Software Component Between Two ABAP Systems.
Basic concepts and terms
To better understand how software lifecycle management with gCTS in the ABAP environment can be implemented, let’s start off with some basic concepts and terms.
Classical Git
- Git
Git is a distributed version-control system.
Distributed version control is a form in which development objects and all their versions and metadata are mirrored from a central place to every developer's computer. The developer can switch locally and offline between different versions and change all of them before updating the central originals later.
Online version of GitPro book, GitPro Glossary
- Repository
A Repository is a collection of objects, their directory structure, and metadata, for example, a historical record of changes in the repository, a set of commit objects, and a set of references to commit objects.
The central place that all objects are mirrored from and saved to, after having finished changes on a developer’s computer, is the so-called remote repository. Every developer’s computer holds a so-called local repository to work on.
- Branches
Git repository branches can be used to control the flow of changes through the test and production landscape. They are used to separate changes from each other, which shall or might not be delivered together (i.e. development vs. correction, feature A vs. feature B). A branch is created on the current state of another branch, the parent branch, and reflected by a new copy of all included objects. Depending on which branch is supposed to be changed, the corresponding copy is worked on.
- Pulling
Pulling means getting the code that is currently in the remote repository into the local repository.
- Pushing
Pushing means getting the code that is currently in the local repository into the remote repository.
- Commit
Contains the changed files that were pushed as well as a description and information about which user performed the commit and when.
- Checkout
Checking out means that, if several branches are available, the one that is selected is added to the working tree. The working tree consists of the objects of the branch you are currently working on. It contains the state of these objects since they were last pulled and the changes that were made locally but are not yet pushed to the central remote repository. This checked out branch/working tree is what is displayed in the application to edit the objects.
ABAP and ABAP with gCTS
- ABAP system/ instance
SAP Cloud Platform offers a service called “ABAP System (abap)”. If you want to develop with ABAP in SAP Cloud Platform, you have to create an instance of that service, see Create an ABAP System. This service instance provides the ABAP system that you are developing in. The terms ABAP system and ABAP instance can and are often used synonymously, however, in this blog post, we stick to the term ABAP system.
- Transport requests
In the following example you see the Transport Organizer tab in the ABAP Development Tools for Eclipse. The sreen shot shows the modifiable and released transport requests that belong to the transport target Y52 which has been generated for the software component ZRAP_GENERATOR_SWC. The last released transport request is Y05K901354.
In the Manage Software Component app we can see the number Y05K901354 of the transport request in the Last Commit Message: [Y05K901354] RAP Generator and BO node proxy
Detailed view
Note that transport requests cannot be imported selectively into subsequent ABAP systems but as part of software component branches their changes were added to.
- Releases
A release (for example with the format YYYY-<nn>) is a set of changes that are tested successfully in your quality ABAP system(s) and imported into your production ABAP systems after a release decision. It is represented by a release branch in the Git repository. Once the release decision has been made, you have to create and pull (import) the new release branch into the production ABAP system.
ABAP Environment Specifics
gCTS and the Manage Software Components app in the ABAP environment provide a simplified git, adapted to the possibilities of ABAP. This means:
- There is a remote Git repository for each software component managed by SAP in the cloud. Using the Manage Software Components app, a software component can be created from any ABAP system in the same global account. Alongside with the software component creation, the corresponding remote repository is created. Afterwards, the software component needs to be pulled into the ABAP system. With this step, a corresponding structure package is created in the ABAP system that acts as a local repository so that you can start developing.
(software component = repository in gCTS) - The creation of a Git repository branch is also performed in the Git repository. It does not matter in which ABAP system you create the branch. However, you have to check it out in each ABAP system where you want to use it, be it for development, testing, or productive use.
- In an ABAP system
- there is only one branch of a software component at a time
- all developers work on the same object versions
- an object can be edited by one developer at once
- Pulling a software component does not simply copy object files, but, depending on the object type, also activates the objects (for example a data element) or even generates additional invisible objects in Eclipse (for example authorization artifacts for business catalogs used in business roles).
- You have no merge functionality. If you pull the current branch while changes have been added from another ABAP system, all the changes in the ABAP system the branch is pulled into are discarded. Consequently, you should not work on the same branch in two different ABAP systems.
- Before being able to pull a software component again, or before checking out a different branch, you have to release all open transport requests. There is no way of saving them without releasing, like a git stash.
- Releasing a transport request combines the git actions of committing and pushing.
- A new branch is created remotely in the Git repository. This means, that if the new branch shall be derived from the one currently checked out, changes in the ABAP system that are not yet committed and pushed by releasing the transport that contains these changes are not part of the new branch. The “Last Commit Message” text consists of the Transport Request ID and description, and helps you to ensure that the expected changes are part of the new branch. If you don’t want to hold back any new changes, you must release all open transports before creating a new branch.
- In case you need discard changes, you have to do this manually. This can be done with the help of the “History” view in Eclipse, which offers a compare editor to revert to the last transported version. Afterwards, you have to remove all the discarded objects from their modifiable transport request in the “Transport Organizer” view.
- Branches cannot be deleted or set to “obsolete”, therefore consumers have to be informed about a branch that they shall not use, for example, if you skipped a release branch that could not be finished in time.
- Basic change logging using the “traditional” ABAP server capabilities is available in the development ABAP system: e.g. the Revision History for ABAP objects and the Responsible and Last Changed By contacts. However, if you de-provision the development ABAP system, this information is lost. The Git repository still stores the version (see section “Audit”) and the person who released the transport request(s) but the information on the Last Changed By contact per object is only available in the development ABAP system.
- You cannot work offline because you need access to the ABAP system.
Setting Up and Working with your Landscape
In general, the number of ABAP systems in your landscape is the result of the processes (development (DEV), quality assurance (QAS), and production (PRD)) that need to run in parallel and the number of branches of your biggest software component that is worked on or tested in parallel.
No. ABAP systems = (No. Branches x DEV) + (No. Branches x QAS) + No. PRD
This is due to the fact that an ABAP system always checks out only one branch of a software component. Yet, several software components represented by one branch can run in one ABAP system in parallel.
Required Tools
Different actions require different tools. In the process descriptions, the following tools are used:
- SAP Cloud Platform Cockpit (web-based administration interface)
- Maintain Business Roles (SAP Fiori app)
- Maintain Business Users (SAP Fiori app)
- Manage Software Components (SAP Fiori app)
- Eclipse Tool for the ABAP Environment is an Eclipse installation with our ABAP Development Tools (ADT) plugin (see Installation Guide), shortened to “Eclipse with ADT” in this document
- Custom SAP Fiori apps: These apps are the result/aim of your development
- External test tools (e.g. for OData tests)
- External documentation tool to document test results and release decision if required
Required Business Roles
Different actions require different roles as well. In the process description, the following role proposals are used:
- System Administrator
- Creates ABAP systems in SAP Cloud Platform Cockpit
- Needs authorization for space/ organization management in the SAP Cloud Platform Cloud Foundry subaccount
- User Administrator
- Maintains business roles and assigns users to them
- Needs authorization for business catalogs
| Catalog ID | Catalog Description | Needed for |
| SAP_CORE_BC_IAM_UM | Identity and Access Management – User Management | Creation and maintenance of business users with Manage Business Users app |
| SAP_CORE_BC_IAM_RM | Identity and Access Management –Role Management | Maintain business roles with Manage Business Roles app |
- Release manager
- Performs tasks that are executed centrally for a release, such software component creation and import, making the release decision, approve corrections, creating and releasing transports etc.
- Needs authorization for business catalogs
| Catalog ID | Catalog Description | Needed for |
| SAP_A4C_BC_MSCL_PC | Lifecycle Management - Software Components | Software component creation and import with Manage Software Components app |
| SAP_A4C_BC_TRN_REL_PC | Development - Transport Release Management | Releasing transport requests in Eclipse with ADT |
| SAP_CORE_BC_IAM_UM | Identity and Access Management - User Management | Un-/lock developers for corrections in correction ABAP systems with Manage Business Users app |
| SAP_CORE_BC_IAM_RA | Identity and Access Management – Role Assignment | En-/disable developers for corrections in correction ABAP systems by Role Assignment with Manage Business Users app |
- Developer
- Develops the code and performs tests
- Needs authorization for business catalogs
| Catalog ID | Catalog Description | Needed for |
| SAP_A4C_BC_DEV_PC | Development - ABAP Development Tools | Developing in Eclipse with ADT |
| SAP_A4C_BC_TRN_MNG_PC | Development - Transport Management | Creating transport requests in Eclipse with ADT |
- Tester
- Tests the software
Note: Depending on your organization, the tasks of this role can be performed by automatic test tools, developers, or dedicated persons that are responsible for executing manual tests .
- Needs authorizations for custom business catalogs created via IAM business catalogs for custom apps.
Note: Do not assign catalog SAP_CORE_BC_EXT_TST (Extensibility - Custom Apps and Services) to a tester!
As this catalog is used to provide an easy test of custom apps or their underlying services in a development ABAP system only by adding them automatically to it during activation, real service tests with own catalogs might not be tested securely. In non-development systems, automatic authorization via business catalog SAP_CORE_BC_EXT_TST is not enabled, instead custom authorization is required.
Important Notes
- The creation of a Git repository branch creates a clone of the parent branch. If you create a branch immediately after the release decision, you have a “frozen” state. You can import this state safely into a production ABAP system or multiple production ABAP systems, “pre-production” ABAP systems, etc. or you may use it later for auditing.
- In the different system setups, the ABAP systems can either be provisioned at once upon development start or just in time when needed for the first time for going live, which is the point in time, when the first release is used productively in the production ABAP system.
- A classical 3-system setup comprising a development, quality assurance, and production ABAP system can be enhanced by pre-production ABAP systems, multiple test ABAP systems, etc. Test ABAP systems can be provisioned on demand (temporary) or permanently.
- SAP Managed Tags:
11 Comments
