ABAP Cloud - Access to Components

Table of contents

• Introduction
• Level
• Software Component
• Classic ABAP
• Local Development
• Access
• Use case
• Clean Core Level Concept
• IDE Actions
• Conclusion

In this article, we'll discuss ABAP Cloud, classic ABAP, and local components and how you can use them to build specific scenarios.

 

Introduction

In the article about software components and their relationships, we looked at how software components interact with each other. But what about classic ABAP in an on-premises system, or what about local components in ZLOCAL or $TMP? In this article, we'll take a closer look at the different levels and how they interact with each other.

 

Level

To do this, we'll divide the various objects and packages into three levels and show you how to better identify them. We'll leave the topic of package encapsulation and interfaces aside for now.

 

Software Component

A software component (SWC) is a type of customization that can be assigned to a package. Previously, customers primarily used the "HOME" software component in their development. With the introduction of the ABAP Environment and ABAP Cloud, the software component was also used to structure developments. This creates a demarcation within the ABAP environment:

• Language version - Developments under the structure package automatically receive the language version for "ABAP for Cloud Development." This ensures the language version within the component, and the rules for ABAP Cloud must be followed.
• Separation - The components created within the software component can use and call each other, as was previously the case in the HOME component. However, this does not work if components from another SWC are to be called.
• Git - Behind an SWC is a 1:1 Git repository, where a commit occurs after a transport is released. This means that the entire development, as well as all changes, can be found in one central location.
• Transport - Transport takes place in the ABAP environment for each software component; there is no mixing of different objects from different SWCs. This doesn't matter for normal transports; no commit to Git is necessary here.
• APIs - When it comes to using standard objects, these are usually from the "Standard ABAP" language version and are enabled for ABAP Cloud via release. However, for us, this also means that we have a limited scope for the objects we can use.

 

Hint: The Git and Transport points only apply to the ABAP environment, since the standard for transport here is gCTS. The various S/4HANA versions mostly use the classic CTS, and gCTS can be used optionally.

 

Classic ABAP

In the area of classic ABAP and customer developments, we are primarily active in the HOME component. External service providers and manufacturers use software components to deliver products and add-ons. There are initially no access restrictions in this area. Within the component, we can access all artifacts as long as the package interfaces are not activated. Objects at this level are recorded in transports when changes occur, usually in the classic CTS, and thus rolled out to the system landscape.

This means that we can use all objects of an SAP system at this level and have no restrictions here. However, it must also be noted that there are certain restrictions here, or that some SAP objects are not suitable for use.

 

Local Development

There are currently two concepts for local development that can be used. This also depends on the package used.

• $TMP - Developments in this package are all local system objects. No transport is required for these objects, but they are also not transported in the system landscape. Objects in this area are defined in the standard with "Standard ABAP", so all objects can be accessed.
• ZLOCAL - Developments under this package are also local objects that are not transported. Depending on the release, you may be asked to transport them. There were 2508 changes to the ABAP environment, meaning newly created packages no longer require transport. Objects created here are defined with "ABAP for Cloud Development" and therefore cannot access the entire standard, but only released APIs. However, objects from this package can access all objects of a software component without being released.

 

In principle, local development is suitable for several scenarios:

• Prototyping - Since the objects and packages are local, they are often used for prototypes, tests, and training. This means that no change request is initially generated, and the objects can subsequently be simply removed from the system.
• Generation - Certain frameworks, such as LSMW or SAP Query, use local objects in test and production to generate and store objects. Since no transport occurs and the objects are only used locally, this layer is particularly worthwhile.

 

Access

So what does access from the various layers actually look like? Let's take a look at a graphic and derive the various scenarios. The following key describes the graphic.

 

The following overview demonstrates the access from software components to the standard, as well as between ABAP Cloud, standard ABAP, and local components. The components can represent different objects, such as classes, Core Data Services, tables, RAP objects, and much more. The SAP standard is in the middle, as this is required for most custom developments to access the APIs.

 

So let's summarize the special features:

• Standard ABAP - In the standard, we can actually do anything; we can use the entire SAP standard, but also all components of a software component. This also gives us flexibility if we initially make certain APIs available only in ABAP Cloud, since we can also use them in existing applications.
• ZLOCAL - The local ABAP Cloud component is very close to the standard ABAP, but can only use the released objects from the standard. This is to ensure that you can only use what the standard provides in the local context.
• Software component - This is the most restrictive form, as we can only use shared objects (C1). We can use all kinds of objects for this, even from the local area. However, you should be careful here, as this can lead to transport problems and errors.

 

Use case

What can we derive from the various properties? Let's look at two current use cases that we can implement on-premises and in the cloud.

 

Clean Core Level Concept

If we implement the level concept and provide ABAP Cloud components, we can still use them in classic ABAP development. A classic example here would be message logging or central settings that we can store for applications. The clean separation takes place between the various SWCs, which, however, represents a small risk for standard ABAP, as we can use objects that may not have been intended for release.

 

IDE Actions

We can easily develop IDE Actions in ZLOCAL, as we have access to the components in the software components from there, which is important for central actions. In 99% of cases, we will use the actions to accelerate our development flow on the development system, so they don't need to be transported.

 

Conclusion

Which level can access which elements? We should now have clarified this question, as well as the various options available in this context. This doesn't stand in the way of an API in ABAP Cloud, but be careful if your colleagues use your objects in a way that violates the Classic ABAP concept.