Those who have been coding via the ABAP Editor and with ABAP prototype design patterns for years might have heard about the ABAP RESTful programming model (sometimes named RAP). But what is it? Let’s take a look.
The three central pillars haven’t changed when programming with the ABAP RESTful Programming Model: there’s still clear separation between the database layer, the business logic layer, and the UI layer. However, in each case how you go about programming has changed to a lesser or greater extent, so let’s talk about the changes to each layer in turn.
Changes to Database Layer
The main change here is that you can no longer use SELECT statements to access database tables in the core ERP system like KNA1. For your own Z tables, you can keep using SELECT or UPDATE because they live in the same database as your cloud ABAP code.
Because you will always want access both to reading data from the ERP system and indeed updating it (like doing a goods issue), there has to be some mechanism to do this.
In this case, the communication mechanism is via whitelisted APIs. What are they, I hear you ask? Well, you know how 95% of standard SAP function modules are marked as “not released” but we use them anyway? Imagine if you couldn’t. Imagine if suddenly one day every unreleased function module in your Z programs started causing a syntax error. I imagine you would be stuffed; I know I would.
The whitelist in the ABAP cloud is like that horror scenario. Instead of being able to call any standard SAP function module or class you feel like, you have to choose from a list of approved ones. In return, SAP 100% guarantees those calls will keep working after an upgrade to the core system.
If you want to send and/or receive data from the ERP system, you have to use a whitelisted API. The definition of a RESTful API according to https://searchmicroservices.techtarget.com/definition/RESTful-API is thus: “A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT, POST, and DELETE data.”
To be even more precise, SAP has said that if it wants to whitelist a table, it will create a CDS view for it (read access) and for write access will offer a typed class-based API. At some point in the future, SAP also will support RFC calls, which might make you a bit less nervous.
This situation—communication with APIs—isn’t the end of the world, though it might seem like it at first glance. The question you have to ask yourself is whether the stability you get as a result of this approach outweighs the initial pain of doing everything in a different way. The point about stability is that it lets you make changes faster, and these days being able to adapt faster stops you going the way of the dinosaur or Blockbuster Video in a hurry.
With your Z tables, you can do code pushdown any way you fancy. Nothing has changed—except, as you’ll see, when it comes to business objects, which have to revolve around a CDS view.
Changes to Business Logic Layer
The changes in this area are a bit more radical. The BOPF you know and love is no more. It’s been replaced by something that—though conceptually identical—is implemented in a totally different way technically. In case you have a heart attack when you read that BOPF is now in “maintenance mode” when 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 from 2020 there will be native integration between RAP and BOPF, although it does say that once RAP is available to you, don’t use BOPF for any new developments.
At the time of writing, the new business object concept is not very old and thus will no doubt get radical changes in future releases. There are two strands to this: the use of a Business Definition Language and the idea that business objects are first-class citizens.
Business Definition Language
One of the primary benefits of a CDS view over a 100% identical SQL query is that a CDS view 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 a human thinks about the relationship between two tables.
So the CDS definition reads like plain English but gets compiled into the exact same SQL statement in the background as the one generated by the more technical Open-SQL query.
When ABAP in the cloud came out in September 2018, SAP revealed the concept of a business definition, which is all about defining a business object in a text-based way, just like the DDL which defines a CDS view. 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 view).
In the initial release of RAP, you only have the concept of a so-called 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 the future, the concept of managed business definitions will be introduced, via which, presumably, the BDL itself generates the code to control the behavior. A lot of ABAP programmers (including me) find that idea quite scary, but we’ll have to wait until SAP actually tells us what it means before going into a mad panic.
It’s worth noting that since the 1950s software companies have been promising that “next week” they’ll introduce an option to write a specification in plain English and have a program generate itself, needing not one line of code. Up until now, this has never happened in a meaningful way, so rather like nuclear fission, the actual realization of this promise always seems to be ten years away.
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 non-SAP 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 RAP the business object definition is done via ABAP language constructs, and you have typed interfaces. This is in contrast to 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.
It could be argued that makes a 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 RAP work out what their correct type should be is very strange indeed and happens under the hood seemingly by black magic.
Changes to User Interface Layer
This area has changed hardly at all. The idea was always that UI technology changes so fast that you need to totally decouple the backend from the frontend by having the UI layer consume OData services provided by the backend. For the moment, SAP has SAPUI5 as its preferred UI technology, but in this day and age something bigger and better could come along at any second.
The traditional model declares information that in the past could have been considered the job of the UI, such as which order the fields go in, alternate names, and basically all of the ALV field catalogue type information.
In RAP, such behavior in the UI is controlled totally by annotations in the CDS views. The UI layer is dumb and is solely concerned with making the application look as nice as possible. The idea is that if there are no smarts at all in the frontend, then you can switch technology at the flick of a switch and not have to change the backend at all.
That said, some people are deeply uncomfortable about controlling the UI by coding in what appears to be the database layer (the CDS view). It could be argued that a data model has no business knowing how its data is going to be interacted with in the frontend, especially if the model is designed to be consumed by many different applications.
A counterargument is that a CDS view is one level up from the database layer because one day (possibly) a CDS view will be able to consume sources other than database tables/views, such as OData services.
Whether you like the concept of UI annotations in a CDS view or not, one thing that’s quite impressive in RAP is that you get a sort of WYSIWYG preview of what your application will look like, generated on the fly as you add UI-specific annotations to your CDS view.
How this works is that you define your CDS view using ABAP in Eclipse. While in the CDS definition screen, at any point you can click Open Fiori Elements App Preview to see what the application would look like based on the current annotations in the CDS view.
This is very similar to the test tool in BOPF via which you could get a list of monsters on the fly and perform actions upon them, such as creating a new one, and have the result saved in the database. The big difference is the user interface, which is SAPUI5 as opposed to SAP GUI.
Going forward yet again, at some point in the future the UI annotations won’t need to be coded manually in the CDS view definition at all. You’ll have a WYSIWYG visual editor instead in which you drag fields around and change their properties and an application-specific file of annotations will be generated.
Conclusion
There you have it—the ABAP RESTful Programming Model! What do you think? Not as scary as you thought or something you’ll stay away from at all costs? What about the changes discussed above: do they sound like a good direction? Let us know in the comments!
This content was originally posted on the SAP PRESS Blog and has been adapted from a section of the book ABAP to the Future by Paul Hardy.