Introducing ABAP Platform 1809

Introducing ABAP Platform 1809

Reading time: 18 mins


by Karl Kessler, Vice President of Product Management ABAP Platform, SAP SE


At the SAP TechEd conferences in the fall of 2018, SAP introduced SAP Cloud Platform ABAP environment, which is a platform-as-a-service (PaaS) offering for ABAP development that went live in September 2018.1 While the announcement of this cloud-based environment has generated a considerable amount of excitement and interest among SAP customers, there are more than 100,000 existing productive installations of the on-premise ABAP environment, and to support these customers going forward, SAP delivered another technology at the same time: version 1809 of the on-premise ABAP platform.

ABAP platform 1809 is the technological foundation for SAP S/4HANA 1809, and these two technologies were shipped together in September 2018, with ABAP platform 1809 as an embedded delivery. ABAP platform 1809 includes an ABAP programming layer that is fully optimized for SAP HANA and for the development and enhancement of modern applications, including support for Internet of Things (IoT) and machine-to-machine (M2M) communication. It also delivers a wide range of valuable improvements to various ABAP development tools to increase efficiency.

This article examines some of the key innovations delivered with ABAP platform 1809 — including improvements to the Eclipse-based ABAP development tools and optimizations that leverage the full functionality of SAP HANA and SAP S/4HANA — and how these innovations help you develop sophisticated applications that meet your digital business needs. Before we take a closer look at these new capabilities, however, we’ll first review the release strategy for the ABAP stack, which involves some changes required to fully support SAP HANA functionality. These changes are important to understand so that you can properly plan for the adaptations that are necessary when moving from traditional SAP NetWeaver and SAP Business Suite deployments.

SAP’s Release Strategy for the ABAP Stack

Up to version 1809, innovations for the ABAP stack have been developed based on one common codeline that has served all existing ABAP-based products. These products include the SAP Business Suite applications (such as SAP ERP) and SAP NetWeaver hubs (such as SAP Gateway) that run on SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP 7.5, which includes the traditional ABAP programming model and software component SAP_ABA. SAP S/4HANA on premise and SAP S/4HANA Cloud are also based on this common codeline, with SAP S/4HANA on premise running on SAP NetWeaver AS ABAP 7.5x (that is, 7.5, 7.51, and 7.52) and its new version of the SAP_ABA software component, and SAP S/4HANA Cloud running on a cloud-based version of the platform.

As of ABAP platform 1809, SAP plans to focus all innovation on SAP S/4HANA. Since SAP NetWeaver AS ABAP must be able to run on all officially supported database platforms, it takes a least-common-denominator approach to database functionality and cannot benefit from the latest innovations and advantages that are specific to SAP HANA. SAP S/4HANA on premise and SAP S/4HANA Cloud, on the other hand, support SAP HANA only and are fully optimized for that database and its features. With the focus on SAP S/4HANA — and with SAP NetWeaver AS ABAP 7.51 and 7.52 adopted only by SAP S/4HANA 1610 and 1709, respectively — the latest enhancement package for SAP Business Suite (enhancement package 8) is based on SAP NetWeaver 7.5.2

So, how does SAP plan to deliver innovations to SAP S/4HANA on premise and SAP S/4HANA Cloud while delivering continuous improvements to the existing installed base of SAP Business Suite customers without disrupting their business? Figure 1 provides an overview of the planned path forward. As you can see, the SAP S/4HANA and SAP Business Suite codelines are separated. On the left is the SAP Business Suite and SAP NetWeaver codeline, which is based on SAP NetWeaver AS ABAP 7.5x. It is intended to deliver improvements for the ongoing operation of SAP Business Suite and SAP NetWeaver deployments — including the SAP NetWeaver hubs, SAP NetWeaver add-ons, and custom code developed by SAP customers and partners — and will include all maintenance efforts, security fixes, and selective downports (of version 4.0 of the OData protocol to older SAP NetWeaver releases, for example). As a result, there is no standalone 7.53 version of SAP NetWeaver AS ABAP.


Figure 1 — The release strategy for the ABAP platform going forward


