Co-Authors: @Sivakumar_Subramaniam , @ShivaniShankar 

A common feedback when talking about clean core extensibility is the absence of demo-ready content to visualize these guidelines that have evolved over time. This blog post attempts to take an extensibility scenario as example and showcase the equivalent scenario in a clean-core compliant world. Nevertheless, we cannot claim to be covering every possible flow in one post. The intent is to showcase one example covering a wide range. In the process, we walk through some of the decisions taken that go beyond technology and consider business aspects as well. A lot of technical details are omitted since this post is already quite long. Look forward to the discussions and feedback in the comments section to assess interest and demand for similar posts/more technical versions. 

Recommended Pre-read: 

While an effort is made to abstract technical complexity to a great extent, a reader still needs some basic understanding of the SAP ecosystem, how extensions work, why they exist and some background of clean core.

To maximize takeaways from this blog post, consider reading the clean core extensibility whitepaper before you start, particularly if “Clean Core” sounds unfamiliar. Due to the rich context, answers to why clean core etc available in the whitepaper already, we skip it here. Nevertheless, a lot of what this blog post covers would not make much sense without this background/context. 

Key Assumptions: 

1. We consider level-A of clean core extensibility since this is the highest standard. If one were to target level-B for example, the target architecture might look a little different with potential reuse of certain objects

2. For simplicity and to keep the focus on extensibility, we assume there is no fit-to-standard solution available for this scenario which may or may not be factually correct. In a real project, please consider fit-to-standard analysis and an analysis of your existing custom-developed artefacts before developing something new

Scenario Description : 
– Provide a capability to add custom gift cards when creating sales orders in SAP Cloud ERP Private (S/4HANA Cloud Private Edition)

– On applying the gift card, a discount is added to the sales order by an amount equal to the gift card amount

– On creation of a sales order, loyalty points need to get accrued against the membership of the business partner (from the sales order). For simplicity, assume only business partners of type “Customer”

– The loyalty program has tiers and based on the tier the customer is on, he/she/they accrue a percentage of the sales order value as points

– It shall be possible for a customer to request an upgrade to their loyalty program tier. In this case, approval from an admin is required before the change is active 

Scenario Refinement:  

Understanding/context: When working with sales orders, this company has 2 parallel reward programs. One, a gift card that can be applied on creation of the sales order for an immediate discount. Another, a loyalty program where one accrues points with each sales order. Potentially, for redemption (not in scope here) through different means at a later point in time

Tasks:

– Since gift cards need to be applied, there is also an unsaid need to be able to create and maintain these gift cards (by an admin). This means an app to create/maintain gift cards with appropriate fields

– To be able to apply the gift card when creating a sales order, an option is needed directly in the sales order application (or transaction)

– The applied gift card should impact the value of the sales order before creation (not post-processing) 

– Similarly, loyalty program tiers would need to be maintained (possibly as business configuration)

– The loyalty points are calculated based on the created sales order and don't have a dependency or need to update/modify the consistency of the sales order itself. This could be handled as a separate activity from the creation of the sales order

Solution Architecture (Classic Extensibility – non-Clean Core level-A):In the classic extensibility scenario which is non-clean core level-A, we use the following technology choices to build this – 

1. Gift Card Maintenance – WebDynPro Application
2. Capability to add gift card to sales order in VA01 (Transaction code for sales order creation) – User Exit
3. Loyalty Management Application – Module Pool Program
4. Tier upgrade – Classic workflow

 Solution Architecture (with ABAP Cloud and SAP Build – Clean Core)

In the clean-core level-A compliant extensibility scenario, we use the following technology choices to build this – 

1. Gift Card Maintenance – Application developed using RAP (ABAP RESTful Application Programming Model) with on-stack developer extensibility. Yes! with real code written by a developer inside the S/4HANA system outside of key user tools and still the highest level of clean core! If this is against your understanding of clean core, read SAP's official whitepaper (section 3.2 at the time this blog post is written) linked in the pre-read section of this blog post!  
2. Capability to add gift card to sales order in the standard sales order Fiori app  – Key User Extensibility
3. Loyalty Management Application – Side-by-side extension using BTP ABAP Environment
4. Maintenance of tiers of the loyalty program – Business Configuration in the BTP ABAP Environment (not shown in the demo except as value help)
5. Tier upgrade – SAP Build Process Automation
6. Communication between S/4HANA and BTP – Event Mesh (or Advanced Event Mesh)

Alternate options – The Loyalty Points Application could also have been developed side-by-side using CAP (Cloud Application Programming Model) with additional handling for tier maintenance. 

Decision Criteria (Technical and Business): 

1. The use case around application of gift card has a very tight dependency on the sales order. The standard SAP sales order application needs to understand and bring up the gift cards for a value help, have the gift cards applied consistently across impacted business objects when the sales order is updated. All of this needs to happen as part of the sales order creation/update process in S/4HANA. This makes on-stack developer extensibility and key-user extensibility good candidates. 
2. The loyalty points application has 2 factors to consider – Side-by-side v/s on-stack and CAP v/s ABAP Cloud
   • Side-by-Side v/s On-Stack:
     • Decision: Side-by-Side
     • In private cloud/on-premise, SAP ships a new major version every 2 years. By moving out of the core (S/4HANA) anything that can be moved logically without adverse performance/over-engineering, etc, the customer can benefit from always being on the latest release and getting the latest updates. This de-risks innovation from upgrade project timelines and upgrade strategy. 
     • Enforcement of clean core – With the side-by-side approach, clean core is enforced with syntax checks etc since ABAP Cloud is the only option on BTP ABAP Environment as opposed to governance based approaches on-stack which may need an ABAP Cloud package and processes to ensure a developer doesn't slip back to the familiar classic extensibility when cloud ready alternatives are available.
   • CAP v/s ABAP Cloud
     • Decision: Both options are valid. Here, ABAP Cloud due to developer skill set and business configuration handling know-how. Since each option has strengths and benefits, refer the BTP Developer's guide for details. To generalize any of the two as always the better option without case-to-case analysis and comparison may be an unfair/sub-optimal decision. 

General question on BTP ABAP Environment cost –
“The cost of BTP ABAP Environment is higher” – Apart from the smaller runtime size now available, which reduces costs, the cost needs to be spread out across applications being developed. One instance of the BTP ABAP Environment can be reused for multiple applications so long as the runtime/memory requirements are within available limits. Compare this to additional costs for CF Runtime (for example) for each deployed app with CAP and the costing at solution level at scale tends to be similar. This is not to say CAP is a bad option, just that when the decision is influenced by cost, how this cost is calculated decides quite a bit! When this becomes equivalent, the models can be compared on best fit for the use case on technical/architectural grounds.

Demo of functional scenario in both approaches along with ATC findings across levels – B, C, D on the package where classic extensibility was used

The following demo showcases the scenario with classic extensibility as well as with Clean Core Level-A. It also touches upon ATC checks on the package containing the classic extension. To understand how ATC (ABAP Test Cockpit) helps categorize the findings, refer section 3.3.4(at the time of writing) of the clean core extensibility whitepaper (in the pre-read section)

Call to Action: Comment below what you would wish was better covered in the post and what key takeaways you had! Your inputs help us understand and validate where such blog posts can add more value