A New ABAP Programming Model for Digital Business

SAP S/4HANA is a business software suite designed to run in the digital age, with built-in support for the technology required to meet the needs of digital business, such as a consumer-grade user experience, business networks, and connected devices and things. As digitization continues its steady ascent to the top of the priority list for most organizations, growing numbers of businesses are moving forward with an implementation of SAP S/4HANA. For many SAP customers, this means a transition from traditional SAP NetWeaver and SAP Business Suite deployments to one that provides cloud qualities at large scale, and fully leverages SAP HANA and SAP Fiori technology — a new type of deployment that requires a new ABAP programming model.

The ABAP platform has been adapted over the years to enable a variety of new ABAP programming models, from Dynpro and list processing for traditional SAP GUI-based applications to models and tools for web-based development, such as business server pages and Web Dynpro. While these past adaptations have not fundamentally changed the ABAP programming model, the introduction of SAP HANA as an in-memory database and SAP Fiori as the new user experience paradigm has made it necessary to rethink the ABAP development approach for solutions such as SAP S/4HANA.

This article helps you fully leverage all the advantages of the new ABAP programming model by outlining the key requirements for a model that supports the development of modern business applications, and explaining how these requirements are met by the ABAP platform starting with SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP 7.51 and a successor version planned for shipment in the fall of 2017.

Why a New ABAP Programming Model?

When it comes to modern applications, customers expect a sophisticated look and feel, an intuitive and responsive user experience design, and role-based access for the different personas involved. In addition, in contrast to traditional Dynpro or Web Dynpro applications, customers expect to be able to continue their work regardless of the device they are using. For example, they might start in the morning on their smartphone, continue in the office at their desktop or laptop, hand over their work in progress to colleagues, and in the evening run analytics to pull a status report.

Customers also prefer the 24/7 availability of cloud-based applications, and want developers to be able to extend business applications on the fly — out of the running context — without invoking complex design-time environments. They expect a high degree of scalability and elasticity when the number of users and requests heavily increase. And last, but not least, they take for granted the traditional lifecycle and supportability capabilities of their proven ABAP environment, including transport from development and quality assurance to production.

Available with 7.51 and its successor release (planned for the fall of 2017), the new ABAP programming model is designed to address all these requirements and bring new opportunities and flexibility to developers. It retains the lifecycle and supportability features of previous models while supporting new innovations with its ability to push down data-intensive logic to SAP HANA and to run user interaction logic inside the browser.

On the data side, the core data services (CDS) paradigm based on SAP HANA provides modeling support for both the transactional and analytical aspects of the underlying business objects. On the front-end side, the SAPUI5-based SAP Fiori provides a responsive design for applications running on both mobile devices and traditional desktops. SAP Fiori builds on a role-based model with key user extensibility options that no longer require any modifications to traditional user interfaces, which can be difficult to implement and challenging to maintain when SAP delivers upgrade options.

Release 7.51 and higher of the ABAP stack provides full compatibility between the new model and previous models, such as Web Dynpro and Floorplan Manager, which eases the transition to SAP S/4HANA dramatically. In addition, required code adaptations for SAP S/4HANA are well documented and supported by corresponding conversion tools. Existing SAP NetWeaver customers are also supported in the transition with the ability to evaluate the new programming model in an incremental way. The first elements of the new model were introduced in SAP NetWeaver 7.4 and 7.5 with the addition of CDS. While initially introduced to support analytical scenarios, CDS support for transactional services was added in ABAP 7.51.

So, what are the characteristics of this new ABAP programming model, and how does SAP NetWeaver AS ABAP 7.51 — and its planned successor — implement them? Let’s take a closer look at what is expected and how the new ABAP programming model meets these expectations.

A Modern User Experience

Modern users have a set of expectations for how they will be able to perform their daily tasks, including a high degree of usability, instant insight into data, and the ability to work anytime on any device. The new ABAP programming model has evolved to meet these requirements.

Traditional ABAP applications based on Dynpro or Web Dynpro tend to be fairly complex. For example, think of the well-known order entry transaction VA01, which is a single, large transaction that encompasses nearly all the functionality for the different personas involved, such as the sales representative, the financial accountant, and the controller. This can lead to complex user interfaces that merge all the different views into one place.

