SAP S/4HANA Cloud Extensions with SAP Build Best P...

Terry_Penner · ‎04-03-2024

In this blog adapted from the podcast “SAP S/4HANA Cloud Extensions with SAP Build Best Practices: An Expert Roundtable”, SAP experts discuss SAP S/4HANA extensibility best practises and SAP Build.

Vanessa Micelli-Schmidt, Chief Product Expert, SAP Build
Felix Wente, Chief Development Architect, SAP S/4HANA
Mark Wright, Director, Marketing and Solutions, SAP Build Code
Host: Terry Penner, Marketing and Solutions, SAP BTP

Let's Talk Cloud ERP Podcast

Key products covered:

SAP Build Code at sap.com/build-code
SAP BTP for RISE at sap.com/btp-for-s4hana
RISE with SAP

Topics discussed:
Part 1: Introduction to S/4HANA Cloud Extensions Best Practises

What is Clean Core
Extensibility Options and Best Practises for S/4HANA Cloud Private Edition customers
Advantages and disadvantages of on-stack vs using BTP tools
Extensibility changes for S/4HANA over the past few years.
Best practices for UI-focused applications and mobile services with SAP S/4HANA

Part 2: SAP Build Code for SAP S/4HANA developers

What is AI bringing to the table for S/4HANA implementers and developers
Build Code scenarios for developers who are using Business Application Studio right now
Build Code roadmap plans to help developers work more easily with S/4HANA
How S/4HANA developers can improve governance
Pragmatic recommendations for the type of extensions developers should create

Part 1: Introduction to S/4HANA Cloud Extensions Best Practises

Terry: To start our discussion, please describe what "Clean Core" means to you and why is it important to S/4HANA Cloud Private Edition customers in particular.

Felix: I think it can be best explained if you look directly at each of the words. The term “core” in ERP systems primarily refers to extensibility, processes, data quality, integration, and operational capabilities. These features depend on the specific software stack implemented by the customer. The concept of "clean" refers to the quality of how this core is adapted by customers and partners, focusing on up-to-date extensions, transparency, an unmodified and consistent core, and efficient, cloud-compliant operations.

The main advantage is agility, which allows you to benefit from innovations in a quick, straightforward manner. This includes consuming updates and upgrades without being disrupted by large adaptation projects, which can be hard to plan especially if you have extensive modifications. Ultimately, you save effort in extensibility and testing, reducing the Total Cost of Ownership (TCO). Furthermore, when it comes to data quality, you can more easily turn your data into value, resulting in more reliable forecasts and precise predictions

Terry: What are some key customer challenges you’ve experienced around extensibility and clean core?

Vanessa: Sometimes, customers are unaware of the full capabilities of SAP's developer portfolio. Depending on the skill level of their developers, ranging from professional coders to low coders or key users, fusion development scenarios can be utilized to create robust applications or process extensions, maintaining a clean core. This brings numerous benefits as mentioned earlier by Felix.

However, when discussing our extension development portfolio, customers can find it challenging to determine the appropriate tool for a specific use case. Despite the increasing integration among our tools, the use case might dictate the choice of tool. Therefore, I always recommend conducting a thorough use case evaluation.

Before starting to implement something, it's crucial to ask key questions: Is it a typical low-code use case? Are key users available who can reduce some of the burden from your IT by using SAP Build tools? Or, do you want to quickly create template-based SAP Fiori applications and have someone who prefers working in a pro-code environment? Then use SAP Build Code. Determining the types of personas who will be available to work on the solution should be an integral part of the decision-making process on which tool to use while maintaining a clean core.

Mark: Vanessa mentioned the importance of tooling. I'm from the app development side, so I hear a lot about extending beyond S/4HANA. Business acceleration is driven by making data available to end users. SAP is a leader in providing business-relevant data, but we can't rely solely on it. We see many customers wanting to run applications across various business networks. This presents a challenge for developers who need to interact with both SAP and third-party systems.

So, we're creating a landscape for side-by-side extensibility that encompasses both SAP and non-SAP systems. While we are leaders in SAP applications, it's crucial to also focus on integrating non-SAP systems. This is where tools like build apps, build code, and enterprise automation, which we provide in BTP, come in handy for our customers.

