Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
ThomasSchneider
Product and Topic Expert
Product and Topic Expert
In the blog post S/4HANA Extensibility Concept Details: Restricted ABAP  I introduced the concept of restricted ABAP, or naming it correctly: ABAP language versions. Initially it was introduced for the usage in the key user editor in SAP S/4HANA Cloud. With SAP BTP ABAP Environment (aka Steampunk https://blogs.sap.com/2019/08/20/its-steampunk-now/ ) a second  use case was introduced. In this blog post, I want to spend some words about this use case.

First, let me recap the basics of the concept of ABAP language versions (for more details read my previous post):

The concept is built of two pillars:

  • Restricted syntax: only a well-defined part of the ABAP syntax tree is allowed in a specific ABAP language version.

  • Released object check: only released SAP APIs (for example released classes and CDS views) can be used. The syntax check analyses the used SAP objects and checks if they are whitelisted.


The concept of ABAP language versions supports two targets:

  • De-couple custom code from the SAP core by enforcing the exclusive use of released SAP APIs

  • Minimize the risk of damages to the system or the data integrity/security


The ABAP language version is a property of the ABAP object, and so is independent of the used editor. This means, if you set a ABAP language version to, lets say “ABAP for Key Users” the syntax restrictions and release checks are executed an any case - whether you use the Web editor in the Fiori app Custom Fields and Logic, the Eclipse-based editor or the ABAP editor in SAPGUI.


Figure: Relation between ABAP sources, language version and ABAP editors

 

In an on-premise system, you can set the language version using the Eclipse-based ABAP editor (ADT) as shown in the following figure:


Figure: Set the ABAP language version in the Eclipse-based ABAP editor (ADT).

 

In Cloud systems, the ABAP language version is automatically set and cannot be changed. For example:

  • SAP S/4HANA Cloud: the ABAP language version ABAP for key users is automatically set by the key user tools (e.g. Fiori app Custom Fields and Logic).

  • SAP SAP BTP ABAP Environment: the ABAP language version ABAP for SAP BTP is automatically when creating new ABAP objects.

  • When using the key user tools (e.g. Fiori app Custom Fields and Logic) in on-premise, the key user tools will also set the ABAP language version ABAP for key users.


Let us now shortly discuss the common parts and the differences between the ABAP language version ABAP for key users and ABAP for SAP BTP.

1) Both language versions are designed for use in Cloud. Therefore, they must not support all kind of statements that would endanger the operations in the Cloud: Examples are:

  • Access to file system OPEN/CLOSE/READ/GET DATASET

  • Low-level access to the database and to other clients: EXIT FROM SQL, EXEC SQL, OPEN/CLOSE CURSOR, SELECT CLIENT SPECIFIED, SELECT USING CLIENT 

  • Low-level access to the ABAP system: CALL CFUNCTION, SYSTEM CALL, SYSTEM EXIT


2) Some frameworks and technologies are no longer supported in Cloud development. This includes reports, list processing, dynpros. Thus, the related ABAP statement are forbidden.

3) Both language versions are designed to support “modern” ABAP, Therefore, obsolete statements are not supported. Here, ABAP for key users is stricter than ABAP for SAP BTP, because in the second, we want to support the migration of coding from on-premise to the Cloud ( How to bring your ABAP custom code to SAP Cloud Platform ABAP Environment ). For ABAP for key user use cases, we assume that coding starts on a green field and can be modernized to a larger extend.

Here are some examples for obsolete statements, which are forbidden in both language versions:

  • COMPUTE, MAXIMUM/ MINIMUM, MOVE, TABLES, DATA WITH HEADER LINE

  • DESCRIBE, WRITE TO, SEARCH

  • EXPORT MEMORY, EXPORT SHARED MEMORY


For these statements, “modern” alternatives are available.

In ABAP for SAP BTP, some statements are available, but a warning is issued that they should be replaced by a newer syntax.

4) Working (creating and calling) with classes is supported for ABAP for Key Users and for ABAP for SAP BTP. In the Key user tools, you can create custom libraries (ABAP classes) only using the Fiori app Custom Reusable Elements.

Function modules (creating and calling) are supported in ABAP for SAP BTP only.

5) Dynamic programming is supported in ABAP for SAP BTP, but not in ABAP for Key Users.

6) Code (object) generation is supported in ABAP for SAP BTP, but not in ABAP for Key Users. For code generation in ABAP for SAP BTP, APIs can be used, see for example the following blog: https://blogs.sap.com/2020/05/17/the-rap-generator/

7) Asynchronous programming is supported in ABAP for SAP BTP, but not in ABAP for Key Users. But statement like CALL FUNCTION … STARTING NEW TASK, RECEIVE, WAIT are no longer supported. They are replaced by an API (CL_ABAP_PARALLEL).

8) Providing and implementing extensions is supported in ABAP for SAP BTP, but not in ABAP for Key Users. Thus, CALL BADI, GET BADI is supported in ABAP for SAP BTP (planned). Obsolete extension technology is not supported, e.g. ENHANCEMENT-POINT

9) For ABAP for Key Users is design for implementation of “code snippets” in exits, for example BAdI implementations and determinations, validations, actions in business objects. Therefore, direct manipulation (insert, update, delete) of tables (even for custom tables) is not supported here.

10) System variables (SY-) are also subject to allowlisting. Some of them are no longer available due to the Cloud environment or non-supported frameworks (e.g. dynpro). All others are only available for read-only access and a warning is raised. For use cases like language, time, etc. APIs are provided that must be used, e.g. class CL_ABAP_CONTEXT_INFO.

11) Finally, what is “in” for both language versions?

  • Statements for the program flow: IF, CASE, WHILE, DO, TRY,

  • Statements for working with data type, including field symbols: DATA, TYPES, CONCATENATE, ASSIGN

  • Statements for working with internal tables and selecting data from the database: APPEND, LOOP, SELECT, READ, …


Let me conclude with a list of useful documentation:

 
37 Comments