Summary
Here we are with the summary. You'll find an overview in the document Introduction.
We have seen how to create a Gateway service based on a BOPF BO using SADL - and how this service is used in an UI application. There are open issues. The integration of BOPF in SEGW could be smarter. There could be for example some help to import the BOPF data model and to map the entities and the associations. There is no support for BOPF actions. This is all manual work. And we have seen that you can use implicit joins in read scenarios but not in modifying ones. And what about error handling? No single line on this in the series. Facing these gaps you may ask the following question.
Why using this technology at all?
Advantages in Read Only Scenarios
Let's first talk about read only scenarios. There are not only the view building capabilities of SADL which allows creating easily the work lists and fact sheets the user needs. But you get a lot more.
The SADL engine is the same engine which is behind the scene of ALV and FPM on HANA. It is a proven, wide spread technical component caring for pushing down date centric operations to the database. Especially in SAPUI5/OData scenarios this is even more important than in SAPGUI or WebDynpro applications. Later profit from the data copied to the application server: the second request could be considerably faster than the first one. But OData services are stateless, the data you copy to the application server should be as suitable for the actual UI request as possible - the rest is waste and cost unnecessarily performance.
You get this out of the box in just defining the service as we have seen it in the blog: SADL provides the paging, the top 10 list, aggregates data, supports search, sorts the data, expands it - you do not have to implement a single one of these operations. Authority checks? No problem if they are modeled in BOPF or CDS SADL transforms them into an additional where clause in the SELECT statement.
I think these are already quite convincing reasons.
Advantages in Update Scenarios
In modifying scenarios you normally do not have to handle mass data but single instances in depth. This is another dimension of complexity. Pageing and so on is not so important but navigating to dependent nodes and executing the CUD operations consistently - meaning handling the composition constraints for example are the challenges. SADL solves it for you.
So even if the data model is more complex, the advantages are given, you do not have to implement the navigation and deep create method of the service for example.
But the most important reasons of all is that ABAP and the Business Suite are going this way. And here we are with a perfect transition to the outlook.
Outlook
Let's start the outlook with a reference to Oliver Jägle's blog TechEd 2014 - some thoughts on UI5 and its impact on business application development where he discusses the stateless/stateful programming model. It's really worth reading it. One of his point is that if you have 'real' applications beyond some kind of approval scenarios, the application is not stateless - actually no application is stateless. The question is who is keeping the state. BOPF is well known for managing transactional buffers and all kind of images an application developer could need. And this state is in the ABAP memory. Isn't that some kind of a conflict?
If you have stateless request, the state is either in the UI or on the database. The challenge with existing applications is, that they very often do not allow saving inconsistent data - the BOPF demo BO is with this respect very indulgent: it doesn't check anything. But normally you will face problems if you just want to dump the UI input into the persistency.
You will need some kind of staging area on the database for existing applications where you keep the state which you do not want to keep on the UI and cannot keep in the original persistency. In 7.50 we are working on a programming model in this respect. And BOPF plays a central part for the persistency handling. A good UI is responsive, meaning that there is early feedback for erroneous input, that sums are immediately updated and so on. In the BOPF terminology you would say, that we need validations and determinations on the staged data. This is where BOPF shows its strengths. BOPF will not only be used for new applications, but for existing one to handle the objects in the staging area - currently we call them drafts. (Of course in the case of drafts BOPF will not use the buffers but communicate directly with the database.)
And there are lots of questions resulting of this approach on all levels: persistent locking and releasing the locks consistently, the interaction of SAPUI5 UIs and vanilla ones: one can handle drafts, the other one not. Does a user want to (or should he) see all drafts of all persons or only his ones. How to solve conflicting changes and so on.
To work on these challenges is the main focus for the next release, beside the move of BOPF from Business Suite Foundation layer to SAP Basis, some tool improvements like the usage of CDS views for the definition of the data tree of BOPF and the better support for GW model definition based on BOPF.
With this approach we are already beyond the question stateful - stateless. These are categories of a protocol, not of an application. An application has normally a state. But the draft concept based on CDS-SADL-BOPF brings a new quality to the applications: the fact that you can always save your data independently if you run a stateful or stateless protocol.
The BOPF - Gateway Integration based on SADL in 7.40 is the first step on this bigger construction area - and you can use it already. Stay tuned´.
Need for some background, visit the spaces or .
