The Rappy Horror abapGiture Show – Part Three
NARRATOR: As you will probably be aware by now, the two biggest things happening in the SAP world are the introduction of the Cloud RAP (Restful ABAP Programming Model) and abapGit for version management, hence the title of this blog series, which narrates a horror story concerning both new concepts.
The night before the publication of the “ABAP to the Future 3” book two horrible things were happening simultaneously. First of all the author was writing the book in the first place, and if that was not bad enough in and off itself……
The Story So Far..
NARRATOR: When we left things last week the author was about to actually start creating the various ABAP artefacts needed for the downloadable code, and SAP and ABAP were in Castle Frankenstein where they – foolishly – think they are going to be able to phone for help regarding their broken down self-driving electric car. What unspeakable horrors await all three “actors” in this waking nightmare? Find out in this week’s exciting episode of the Rappy Horror abapGiture show….
PDH: In the last blog I talked about how to download the code from the book. Now naturally I had to start from scratch with that code, so I am going to document the order of development.
What follows is the idealised code that would need to be created. As might be imagined the whole project is a work in progress –forever, just like a real SAP system – and the latest additions will be uploaded to GitHub on a regular basis.
Data Elements, my Dear Watson
If step one was installing abapGit then step two is the creation of the lowest level building blocks of any SAP solution – the Z domains and data elements, so I created a bucket load of them, as and when required, whilst creating the higher level structures and such. In other words, this is how you suck eggs, Grandma.
Vampire Driving In-Structure
Step three is to create some structures for my monster header and monster item. This is to demonstrate the BOPF concept where the underlying database table consists of a generic GUID structure plus a structure of all the fields to be persisted in the database. On top of this you can add another structure of the “transient” fields which do not live in the database and only get filled at runtime e.g. text names of elements like sales organisation for example, in my case more sensible things like sanity description and hat size description.
Transient fields can be filled by BOPF derivations, or via a CDS view. Naturally I want to demonstrate both approaches.
For the Monster Business Object the process from CDS view to BOPF to SEGW Gateway service is going to be 100% manual (just to demonstrate how to do everything manually) so I create the structures manually. For the other business objects the corresponding BOPF objects are going to be generated from the CDS view automatically so I do not need to fluff about manually creating structures for them, their structures will be generated automatically.
So I only need to get four structures, as follows:-
ZSP_MONSTER_HEADER_D Monster Header Structure (Database Fields)
ZST_MONSTER_HEADER_DT Monster Header Structure (Transient Fields)
ZSP_MONSTER_ITEMS_D Monster Item Structure (Database Fields)
ZST_MONSTER_ITEMS_DT Monster Items Structure (Transient Fields)
These will get nominated later when the BOPF object for the Monster business object is created manually.
Dancing on the Table (as opposed to the ceiling)
I am on step four already! Hurrah! How many steps are there, I hear you ask? A lot is the answer – circa 40. Still it is like how Snoopy reads ‘War and Peace” – one word a day. He got there in the end. It’s not like I have only one day to write the whole book before the Gala party tomorrow – oh hang on, that is exactly the case! Oh Dear!
Step four is creating the database tables which will be used by the CDS views which will be used by the BOPF objects which will be used by the Old Woman who swallowed a fly, I don’t know why she swallowed a fly, perhaps she’ll die.
There are five business objects, but two of them have items (Monster and Monster Sales Order) so there are seven underlying database tables in total.
Of those seven two (Monster Header and Item) are going to be generated automatically when the Monster BOPF object is created manually, which shows why that approach is wrong – you should start with the data model and work your way up.
In the remaining tables I will give the Monster Delivery table a GUID as a primary key, just to show that this is the way the BOPF has always liked doing things, and the other tables can have proper logical primary keys, and they will get shoved down the throat of the BOPF and it will have to like it or lump it.
Here are the tables listed based on the object model i.e. lowest objects in the structure first, before tables that depends on them. You can of course create them in any order, order, Mr. Speaker.
Village Master Data (Real Key) – ZMN_VILLAGES -Lowest Level
Monster Items (GUID) – ZTMONSTER_ITEMS – Lowest Level – Generated by BOPF
Monster Header (GUID) – ZTMONSTER_HEADER – References Monster Items – Generated by BOPF
Reservation (Real Key) – ZMN_RESERVATIONS – References Monster Header
Monster Sales Order Item (Real Key) – ZMN_ORDER_ITEMS – References Reservation + Village
Monster Sales Order Header (Real Key) – ZMN_ORDER_HEADER – References Sales Order Item
Monster Delivery (GUID) – ZMN_DELIVERIES – References Sales Order Header + Item + Village + Monster Header
The MN stands for “Monster” as might be expected, I am pretending there is a Monster Module in SAP like SD or MM. As I am going to be getting ahead of myself and referencing the Monster Header/Item tables in some example programs I need to at least partially create the Monster BOPF Object so the two Monster Object database tables get generated.
I wouldn’t say “CDS View” to a Goose
Step five is to create CDS Views for the various business objects. Two of the objects have items – the Monster and the Sales Order – so an association is needed in those cases.
You are no doubt familiar with the problem whereby you have a value table for a domain, which relates to a data element, and of course that data element is in the value table along with the language (or whatever). So you have to do the procedure in several steps i.e. create the domain without the value table initially to get around the circular dependency.
It is the same for the CDS views for the header and item. They both refer to each other e.g. the Chicken CDS View refers to the Egg CDS view and vice versa. So you create the item one first without a reference to anything, and then activate it, and then create the header view referencing the item, and then you (amazingly) get a warning, and then change the item view to reference the header.
My pet hate in SAP is when you create a table or structure and then try and assign an “enhancement category” and then you get a warning message that you have not yet assigned an enhancement category. Whoever came out with that process is barking at the moon, foaming at the mouth, free energy crazy, and just to add insult to injury SAP will never even dream about thinking about fixing this.
We are living in a MetaData World, and I am a MetaData Girl
Whilst we are on the subject of CDS Views, and moaning, I was always puzzled by having to put all the UI specific annotations in a CDS view i.e. at the database level. That did not half seem like a clear breach of the “separation of concerns” principle. I can see why an application model can state how its data is to be displayed, but not a database table. Surely the database tale should not know anything about how it is going to be used?
That is why despite the claim that CDS Views were “Jungle is Massive” and “Massively re-Usable” SAP had to create twenty billion zillion of them, as each one was application specific due to all the annotations.
The solution was the so called “MetaData Extensions” which over-ride any annotations in the base CDS view, and thus one CDS view can then be used in lots of different applications, each with an application specific extension.
Anyroad up, as we say in the UK, I need seven CDS Views for seven brothers, I mean for the five business objects. Some of these are going to auto-generate further objects.
This is just to demonstrate the various options available. For the Monster Business Object both the BOPF definition and the SEGW definition will be created manually.
For the delivery the BOPF object will be auto-generated from the CDS View, and then the SEGW service will be generated by “pulling” the Delivery BOPF object, it’s got bells on.
The Monster Sales Order CDS View will go all the way tonight, tonight tonight, go all the way tonight tonight, and “push” the automatic creation of both the BOPF object and also the associated SEGW service with a smile.
Step six is to demonstrate the usage of ABAP Managed Database Procedures. Traditionally you would code a “stored procedure” which gets executed in the database, in the database – where else?
Now we can control this via ABAP. You still have to write the code in database language – SQLSCRIPT for HANA in our case – but it gets called just like a regular ABAP method. Spooky. Moreover you can call an ADMP from within a CDS view via a so called “table function”.
Now I think this is a wonderful breakthrough technology solution, but it could also be described as a wonderful breakthrough technology solution looking for a problem. I for one had to really struggle to find a practical use for this, but I got there in the end by looking for situations in my actual company where the database was getting a real hammering.
Where an ADMP can beat the pants off a database view is that it (a) can have multiple results coming back just like a normal method and (b) unrelated SQL queries can be executed in parallel. Think about that for a second – in your normal code a routine could call several unrelated SQL queries at various points in the code. Naturally the queries are executed one by one, in sequence. Now if you encapsulate the queries into a database access class – which is a good thing to do anyway, for unit testing purposes – you could in theory have three or four unrelated queries execute in parallel.
It could however be argued that this is not a very realistic scenario as most of the time each SQL query in some way depends on the result of a previous SQL query, or you do a JOIN. Nonetheless you need to be aware of the possibility, just in case you do have unrelated queries. The other problem of course is that the functionality of ABAP SQL and CDS views keeps increasing by leaps and bounds, making the advantage of an AMDP that much more difficult to quantify
I would be very interested if you have a clear use case for this, and can sing to me “Who you Gonna Call? AMDP Busters!” and bounce your solutions like bombs.
Naturally a lot of people do not have a HANA database and so cannot use ADMPs anyway. If you want to have a play with this technology without spending ten zillions dollars you have to use the SAP CAL (Cloud Appliance Library) and then you can “spin up” your very own standalone ABAP system (i.e. BASIS and ABAP only, no application modules) with a HANA database.
NARRATOR: Meanwhile whilst PDH was creating DDIC elements and CDS views and so on that – fateful – night, SAP and ABAP were at Castle Frankenstein trying to access a telephone so they could report that their car had broken down. As you may recall they were not getting very far with the servants, who just wanted to sing and dance and use buzzwords like “Game Changer” and “Paradigm Shift”.
Luckily – or maybe not – they would have another chance to ask for help when the master of the castle, none other than Baron Frankenstein himself, abruptly arrived by walking through the audience onto the stage.
MONSTERS: Master! Master!
Just a Business Sweet…
How d’you do, I
See you’ve met my
Faithful ABAP Developer
He’s just a little brought down
Because when you knocked
He thought you were a Pelican
Don’t get strung out by the way I look
Don’t judge an SAP Press book by its cover
I’m not much of a man by the light of day
But by night I’m one hell of a programmer
I’m just a Business Sweet on HANA
From Walldorf, Germany
Let me show you around
Maybe play you a sound
You look like you’re both pretty loopy
Or if you want something visual
That’s not too abysmal
We could take in a massive open source SAP training video on YouTube, eh?
I’m glad we caught you at home
Could we use the co-pilot digital assistant on your smartphone?
We’re both in a bit of a hurry
We’ll just say where we are (possibly using the ARC GIS system from ESRI)
Then go back to our self-driving autonomous car
We don’t want to be any worry
Well you got a short dump, well, crumbs crumbs crumbs!
Well, babies, don’t you choke
By the light of the night it’ll all seem alright
I’ll implement a satanic OSS Note (is there any other sort?)
I’m just a Business Sweet on HANA
From Walldorf, Germany
Why don’t you stay for the night? (Monsters: Night)
Or maybe a bite? (Monsters: Bite)
I could show you my latest product, on ramp-up, you know,
I’ve been making a monster
With blond hair and tonsils
And he’s good for relieving my… …tensorflow
I’m just a Business Sweet on HANA
From Walldorf, Germany
HIT IT, HIT IT!
I’m just a Business Sweet on HANA. (Business Sweet on HANA)
Business Sweet on HANA
From Walldorf, Germany
So – come up to the end user testing lab
And see what’s on the slab
I see you shiver with antici – (3 seconds) – pation
But maybe the user experience
Is really to blame
So I’ll remove the cause. (chuckles)
But not the SAP systems
(Monsters rip off the clothes of SAP and ABAP)
BARON FRANKENSTEIN: Well you both have very nice underwear, but maybe you had better have these special SAP laboratory coats, so your code is not vulnerable. These coats work out of the box, don’t you know.
SAP: These lab coats have twenty three arms and no hole for the head!
BARON FRANKENSTEIN: Well obviously they do not work out of the box, despite me promising just exactly that before you had to use them. You have to customize them before they work, just like any other SAP customer. It should only take you 47 months and several million dollars, I have a team of 700 consultants I can lend you. They are all monsters, so no change from all the other options out there.
NARRATOR: Here we leave things for the time being on that – fateful – night, the night before the SAP Press Gala launch party for “ABAP to the Future Part 3” with the author six steps finished in regard to creating the various ABAP artefacts needed for the downloadable code, and SAP and ABAP in Castle Frankenstein where they – foolishly – think that Baron Frankenstein is going to help them regarding their broken down self-driving electric car. What unspeakable horrors await all three “actors” in this waking nightmare? Find out in next week’s episode of the Rappy Horror abapGiture show….