Version 1809 of the on-premise ABAP platform — released in September 2018 and shipped together with SAP S/4HANA 1809 — delivers a set of notable improvements to the Eclipse-based ABAP development tools, which are tools for enabling rapid, efficient development and enhancement of business applications. The tool improvements included in ABAP platform 1809 are centered on helping developers create sophisticated, modern applications that meet the needs of digital businesses.
Here, we take a closer look at a few of the key tool improvements delivered with ABAP platform 1809, including new features for maintaining enhancements, analyzing runtime errors, defining lock objects, and editing transport objects are particularly notable.
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 1 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.
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 2 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.
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 3 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.
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 4 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.