Skip to Content

When I was building my agenda for SAP TechEd Barcelona, I didn’t find (as last year) any session on BOPF. But Oliver Jaegle and Tobias Trapp pointed me to “DEV106 The ABAP Programming Model in SAP S/4HANA.” The title of the session and talking about it in the SCN BOPF space reliefes already one big news about BOPF: BOPF will become “the” framework for implementing business logic. Therefore I’m quite sure, that was the last TechEd without a session on BOPF 🙂

CDS and BOPF

CDS will also play a major role in the new programming model. There were several discussions going on about CDS, especially on annotations during TechEd and on Twitter. Oliver Jägle wrote already a very good blog post about CDS views and annotations.A note on SAPs annotation-notion I actually share his doubts. I do not want to go into details about CDS here and please write your comments on CDS views and annotations below Oliver’s post.

But there will be also a big change for the way you will model your BOPF objects with CDS views:

The programming model will look as follows:

Starting point will be the CDS view. There you will modle your business modle regarding data types, structures and associations. If you are done with your CDS view, you switcht to the BOPF ADT tools, import the CDS model and you add your BOPF specific artefacts (actions, determinations, validations) there.

One thing I really like about that is, there will be one single point of truth regarding the meta-model for datatypes and their relations to each other. But there is one thing I’m really worried about: till today the only way to edit CDS views is a text based editor. I really cannot imagine how anybody will be able to handle a text based meta model of a complex business object as we are having it in my current project. I have to define my whole business model by writing it in the CDS definition, it’s quite easy to forget something. There is no real guidance available. You might argue there is a syntax check and code completion, but for me that’s not as comfortable as using some kind of configuration UI. Maybe I’m used to the form based development tools from SAP already too long and just old fashioned, but that’s my view on that. Especially if I have to maintain an existing model which was defined by another developer, I guess I will be lost in all that text based definition.

Another aspect I like so far in BOPF is the visualization of my model. This makes it easier to discuss the model with the functional consultants. If I will have only a text based definition in the beginning, I will not be able to discuss that with the functional guys. I assume, the BOPF ADT tools will still provide this feature, but as I said, working with the BOPF tools is thought as a second step. Therefore I see a strong need in at least an optional graphical tooling for the CDS.

Getting rid off the state

The UI of choice for S4HANA will be UI5 based Fiori apps. They will consume OData services to communicate with the backend. CDS views can be exposed as OData service by just writing one line of code: @OData.publish: true (btw, that’s an annotation)

As OData is REST based, there will be no real state anymore on the backend site. After each call of an OData service which changes data there should be a commit in place. If you think about your current applications, you might recognize that this might cause some problems. Therefore SAP introduced the so called soft state to the S4 programming model. This means the intermediate state of your transaction will be stored as a draft. And there will be draft handling actions in each draft enabled BOPF model as PREPARATION and ACTIVATION which will enable the draft handling. In order to be able to make existing business logic draft enabled, SAP has to wrap the existing business logic also into BOPF objects. I can image this is a quite cumbersome task e.g. for some of those monolithic BAPIs.

Another thing which came into my mind was the s in S4HANA which stands for simplification especially of the data models. If there will be an additional draft table for all tables containing the data in final state, I’m not that sure if this is a real simplification of the data model. So simplification is in the eye of the beholder (or the SAP marketing department :-)).

To sum it up: it was a quite interesting session. But there were also many questions popping up in my head. It seems that things are still in development, so it might be a good point in time to provide some feedback, maybe as comments below.

As BOPF made it to the NetWeaver layer with 7.5 it will get easier to find a system to start to work with BOPF. As it will play a much bigger role in future, it’s a good point in time to start to work with it.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

    1. Martin Fischer Post author

      Hello Ivo,

      No, I didn’t notice that post. That sounds quite promising. I will have a look as soon as I will have access to a 7.5 system. If I got it right, changes are only possible in the text editor?

      Thanks and Regards,

      Martin

      (0) 
  1. Cain Sun

    Very interesting post. After 2 years, I am reading this and having the same questions in my mind. I see some duplicated logic in draft BO and BO. How SAP can merge the logics for the 2 BO? Also, I am thinking will all the functionality be exposed by ODATA? Is it a must to convert all the logic in the system like TM to stateless? Will draft  BO be created for all the BOs?

    (0) 

Leave a Reply