ABAP Cloud - Software Components and Relations

Table of contents

• Introduction
• Structure
• Separation
• SWC relations
• Other points
• Namespace
• Cross-functional objects
• Transport
• Many components
• Conclusion

How do we actually handle software components correctly and how can we use and structure them meaningful in development? In this article, we will go through the different concepts in more detail and look at the different facets of SWC.

 

Introduction

We have already discussed what software components (SWC) are and how you can use them in BTP in this article. In this article we will look at the use and possibilities in on-premise development with ABAP Cloud. We will use this legend for the following graphics:

 

You are already familiar with a development package because you use it in your daily development and can create all kinds of objects under it. A structure package is something different because you can only create packages under this package and not objects directly. In many cases, this ensures more order in the system, as the packages provide a kind of structure.

 

Structure

If you implement the 3-TIER model into the system, you have the option of creating a software component for TIER-1 or, similar to the ABAP environment, many SWCs. In this section, we will take a look at the structure when we rely on many software components. Accordingly, a best practice for the structure has been developed when working in the ABAP environment. Here is a schematic representation of a SWC with a structure package and the corresponding development packages underneath.

 

Here is a brief explanation of the individual layers:

• FIORI - This is where the deployments of the Fiori Freestyle and Fiori Elements applications (BSP) are located, as well as the descriptor item. Other objects are the IAM app, the business catalog or the launchpad space. Basically, all artifacts for the launchpad integration can be located here.
• INTF - This is where all interfaces to other systems would be located if, for example, we create a consumption model, a proxy or HTTP access. This lets the developer know that other systems are being accessed and that data is coming from them. It usually helps to name the packages after the system and interface.
• APP - This package contains all the SWC applications. Applications used to consist of a report, a transaction and perhaps a class. With RAP, an application can quickly consist of 15-20 objects and you don't want to mix these in a package with other applications. This means that each app can have its own package and the objects are clearly assigned.
• TEST - Separate test components for unit or integration tests can be stored in this package. However, this is rarely the case since the unit tests are usually created on the objects they test.
• REUSE - Different applications use the same components and helper classes? We can store such re-use components in their own package. In contrast to the shared components, we only use such components within the SWC.
• SHARE - Here are components that we also want to release for other software components and that always have a C1 contract. With the contract they enter into a certain stability and we can control which components can be used in the system.

 

Not every package is necessarily created in every software component; rather, the structure is intended to help you find your way around the components quickly.

 

Separation

One advantage of having many software components is the strict separation of the various applications with options for releasing specific functions. As already described in the structure above, there are certain components within the SWC that we release. Let's take a look at the following graphic:

 

Usage is divided into three areas:

• Within - Objects can be used within the software component without any problems. You can call up and use all objects, just as you do on-premise today.
• Across - Components of another software component cannot be used; you will receive an error message from the compiler stating that the function cannot be used. This means that these components are "protected".
• Contract - A released object can be used freely in the system and by other SWCs. The developer guarantees stability during use and is also warned by the system in the event of stability violations.

 

This means that each application uses its own components without running the risk of data elements or structures being adapted, which may make sense in one application but also has an impact on our application. Control therefore remains completely in the SWC. The disadvantage would be that we have a similar object in several SWCs, but shared components that release such objects for use (C1 contract) can also help here.

 

SWC relations

The new topic is Software Component Relations, which is available in the BTP on the ABAP environment and will probably be available with the S/4 HANA 2025 release or a downport on-premise. This allows you to release all objects and components of your software component to another SWC. The "Software Component Relations" object is created directly under the structure package of the SWC and must have the same name as the software component.

 

In the relationship you can specify which SWCs the objects of the current component can use. You can find the setting in the upper area. In the lower area you can specify which other software components you use in the current SWC. This makes relationships between components easier to see, as long as you maintain them correctly.

 

Let's take a look at how it works in the following graphic:

 

After we have created the relationship and ZBC_NXT has been added, the components of the software component can access the components of ZBC_SWC. However, this only works one-way, as components of ZBC_SWC cannot access components of ZBC_NXT. The software component relations offer you the option of controlling the releases even more precisely and you no longer have to define a C1 contract so that another SWC can use objects. This also means that all objects in your software component can be used and called, even if they were perhaps not intended for this purpose.

 

Other points

In this section, we will take a closer look at various smaller points and shed light on the details of other concepts.

 

Namespace

Unfortunately, software components do not have their own namespace, as is the case in other programming languages. The individual components within our SWC are protected from external access, but we can still only use the same name once in the system. The same applies to applications, helper classes, core data services, etc. As a best practice, we therefore use the abbreviation of the software component and include it in each object, similar to the group numbers in SAP training courses.

In the examples above, we have already tried to illustrate the usage. EXA (Example), SWC (Software Component) or NXT (Next) are such abbreviations. You can use the suggestion to assign the objects and applications to the individual software components. With a length of two to a maximum of five characters, they should fit into most objects and give the object its own "namespace". Where the abbreviation is placed in the object is ultimately up to you. We can then use the search to narrow down the objects or know directly which SWC an object belongs to.

 

Cross-functional objects

In many developments there are helper classes and functions in the system that many applications use. Such as logging, sending emails with templates, configurations and settings. Such helper objects would find a place in their own software components and can then simply be released in the system via a C1 contract. Such components must be stable in any case and will most likely be used in many applications.

 

Transport

In the BTP, software components are transported individually, as a separate Git repository is created for each SWC. This can lead to problems when releasing dependent SWCs and cross-relationships should therefore be avoided. In on-premise, this is currently less of a problem, as you can assign the same transport layer to different SWCs and thus bring them to the next system in one transport via the classic CTS. This means that cross-relationships between components should not be a problem, but as a tip we recommend that you avoid them if possible.

 

Many components

Currently, the ABAP Extensibility Guide does not recommend using more than one software component. It is only described that a SWC should be created for TIER-1 in order to set the ABAP Cloud rules as standard below the package.

We recommend more SWCs for the following reasons:

• Separation - The division into different software components also separates the use of the different components from each other. As a developer, you can decide for yourself which application your classes and objects use. Data types and helper classes belong to your application until you decide to make them generally available and thus dependencies become more clearly visible.
• Size - By separating into different software components, meaningful groups of applications are formed in the system. As a developer, you think more about the structure and delimitation of the components and no "monster packages" are created, under which every developer simply adds new applications and the search for related components becomes a torture.
• Structure - A uniform structure on-premise and in the ABAP environment can also ensure that related applications can be easily moved between the systems (migration). As a developer, you can find your way around both systems and immediately understand the structures and patterns used.

 

Conclusion

The structuring and use of software components in the on-premise system can be a science in itself. With our information, you should now be able to understand the SWC better and use it more effectively in your development.