Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
SAP S/4HANA is a revolutionary approach to dealing with data and its interactions. Businesses opt for S/4HANA because of how easy it is to integrate non-SAP systems into the existing setup. However, this would be impossible without SAP's transactional infrastructure. The transactional infrastructure makes it much easier to decouple different systems from each other. Business logic is crucial in an ABAP environment like SAP S/4HANA. Business logic in SAP S/4HANA is a core part of the application server and uses ABAP for its implementation. Ideally, the aim should be to shift data-intensive logic onto the database, to free up processing power for the application server.
SAP S/4HANA is used optimally for reading operations. Transformations are mapped using SQL after data is read. Additionally, authorization checks also run through this situation, ensuring that data isn't loaded just to be removed. If we examine this approach, we can see a clear case for using it in transactional logic.
CDS and ABAP
The platform is built on ABAP but also uses CDS to model transactional applications. As such, all the requirements previously defined for transactional applications must be met, meaning there needs to be a streamlining process. Enter ABAP RESTful application programming. This model changes how we think about building a program. While there is still a distinct separation between the UI, business logic, and database layer, the approach for developing a program has changed from traditional ABAP programming. With easy interaction with both backend and frontend, SAP Fiori has been the go-to for many application developers. Now it can also include a RESTful application programming model under its integrations, allowing for more powerful SAP Fiori apps to be developed.
ABAP RESTful Application Programming Model (RAP)
As mentioned before, the separation of layers (UI, business logic, and database) form the same thinking that underlies ABAP programming. In the case of SAP Fiori, UI and UX separation comes from leveraging OData as the protocol it intends to use. A developer can further separate the layers by combining Fiori with the ABAP RESTful application programming model. On the one side, the standard general base model, application (business) logic, and all that depend on it, and the other, service-specific processing and application logic.
Leaving the infrastructure to manage the protocol makes life easier for the developer while making these applications portable and forwards-compatible. The application implementation doesn't depend on a particular protocol but can be implemented in any iteration of that protocol. If the business chooses to switch to a different protocol or install a new protocol version, it can do so without any hassle.
Flexible Installation Options
Initially, when installing ABAP for SAP Fiori, businesses had to have a fresh install (greenfield) for proper integration. ABAP RESTful application programming model can make use of their fresh installs or previously existing installation (brownfield). This upgrade ensures that businesses that may have wanted to use ABAP for their SAP Fiori installations can now do so without having to roll out an entirely new installation for that purpose. The end-user doesn't have to know if the front end uses ABAP or the ABAP RESTful application programming model. Since these are seamlessly integrated with each other, the user would be none the wiser as to which system they're using.
What Does This Mean for Users?
The ABAP platform, though not as complex as investing in a gold-backed IRA, already supports consuming the application via OData and REST. Since we've decoupled the protocol handling to the infrastructure, we don't need to be concerned about it going forward. The protocol will handle the forwarding of all read and write requests to the database layer or the provider implementation (depending on request type). Non-transactional requests go to the SAP S/4HANA database, where it's then delegated via ABAP SQL. The system leverages the CDS data model to translate these requests. The application server handles the transactional runtime and transactional buffer, and all requests that deal with transactions end up here. When we combine all of these elements, we get a streamlined system that separates business and application logic while staying true to the separation of layers as defined by ABAP.
So, how does the system deal with OData GET requests? There's no native translation for this methodology; instead, the system must depend on an intermediary. The Service Adaptation Definition Language (SADL) that exists on the ABAP platform translates these OData requests into ABAP SQL, which the system can then consume. In this way, OData GET requests can be handled quickly and efficiently, freeing up the system's transactional buffer for other requests. While the RESTful application programming model isn't the easiest thing to grasp from an initial look, it's not that scary. Since it keeps the core of ABAP programming and the separation of layers constant, all it requires a developer to do is use the system more often. Eventually, the process becomes much easier from a development perspective.