Modern end users expect a role-based, easy-to-learn flow of user interactions to get their work done — an expectation that has had a major impact on the new ABAP programming model. To meet this expectation, the new ABAP programming model follows a template-based user interface approach that reflects user roles more precisely — by providing views and perspectives on specific data that is relevant to a particular role while hiding unnecessary details, for instance. This approach makes it possible to support multiple applications with the same data and functionality, while also properly managing redundancies in the applications without introducing inconsistencies in the underlying data model (see Figure 1).

Another modern user expectation is instant, unlimited access to data. Traditional applications are bound to an application server. This means entering restrictions into a selection screen to specify the required data, which is then copied from the database to the application server level — think of an SAP List Viewer (ALV) scenario. Modern users, however, do not accept data browsing that is limited by the sizing and workload of the application server level. They want to sort, filter, group, and aggregate data in real time with immediate effect. To meet this expectation, the new ABAP programming model supports SAP HANA features and performance without the limitations caused by the least common denominator approach of traditional row-based database systems.

In addition, users want the freedom to work on their preferred devices at any time without disruption, and they want to freely collaborate with their peers. To provide this capability, the new ABAP programming model removes the tight coupling of the traditional client-server model to avoid server stickiness, so that an application can move from one application server to the other, and so that the application context is not stored on the application server level — it remains stateless (see Figure 2). This enables functionality such as saving intermediate objects in draft mode.

Support for the Cloud

Another driver for the new ABAP programming model is the need to support cloud-based applications. In traditional on-premise environments, users expect rare updates managed with planned downtimes upfront — in cloud-based environments, on the other hand, consumers expect new features and fixes to be continuously delivered.

Technically, this continuous delivery must be achieved through a business continuity model with zero-downtime maintenance and online imports. Applications must not stick to a particular server environment. On the provider side, resource consumption must depend on system load. If more resources are needed, computing instances, such as additional servers, need to be added dynamically. To enable ABAP developers to meet these requirements, cloud services are integrated in a completely transparent fashion in the new ABAP programming model, enabled by a multi-tenant architecture.

In the new ABAP model, adaptation of cloud applications, such as extensions, take place in a well-managed manner. Typical extensibility actions involve adapting the user interface, such as adding custom fields, changing the layout, extending business logic or analytical scenarios, creating custom business objects, and extending the SAP Fiori catalog and roles. These adaptations are typically carried out by a key user or by a developer (from SAP, a partner, or a customer), who makes the adaptations in a modification-free way using in-app extensibility options, without any clashes and using only whitelisted APIs and predefined extension points (business add-ins, or BAdIs) that comply with zero-downtime principles. The corresponding toolset in the ABAP application server is fully cloud ready, meaning that extensions are managed in a transparent fashion.

When it comes to integrating cloud services, the challenge for the new programming model, then, is to utilize resources on the various levels — browser, ABAP application server, and SAP HANA database — so that the right tasks are performed on the right layer. In particular, this includes proper use of caching, appropriate management of the application state, and reduced roundtrips. The new model delivered with ABAP does this by optimizing the infrastructure at all layers (see Figure 3).

All in all, to support cloud-based applications, the new ABAP programming model must utilize modern user interface technology, reduce the inherent redundancy in traditional applications, offer integrated extensibility, keep proven platform assets, and avoid server stickiness. The new model delivered with the ABAP platform does this with a well-balanced architecture on the various levels of abstraction.

A RESTful Architecture

To enable collaboration and seamless shifting between devices while preserving work continuity — features that modern users depend on — a REST-based architecture is required. With a REST-based architecture, you achieve more loosely coupled layers that interact and interface in a stateless fashion using REST-based protocols based on HTTP, such as the OData protocol.

In the traditional Dynpro and Web Dynpro world, the application state is kept in the back-end session residing on the application server (in the well-known roll area), which disables device switch and continuity of work. Sessions simply time out if not continued on that server. In simple SAP Fiori applications, traditional logic is carried out in a “batch-input” fashion, meaning input is gathered in several steps from the end user and then written against the database. The state of the application is held on the client level, which does not allow for continuous work or collaborative scenarios.

