The architecture I’m sharing here isn’t the only way or necessarily the best approach for every scenario. Rather, it’s the solution I’ve found effective and applied successfully across multiple projects.
Why did I choose a Side-by-Side Architecture?
I opted for this architecture mainly because it allows me to extend the standard functionalities of SAP S/4HANA Cloud without directly impacting the ERP core, thus making it easier to maintain a clean core and simplifying the management, maintenance, and evolution of developed applications.
How do I organize SAP BTP?
I usually set up separate subaccounts for each project environment:
- Development: Where I perform initial testing and functionality development.
- Quality (Test): Used for integrated testing before final deployment.
- Production: A stable environment accessed by end users.
This approach has helped me keep things organized, avoid confusion, and significantly simplify the management of BTP services and instances.
Frontend using SAPUI5 and Fiori Elements
My frontend applications are typically developed using SAPUI5 or Fiori Elements, which accelerates development. I deploy these apps in the HTML5 Application Repository and publish them using SAP Build Work Zone, simplifying the management of connections to backend services.
Backend: Choosing between CAP and Java Spring Boot based on needs
For backend development, I divide responsibilities across two main application types, depending on technical requirements and project complexity:
- CAP (Cloud Application Programming) Applications:
I use CAP primarily for simpler OData services or functionalities with low concurrency. CAP has been practical for me due to its ease of development and seamless integration with standard SAP services.
- Java Applications with Spring Boot:
For scenarios that require complex processing, high concurrency, transactional logic, advanced reporting, or parallel processes, I prefer Java with Spring Boot. This stack consistently delivers excellent performance for demanding scenarios.
Combining these technologies within the same architecture allows me to select the most suitable tool for each specific need, rather than forcing one technology into unsuitable scenarios.
Shared SAP HANA Database
To simplify data management, I typically use a single SAP HANA database shared by both backend application types. A particular choice I make, perhaps less common, is not to use the default HDI infrastructure provided by CAP.
Instead, I manually create a dedicated HANA schema directly accessed by both CAP and Java applications.
This approach has advantages such as simpler database management and easier integration, but it also has some drawbacks, like losing certain automated management features provided by HDI. Still, based on my experience, the benefits have outweighed these disadvantages.
Direct Integration with SAP S/4HANA Cloud
Another critical aspect of my architecture is integration with S/4HANA Cloud. Here, I’ve applied two methods based on backend technology:
- For Java/Spring Boot, I typically use the SAP S/4HANA Cloud SDK for Java, as it simplifies the connection and management of S/4HANA services significantly.
- For CAP, I often import EDMX models exposed by S/4HANA Cloud directly, facilitating quick and straightforward integration with standard SAP services.
Both approaches have proven practical and effective in various contexts.
Centralized Authentication with Single Sign-On (SSO)
In most implementations, end users log in using the same authentication they use for S/4HANA Cloud. I achieve this by setting up trust relationships between SAP BTP and the Identity Provider (IDP) used by the ERP. Consequently, once logged into BTP, users can seamlessly interact with S/4HANA Cloud through transparent Single Sign-On (SSO).
This significantly improves the user experience and simplifies access and permission management.
Everything I’ve shared here comes directly from my practical experience implementing real projects. While this isn’t the only method, it’s an architecture I’ve found functional, flexible, and effective. I’m always open to learning from other experiences and alternatives to continuously evolve my approach according to future needs.
