Gert Mertens , Dries Van Vaerenbergh and myself were involved in a BTP project that would become the foundation of a full blown business tool which had to be scalable and maintainable, that we also can easily support afterwards. As a BTP project it was a no brainer for us to this with CAP for the backend and UI5 for the frontend. The data model in CAP exists out many tables with dependencies between all tables. In CAP we also have to connect to different SAP solutions e.g. S/4 HANA, ARIBA, IAS, … to combine the data of the app with the data coming from other SAP solutions. With all the dependencies between the entities and keeping multitenancy in mind, it was difficult to split the backend in multiple parts. On top of that, the CAP app would require a lot of coding in event handlers for fetching and merging data from other SAP systems. Therefore, we sat together before starting coding to think this through.
In the end we came up with an approach for CAP that avoids having a lot of code (+1000 lines of code) in one and the same file to make it easier maintaining the code in an understandable way, this concept is also known as separation by concerns. Allow us to explain our approach in detail using our BTP Service Overview app as an example: https://wlcf-development-btpserviceoverview-approuter.cfapps.eu20-001.hana.ondemand.com/recapcapadvancedprogrammingmodelbtpservices/index.html
The code is available on a public GitHub page: https://github.com/lemaiwo/ReCAPBTPServiceOverview
You can read more about this app here: https://blogs.sap.com/2023/08/02/btp-service-overview-matrix/
The goal of the CAP app is to collect the details of every BTP service from the BTP Discovery Center and expose it as one entity for the UI5 app. It comes with one service ,one entity and a connection to the SAP BTP Discovery Center API:
The logic behind this service is not just in one file. We separated it in different classes (handlers like we call it), one for every entity. Besides the handlers, we also create a class for every system we connect to. In those classes, we’ll handle all the remote requests. To achieve this we started by creating a folder structure in the CAP service layer with a folder for “services” and “handlers”:
- “services” folder is used for storing all the logic to external systems like S/4HANA, Ariba, IAS, … . For each REST/OData API of a system we will have a service class that contains all the required requests to that system. In our reCAP example we are using the API behind the BTP Discovery Center, so we make a “DiscoveryCenterService” class which we will use later on for all the HTTP calls to that API:
- “handlers” folder contains a subfolder for each CAP service, in this case “CatalogService” is the only one, with a handler class for each entity. In our example, we have a “ServicesHandler” class for the entity “Services”:
Once the structure is in place, we can simply call one line of code in the default “cat-service” file:
This line will use our “EntityFactory” that takes care of the magic. Gert will explain more in detail on how everything works while Dries will show you how to use it.