ABAP Cloud - 3-TIER Model

Table of contents

• Introduction
• Software components
• Creation
• Similarities
• Differences
• Model
• Legend
• TIER-3 - Classic ABAP
• TIER-2 - API Layer
• TIER-1 - ABAP Cloud
• Overview
• Release
• Authorization
• Conclusion

The 3-TIER model is an important building block in the implementation of ABAP Cloud. In this article we will go into a little more detail about the structure and construction. The implementation of the structure can vary from customer to customer, so here is an example of how we are currently implementing it here.

 

Introduction

The 3-TIER model is intended to enable the transition from Classic ABAP to ABAP Cloud, since almost no customer will start their processes directly and only in ABAP Cloud. Above all, ABAP Cloud gives SAP an overview of how customers use the system and which ABAP APIs are still needed so that Clean Core can be implemented. The division into the three TIERs:

• TIER-1 = ABAP Cloud (only)
• TIER-2 = APIs we need and a TODO for SAP
• TIER-3 = Our task is to modernize the objects and transfer them to TIER-1

 

Software components

In last week's article we described the software components and how they work in the ABAP Environment. The concept of software components is also used in ABAP Cloud to apply the stricter ABAP Cloud rules to the objects and to separate yourself from the non-clean core components.

 

Creation

Unlike the software components in the ABAP Environment, new components are created via the RSMAINTAIN_SWCOMPONENTS report in the system. There will probably be a solution here later via the Fiori app or ADT View. We start the report directly via the ABAP Development Tools.

 

We directly receive a list of all software components of the system. In the lower part of the list we find the Z* components that are relevant to our development. We can use the “+” button to create a new component.

 

 

In the next popup we can now enter the information about the software component, which will then be created in the system and can be used.

 

The individual points are briefly explained:

• Component - ID of the software component to be created in the system, the ID must be unique.
• Release - freely assignable version ID, here you can use the existing versions as a guide.
• Development Type - Differs in Local and Transportable. For local packages, a transport request is not requested and the objects only remain in the current system.
• ABAP Language Version - For software components that are used in TIER-1, "ABAP for Cloud" is set here. Packages with this software component work according to the stricter rules of ABAP Cloud. TIER-2 and 3 use “Standard ABAP” as a software component.
• Description - A descriptive text about the software component.

 

Similarities

• Objects in TIER-1 can only access other TIER-1 objects in the same software component, unless a release contract exists.

 

Differences

• The components are currently maintained via a report and not via a Fiori application.
• Various software components can be transported in classic CTS in one transport; the objects are not differentiated.
• gCTS and Git are not mandatory when using software components.
• A structure package with the same name can be defined, but it does not have to be.

 

Model

Hint: The following subsections deal with an example structure of the 3-TIER model. There are currently no best practices here and this is a suggestion from us that we also implement and apply in our company.

 

Legend

The following legend applies to the following sections and explains the various objects in the model. We differentiated between structural packages (only packages below) and development packages, where all other components are located.

 

TIER-3 - Classic ABAP

The third TIER describes the “Classic ABAP” world. Here would be all the objects that already existed on the system when you introduce ABAP Cloud in the system. This layer therefore becomes a brownfield and must be transferred to ABAP Cloud bit by bit in the future. Individual objects can also be manually transferred to the “ABAP for Cloud” language version, but this reduces the clarity in the system and external tools are necessary for evaluation.

 

Structure:

• Structure package - We use a separate structure package ZCA_TIER3 here for reporting purposes and to assign all objects to a TIER.
• ABAP Test Cockpit - A separate ABAP Test Cockpit (ATC) test would later be possible here, so that new objects always have to be assigned to a package with TIER assignment. There is currently no standard test for this.

 

 

Rules:

• Classic ABAP - Use of all technologies and objects as previously known (BAPI, user exits, modifications, SAP GUI, file access, reports, etc.).
• ABAP Cloud - For the purpose of mixing, no objects with the language version "ABAP for Cloud" should remain permanently in TIER-3.

 

