Extensibility in SAP S/4HANA Cloud

Introduction

Extensibility covers a broad spectrum of topics that allow customers and partners to adapt standard business software to their business needs. This includes business configuration, integration, custom fields, and logic, layout adaptation of user interface (UI), forms, and reports. It also covers custom terminology and translation for customer-specific applications. (SAP, 2022)

Extensibility in SAP S/4HANA Cloud can be divided into three parts:

◉ In-App/Key User Extensibility

◉ Side-by-Side Extensibility

◉ Developer Extensibility/Embedded Steampunk

All these 3 extensibility options follow the Lifecycle stable, decoupled model of creating and managing extensions on SAP S/4HANA Cloud that enables, smooth, undisruptive, and fast upgrades.

Now, let us have a look at the 3 extensibility options in detail

Key User Extensibility

Key user/In-App Extensibility allows key users to edit and customize existing objects in SAP S/4HANA Cloud to a certain extent. The main advantage of key-user extensibility is that, a key user doesn’t require advanced technical skillset to alter any existing object.

This means that a user will be able to add/change objects onto SAP S/4HANA Cloud without affecting the standard SAP code stack. It will remain decoupled from the standard stack thereby making SAP S/4HANA Cloud always upgrade ready.

The following options are available for a customer as part of Key-User-Extensibility

System Landscape

Side-by-side Extensibility

Side-by-Side Extensibility enables users to utilize the Released APIs and the APIs created by exposing custom CDS views and Custom Business Objects in SAP S/4HANA Cloud and create custom applications in SAP Business Technology Platform. SAP BTP is a secured Platform as a Service for creating applications or extensions in a secure cloud based computing environment managed by SAP.

Like Key-User-Extensibility, as the custom applications are created based on released APIs/APIs based on Key User objects (Custom Business Objects and Custom CDS Views), Side-by-Side extensibility is also decoupled from the SAP S/4HANA Cloud standard stack and is always upgrade ready

System Landscape

Developer Extensibility

Developer Extensibility on SAP S/4HANA Cloud introduces the same flexibility offered by Steampunk on BTP now on SAP S/4HANA Cloud. Hence this is also known as Embedded Steampunk.

This means that you will be able to develop applications using ABAP Development Tools(ADT) or Eclipse with ADT by connecting your SAP S/4HANA Cloud Instance.

Like the existing extensibility options mentioned above, Developer Extensibility provides a decoupled lifecycle stable environment on SAP S/4HANA Cloud which allows developers to create custom applications using ADT based on Restful ABAP Programming Guidelines.

System Landscape

Let us consider a requirement from an imaginary client and see how this requirement can be implemented via all the three available Extensibility options in SAP S/4HANA Cloud which are discussed above.

Requirement

A customer wants a report to view the Revenue Accrued based on the cost booked through EBRR process. These Accrued Revenues must be aged based on a basket of days (Say (0-30) (31-60) etc). This will give visibility to business on how much more revenue needs to be billed based on ageing.

Key user Extensibility

Implementing such a requirement via Key user extensibility consists of the following steps

◉ Identify the right CDS views (released API) which contains the required data.

◉ Create a Custom CDS view of type Analytical Cube

◉ Create of a Custom Analytical Query

◉ Create a Custom tile for the Analytical Query to be displayed in the Fiori Launchpad of SAP S/4HANA Cloud

Side-by-side extensibility

Implementing such a requirement via Side-by-side extensibility consists of the following steps in addition

◉ Connectivity between SAP Business Technology Platform and SAP S/4 HANA Cloud uses HTTPs communication via. OData APIs.

◉ Required Identity Management (authentication techniques like Basic Authentication, OAuth2, XSUAA etc).

◉ Developing an application on SAP BTP ABAP Environment.

◉ Deploying application on HTML5 repository service and then integrate into SAP S/4HANA Cloud launchpad service.

We have seen the ways that are described above on how this requirement could be taken up and implemented based on Key-User-Extensibility and Side-By-Side Extensibility. We now know that Key-User Extensibility utilizes the existing key-user functionalities provided by SAP S/4HANA Cloud whereas in Side-By-Side extensibility, the user must utilize other language skillset like Node.js/Java etc. or other BTP integration/analytical services or the ABAP Environment on BTP

Now, let us take the same customer specific requirement and see how different the implementation looks like on Developer Extensibility, compared to Key-user Extensibility on SAP S/4HANA Cloud.

Developer Extensibility

A report created by following Key-User/Side by Side extensibility will be able to meet some additional requirements such as adding a mandatory check in the search criteria.

But if the customer requests for an additional validation on the F4 or while the data is fetched, this calls for a change in coding, which is not feasible via Custom Analytical Queries.

