SAP S/4HANA Cloud Extensions and Clean Core with SAP BTP – A Best Practices Conversation
In this excerpt from the podcast “SAP S/4HANA Cloud Extensibility and Clean Core with SAP BTP”, Terry Penner, Ruben Mellema and Mat Beerkens discuss SAP S/4HANA Cloud extensibility options with SAP BTP and an introduction to clean core best practices.
Part 1: What is Clean Core and its benefits
- Simplifying SAP S/4HANA Cloud upgrades
- Reducing Testing Efforts
- A Modular Approach with Low-Code SAP BTP Tools
- Staying Current with the Latest SAP ERP Innovations
- Getting Started with the Clean Core Journey
- Clean Core Use Cases
Part 2: SAP S/4HANA Cloud Extensions and Integration Options
- Key User Extensibility
- Choosing the Right Development Tool
- SAP S/4HANA Cloud Integration with SAP BTP
- Key Links
About the speakers
Terry Penner is part of the SAP BTP Marketing and Solutions team, focused on BTP for SAP S/4HANA. He has more than 20 years experience in the SAP platform and analytics, including working directly on hundreds of customer implementations.
Ruben Mellema is with the SAP S/4HANA Cloud Solution Management team and is a recognized expert on extending SAP S/4HANA and SAP BTP, presenting at numerous conferences including most recently at SAP Sapphire 2023.
Mat Beerkens is a Technical Architect with the SAP S/4HANA Cloud team with more than 15 years of SAP ERP implementation and IT planning experience.
Part 1: What is Clean Core and its benefits?
Terry: To start with, let’s talk about a few terms that we’ve been hearing. What does clean core mean? To me, clean core, is a methodology. It’s a way of building so that extensions are kept separate from the SAP application.
Every time you apply a system update, when a patch is deployed to your S/4HANA system the specific extensibilities that you’ve done for your business aren’t touched. So you can upgrade with confidence, but still keep those special things that you need. Ruben, what are your thoughts on clean core and how have you seen it in action?
Ruben: Yes, in the past with legacy systems, whether it was SAP or any other vendor, a lot of times customers had certain requirements that were not part of the solution offering. What they did at that time was just modifying the core code from that vendor to modify it according to their needs. The customer basically changed the core delivered software according to their needs, and of course it worked at that time.
Simplifying SAP S/4HANA Cloud Upgrades
Ruben: But it also presented a lot of issues during upgrade cycles. Customers were potentially on legacy systems for years, while the feature that they had custom created was now part of the standard software and now in the new, let’s say S/4HANA cloud concepts, we work with these best practices.
So what we call scope items and these best practices we deliver out of the box, those also come with automated test scripts. We have a lot of process flows automatically covering that end-to-end scenario, and covers most or all of the scope required from a customer perspective.
Now there still may be a scope item that is not part of the standard offering, which either is differentiating them in the market, or something SAP may be planning but isn’t available yet. The core thing here to understand is that you’re not modifying the core system anymore, so you cannot touch the core objects delivered by SAP, you can only extend them.
Mat: So what we try to do is we give tools and options with SAP BTP to still make the process and the system behave in the way that any customer wants it to, with those fixed points where we take care of the full lifecycle. So if you go into an upgrade, then SAP takes care of the core features. It might not always be 100%, but we try our very best to make it backwards compatible and to give the customer the maximum freedom of still having the benefits of doing extensions, while keeping the core stable and steady and running as it should run even after an upgrade.
Reducing Testing Efforts
Terry: Thinking about clean core and extensibility, one of the benefits for a customer that jumps immediately to mind is that it reduces testing effort. If I create an extension that I know is going to be separate from the core modules that SAP is upgrading, I can focus my testing efforts and save money on my total cost of ownership. Matt, could you talk about what are some other benefits for clean core?
Mat: Let me first start by confirming what you’re saying. What we’re doing with the clean core principle is decoupling development. So that means that we’re completely separating the way customer and SAP code interact with APIs. You said that with clean core you reduce risk and less testing is needed. Of course, the end-to-end tests still need to be performed. But because we split up the separate development between core and extension, in the SAP development team we can really focus on each cycle.
We want the custom development to work perfectly each time, so from an SAP perspective the only thing we then need to test after an upgrade is that API. So that’s really where we still bring in that stability, and focus on API backwards compatibility. But even in the rare case where an API is going to be changed or deprecated, then of course we indicate that to give the customer enough time to be aware of the situation and make sure that the correct solution is going to be put in place.
A Modular Approach with Low-Code SAP BTP Tools
Terry: Right. And Ruben, one of the key benefits of clean core and how we’re doing extensibility now is that it can be very modular. Can you give an example of how data or custom fields would benefit from using clean core with S/4HANA and BTP.
Ruben: Keeping the core clean and making sure that you stay up to date is key. This is possible through the decoupling of extensions and making changes like adding or hiding a field. This makes you extremely modular and agile. You can run at your own pace, so if you decide to add a field today, you can bring it live today. You don’t need to wait on us or until release cycles. You can simply create or change the extensibility option and deploy it right away.
And the great thing is that it all works with local, low code tooling. There’s not even coding involved to add a particular field. If you have a custom field that you want to create, you can do so with low code, capabilities. That means that a key user or business expert can make those changes in your system automatically, and this all works smoothly together with the clean core approach.
Staying Current with the Latest SAP ERP Innovations
Ruben: One of the key things that I wanted to highlight on keeping the core clean – making sure that you stay up-to-date with the latest innovations. In typical systems, it was often difficult to keep up-to-date with the latest innovations due to modifications and changing core codes. Now, if all the latest innovations get pushed to you automatically, and because you have that extensibility by using the clean core methodology, you can immediately leverage or use these innovations the moment they become available in your system.
For instance, the moment we upgrade the systems, that innovation becomes live for a customer. To give you a practical example, AI is a huge topic now in the world. I think there are endless possibilities with it and SAP actually has AI capabilities embedded in the best practice solutions. SAP also provides things like the digital assistant that you might have heard about at the SAP Sapphire conference. So when we release a new version of S/4HANA, then all of these innovations will be available in the system. This reduces the time to create and adopt innovations and it makes you highly competitive in the market.
Getting Started with the Clean Core Journey
Terry: Just before we get into our different extensibility options, which does relate to clean core, let’s say an existing ECC customer really wants to go on the clean core journey. Perhaps they’re an existing customer who’s created a bunch of app extensions. What should they do? What would be their first step?
Mat: An existing ECC customer can of course start with the RISE transformation. One of the components we have is a Custom Code Migration app (see also the Custom Code Migration guide). This is a very useful tool that you can enable on your system. It can run in the cloud or you can install it locally. It will pick up all of the coding that you have introduced into your system, help you segment it, and then give you advice on what to do with it.
There are a few options. One could be that the code has not been used or touched for a long time, so it’s better to retire it. Another option could be that the code is not compliant in the newer system, but we can help you apply changes to those developments. And then there are specific things that you need to cut out of the system because they don’t really touch the rest of the platform. It’s better to move them to the Business Technology Platform. This is really when we start talking about the clean core, and the Custom Code Migration app is the perfect tool to guide the customer in that journey.
Ruben: What we typically see happening is that if a change can better be taken out of the core, you typically take that to the SAP Business Technology Platform, or BTP. On BTP, you have a lot of different services. You can use low-code or what-you-see-is-what-you-get editors to create, for example, new applications using drag and drop.
Configuring that is very easy and then connecting that to S/4HANA Cloud to get data out of the system or push data back into the cloud. But you also have the option to indeed leverage process automation to automate certain manual tasks. As an example, you can automate reading through an Excel file and uploading that into S/4HANA Cloud.
You also have on BTP an alternative option to use Pro-code (SAP Business Application Studio) to write code. If you are then using the SAP UI5 SDK to create proprietary applications you can deploy as a UI5 tile or create with SAP Build Workzone as an application within from the cloud. From an end user perspective, they would not even recognize whether it’s an extension of core S/4HANA cloud, or a separate application. It could be built either by you or a partner on SAP BTP, then deployed on S/4HANA cloud.
Clean Core Use Cases
Terry: Do you have a specific use case you’ve seen for user interface extensions?
Ruben: Yes. I was talking to one of the Big 5 professional services firms recently, and they had a specific process about project discounts. They wanted to give the full project a 5 or 10% discount and in the core S/4HANA cloud system what you typically then do is go into the projects. The work packages then contain the staff rates, including those rates you want to provide a discount on.
Now within S/4HANA Cloud you have a section for that which allows you to set those prices per hour per person, which solved part of the requirement on that project. But this firm, they wanted to apply a mass discount on the project, automatically decreasing or increasing the values with a certain percentage. You have two options: you can either build that within S/4 cloud itself using code, or the easier option to actually build this on the Business Technology Platform, leveraging these low code or no code capabilities, or the pro- code capabilities.
So what I did for this customer, who was investigating whether the fit of public cloud at the time, was to build a BTP application to read the project data out of S/4HANA Cloud using allow-listed APIs like the public APIs Mat explained. These are the APIs that SAP will not touch during an upgrade cycle, following clean core principles. So for this extensibility scenario, the application read all the project details from S/4HANA Cloud including WS structures, etc. The application then also immediately reading the data for people who were staffed on that project, including their roles and rates.
The BTP application displayed all of those values, and then on the top of that screen there was a small input field that actually said “What is the percentage discount that you want to apply”. Once the user decides they want, say a 20% discount, then the application would pick the rate of all those people and apply that 20% discount.
Terry: Matt, do you have an example as well?
Mat: Yes, we also have the SAP Discovery Center. This is where we have a lot of missions, some of which describe exactly what you’re asking about. We have predefined content that spans from the Business Technology Platform into the back-end system. This includes content for both S/4HANA Cloud, Public Edition and S/4HANA Cloud, Private Edition.
There are specific places for areas like process automation where you can download applications and processes and run them. It’s as simple as that. In the Discovery Center, there are many more missions and examples available to customers, which I think is a huge value.
Terry: Absolutely. You can also find more use cases that link to pre-built discovery center missions and prebuilt content at sap.com/btp-for-s4hana.
Part 2: SAP S/4HANA Cloud Extensions with SAP BTP
Terry: Let’s talk more about extensibility. We’ve touched on it during our discussion about the clean core, but I want to focus on key areas of S/4HANA extensibility and best practices. Ruben, would you like to start us off?
Ruben: Yes, the first thing to understand is that we differentiate between what we do within S/4HANA cloud from an extensibility perspective, and what is outside S/4HANA Cloud. For business user extensibility we have what we call “in-app extensibility”. This allows end users to make simple changes in a “what you see is what you get” editor.
End users can add a custom field or rename a field and save that as a particular app for themselves or for a group of users within their company. These tasks are easy to do and don’t require going to an IT department to make changes.
Key User Extensibility
Key user extensibility allows you to make simple changes yourself. As part of this, we also have the capability to create new core data services or CDS views, which are basically views on top of the data that resides in your SAP Cloud system. You can create your own CDS views with “what you see is what you get” editors. This is a super simple low-code, no-code capability within SAP Cloud itself. All these changes will continue to work even after the upgrade of S/4HANA.
For developer extensibility, you can write code but only on released objects. We release a lot of objects that you can extend using developer extensibility, but you don’t modify the core of SAP with that.
Terry: Looking at key user extensibility, some examples that I’ve heard of are things like adding, hiding, renaming fields, creating custom fields on here. Matt, could you talk a little bit more about maybe the low code versus pro code and when you would choose to use low code versus pro code and when each option is best?
Choosing the Right Development Tool
Mat: If we look at it from a very high level, every line of code that we have to write turns out to be a lot more expensive than if we talk about local changes, or “what you see is what you get” changes. WYSIWYG changes are very simple, and you don’t have to train people much. With low code solutions, you don’t have to do so much debugging, so that is a huge difference from between what we call in-app extensibility and developer extensibility. But both are still available to work with S/4HANA cloud.
So in terms of giving advice on when to choose what development tool, I would always say if you have the option to do something simple with a user interface, then choose that before writing a lot of code. And the reason for it is that it’s much simpler easier to set up and maintain.
Terry: Yes. And whether you’re doing integrations or process automations, check to see what we have available out of the box. I know we have a customer reference example on the sap.com/btp-for-s4hana page where a customer was able to use 95% standardized processes (Albemarle). They had previously been using a lot of custom extensions, but were able to reduce their maintenance cost and total cost of ownership by using standard processes.
Mat: So we’re really make a split into two worlds: what is available in the SAP S/4HANA Cloud product, and what is possible together with the SAP Business Technology Platform. The application development, integration, process automation, artificial intelligence, is in the SAP Business Technology Platform and that is good at. So the combination S/4HANA with BTP is a golden combination which will take care of any change that you want to have in your end to end business process.
Terry: Yes. And the stats show that most of our S/4HANA customers are also using BTP.
SAP S/4HANA Cloud Integration with SAP BTP
Ruben: And from an integration perspective, Integration Suite with S/4HANA Cloud has a lot of integration capabilities between SAP S/4HANA Cloud SAP SuccessFactors, Concur and other SAP applications, and with third party solutions. We offer out-of-the-box integration capabilities between SAP HANA Cloud and platforms like Salesforce or Workday, as well as tips and tricks for deployment. The integration flow we build is displayed on api.sap.com. You can see the entire integration flow, value mappings, and a full implementation configuration guide. All you need to do is deploy it on the Integration suite on the Business Technology platform and connect Salesforce or Workday to it.
We also maintain best practice perspectives and allow you to create your own APIs or extend the out-of-the-box APIs. Even after an upgrade, your extensibility patterns continue to work. One of the advanced features in there allows you to create custom business objects, which you can think of as a new table or object within SAP S/4HANA Cloud. You can immediately create an API for that automatically with our out-of-the-box capabilities.
Mat: We aim to have as much coverage as possible with standard processes, but we can also accommodate any changes you want to make. We can start with basic extensibility and grow as needed, whether you’re a small company with minor changes or a larger company with advanced artificial intelligence requirements. We’ve got you covered from small to large.
Ruben: We offer a lot of out-of-the-box capabilities. If a customer finds that we don’t completely cover their needs, they can adopt that standard feature, configure the system to their needs, or go into more extensibility approaches. Always start with the in-product extensibility, then go to developer extensibility, and only as a last resort side-by-side extensibility. This will help you keep the core clean.
Terry: Thank you, Ruben and Mat, for your insights. More about extensibility and clean core topics can be found on sap.com and the BTP for S/4HANA page, as well as in the Discovery Center. We also have prebuilt content, eBooks, and community content from SAP and from partners that’ll help you in your clean core journey.
Listen to the full podcast at SAP S/4HANA Cloud Extensibility and Clean Core with SAP BTP