Architecting S/4HANA Extensibility: Full Stack Extensions with Clean Core Paradigm

[Avinash_Vaidya]

Introduction

In the ever evolving landscape of enterprise applications, designing and developing a scalable and secure business applications is a crucial skill for developers, consultants and architects. This blog showcases a full stack project that brings together SAP and open source technologies to deliver a robust solution.

I have tried to showcase the important components of the project and how they are translated to executing blocks once deployed on cloud. The blog also touches cloud (Business Technology Platform) services which are important in many customer use cases. 

The intent of this blog is to provide you the starting point and give you a leverage to explore possibilities on your own and ofcourse, with the help of your preferred co-pilot!

At the end of the blog, I have also provided my GitHub repo where you can find a complete project for your reference.

I will breakdown the article into 3 parts

1. Use Case
2. Solution architecture
3. Components of the architecture

Use Case

I have developed a full stack application adhering to the architecture and developed based on a use case. It is available on GitHub.

The README file takes you through each and every step starting from use case till full fledge enterprise solution.

The project is more than just a standalone application. It serves as a blueprint for SAP extensibility while adhering to the Clean Core strategy. By leveraging SAP BTP services, CAP, Fiori, and seamless S/4HANA integration, this approach ensures that businesses can extend their ERP capabilities without modifications to the core system.

This architecture is highly adaptable and can be referred to your specific use case.

Solution Architecture

Below diagram provides the architecture of the solution. It also shows the transition from design time to run time artifacts and how the components fit along with seamless integration with the BTP services.

Figure-1

Components of the architecture

In this section, let us go through all the components shown in the above diagram and understand the details around each one of it and how these components are translated to the code for the specific use case.

The complete solution is built on the robust SAP Business Technology Platform.

Development/Design Time

I have extracted a part of the architecture diagram below to focus on the design/development aspects:

Figure-2

Developer develops the application on Business Application Studio. When creating a full-stack CAP application, there are 6 important components which are explained below to showcase some critical files inside each of the directories.

1. app - This directory contains all the UI content. This means, when you create UI apps (standard or freestyle FIORI), all the UI content for each app goes inside this folder. This is the face of your application.
   1. Take a look at the content of one of the UI apps - sales. You will see webapp folder which contains the UI code adhering to the MVC pattern. For standard FIORI you won't see much UI code in webapp as the UI is rendered using FIORI AppComponent using the OData annotations. Take a look at the freestyle FIORI app - commissionconfig. Here you will see controllers, views and stylesheets.
   2. The second important component inside the UI app is the xs-app.json. This is important as this is used by the application router to define routes/destinations and provide authentication type.
2. db: This is the foundation of your application/project. Here you define the entity model and the relationships between the entities. Take a look at the schema.cds. This folder also holds the initial data to be loaded inside the data folder. 
3. srv: This is the heart of your application. This directory holds the services and event handler where you can add annotations, custom logic and secure your entities. This folder also holds external API service entities. 
4. xs-security.json: Securing your application is as important as developing it. XSUAA service in BTP is leveraged for this. It gives role based access to the resources of your application. Take a look at the file: xs-security.json. Here you will see role templates and scopes defined which are translated to your XSUAA instance at runtime.
5. package.json: This is one of the important file which packages your project by defining the dependencies, start up scripts and most important cds configurations for development and production environments. Browse through this file: package.json.
6. mta.yaml: This is the deployment descriptor and orchestrator. In this file you define the modules of your application, resources required by your application and dependencies. This file is used during the deployment of the project to cloud foundry environment. During deployment, as per the configuration provided in this file, service instances will be created and application will be deployed to the environment accordingly. Do not get overwhelmed by the structure of the file, when you start building the application, you will understand. Take a quick look at the file: mta.yaml. Refer the mta build tool help docs here - https://sap.github.io/cloud-mta-build-tool/

Deployment/Run Time:

Now, let us see how the above components translate after deployment. I have extracted a part of the architecture diagram below to focus on the runtime/deployment aspects:

Figure-3

When you deploy the project, using the multi target application descriptor file, the MTA deployer creates the resources defined in the resources section of the mta.yaml. Let's take an example of the HDI container and XSUAA service instance required by the application runtime i.e. srv. In the below fragment, you will see the module sales-commission-srv and dependencies in the requires section

If you go down in the resources section, you will see the dependencies for HDI container and XSUAA service.

• If you observe the XSUAA resource, you will see it takes the xs-security.json during deployment and creates the scopes at the deployment time.
• Once the HDI container is created, the entities described in schema.cds are created in the database container.

Now, let's come to the UI part and see how the artifacts are translated from design time to runtime during deployment

As you know, HTML5 repository provides a central place to store the static content of the HTML5 applications. Deep dive on HTML5 repository can be found here.

So, to add the UI content to the HTML5 repository on BTP, you have to add the service in your mta.yaml as shown in the below fragment

 Once you update the HTML5 repository, it will pull the UI content from your project.

Destination Service: The destination service is required to store the API destinations which can be used at runtime to connect to the backend APIs. In our project, we have a use case to connect to the backend API_BUSINESS_PARTNER. In package.json you will see the API_BUSINESS_PARTNER configuration.

You create the destination - BP_DESTINATION in the destination service which will be used by the application when connecting to the backend API.

The Application Router & SAP Build Work Zone: The last two critical pieces in the puzzle. These are the gateway to your application.

• Application Router: The application router is the single point of entry for your application. This is the secured gateway to your application resources. You can leverage SAP managed application router or even extend the application router by installing it manually. At runtime, the application router fetches the xs-app.json from the UI content and uses it for routing and authentication leveraging XSUAA service. 
• SAP Build Work Zone: This is the launch pad where you can launch your applications, group your applications and also hide/show applications based on roles. The managed application router is provided with SAP Build Work Zone subscription.

Conclusion

Drawing from my experience, I must emphasize that these insights can serve as a starting point, though their applicability may vary based on specific scenarios. Also there will be most probably customizations required as per your specific use case.

In summary, SAP BTP provides robust ecosystem that empowers enterprises with flexible integration, secure connectivity and efficient development. 

This project will surely give you a holistic view from design and development of cloud native application and eventually deployment on cloud in production scenarios.

It's never too late to start  —  GitHub Repo

Stay curious! Keep learning!

Feel free to “like“, “Share“, “Add a Comment” and to get more updates about my next blogs follow me!

References

1. https://cap.cloud.sap/docs/get-started/
2. https://developers.sap.com/
3. https://sapui5.hana.ondemand.com/#/topic/851bde42e4e1410c96abbe402fa9128c 
4. https://api.sap.com/api/API_BUSINESS_PARTNER
5. https://help.sap.com/docs/build-work-zone-standard-edition/sap-build-work-zone-standard-edition/what...
6. https://help.sap.com/docs/btp/sap-business-technology-platform/application-router