A New ABAP Programming Model for

Digital Business
With digitization a top priority, many organizations are preparing to transition to SAP S/4HANA
and its built-in support for business operations in the digital age. To meet the needs of this new
type of deployment — which requires cloud qualities at large scale and full support for SAP HANA
and SAP Fiori — SAP has introduced a new ABAP programming model. This article helps you take
advantage of this new model by walking through the requirements for modern application
development and how these requirements are met by the ABAP platform as of SAP NetWeaver
Application Server ABAP 7.51.

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 Floor plan 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).

Figure 1 — The new ABAP programming model provides an easy-to-use, role-based user experience
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.

Figure 2 — With the new ABAP programming model, continuous work, device switching, and collaboration are
enabled by a stateless back end
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 white listed 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).

Figure 3 — The new ABAP programming model optimizes the infrastructure to ensure proper use of caching,
appropriate management of the application state, and reduced roundtrips
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.

Figure 4 — The new ABAP programming model supports a RESTful architecture to enable persistence in the
database
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 (enqueue). 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.

Figure 5 — The new ABAP programming model uses an optimistic locking strategy for interactive applications
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 CDS1 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).

Figure 6 — An example sales order defined with draft persistence using the new ABAP programming model
Figure 7 — The sales order items for the example sales order defined with draft persistence
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).

Figure 8 — Pending draft changes in the example sales order scenario

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.