Argus - Fotolia


SAP ABAP programming needs to be brought into the modern era

As a programming language, ABAP has improved. But the ABAP development platform lags behind modern approaches. Contributor Ethan Jewett argues for better tooling support from SAP.

ABAP is sometimes maligned as behind the times, but as a programming language it has progressed quite quickly in...

recent years. It has adopted more functional and concise syntax, powerful additions to its database abstraction and the introduction of new capabilities for defining HTTP Web services.

One part of ABAP that continues to lag well behind the times is its developer tooling. The basic workflow that all ABAP developers follow has remained unchanged while the rest of the development world has dramatically revamped and improved the standard development workflow. This stagnation poses real problems for ABAP development organizations that wish to remain competitive.

How SAPABAP programming works

ABAP development happens on a shared development system. Developers log on to this system and make changes to development objects like classes and function modules. Once changes are made, they can be saved and activated. The only way to test a change is to save and activate the development object and see what happens. This means that when a developer changes an object, that object is changed for all users of the shared development system (Figure 1).

Development workflow in an ABAP environment.
Figure 1: Development workflow in an ABAP environment. Developers make changes serially.

The standard SAP system landscape consists of the previously mentioned development system, a test system and a production system. Once development changes are complete in the development system, they are moved to the test system using a transport. A transport is a point-in-time snapshot of a set of development objects. The changes are further tested in the test system -- no changes are made in this system directly. If all goes well, the same transports are moved to the production system.

How other development platforms work

Most other platforms take a different approach to development work. There is no central shared development system. Instead there is usually, but not always, a shared distributed version control system (VCS) like Git used to store the source code and configuration files that define the application and the environment setup required for the application.

When a developer wishes to change something in an application, the developer will check out a copy of the source code and configuration, automatically build a complete local version of the platform the application runs on, run the application locally and make and test changes locally.

Other developers are not affected by the changes this developer makes until the developer sends the changes back to the central VCS. Even then, other developers can choose exactly which changes they want to apply to their local versions of the application, or even maintain several different local versions of the application with different sets of changes applied to them (Figure 2).

In a standard development workflow based on a VCS, developers can work in parallel.
Figure 2: In a standard development workflow based on a VCS, developers can work in parallel.

This practice of maintaining several versions of an application is commonly referred to as "branching" and is useful when working in parallel on multiple features, bug fixes or refactorings. Developers can maintain branches locally, or send branches to the central VCS so that multiple developers can work on the same branch. Only when developers wish to send their changes back to a branch on the central VCS do they need to ensure their changes are compatible with those on the central system.

Changes on a branch ready to be tested and sent to production are often noted using a tag. This tag is kept unchanged but, if fixes are required, a new tag with a fix can be created based on any version or branch in the VCS.

Why do these differences matter?

The key difference between these approaches is the following:

In the ABAP development workflow, any change by any developer affects all other developers immediately and it is difficult to roll back to previous versions of the application. Transports created for promotion to test and production systems are based purely on the current state of the development system.

In the standard modern development workflow, every developer has control over when changes by other developers are applied to their working environment and it is easy to roll back to a previous version of the application. Tags created for promotion to test and production systems can be created based on any historical version of any branch.

These differences result in byzantine processes in the ABAP world. Consider the case in which two SAP ABAP programming developers each need to make changes to a set of classes that interact with each other. It is difficult for two ABAP developers to work on the same code at the same time, so the best approach would be for one developer to do her work first and for the other to start once the first is finished. If the work will take one day for each developer, getting all the work done takes two days.

Of course, if there is a problem with the first set of work in the test system, the work of the second developer is already in place and we can only make transports based on the current state of the development system. Now we have to decide whether to remove the work of the second developer and try to fix the original problem, or if we also promote the work of the second developer to the test system along with the fixes to the work of the first developer.

For this reason, it is often a good idea to wait until the first developer's work is promoted to production, which could take weeks, before the second developer begins her work. We have two person-days of work to do, and we have two developers to do the work, but the work could take weeks to complete because of the process required to work around SAP ABAP programming development tooling deficiencies.

In the non-ABAP world, both developers make their changes on branches locally, in parallel. Once a developer is done with her work she sends it back into the central version control system. The second developer does the same, although if there are incompatibilities between her work and the work of the first developer, she may need to spend some time fixing the problems. So work that should take a day takes possibly a little extra time for fixing incompatible changes.

A management issue

The nature of these differences between ABAP and other platforms seems like a simple issue of developer tooling and support for full-featured version control systems. But it results in major process and management pain points. In my opinion, because of the lack of support for modern version control, ABAP development work is inherently less parallelizable and more brittle than development work on platforms that support version control systems.

Is it still possible to run a relatively efficient and effective ABAP development organization? Of course it is. But it sure would be a lot easier with better tooling support from SAP.

Next Steps

How to use Git and GitHub for SAP software development

Defining good software development tools

Choosing the right developer tools

Dig Deeper on SAP ABAP