BTP - Software Components
Software components are a modern part of the ABAP architecture, especially in the ABAP Environment. In this article we will look at working with them.
Table of contents
In this article we will go into the use of software components in the ABAP environment in more detail. How you create them, manage them and what deployment is all about.
Introduction
Software components have been around in SAP development for ages, but as customers we actually only know HOME or LOCAL when it comes to developing our own objects. With the introduction of the ABAP Environment, this has now changed and they are an essential part of the software architecture in development. The “Manage Software Components” app (F3562) is required to create and manage the software components. You can find these in the business catalog SAP_A4C_BC_MSCL_PC (Lifecycle Management - Software Components).
This is where new software components are created and existing components are managed. It is the interface between the ABAP system and the connected Git, as it provides many actions that are also required for release management and transport. The app is also available in test and production systems as it is required for manual deployment.
Creation
Let's create a new software component for testing. To do this, use the “Create” button in the “Manage Software Components” app to open the dialog and fill in the information. We enter the name of the software component and a description.
We leave the URL for an external Git repository blank because we want to use SAP's internal Git server. We'll leave this guy on development as well. Basically there are currently two types:
- Development - Development objects are transported here and maintenance and new releases can be mapped. Role customizing can also be distributed across the component.
- Business Configuration - Can be used to distribute customizing from the "Custom Business Configurations" app.
After creating the software component, we receive the details as well as the current status of the component in the current system.
So that we can now work with the component, we have to clone it into the development system. When cloning, the main branch is checked out for the system, a package is created in the system that has the same name as the software component and is also assigned to it. At the same time, you can also set how the repository behaves in the system (push/pull or just pull).
Once the cloning process has been completed, we can find the actions carried out in the “History”, where we can also navigate to the details. Below we find the branches that exist in the Git repository. When creating a new branch, we only find the “main” branch there and this is also the active branch for further work.
Development
After creation, we can use the ABAP Development Tools to find our package and add it to our favorites. The package has the same name as the software component. Each component has its own transport layer, as this is responsible for distribution to the corresponding Git repository.
As you can see in the picture above, it is initially a structural package. We cannot create objects directly under this, but must first define development packages. This also means that we should first think about the structure of the application.
For demo purposes, we will now create another package by right-clicking on the ZBS_DMO package in the Project Explorer and using the context menu "New -> ABAP Package" to start the dialog.
Enter the name and description of the new package there. The upper package is already assigned and the new type is "Development", so we can leave the default settings as is.
In the next step we see the assigned software component and the transport layer again; these are relevant for the transport and the assignment to the correct Git repository.
In the last step we have to create a new transport; here a separate transport is created for each software component. It is not possible to assign objects from different software components to the same transport; the system checks for the correct component. After we have created the package, we define a new class that I then want to transport.
CLASS zcl_bs_dmo_hello_world DEFINITION
PUBLIC FINAL
CREATE PUBLIC.
PUBLIC SECTION.
INTERFACES if_oo_adt_classrun.
ENDCLASS.
CLASS zcl_bs_dmo_hello_world IMPLEMENTATION.
METHOD if_oo_adt_classrun~main.
out->write( 'Hello world' ).
ENDMETHOD.
ENDCLASS.
Transport
Now we want to release the transport in the system and check the dependencies on Git.
Functionality
The software components are closely linked to Git. Instead of the classic CTS (change and transport system), we use gCTS for the transport, the basis of which is a Git repository. In the ABAP Environment we basically work with a “hidden” Git, over which we as the customer have no influence or insight. How does development work in a 3-system landscape? Changes are made in the development system, when the transport is released, a commit is made in the Git repository and the changes are distributed to the other systems via pull:
Since Release 2402, it has also been possible to use a public repository (Bring your own Git) and thus influence the code and storage. You can find further examples and possible landscapes in SAP Help.
Example
Now we release the transport in the system. To do this, we open the “Transport Organizer” view and find the transports grouped according to the transport layers of the system. Let's open our transport layer, then we find our transport with the attached objects (package and class). We can now release the task using the context menu.
The transport must then also be released, otherwise no transport or export will take place. Each transport creates a commit in the repository of the software component; the transport text is used as the text. Let's now take a look at the software component and navigate to the associated commits under "Branches"; our transport has now arrived there as a commit.
If we continue navigating to the commit, we can also see the changes to the transport. This is practical for being able to carry out further evaluations of the system.
Deployment
If we now want to carry out a deployment, we first have to go to the system where we want to deploy the changes. There we go back to the “Manage Software Components” app and navigate to our software component. This is present in the system because the software components are managed across systems. However, no “clone” has been carried out here yet, so the component is listed but cannot yet be used. In the first step, we have to make the component available in the system using the “Clone” button.
It is important to set the setting to “Target” if it is not a development system. This means that no “push” is possible from this system and only applications can be deployed. By cloning the software component, the current status is available in the system. In order to see a delta, we change the created object and release the transport in development again. We will then find an updated version in the software component.
If you now navigate to the branch, you will see the new commit/transport and can initiate the import of the changes into the system.
Usage
How would you like to use software components for development? You should pay attention to the following important points:
- Deployment - The release always takes place across the entire software component. You can choose a commit during import, but all other commits/transports before it will also be imported.
- Access - All objects within the software component can use each other. Objects from other software components can only be used if they have a release contract (C1).
- Structure - Under the structure package you first have to create a package in order to work in it. It is advisable to use a uniform name for certain packages that take on tasks within the software component.
- Size - Which parts of an application and how many apps do you want to have in a software component? The transport and changes occur together, so not all of your system's applications should be in it, but rather logical small groups should be formed.
- Releases - Releases of objects should only be carried out from one software component to another. Since the components are transported individually, insoluble transport conflicts can otherwise arise.
Hint: In particular, the last point with the release of objects (C1 Contract) should be carefully considered. Software components that release objects should not contain any breaking changes and should always be transported first.
Conclusion
The software component is an essential part of development in the ABAP environment. You should be clear about how you use them and what added value you can get from them. You should also be aware of the limits of use. With the help of the article, nothing should stand in the way of development in the ABAP Environment.