TIER-2 - API Layer

The second TIER is also known as the API layer. Only objects that are not released by SAP but are required in the TIER-1 process are located here. Every object on this TIER has a clearance so that it can be used accordingly. The Extensibility Guide describes which objects are best suited for this purpose.

 

Structure:

• Software component - We only use one software component for the entire TIER-2, for reporting purposes and to delimit the objects. If you also want to do this and are on S/4 HANA 2022, you have to install note 3319469, otherwise you cannot work with the component. The language version of the component must be set to "Standard ABAP", not ABAP Cloud.
• Packages - The names of the associated packages on the various TIERs are ensured by the corresponding abbreviation (T1, T2 or standard).

 

 

Rules:

• Wrappers - Wrappers are objects that make standard objects available in a new object for TIER-1 (Facade Pattern). The wrapper requires a C1 release contract to be used from TIER-1. You can also find out how to build and make a wrapper available in this tutorial on the Developers Platform.
• SAP Objects - Wrappers are provided for TIER-1, the following objects are recommended by SAP: BAPI, Classes, Function Modules, Core Data Services. The following objects should not be used: FORM routines, parts of coding, SAP GUI functions.
• Cloudification Browser - SAP already suggests various objects for TIER-2 that you can view via the Cloudification Browser or Cloudification Repository Viewer.
• Influence Request - How does SAP know that you have built a wrapper? You should then open an influence request and request the wrapped object. You will then receive an appropriate response that the object will be released, there is an alternative or there will be no release.

 

TIER-1 - ABAP Cloud

Our goal at ABAP Cloud is to only implement all of our applications on TIER-1 and thus achieve the gold standard. The objects from TIER-2 are available to us as an interface if the corresponding APIs are still missing.

 

Structure:

• Software components - As with the ABAP Environment, we use software components to divide the applications and differentiate them from one another. This allows us to achieve clean decoupling of the application and release objects that can then be used across the board. This automatically gives you clean interfaces to other applications.
• Multiple components - Why not one component? This forces the developer to cleanly separate the objects and applications and not to use one large package.
• Abbreviation - All objects are still in one system and one namespace. By using an abbreviation (2-4 digits) you avoid naming conflicts and can assign the objects to the software components.

 

 

Rules:

• ABAP Cloud - Limited language scope for ABAP for developing Cloud Ready and Clean Core applications.
• Concepts - Only the use of the new concepts is possible: Application Jobs, Fiori applications, new Application Log, etc. Old concepts such as SAP GUI or access to the server's file system are no longer possible.
• APIs - Access to the core only takes place via released APIs (RAP objects, Core Data Services, released BADIs, classes). It is possible to create shared objects yourself as long as the required interfaces do not exist. What APIs are there and what are the successors for old objects? You can view this via the Cloudification Browser or Cloudification Repository Viewer.

 

Overview

The overall model again at a glance. By clicking on the image you get the complete view and can see the various details.

 

Release

As indicated in the overview above, there is the possibility of bringing TIER-2 objects to TIER-1. If a corresponding API is available (successor solution or release of the object used) and the object is therefore ABAP Cloud, it can be brought to TIER-1. To do this, the object must be converted to "ABAP for Cloud" and can then be moved to the corresponding TIER-1 package using "Change Package Assignment...". The checks and compiler then ensure that the object can be moved.

 

Objects are therefore not given the TIER abbreviation so that they can be moved freely between the individual TIERs when the status changes.

 

Authorization

What does the delimitation of permissions actually look like? Should the external colleagues perhaps only develop ABAP Cloud and individual internal colleagues take care of the wrappers on TIER-2? To do this, you can use the authorization object S_ABPLNGVS. You can use the ABP_LNG_VS field to limit the different language versions that a developer can create and edit.

 

Conclusion

Today there was a theoretical overview of the 3-TIER model and how you can build it. As a suggestion, you can adopt it, adapt it or live it differently. Next week we will present a migration from TIER-3 to TIER-1 using an example.