At a very high level, there are two main differences between the ABAP RESTful application programming model and BOPF.
First, in BOPF you defined the behavior of business objects in a form-based manner somewhat akin to configuration, and lots of “black magic” code was generated as a result. In the ABAP RESTful application programming model, everything is done via coding. You’ll have a behavior CDS entity and a behavior class, which are two interlinked sides of the same coin. This approach has proved very popular with programmers, who after all much prefer writing code to filling in half a hundred checkboxes to achieve any given task. The second difference is that you must use Eclipse as the IDE as it’s the only environment in which you can create CDS entities.
Don’t a heart attack when you read that BOPF is now in maintenance mode, as it were, after you’ve just spent the last three years writing all your new applications using BOPF—as SAP recommended. Fear not: SAP says that your investment is safe and that at some point in the future there will be a way to automatically convert BOPF objects into the ABAP RESTful application programming model equivalents (provided the BOPF objects were generated from CDS views).
There are two strands to the idea behind business objects in the ABAP RESTful application programming model: the use of a Business Definition Language (BDL) and the idea that business objects are first-class citizens.
Business Definition Language
The primary benefit of a CDS entity over a 100% identical SQL query is that a CDS entity expresses the same information semantically. For example, an INNER JOIN on VBAK/VBAP is how a database (machine) thinks about linking two tables, whereas an association between two concepts (order header and order items) is how humans think about the relationship.
The CDS definition reads like plain English, which is good in and of itself. For the old fashioned CDS view, the association gets compiled into the exact same SQL statement in the background as the one generated by the more technical OpenSQL query. A CDS entity is bit cleverer. It will only turn an association into a JOIN if it is needed based on the input data. That’s a bit abstract; we’re talking about some sort of query from the frontend asking for monster header details, and the CDS entity that gets hit in the backend has an association to items, so a CDS view would have done an INNER JOIN on the item table regardless—but the CDS entity knows that no item data has been requested and thus just does a read on the header table with no JOIN.
When ABAP in the cloud (now SAP BTP, ABAP environment) came out in September 2018, SAP revealed the concept of a Business Definition Language, which is all about defining a business object in a text-based way, just like the Data Definition Language (DDL) that defines a CDS entity. You could now describe the nature of the business object (as in, what behavior it’s capable of) in a BDL definition (which is itself a specialized type of CDS entity).
In the initial release of the ABAP RESTful application programming model, you only had the concept of an unmanaged business definition, whereby you describe the business object behavior in the BDL but actually implement the logic using what appears at first glance to be traditional ABAP code, albeit with some new quirks. In a subsequent release, the concept of managed business definitions was introduced, via which the BDL itself generates the code to control the CRUD operations. The point is that you have total control: if the idea of always having to manually write boilerplate code for CRUD operations for business objects bores you to tears, then take the managed option; if you’re a control freak and want to code every little thing yourself, then take the unmanaged option.
Business Objects as First-Class Citizens
SAP has also come up with the rather nebulous concept that a business object should be a first-class citizen. What that term means (in the programming language world) is that it (the business object) can be passed as a parameter, be the result of a functional method, and be assigned to a variable. In essence, in the ABAP RESTful application programming model, the business object definition is done via ABAP language constructs, and you have typed interfaces. This contrasts with BOPF, in which you define metadata that generates classes with generic interfaces—so you can’t have a BOPF object instance as a RETURNING parameter, for example.
You can argue that makes the standalone monster model class a first-class citizen as well: it has a typed interface and represents a business object. Moreover, how the ABAP interfaces used by the ABAP RESTful application programming model work out what their correct type should be is very strange indeed and happens under the hood seemingly by black magic. To learn more about this, check out the book ABAP to the Future by Paul Hardy.
Comments