In parallel, all innovations for the ABAP stack are placed into a common innovation codeline, shown on the right, that serves SAP S/4HANA on premise, SAP S/4HANA Cloud, and the recently released SAP Cloud Platform ABAP environment. This innovation codeline takes full advantage of the underlying SAP HANA database and data platform, with its capabilities fully exposed on the ABAP platform layer. In each case — SAP S/4HANA, SAP S/4HANA Cloud, and SAP Cloud Platform ABAP environment — the new SAP_ABA layer is used, which contains the extended material code field (which is now 40 characters instead of the 18 characters supported by the classical SAP_ABA layer used by SAP Business Suite).

The platform naming follows the nomenclature used by SAP S/4HANA, meaning that ABAP platform 1809 is the foundation for SAP S/4HANA 1809 on premise, while ABAP platform 1808 is the foundation for the cloud solutions SAP S/4HANA Cloud 1808 and SAP Cloud Platform ABAP environment 1808. New cloud versions (for example, 1811 in November 2018, 1902 in February 2019, 1905 in May 2019, and 1908 in August 2019) are shipped every quarter and are consolidated in the yearly on-premise delivery in September, which will be the 1909 version in September 2019. This new release strategy opens up a completely new way to quickly deliver SAP HANA innovations together with the ABAP stack. In traditional deployments, the back-end version determines the speed of innovations — now ABAP innovations can be deployed in the cloud much faster.

It is important to note that unlike SAP NetWeaver AS ABAP, ABAP platform 1809 is not shipped independently but only indirectly (embedded) with the shipment of SAP S/4HANA, although it can be patched separately. The development capabilities delivered by this platform are compelling reasons to move to this SAP S/4HANA release, which is an easy upgrade from previous on-premise SAP S/4HANA releases (1511, 1610, and 1709). Existing SAP Business Suite implementations can be migrated with the support of SAP tools and methodologies3 — and with maintenance and support for SAP Business Suite set to end in 2025, it is a good idea to consider making this move sooner rather than later.

With a solid understanding of the release strategy, let’s now look at some of the key innovations delivered with ABAP platform 1809. We’ll first examine improvements made to the Eclipse-based ABAP development tools, and then look at optimizations that fully leverage the capabilities of SAP HANA and SAP S/4HANA. This article covers the most prominent examples of the delivered innovations — details on additional improvements are available from the ABAP community site and the release notes for ABAP platform 1809.

Improvements in the Eclipse-Based ABAP Development Tools

ABAP platform 1809 enhances the Eclipse-based ABAP development tools in several ways to help improve developer efficiency. Improvements in the areas of maintaining enhancements, analyzing runtime errors, defining lock objects, and editing transport objects are particularly notable. Let’s take a closer look.

Maintaining Modifications and Enhancements

Prior to ABAP platform 1809, it was not possible to maintain modifications within the Eclipse-based ABAP development tools. To be more precise, you could directly modify a standard SAP program using the source code editor tool in the Eclipse workspace, but that meant losing the ability to track changes with the Modification Assistant, which is not available to the Eclipse-based tools. This approach is not recommended, since without the Modification Assistant, the system has no clue where you tried to enhance the standard version, which results in significantly more effort when you need to apply a support package or upgrade your system to a higher release. With ABAP platform 1809, you can maintain the modification directly inside the Eclipse-based tools. Creation and deletion of modifications are not yet supported.

In addition, when implementing enhancements that should be inserted into the standard logic or replace standard logic — allowing you to add functionality without modifying the standard source code if an enhancement spot is available — developers would still have to switch to the SAP GUI-based ABAP Editor (transaction SE38) within the ABAP Workbench, even if they started their development work in the Eclipse-based source code editor. Only the SAP GUI-based tool could fully handle enhancements.

With ABAP platform 1809, the Eclipse workspace includes a native enhancement implementation editor tool that is fully capable of displaying and changing enhancements directly within the workspace. You can now freely edit the code and implement enhancements to standard SAP programs without leaving the ABAP development tools environment. During support package implementation, the system will help you identify the place where the enhancement was made and support you in readjusting the enhancement if necessary. Creation and deletion of enhancement implementations are not yet supported.

Figure 2 shows the enhancement implementation editor in the Eclipse workspace. A pop-up window shows an enhancement implementation consisting of several lines of ABAP code — including regular ABAP data declarations, a SELECT statement, and a READ TABLE operation — that is located at an enhancement spot defined by the application.


Figure 2 — The enhancement implementation editor enables you to display and change enhancements directly within the Eclipse workspace


Analyzing Runtime Errors