Developer Extensibility helps in solving these limitations by providing an environment where a developer will be able to connect their SAP S/4HANA Cloud development client (This will be Client 080) to ADT and then create a custom report based on RAP guidelines.

Now, let us see how a user can create applications using Developer extensibility for the requirement discussed above.

Benefits –

◉ Opportunity to build cloud ready applications

◉ Upgrade stable custom ABAP Code

◉ Build Fiori Apps using Restful ABAP Programming Model (RAP).

Implementation Types

As explained in the document, different Business Object implementation types offer various options to create your development scenario with the ABAP RESTful application programming model.

There are 2 different implementation types in RAP.

Managed Implementation type

The managed implementation type addresses use cases where all essential parts of an application must be developed from scratch. However, these new applications can highly benefit from out-of-the-box support for transactional processing. Standard operations (create, update, delete) must only be specified in the behavior definition to obtain a ready-to-run business object.

The document Developing Managed Transactional Apps provides a complete step-by step guide on how to develop a new application.

Unmanaged Implementation type

In unmanaged business objects, the application developer must implement essential components of the REST contract. There is no standard functionality provided by the RAP framework. It is only the frame of a business object, that an application developer needs to adhere to. The behavior must be specified in the behavior definition but implemented manually in ABAP classes in the behavior pool. All existing business logic can be integrated, including standard behavior like create, update and delete. In addition, the transactional buffer must be provided and handled by the application developer in the ABAP behavior pool.

The document Developing Unmanaged Transactional Apps provides a complete step-by step guide on how to develop a new application.

Requirement Implementation

To begin with, we shall create a standalone managed RAP Fiori application which will maintain a customer specific GL account to extract Accrued Revenue, Revenue Adjustment and Billed Revenue amount. This GL maintained Fiori application is draft enabled and provides accrued revenue versioning as well.

Steps involved to create a managed RAP application(managed)

◉ Create an ABAP Cloud Project in an ADT or Eclipse tool.

◉ Build a database table to provide a data source to a CDS View Entity.

◉ Create a Root View Entity to expose data from a DB table and same DB table will be used in standard OData Operation like Create, Update and Delete.

◉ Create a Projection View Entity on top of Root View Entity, to project or provide an alias of a data source.

◉ Create a metadata extension view to provide UI specific annotations.

◉ Create a behavior definition to manipulate the behaviour of an application. Using behavior definition, create a local implementation class to implement validation and determination.

◉ Create a Service Definition to expose projection view and finally define the OData protocol in the service binding.

Next, we will create another managed Fiori list report, to display Unbilled Revenue Aging, where we will display revenue based on days bucket with respect to company code, Project and WBS element. These revenues have been fetched based on the previously built managed GL maintenance Fiori application. This list report is a managed application utilizing an unmanaged query, which means that the framework can’t provide the SQL statement to access the database. Instead, we must implement a query capability to retrieve the data matching the OData request. This can be handled with the help of an ABAP class declared in the consumption view using @ObjectModel.query. implementedBy annotation.

These unmanaged queries are implemented in ABAP Classes. The query implementation class implements a predefined ABAP Interface IF_RAP_QUERY_PROVIDER to ensure that the required basic oData support is enabled.

Steps involved to create managed RAP application list report using un-managed query

◉ Create a DB table to create a Root View entity. This Database may not consist of Ageing fields because these are calculated field and those fields, we can directly define in the Root View Entity.

◉ Create a Projection View Entity on top of Root View Entity, to project or provide an alias of a data source. In the Projection View, we must declare unmanaged query annotation with ABAP Class.

◉ Implement ABAP Class with relevant unmanaged query capabilities like sorting, paging, search, filtering etc. In addition to that we also have implement calculated fields logic for e.g., Ageing buckets based on other interface views.

◉ Create a Service Definition to expose projection view and finally define the OData protocol in the service binding.

◉ In this scenario, we can omit behaviour definition and implementation part because we don’t need to provide transactional capabilities to this application.

Once we are ready with the RAP based applications, we can deploy these applications on the launchpad as shown below.

As you have already seen, this opens up a huge potential for developing custom applications on SAP S/4HANA Cloud by leveraging the stability contracts and RAP guidelines.

Benefits of Developer extensibility over key-user extensibility –

 

◉ Draft capability is not possible using key-user extensibility.

◉ To implement extensive logic i.e., validation and determination some feel difficult to manage it (purely depends upon use cases and development complexity).

◉ Flexibility to enhance business logic rather than focus on the technical artifacts and have a privilege to use debugging, troubleshooting, and testing tool support.

RAP guidelines and how to write code on SAP S/4HANA Cloud

The coding standard for Developer Extensibility on SAP S/4HANA Cloud follows the same principles and guidelines for Restful ABAP Programming.

This document, provides a detailed flowchart on how a RAP application should be developed. All development constraints which a developer can face during developing a RAP application are discussed here