Modification-Free Extensions for SAP S/4HANA

SAP standard applications have been meeting enterprise customer needs for decades. One of the major reasons these applications have been able to do this, aside from their scope and quality, is customers’ ability to tailor the applications to the unique needs of their business through various extension options, such as predefined extension points and modifications. Through extension options, SAP Business Suite and the underlying SAP NetWeaver technology platform offer full flexibility to adapt and change almost every delivered SAP functionality.

SAP customers are familiar with a huge range of extensibility options, starting with very simple extension scenarios, such as adapting the layout of fields at the user interface (UI) level, to extending the underlying business logic that affects all software layers, to extensions on the persistence and database layers, such as creating include and append structures for the underlying SAP tables. While traditional approaches to extensibility have served SAP customers well for many years, SAP S/4HANA and the cloud bring with them new requirements, such as rapid onboarding and software update cycles, that have led to the need for a new extensibility framework.

This article provides an introduction to the extensibility framework delivered with releases 1511 and 1610 of SAP S/4HANA to meet modern extensibility requirements. It looks at the available approaches for extending SAP S/4HANA applications and then walks through an example of using in-app extensibility — a powerful extensibility approach that enables users to add key features to applications using web-based, easy-to-use tools, without the need to dive into the full details of the underlying code using in-depth ABAP development tools.

Why a New Extensibility Approach?

SAP customers have long been able to use predefined extension points built into SAP technology to add custom fields and logic to differentiate their applications from competitors or adapt them to the operational needs of their business processes and end users. If there is a customization need that is not covered by predefined extension points, which support mainly straightforward extension scenarios, such as adding custom fields for master data, customers have the option to create modifications in the code.

However, the more extension options a customer uses, the higher the cost when SAP delivers new versions of the application during a support package installation or upgrade, particularly with modifications, each of which must be checked and adapted, if necessary, to any SAP-delivered application changes. In addition, ABAP developers have traditionally been responsible for managing the life cycle of an extensibility project, from creating the extensibility artifacts, to extending the different application layers, to binding the artifacts in transport requests — all while ensuring that development is carried out in a coherent and consistent way. This is no trivial task, since development landscapes at large customer sites are spread over many different SAP repositories. It also means that business users and IT users must work together to ensure features are meeting needs, which can sometimes lead to delays due to resource constraints or miscommunications.

In a cloud-based landscape driven by speed, simplicity, and flexibility, the traditional approach to extensibility comes up against some challenges. For instance, in a cloud-based environment, the manual intervention required for each customer modification conflicts with the operational automation needed to run a cloud-based solution at large scale, and becomes even more resource intensive with frequent delivery of cloud-based updates. Delayed feature implementations and development complexity can also affect speed and agility, which are key characteristics of cloud-based implementations.

To meet the needs of modern landscapes, releases 1511 and 1610 of SAP S/4HANA redefine extensibility from both a conceptual and technological perspective. In particular, these releases introduce an option called in-app extensibility that enables business experts without deep technical knowledge — known as key users — to implement key types of customer extensions, such as creating custom business objects and adding custom fields to business objects. And while this concept is essential for cloud-based deployments, it is also valuable for traditional on-premise landscapes. With a move to the cloud inevitable for most organizations, it is important to think of extensions in a cloud-first context, even for applications running in established on-premise landscapes.

A New Extensibility Framework for SAP S/4HANA

The extensibility framework delivered with releases 1511 and 1610 of SAP S/4HANA supports a few different extension approaches for adapting applications. The approach you take depends on the types of changes you need to make:

• Custom code development, which is available for on-premise SAP S/4HANA and SAP S/4HANA Cloud, typically requires full access to all ABAP development objects and corresponding tools via ABAP in Eclipse. This approach is the best fit for customers who want full control over the details of their SAP S/4HANA deployment.
• Side-by-side extensibility, which is available for SAP S/4HANA Cloud and SAP S/4HANA on premise, is ideal for loosely coupled extensibility that incorporates non-SAP S/4HANA software. Side-by-side extensions are implemented on SAP Cloud Platform as extension applications using the SAP HANA native development environment.¹ These applications contact SAP S/4HANA through established protocols and replication tools. This approach is particularly relevant for cloud-based extension scenarios that include non-ABAP assets that access both SAP S/4HANA Cloud and on-premise SAP S/4HANA via published and stable APIs.²
• In-app extensibility, which is available for SAP S/4HANA Cloud and SAP S/4HANA on premise, enables customers to create custom fields and custom objects using web-based tools that do not require deep coding skills. As with the side-by-side extensions, the customizations are loosely coupled and use published and stable APIs, but rather than running on a different platform, such as SAP Cloud Platform, they run on the same ABAP software stack as the enhanced application — that is, they run “in app.”