Every ABAP developer is familiar with the traditional handling of ABAP runtime errors. When an ABAP runtime error occurs — and there are often numerous error conditions in a development or productive ABAP runtime environment — the system shows the location in the source code where the error occurred that caused the ABAP program to abort. The system allows you to switch to the debugging environment, analyze the call stack from when the program terminated abnormally, and inspect the local variables, the global tables, structures and fields, and other valuable information.

Previously, these analysis tools were only available in the SAP GUI-based environment. The Eclipse-based tools would implicitly switch to SAP GUI when a runtime error occurred that prevented the ABAP program from continuing its execution. As of ABAP platform 1809, the Eclipse-based tools can directly handle this situation without switching to SAP GUI. Remember that in SAP Cloud Platform ABAP environment, where the same Eclipse-based ABAP development tools are used, SAP GUI is not supported at all, meaning that using the runtime analysis capabilities of the Eclipse workspace is the only way to gain useful information for error analysis. However, this is also helpful on premise, since the error analysis is presented in the Eclipse workspace directly rather than in an embedded SAP GUI screen.

Figure 3 shows an example runtime error analysis in the Eclipse workspace. The identified error is an occurrence of a division by zero that causes program termination if not caught on a higher-order level. The information displayed includes details of the error analysis and, most important, the location in the source code where the error occurred. It also includes details about the call stack (such as the active function modules and method invocations), which are displayed at the bottom.


Figure 3 — As of ABAP platform 1809, the Eclipse-based ABAP development tools can handle runtime analysis within the Eclipse workspace


Defining Lock Objects

From its very beginning, the ABAP stack was optimized to handle large volumes of transactional workload. With the in-memory technology of the underlying SAP HANA database platform, this can easily be achieved for traditional reporting as well as for transactional access, such as SQL insert, update, and delete operations.

In a transactional environment with multiple users, database records must be locked before updates are written back to the database. In a simple client-server scenario, each parallel user could use database locks to achieve isolation when shared resources are accessed. Using database locks in interactive environments such as SAP Business Suite and SAP S/4HANA is more problematic. In this case, a database lock would have to be held during several steps and screen changes to avoid parallel updates from other users logged on to the system. However, the ABAP stack prevents database locks from being held over several screen changes, since a work process that executes an ABAP program execution request will free any locks by issuing a commit when the screen is sent to the dialog user for further input (for example, a pop-up that the user must answer). This means that database locks cannot be used in the ABAP stack to provide exclusive access to database resources (to update database rows or fields, for example).

For this reason, ABAP developers have used logical lock objects called enqueue operations to synchronize access to shared database tables. If a resource is free, an enqueue operation will create a logical lock in the central lock table of an SAP system. If a resource is already locked, the enqueue operation will fail and the dialog user can try again later. The dialog user is not set on hold to avoid database deadlocks when user sessions are waiting for each other to close a transaction. After the update operation, the enqueues are removed from the shared objects to allow access by other users again. You can define these lock objects for one particular database table or you can define combined lock objects that span multiple database table entries.

Previously, enqueue lock objects could not be defined in the Eclipse-based development tools — you had to define them in the ABAP Dictionary via transaction SE11. With ABAP platform 1809, lock objects can be defined from within the Eclipse workspace using a native Eclipse-based editor tool. This allows you to stay in the ABAP development tools environment without the need to switch to SAP GUI and back again. When you activate a lock object successfully, an enqueue function module is created that you can use inside your ABAP program logic to obtain a logical lock.

Figure 4 shows an example lock object for the well-known flight data model. On the left, it lists the tables the lock objects depend on, and on the right, it shows the generated lock function modules that an application programmer needs to call inside the application logic. In addition, it lists the arguments (key fields) that are passed when locking one or several rows.


Figure 4 — ABAP platform 1809 enables developers to define lock objects from within the Eclipse workspace using a native Eclipse-based editor tool


Editing Transport Objects

When you start to edit your development objects in the Eclipse workspace, a transport request pop-up will ask you to assign the changed object to an already-existing transport request or to create a new transport request on the fly. However, sometimes developers must change an implementation several times before transporting their development requests to the consolidation system. In addition, developers often want to manually remove development artifacts from the transport request so that unneeded artifacts are not transported to consolidation, the productive environment remains clean, and there are no name clashes with other developers.

In these cases, it is useful to be able to manually edit transport requests. It is also helpful if, after longer periods of development, a developer can create a mass transport that comprises all development artifacts of a particular project and submit a complete transport, to ensure that a consistent target state is sent to consolidation. Again, this requires the ability to manually edit transport requests.