The new ABAP programming model follows a REST-based approach. The application state is persisted in SAP HANA at the database level, and no session is present on the application server level other than the business logic, which is executed in the current step (see Figure 4). This approach allows users to switch devices and to collaborate.

For performance reasons, not all session states are persisted — only the essential state is saved, which consists of changed original data, interaction data (such as error status), undo/redo history, and acquired locks, for instance. All the session data that can be easily reconstructed on the fly (such as value help) is reconstructed when the application is resumed. The program model also shields all technical session context (such as logon data, authentication, and established database connection) implicitly.

A Locking Strategy

To support a RESTful architecture — where the application state is not kept on the application server, but rather is kept on the database layer — a locking strategy is required.

Traditionally, Dynpro or Web Dynpro applications use enqueue operations to set a logical lock and avoid parallel updates on the same physical object. In a “batch-input” scenario, the locks are typically required shortly before the update takes place, since all update operations are tightly bundled. But what happens if transactions are executed in an multi-step interactive way, as with most SAP Fiori applications?

To facilitate the session handling, the new ABAP programming model introduces the “draft” concept, which enables users to save an intermediate stage of work. Each interactive flow of screens updates the draft consecutively. Only at the end is the draft data activated and written back to the original tables. So what does this mean for locking? An interactive application might be continued over a long period of time, depending on its state, and locks cannot be held over that period of time. How is locking handled for these types of applications?

With the new ABAP model, the approach is to use an optimistic locking strategy (see Figure 5). With this approach, typical request processing in interactive applications is protected and isolated by exclusive locks (enqueues). When a timeout occurs (because the application was suspended due to a long time interval, for instance), the application will resume using an optimistic lock. When the draft is written back, an exclusive lock must be reacquired. Locking is embedded in the persistence framework supported by the enqueue server to simplify the application logic as much as possible.

An Example of the New ABAP Model in Action

To get an idea of how developers can build applications using the new ABAP programming model, let’s consider a basic scenario of sales orders that are changed by different end users.

Figure 6 shows a sales order header defined using CDS¹ and SAP HANA views in a straightforward fashion. To enable draft persistence, a table (Z268_SO_TP_38) is created automatically to store the draft headers (see line 16). Each sales order header has a 1:n association to the sales order items (see line 27). For the sales order items, a draft persistence is created in a similar way (see Figure 7).

In the SAP Fiori template for the sales order application, you see the list of sales orders and whether changes have been drafted by other users. If you change a sales order by changing a product or quantity, a draft will be saved (see Figure 8).

This simple example shows how drafts can be created by several users in parallel who are switching between devices and contexts. The underlying framework enabled by the new ABAP programming model ensures that the consistency of the data is retained (for example, calculating and updating the total amount if the quantity was changed).

Summary

Modern applications require a compelling user experience and cloud qualities, and the new ABAP programming model available with SAP NetWeaver AS ABAP 7.51 (as well as the upcoming successor release due in the fall of 2017) rises to meet that challenge. Instead of building separate applications to handle different functionalities — transactions, search, and analytics, for instance — the model ensures that one user experience builds on exactly one programming model that is based on one common semantic data model powered by SAP HANA.

The ABAP application server offers CDS for that purpose, along with transactional application frameworks and traditional ABAP coding that expose user interface consumption services through the OData protocol, which significantly simplifies template-based SAP Fiori applications.

The key requirements outlined in this article are mapped to proven capabilities of the underlying ABAP application server (such as lifecycle and supportability capabilities) or are addressed by the new programming model (including RESTful applications, code pushdown, decoupling of user interface annotations and back-end logic, state management, and the draft concept). Future versions of the ABAP platform will continue to provide innovations in these areas and to meet the evolving needs of businesses in the digital age.

Learn more at https://youtu.be/AqvWc0_1ffE.

^{1 For more on CDS development, please see my previous SAPinsider articles: “Enhanced ABAP Development with Core Data Services (CDS)” (October-December 2015); “A Foundation for the Future” (July-September 2015); “ABAP for the Modern Age” (January-March 2016); and “Introducing ABAP 7.51” (October-December 2016). [back]}