Terry: Can you share with us some examples of best practices for extending data tables or standard functionality.

Felix: If you're looking to extend S/4HANA on stack, which refers to directly integrating within the system where the software operates, we offer two tool infrastructures tailored for key users and developers.

For key users, the primary focus is on customizing user interfaces, which includes adding custom fields, implementing basic custom logic like checks or calculations, creating mini applications, designing custom views, and configuring analytical queries. This customization is managed within a wizard-like environment, launched directly from the S/4HANA applications. As a key user, you can navigate these features without needing a comprehensive understanding of the technical aspects of the data model.

With developer extensibility you can build complex extensions beyond what a key user can accomplish. You can also expose local software artifacts as remote APIs if you want to build on BTP. However, it's crucial to adhere to SAP's public APIs, both local and remote, that are explicitly labeled as public. By doing so, you maintain compliance with the clean core approach, and your software artifacts remain stable, ensuring that your code won't require adaptation after an upgrade in the private cloud. This means you can continue using your existing extensions.

In the private cloud, you can still use your existing extensions, we call this “classic extensibility”. This concept mainly applies to brown-field code that already operates within system landscapes. Despite this, it's possible to enhance compliance with the clean core, and we recommend using a set of stable legacy APIs, primarily BAPIs. These can be wrapped in your custom code and adapted in the public cloud, similar to future APIs.

We refer to this as the "three tier approach." If you're interested in learning more, we'll provide links to guidance documents, papers, and blogs.

Terry: What are your most important best practices for working with SAP Build on SAP S/4HANA?

Mark: Felix discussed the on-stack and key user capabilities essential for maintaining a clean core. When I address best practices, it's usually about the use of side-by-side extensions to continue preserving your clean core by implementing solutions on a platform. We refer to our platform as the Business Technology Platform (BTP), a truly innovative differentiator within SAP.

We aim to build cloud-native applications and maximize productivity on this platform. We provide a variety of frameworks, languages, libraries, and tools. These are based on two different types of modeling capabilities: the Cloud Application Programming (CAP) model and the Restful Application Programming (RAP) model.

Our developers often use CAP when developing and extending data tables if they're Java or Node.js developers. SAP developers who prefer ABAP typically use RAP. Both can be used effectively to model domains, create service definitions, and extend standard functionality. These tools are solutions provided on BTP, which make it easier for developers to create CAP models using a graphic data modeler. We also offer data backend visual cloud functions and build apps. All these processes are driven through AI and integration, forming our best practices. This allows us to leverage different programming models efficiently.

Terry: What would you say are the advantages and disadvantages of on-stack vs using BTP tools?

Felix: On-stack extensibility offers the advantage of a close connection between SAP applications and customer extensions, enabling extension of the business logic within a transactional context. This provides deep integration into our processes, allows for the enhancement of SAP data schemes, and offers benefits such as Data Neighborhood in analytical scenarios.

However, the same tight coupling is also a disadvantage. Even though On-Stack Extensions comply with the clean core, they don't scale beyond the user group of the ERP system in operation. For example, if you want to engage with third-party customers like contractors, you might not want to grant them access to your system, as the coupling could be too tight.

Furthermore, on-stack extensions are specifically for enhanced stacks and may not be the best option for larger, self-contained applications or hub scenarios. Finally, this approach might not align with your preferred software stack or programming language.

Vanessa: As Felix pointed out, you might select side-by-side extensibility on BTP when you want to avoid tight coupling. This is when you prefer to separate your extensions from S/4HANA and BTP and loosely link them using methods like remote API calls or events.

You'd also choose this approach when your extension isn't available in the on-stack extensibility, as Felix stated, or when it's a hub scenario. In other words, when you wish to integrate with multiple S/4HANA systems, other SAP solutions, or cloud services. The SAP Build option also offers the potential to automate S/4HANA processes across different systems, providing another situation where side-by-side extensibility might be needed.

When discussing Build, it's worth noting the interoperability between low and pro-code tools. We see the use of tools in so called fusion teams in a fusion development setting. This allows more people with varied skillsets within your organization to contribute to the extensibility story. This way, you can leverage innovations from a wider range of enterprise employees and involve more experts in your enterprise's innovation process.