This article focuses on the third option, in-app extensibility.³ From a lifecycle perspective, the boundary conditions of in-app extensions are quite different from traditional extensions. Unlike in a traditional environment, where patches and upgrades are delivered and consumed in half-year cycles, SAP S/4HANA is patched and upgraded in regular, quarterly intervals. To avoid conflict with any SAP-delivered innovations, and to ensure customizations continue to work after an upgrade without manual intervention, in-app custom extensions contain no source code modifications, are loosely coupled, use only whitelisted APIs and extension points, and are fully compliant with zero downtime principles.

Another difference with in-app extensibility is that the task of adapting the UI and behavior of SAP S/4HANA applications is performed by key users — primarily users in line-of-business departments — rather than developers from IT or cloud infrastructure teams, enabling rapid development and less risk of inconsistency between data and business logic. Key users typically have a thorough understanding of an application’s underlying business objects, but are not well-versed in low-level coding and debugging tools. The SAP S/4HANA extensibility framework supports these users with built-in, intuitive, SAP Fiori-based tools that enable quick and easy access to the application, even while it is running, and require no thought about the lifecycle properties of the underlying SAP S/4HANA system. The tools are model-driven and context-aware, and come with a role-based UI along with simple, ad-hoc testing and analysis capabilities.

It is important to note that in-app extensions are not a replacement for ABAP development. Custom ABAP development plays an important role in the context of SAP S/4HANA, and SAP has made significant investments in a new ABAP programming model, based on core data services, to support SAP Fiori development for applications such as SAP S/4HANA.⁴ In general, these two roles — key users and ABAP developers — must work closely together to combine the best of both approaches and provide comprehensive business solutions tailored to organizational needs.

An SAP S/4HANA In-App Extensibility Scenario

Let’s see what it looks like to put an in-app extensibility approach into action by walking through a simple example scenario. Let’s say that a manager wants to create different bonus plans for team members based on their revenue achievements. Here, we will follow the steps that the key user — in this scenario, a project manager or team lead — will need to take to create a custom bonus plan business object, including full transactional control (insert, update, delete) and validation logic.

1. Start SAP Fiori Launchpad

In-app extensions start with SAP Fiori launchpad, where the in-app extension tools are accessed. Figure 1 shows a key user’s SAP Fiori launchpad workplace, where the tiles are grouped into tool categories such as Extensibility and Extensibility Test. The groups and tiles that appear in the workspace are determined by the extensibility roles assigned to the key user, plus any other roles assigned to that user from other work areas. By clicking on a category, SAP Fiori launchpad scrolls automatically to the corresponding tool applications. In the Extensibility group, for example, you see tiles for the tools Custom Fields and Logic, Custom Business Objects, Custom CDS Views, and Custom Catalog Extensions.

2. Create the Custom Business Object

To create the custom business object, click on the Custom Business Objects tile. This launches the Custom Business Object main screen, which displays a list of already-existing custom business objects. Click on New to create a new custom business object. The system prompts for a name (in the example, Team Bonus Plan) and technical identifier (TEAMBONUSPLAN, for example) for the custom business object. The Name in Plural field (here, Team Bonus Plans) helps keep the
SAP Fiori launchpad workspace organized and consistent — by providing labels for the tiles that appear in the workspace, for instance. The system suggests a custom prefix for differentiating customer-created objects from SAP-delivered objects (in the example, YY1).

3. Define the Structure of the Custom Business Object

Once you have created the new custom business object — Team Bonus Plan in the example — click on Create, which takes you to the Edit Custom Business Object screen (see Figure 2), where you define the structure of the object. To define its fields, click on Go to Fields and Logic, which takes you to the Edit Node screen shown in Figure 3 (note that checking System Administrative Data automatically adds a few useful fields — such as Created On, Created By, Last Changed On, and Last Changed By — to the structure of the custom business object).

Here, you can see the list of fields created for the example custom business object, including an ID field, which is marked as the key field, followed by a time interval defined by Validity Start Date and Validity End Date fields, a Target Amount field for the actual bonus amount, and Low Bonus Assignment Factor and High Bonus Assignment Factor fields (additional fields that aren’t visible include Low Bonus Percentage and High Bonus Percentage, Employee ID, and Employee Name). Each field has its own data type, selected from a dropdown.

Once the fields are defined, click on Publish at the bottom of the screen, which makes the custom business object visible to the outside — that is, makes it available to the OData layer, which provides SAP Fiori applications with access to the SAP back end. Publication triggers automatic consistency checks and generates artifacts such as SQL-based SAP HANA tables in the underlying database. The generation of the extensibility checks and artifacts is carried out implicitly in the background — no need to go into the ABAP dictionary. Instead, the corresponding Business Object Processing Framework (BOPF) model and definitions, which enable full transactional control, are automatically generated. To expose the custom business object through the OData protocol and generate a standard SAP Fiori UI for the object, select the UI Generation and Service Generation check boxes on the Edit Custom Business Object screen and republish the custom business object.

