SAP S/4HANA Cloud, public edition – Developer Extensibility (SAP S/4HANA Cloud, ABAP environment) Examples
Welcome! Before diving into this blog, I want to let you know that it’s part of an SAP S/4HANA Cloud, public edition – cloud extensibility series. To get the most out of this post, I highly recommend reading the series overview first. This will give you a better understanding of the context and background information for the topics and examples I’ll be discussing. The series overview will also provide you with a roadmap for the rest of the blogs in the series. So, if you haven’t already, please take a moment to read the overview before continuing with this post.
This extensibility technique is available out of the box for customers running SAP S/4HANA Cloud, public edition, on a 3-System Landscape. It became available for new customers running 3-System Landscapes starting with release 2208 (August of 2022).
Developer Extensibility allows our customers to create tightly coupled extensions and more complex extensions in the stack by benefiting from the tight integration we offer.
Customers will benefit from the simplicity of the ABAP RESTful application programming and the overall number of allowed objects in the stack that will give customers plenty of flexibility.
We also expect that partners can create their own extensions using developer extensibility to offer customers specific solutions that can allow them to cover specific business requirements.
Customers will need to use Eclipse-based ABAP development tools (ADT) to create the extensions.
It is important to point out that Developer Extensibility does require someone (usually a developer) with ABAP knowledge to help drive and implement this extensibility technique.
Developer Extensibility will provide flexibility to address business requirements in a lifecycle compliant manner as all artifacts are specially designed to work for Public Cloud. This means no technical debt will be accrued and no unwanted modifications. It will simply enhance and differentiate the system by allowing your team to address the most pressing business requirements without the adaptations that were necessary during upgrades in the past.
Let’s look at a couple of examples (not an exhaustive list) where my team, in close collaboration with our embedded ABAP team under the leadership of Camille El Gammal, Sunil Setty and Ilya Bibik, helped some of our customers address their specific business requirements using Developer Extensibility:
a) Custom APIs: with Developer Extensibility you can now enhance integration scenarios by creating custom APIs using released ABAP objects. This is a game changer as our customers in the past could only work with SAP released APIs. This will open even more possibilities for integrations empowering customers to solve their business requirements. I strongly recommend to also read this blog and tutorial from Dennis Leslie (SAP Product Expert), where he explains how to create custom APIs with Developer Extensibility.
Finance example – Custom API for General Ledger Accounts: we had a customer looking to extract information about G/L accounts maintained in S/4HANA Cloud, public edition, so that this information can be used in other SAP Systems. The customer was looking to work with the allowed API (API_GLACCOUNTINCHARTOFACCOUNTS_SRV) for retrieving data from G/L Accounts, however the provided API didn’t include some of the mandatory fields the accountant needed. Our team created a custom API that consumes existing CDS views from the G/L account and included the fields the accountant needed using Developer Extensibility.
b) Procurement Example: one of our customers wanted to dynamically hide the purchase requisition price for a specific named user(s). This example was a very particular use case in which the customer wanted to differentiate from the standard to allow for this specific and unique option.
Our team used Developer Extensibility to address this very unique requirement. Our team decided to use an enhancement spot included in a BAdI implementation. Our team created an ABAP Package using Eclipse for ADT where they placed all the created objects to realize this specific business requirement.
To specify the usernames for those whom we want to hide the purchase requisition price, the following steps need to be followed:
- Create a database table with a USERID field to store the names (e.g., zpurreq_users).
- Create a CDS view based on your database table.
- Create a metadata to make the USERID field visible on the UI.
- Create a behavior definition with a declared CREATE and DELETE operation.
- Create a Service Definition and Service Binding with an ODATA V2\V4 UI Type.
- Activate and publish your UI service.
- Open the UI and add the user for whom you want to hide the price.
After following these steps, we see the user in the database table we created earlier. This table can then be used in a BAdI implementation.
Our team created the BAdI implementation by simply taking the ABAP Package and including a new ABAP Repository Object (right click on the ABAP Package > New ABAP Repository Object > Enhancements > BAdI Enhancement Implementation).
Then we specified the name, description of the specific customer enhancement spot and selected the BAdl ‘MM_PUR_S4_PR_FLDCNTRL_SIMPLE’ to be used to cover this requirement. Our team then created a new transport request and saved the changes in it.
Additionally, our team created an ABAP Class where we implemented the new logic for the customer requirement. While creating the class, we selected the interface which will import all the parameters and fields we required for the implementation.
To review the available fields, the team checked the interface used in the class. In the PURCHASEREQUISITIONITEM structure, you can see the following fields:
Our team then selected the CREATEDBYUSER field of the structure PURCHASEREQUISITIONITEM to add the user condition and hide the PURCHASEREQUISITIONPRICE.
Our team then simply assigned the value to the field FIELDSTATUS as per the value to be displayed:
‘-‘ Field is hidden
‘*’ Field is only Displayed, No entry possible
‘+’ Field is Mandatory, Entry must be made
‘.’ Field is Optional, Entry may be made
Finally, we saved and activated the code changes. With this simple procedure, our team was able to disposition and address this very specific customer requirement.
c) Production Planning: Mass Availability Check for Production Orders using Developer Extensibility. Another customer wanted to have the ability to combine a couple of functions included in SAP S/4HANA Cloud, public edition, to create a customer tailored mass availability check app for production orders according to their very specific requirements. The customer’s Production Planner works with a list of production orders daily. He/she runs availability checks and releases a simulation for the whole list to receive a combined list of missing parts. The orders that are due for that day are then released. This process is run daily for hundreds of orders. There are two key areas where the Production Planner was looking to differentiate from the standard for managing production orders: ability to process in mass (which SAP provides as standard functionality) but also to include a pull of an aggregated missing parts list for several orders at once that also considers other factors like capacity check and release status.
To cover this business requirement the team used Developer Extensibility to create a tailor-made custom application for mass availability check of production orders including the main functional points combined, which are offered as standard functionality:
- Availability check of materials for production orders
- Capacity check
- Prioritization of production orders
- Release those production orders where checks were performed successfully
See the screenshot above for the customer’s custom application. As you can see in the screenshot some production orders have some checks performed (Failed / Success). For other production orders the checks have not even started yet. Also, the following actions are available in the custom application: Check Capacity, Set Priority, Release Production Order and Check Availability. Now, for the highlighted production order above the action ‘Release Order’ is not available as the ‘Capacity Check Status’ failed previously.
In summary, with this custom application, the Production Planner can get a sound list of orders and priorities based on his/her specific needs. Besides the functionality described above, the custom application also contains general information details about production orders with statuses of availability and capacity checks.
In the screenshot below you can see additional details why the availability check has failed for other finished good components. As you can see, this is due to a shortage of some the parts. The same information can be seen in the capacity check logs that were included in the custom app.
Our team used Developer Extensibility to build this specific custom app. When building the app, the team also focused on the user interface, so that the app looks and feels the same as any other app developed by SAP.
d) Quality Management example: customer produces material x. After the order is completed, the stock is posted to inventory. Based on quality inspection results the stock of material x may be transferred to material y. The transfer posting is done based on the results of the quality inspection. Customer needs this transfer posting to be done automatically, ideally by having a job scheduled to always keep the right level of stock based on quality conditions.
To solve this business requirement, our team once again made use of Developer Extensibility. The team decided to follow these high-level steps (not all details included to simplify the reading):
1. Create a custom table to store the quality inspection data
2. Create custom inspection lot CDS View with reference to custom table
3. Add Behavior Definition (for Create/Update/Delete functionality) to the CDS view
4. Create a custom class to read quality inspection lot CDS view for Inspection details and update entries in Custom Inspection lot CDS view.
5.Create an application job template, application job catalog entry and an implementing class. After following these steps you will be able to associate custom business logic with the job template. Later the application job will be scheduled using the template.
6. Schedule a job using Fiori App “Application Job” to update Inspection lot data into Custom CDS View.
7. Create an Application Job Template for the transfer posting and to schedule another job to complete the Transfer posting and update the status in the Custom Table.
There are many other ways you can apply Developer Extensibility. I invite you to try some of the samples scenarios included in the SAP Extensibility Explorer.
I hope you found the examples informative and engaging. If you’re interested in learning more about Key User extensibility and Side-by-side extensibility examples, I encourage you to continue reading the other two parts of the series.
More Information on SAP S/4HANA Cloud, Public Edition:
- SAP S/4HANA Cloud, public edition, release info here
- Latest SAP S/4HANA Cloud, public edition, release blog posts here and previous release highlights here
- Product videos on our SAP S/4HANA Cloud, public edition and SAP S/4HANA YouTube playlist
- SAP S/4HANA PSCC Digital Enablement Wheel here
- Early Release Webinar Series here
- Inside SAP S/4HANA Podcast here
- openSAP Microlearnings for SAP S/4HANA here
- Best practices for SAP S/4HANA Cloud, public edition, here
- SAP S/4HANA Cloud, public edition, Community: here
- Feature Scope Description here
- What’s New here
- Help Portal Product Page here
- SAP S/4HANA Cloud ABAP Environment Community here