Fig.1 SAP S/4HANA Extensions

Terry: What has changed with extensibility for S/4HANA over the past few years?

Vanessa: I don't see a shift in the scenarios, and perhaps Mark and Felix could add their input. I do, however, observe a change in the workforce and the tools they want and can utilize. The industry-wide challenge we're seeing, which likely resonates with our listeners, is a talent gap coupled with growing demands on IT departments. Unfortunately, these departments are not growing at the same rate. The common solution sought is simplifying development processes and boosting developer productivity.

Our approach to this issue is reflected in our product design. We previously mentioned AI, which is one avenue for enhancement. For example, our tools can be augmented with AI, such as in the case of Build Code where data models can be created using natural language. AI also soon allows processes to be described in natural language for auto-creation or support in creating in SAP Build.

Another strategy is to expand the range of developers, allowing key users to share in the development burden. This integration of multidisciplinary teams into the development process can lead to powerful fusion development scenarios. Complex solutions can be created collectively, with IT professionals providing oversight or backend creation for specific extensions, following predefined guidelines.

Felix: I want to emphasize that our goals of extensibility have remained consistent. From the outset, our primary aim has been to comply with a clean core, with a focus on extensibility. To this end, we've developed APIs and other software artifacts that we've maintained stably.

However, while our core principles have remained unchanged, our tools have continuously improved. With each release, you can expect to find new features, increased power, and more public APIs. We're also providing more stable points for extending business logic.

One new offering is our developer extensibility of the ABAP Cloud approach. This new feature enables a more complex form of extensibility.

Mark: Building on what Felix and Vanessa mentioned, clean core is not a new concept. What we have done is simplify the process of achieving clean core. While we have been discussing it for over a year, we haven't always made the process easy.

In the past, not all APIs were available, and integrating with side-by-side extensibility solutions was challenging. Now, we're making it easier for SAP developers to stay within SAP. You don't need third-party tools to achieve a clean core.

We're offering solutions like BTP build apps, build code, and an integration suite to simplify the development of clean core with side-by-side extensions and even on stack. This makes it easier than ever to achieve clean core, and you can do it entirely with SAP.

Terry: What best practices do you recommend for UI-focused applications and mobile services with SAP S/4HANA?

Vanessa: My recommendation will vary based on the type of workforce you have. Let's assume you have business experts who not only have specific requirements but are also trained as citizen developers or key users. They could then create a pixel-perfect user interface (UI) in SAP Build Apps, be it a web app or a mobile UI, depending on their needs. Within this low-code environment, they could easily connect to a backend system provided by a developer, for example, in Build Code. I’ll hand over to Mark to share his recommendations for a workforce that prefers to operate solely in a professional development environment.

Mark: Vanessa and I, along with our colleagues, discuss fusion development often. The focus is on creating applications that are, as Vanessa describes, picture perfect. We connect these apps to S/4, but the emphasis lies on adhering to best practices enabled by Build Code.

Internally, we refer to these application frameworks as the Golden Path. We strongly encourage our customers to follow these best practices to develop future-proof applications. Build Code offers design and runtime capabilities, allowing the creation of UI applications.

These applications can be developed with AI using Joule CoPilot and can include data models. They can integrate with SAP and third-party systems through the service center. Best practices for UI development involve UI5, Fiori elements and mobile services.

Fusion development is useful for backend consumption, while the frontend is built with Build apps. We sometimes integrate with enterprise automation flows to allow seamless creation of UI applications. This extends your S/4 environment not just to mobile, but also to web applications.

Part 2: SAP Build Code for SAP S/4HANA developers

Terry: AI is a hot topic right now, what is artificial intelligence bringing to the table for S/4HANA implementers and developers?

Felix: We have ongoing projects aimed at our user groups, such as developers, who we believe will benefit from AI-generated code. This could be particularly useful when programming against S/4HANA, or when building applications, as AI can efficiently create a running skeleton of code.

For key users, we're developing AI assistance in planning and development with the goal of enhancing extensibility. While key users can currently extend an SAP application directly from its user interface or UI, the application's data can also be used in a broader business process. This might involve follow-up activities like using extensions, creating print forms and email templates, and developing analytical reports.