Prior to ABAP platform 1809, transport objects could not be edited in the Eclipse-based development environment — you would have to switch to the Workbench Organizer (transaction SE09). With ABAP platform 1809, you can view and edit the details of a transport request using the Eclipse-based transport request editor tool. With this tool, all changed objects are collected in a list where each list element is of a certain type, such as an ABAP class, an ABAP program, a table definition, or a lock object.

Figure 5 shows an example transport request in the editor tool. The header information of the transport request is displayed in the upper half of the screen, and the lower half shows the list of changed objects that are contained in the transport request. Using this editor tool, an ABAP developer could remove certain elements or add missing elements manually, but in most cases, the system adds the items automatically whenever a developer changes a new development object.


Figure 5 — The transport request editor tool enables developers to view and edit the details of a transport request from within the Eclipse workspace


Optimizations for SAP HANA and SAP S/4HANA

In addition to delivering improvements to the Eclipse-based ABAP development tools, ABAP platform 1809 includes optimizations that help SAP customers take full advantage of the underlying capabilities of SAP HANA and the features of SAP S/4HANA. Here we look at three key optimizations: the ability to use SAP HANA hierarchy and abstract entities in core data services, support for adapting custom code for SAP S/4HANA, and enabling M2M communication.

Using SAP HANA Hierarchy and Abstract Entities in Core Data Services

With ABAP platform 1809, for the first time, the ABAP stack can focus exclusively on SAP HANA without having to ensure that corresponding features are available on other database platforms as well. One key feature that is supported only by SAP HANA is hierarchies, which are not well handled on the SQL level since you need to model them as tables. In principle, you could define a two-column table in SQL, with a column for parent and a column for child, but this approach becomes unwieldy if you need to compute the descendants (such as grandchildren) — in this case, you would have to define join operations of the table with itself, known as self-joins, which are not easy to handle.

In traditional ABAP, these types of hierarchies were typically handled on the application server level using internal tables. With ABAP platform 1809, you can use the SAP HANA hierarchy functions in-memory on the database level using the new keyword DEFINE HIERARCHY (see Figure 6). Supported by core data services, you can easily navigate to subordinate levels and access nodes and branches of a given hierarchy without the need to introduce internal tables on the ABAP language level. The new hierarchy functions can also be used in ABAP SQL, which is the name for Open SQL as of ABAP platform 1809, because SQL no longer focuses on supporting any database, but instead on full optimization of the ABAP layer on top of SAP HANA.