4. Add the Custom Business Object UI to SAP Fiori Launchpad

With the service and UI layers generated, the next step is to add the UI to SAP Fiori launchpad. To add it to the SAP Fiori catalog of UIs, click on the Maintain Catalog text that now appears next to the selected UI Generation checkbox, which displays an alphabetical list of available SAP Fiori catalog roles. From this list, select the Extensibility role to assign that role to the custom business object and republish the custom business object. A new tile for the custom business object UI (Team Bonus Plan in the example) will now appear in SAP Fiori launchpad.

5. Launch the Custom Business Object UI

With the structure and role definitions complete, you can launch the generated application — Team Business Plan — for the custom business object by clicking on its corresponding tile in SAP Fiori launchpad. From there, you can create, edit, or delete bonus plans without a single line of ABAP code. While the example list of bonus plans is empty, new plans can be created by clicking on the plus (+) symbol, which launches an SAP Fiori UI containing all the fields defined previously for the custom business object, along with the selected administrative fields, which appear in read-only mode at the bottom.

The UI for the custom business object is automatically equipped with input validation and help (a date picker for the date fields and number checking, for example). Once the user fills the fields and saves, the bonus plan is displayed in the generated Team Business Plan application in tabular form (see Figure 4).

6. Adapt the UI

Extensibility enables you to adapt the appearance and behavior of the application on the fly. Clicking on the user symbol at the top of all SAP Fiori UIs opens a sidebar on the left (known as the “me” area) that offers several customization options, including Adapt UI. Clicking on Adapt UI opens UI Adaptation Mode, from which you can create a new field group — Bonus Data in the example — and drag and drop fields to it. For example, you can drag the Validity Start Date and Validity End Date fields from the General Information group to the new Bonus Data group (see Figure 5). When the application is relaunched, the new layout is immediately reflected.

7. Add Validation Logic

We have now generated a fully functional UI for the example custom business object. You now have the option to add validation logic that performs checks without having to dive into the full underlying code. In the example, we want to check for consistency within created bonus plans — for example, check to ensure that the bonus percentage falls between 110% and 140%. To add this logic, check the Determination and Validation box on the Custom Business Object screen and republish the object. Next, click on Go to Fields and Logic, which takes you to the Edit Node screen shown in Figure 6. As you can see, the validation and determination logic is triggered at particular events, such as After Modification, when the user has changed the data, or Before Save, when values must be determined before they are written back to the database.

Choose the trigger you want to use (in the example, After Modification) and then click on it, which launches a web-based ABAP editor (see Figure 7) that allows you to specify the validation or determination logic. This web-based ABAP editor is not meant to replace ABAP in Eclipse — it is a context-sensitive logic editor that provides access to the fields of the custom business object to check consistency and apply business rules required for that particular context. The editor is highly sophisticated, providing syntax checking, code coloring, and completion functionality, similar to an Eclipse environment. Of course, not all ABAP statements are allowed in this context — for example, you are not allowed to trigger a COMMIT-WORK inside a validation method.

The editor has two different panes for the draft and published logic, making it easy to apply changes without disrupting the entire user community. You can specify the validation logic and test it in draft mode (see Figure 8) before the new code is published and visible to other users.

Summary

SAP S/4HANA not only ushers in a new era of enterprise solutions, it also brings with it an extensibility concept in keeping with the cloud-based principles of modern enterprise landscapes. SAP S/4HANA provides built-in extensibility tools that are web-based, intuitive, and based on public, stable APIs that remain unaffected by upgrades and patches. And with its in-app extensibility approach, SAP S/4HANA allows key users to quickly adapt an application’s appearance and business logic without the need for deep coding, enabling both business users and developers to effectively focus their individual and collaborative efforts in the ways that will best benefit the enterprise.

^{1 For more on the SAP HANA native development environment, see “A New Development Platform for Native SAP HANA Applications” in the April-June 2016 issue of SAPinsider (SAPinsiderOnline.com). [back]}

^{2 SAP S/4HANA has a highly governed process for publishing APIs via the widely used web services and OData protocols. Carefully screened APIs from both SAP and partners are available from SAP API Business Hub (https://api.sap.com). [back]}

^{3 Learn more about custom code development and side-by-side extensibility at https://bit.ly/2tFwfLM. [back]}

^{4 For more on the new ABAP programming model for SAP S/4HANA, see “A New ABAP Programming Model for Digital Business” in the April-June 2017 issue of SAPinsider (SAPinsiderOnline.com). [back]}