If a key user doesn't easily anticipate all these possibilities, an AI assistant can help define their goals more precisely and streamline the process of creating key user extensions.

Mark: We're truly excited about Build Code. This solution incorporates generative AI through SAP Joule CoPilot. By providing natural language prompts to Joule, you gain the ability to create CAP-based applications. Adhering to best practices for extending your S/4 backend, the Build Code solution creates these applications, complete with data models, OData services, sample data, application logic, unit tests, and even UI extension through generative AI.

This essentially establishes a solid foundation for application extension, leading to increased developer productivity and faster time-to-market for applications. My expertise lies in using generative AI within Build Code.

Beyond Build Code, SAP offers a wealth of AI capabilities with our AI core or AI foundation and S4. Developers looking to extend S/4 can leverage these AI capabilities.

Terry: Help me understand what Build Code means for developers who are using Business Application Studio right now to create applications.

Mark: Build Code is just an evolution. Business Application Studio, our web-based IDE for BTP development, offers guided templates and a service center for integration with your S/4 backend and other environments. It's designed to help developers follow SAP's best practices. We've now integrated Business Application Studio (BAS) into Build Code, SAP's development environment. Here, developers can experience embedded AI with Joule, and we'll keep innovating within Build Code.

Developers aren't losing anything by transitioning to Build Code. It's easy to use just the development environment without committing to all of Build Code's capabilities. By switching, developers can benefit more from Build Code's features like DevOps, lifecycle management, and design capabilities, all in a single solution.

Remember, Business Application Studio remains available for current users, but we'll be focusing on further innovations within Build Code moving forward.

Terry: What is planned in the Build Code roadmap that will help me work more easily with S/4HANA

Mark: Build Code is tailored for our professional code developers, offering a turnkey development environment. We're excited about our contributions to both design time and runtime aspects. We plan to enhance and improve the generative AI capabilities, an area many customers are keen to see progress in. We aim to provide this through various capabilities for your OP developers and also by fostering more fusion development capabilities.

Fusion development, a topic Vanessa and I discuss often, is something we aim to expand so that any developer can utilize our build solutions effectively. We're excited about the support we can provide developers in extending the S4 applications. In addition, we want to emphasize that we're working towards seamless interoperability. Our goal is to enable SAP developers to easily develop extensions while maintaining the core integrity of S/4 and build code.

Terry: What are some ways S/4HANA developers can improve governance?

Vanessa: When discussing SAP Build and local development, as well as empowering key users and enterprises, I receive two customer reactions. The first is excitement, as they believe they can now expedite their extension projects, which is indeed possible. However, I also encounter concern revolving around governance, as one customer once asked, "What if everyone in my enterprise starts building applications without control?" This is precisely what we aim to avoid with providing governance tools for low-code development. Additionally, to address this, we offer guardrails, documentation, and have a comprehensive roadmap ahead of us. These guardrails allow organizations, for instance, to determine who qualifies as a citizen developer. You can choose to be either strict or lenient in this regard. For example, you can specify that only individuals with a particular certification are allowed to start building assets. We recommend certifying your key users or citizen developers in order to make them aware of their obligations when they begin building. This is one way to determine who is authorized to build. We also offer ways to define environments, such as allowing key users to create assets with specific data they can access and use in their applications, and do that in a protected (non-productive) environment. We provide a comprehensive set of easy-to-use tools that help effective monitoring and governance. This ensures that people do not go against the rules when creating these extensions.

Terry: Can you give us some pragmatic recommendations for the type of extensions developers should create

Felix: The most important thing to understand is that it's not a matter of either/or. In your system landscape, you will likely have a mix of clean and not-so-clean extensions. For example, in an existing private cloud installation, you may have a lot of existing code that doesn't align with clean core principles. In this case, it's important to be pragmatic and recognize that achieving a clean installation won't happen overnight. It's more of a journey.

During this journey, as you modernize your custom code, it's important to consider the purpose of your extensions and who they are intended for. Ultimately, the best approach may involve a combination of on-stack extensibility and side-by-side extensions for different tools. This will allow you to achieve the flexibility needed to meet your business needs.

[ Note: This blog was adapted from the podcast transcript by an SAP system using Azure OpenAI–gpt-4 ]