define hierarchy DEMO_CDS_PARENT_CHILD 
  with parameters 
    p_id : abap.char(2) 
  as parent child hierarchy( 
      child to parent association _relat 
      start where 
        id = :p_id 
      siblings order by 
      multiple parents allowed 
      $node.hierarchy_rank        as h_rank, 
      $node.hierarchy_tree_size   as h_tree_size, 
      $node.hierarchy_parent_rank as h_parent_rank, 
      $node.hierarchy_level       as h_level, 
      $node.hierarchy_is_cycle    as h_is_cycle, 
      $node.hierarchy_is_orphan   as h_is_orphan, 
      $node.node_id               as h_node_id, 
      $node.parent_id             as h_parent_id 

Figure 6 — Defining a hierarchy with core data services


Another important improvement is the definition of abstract entities in core data services using the new keyword DEFINE ABSTRACT ENTITY. Abstract entities, such as database entities, have a structure consisting of fields, but they are not stored in a table. They correspond to structure definitions in the traditional ABAP Dictionary. They can be used in metadata extensions to define the user interface, similar to how structures are used in Dynpro and Web Dynpro development.

Adapting Custom Code for SAP S/4HANA

Making the transition from SAP Business Suite to SAP S/4HANA means adapting your custom code for SAP S/4HANA,4 which uses a different data model than SAP Business Suite. ABAP Test Cockpit is a central entry point for beginning this transformation and shepherding you through the adaptation. ABAP Test Cockpit has been a strong analysis tool for identifying incompatibilities between your custom SAP Business Suite code and SAP S/4HANA — however, you have to fix the errors manually when making the conversion to SAP S/4HANA.

With ABAP platform 1809, ABAP Test Cockpit offers quick fixes for commonly identified issues that you can apply with a single mouse click. Figure 7 shows an example that often occurs in the SAP HANA context, where a binary search operation in ABAP requires a sorted result, but the SQL standard is not sorted by default. In this case, you need to append the addition ORDER BY PRIMARY KEY, which is supported by the quick fix functionality. This approach saves a significant amount of development time and also increases code quality.


Figure 7 — The quick fix functionality for commonly identified issues, such as sorting, included with ABAP platform 1809 saves significant time and effort when adapting custom code for SAP S/4HANA


In addition, ABAP platform 1809 introduces highly graphical SAP Fiori-based reporting applications, such as the one shown in Figure 8, to support you with scoping and analysis capabilities, and to guide you through the transition. Objects that are out of scope won’t be imported to get rid of unused code.


Figure 8 — ABAP platform 1809 provides graphical SAP Fiori-based reporting and analysis applications to support the custom code adaptation process


Enabling M2M Communication

Due to the growing popularity of IoT scenarios, the Message Queuing Telemetry Transport (MQTT) protocol, which was designed to support M2M communication in industrial IoT scenarios, has generated a lot of interest for enabling real-time data updates and the ability to react to events on the fly. MQTT supports this capability by offering a lightweight publish-and-subscribe infrastructure where clients can send and receive messages through a message broker.

With ABAP platform 1809, the ABAP stack can act as an MQTT client that can publish messages and receive events, similar to the ABAP channels infrastructure. Figure 9 shows the implementation of an MQTT client that connects to a public MQTT broker and publishes a message to that broker.

In this way, MQTT can be used to extend SAP S/4HANA and SAP Cloud Platform in an event-driven way, taking advantage of the IoT and machine learning capabilities included with SAP S/4HANA, and enabling real-time analytics and responsiveness with the speed provided by SAP HANA.


METHOD constructor.
      " create MQTT client
          i_url            = 'ws://'
          i_event_handler  = me
          r_client        = mo_mqtt_client ).

      " establish the connection
      mo_mqtt_client->connect( ).
    CATCH cx_mqtt_error.
      " to do: error handling, e.g. write error log!

METHOD publish.
      " create message with specific quality of service (QoS)
      DATA(lo_mqtt_message) = cl_mqtt_message=>create( ).
      lo_mqtt_message->set_qos( if_mqtt_types=>qos-at_least_
        once ).
      lo_mqtt_message->set_text( iv_message  ).
      " publish message to topic
                EXPORTING i_topic_name = iv_topic
                          i_message    = lo_mqtt_message ).
    CATCH cx_mqtt_error.
      " to do: error handling, e.g. write error log!

Figure 9 — Implementing an MQTT client that connects to a public MQTT broker and publishes a message to that broker



While the cloud in general — along with SAP Cloud Platform ABAP environment — garners significant attention, a large number of on-premise ABAP-based productive systems are still running in SAP customer landscapes to support SAP Business Suite and SAP S/4HANA on premise. ABAP platform 1809 is intended to support these customers going forward.

ABAP platform 1809 is a thorough foundation for SAP S/4HANA and SAP S/4HANA Cloud, and takes full advantage of SAP HANA functionality. With the optimizations and the improved Eclipse-based ABAP development tools included with ABAP platform 1809, SAP customers and partners can develop custom applications and enhance standard SAP code to position themselves for the digital future.


1 For an in-depth look at SAP Cloud Platform ABAP environment, see the SAPinsider article “Take Your ABAP Skills to the Cloud” (Issue 3 2018) available at [back]

2 For a detailed examination of the SAP NetWeaver release strategy, see the SAPinsider article “Planning Your SAP NetWeaver Upgrade Strategy” (Issue 1 2018) available at [back]

3 Learn more about converting from SAP Business Suite to SAP S/4HANA in the SAPinsider articles “Making the Move to SAP S/4HANA” (Issue 1 2017) and “A Simplified Way to Bring Your Custom Code to SAP S/4HANA” (Issue 2 2018) available at [back]

4 For a detailed look at this process, see the SAPinsider article “A Simplified Way to Bring Your Custom Code to SAP S/4HANA” (Issue 2 2018) available at [back]


Karl Kessler

Karl Kessler ( joined SAP SE in 1992. He is the Vice President of Product Management ABAP Platform — which includes SAP NetWeaver Application Server, the ABAP Workbench, the Eclipse-based ABAP development tools, and SAP Cloud Platform ABAP environment — and is responsible for all rollout activities.

More Resources

See All Related Content