11.6 Extensibility in SAP S/4HANA Cloud Private Edition: Key User, Developer, and Side-by-Side

Extensibility in SAP S/4HANA Cloud Private Edition: Key User, Developer, and Side-by-Side

Section 10.4 explained why a clean core matters. This section covers the tools from the S4C03 unit Customizing Applications: what each extensibility option is for, how key user extensions are created and transported, and what happens to custom code in a system conversion.

The Extensibility Options

Extensibility covers changes that go beyond configuration: data model extensions, data exposure, changes to UIs, forms, and reports, and new UIs or applications. Extensions made with the built-in tools are separated from the core, so SAP can upgrade the system without breaking them. Whatever cannot be done in-app should be decoupled to SAP Business Technology Platform (SAP BTP).

In ABAP Development Tools, choosing the language version ABAP for Cloud Development switches on the strict ABAP Cloud syntax check and limits custom code to released APIs, such as the CDS view I_PRODUCT. Custom database tables have no default security, and Information Lifecycle Management and the Information Retrieval Framework cannot be used for them, so data access must be tested carefully.

The Three-Tier Model

• Tier 1: key user extensions and ABAP Cloud developments. They are upgrade-stable and the default for every new extension, in converted and in new systems.
• Tier 2: custom wrappers around SAP objects that are not released yet; replace them with Tier 1 once SAP releases an API.
• Tier 3: classic ABAP that does not follow the ABAP Cloud rules; it should be modernized after a conversion.

Resources: the SAP Extensibility Explorer for sample scenarios and patterns, and the SAP Business Accelerator Hub for APIs, events, CDS views, and integration content, with a dedicated SAP S/4HANA Cloud Private Edition tile. LoB configuration experts are not expected to develop with SAP Build or SAP Business Application Studio; requirements that key user tools cannot meet are escalated to the project managers, who bring in an ABAP developer or a BTP resource from the partner or the customer.

Key User Extensibility Apps

First check whether an app supports extensibility: in the SAP Fiori Apps Reference Library, open the app documentation and look for the App Extensibility section, which lists the business contexts, the UI elements for custom fields, and the BAdIs for custom logic.

A sales example: a new field on the sales order that also flows to the delivery and the invoice is created in Custom Fields with the sales business context and its business scenarios, and then placed on the screen with Adapt UI (section 10.4).

Forms and Email Templates

Output parameters such as channel, recipient, and form template come from the Output Parameter Determination app (section 9.7), and sent emails can be checked in Display Email Transmissions. Templates are changed by copying the standard ones: Maintain Email Templates for emails, Manage Logos and Manage Texts for the content of master forms, and Maintain Form Templates for forms. XDP files are edited in Adobe LiveCycle Designer; XSD files can be changed with any text editor when only texts change. There are three types of form templates: master forms (page layout, logo, sender address, and footer), application forms (the business content, placed in a master form layout), and standalone forms (content and layout in one). Only print forms are supported; interactive forms need the SAP Forms Service by Adobe on SAP BTP. Customized templates are created in the customizing tenant and transported.

Transporting Key User Extensions

Key user extensions start as local objects. The Adaptation Transport Organizer (ATO) must be set up. In Configure Software Packages, a software package is assigned to a transport request and task so that changes are recorded; in Register Extensions for Transport, the extension items are assigned to that package. An administrator then releases the transport requests in SE09 to move them to quality and production.

Custom Code in a System Conversion

• The Simplification Database lists the simplification items; each refers to an SAP Note that explains the impact and how related custom code can be adapted.
• Custom code scoping with the Custom Code Migration app, run in the ERP system or on SAP BTP, finds the code that is used and must be adapted and the unused code that can be deleted with deletion transports during the conversion. Its results can be uploaded to the SAP Readiness Check.
• During the conversion, ABAP Dictionary modifications are adjusted with SPDD; after SUM, repository modifications are adjusted with SPAU and SPAU_ENH.
• Then the ABAP Test Cockpit (ATC) with SAP S/4HANA checks lists the findings, each linked to SAP Notes. Quick fixes in ABAP Development Tools resolve frequent findings such as ORDER BY issues and data model changes, for example around KONV and BSEG. Apply them in portions, fix syntax errors first, and run ATC again, because ATC checks only syntactically correct objects.
• Finally, modernize Tier 3 code toward Tier 1 or Tier 2, and use the SQL performance tuning worklist together with the SQL Monitor to find and prioritize performance hot spots.