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..
https://blogs.sap.com/2019/02/26/the-rappy-horror-abapgit-ture-show/
https://blogs.sap.com/2019/03/05/the-rappy-horror-abapgiture-show-part-two/
https://blogs.sap.com/2019/03/12/the-rappy-horror-abapgiture-show-part-three/
https://blogs.sap.com/2019/03/19/the-rappy-horror-abapgiture-show-part-four/
NARRATOR: When we left things last time on that – fateful – night, the night before the SAP Press gala party to launch ABAP to the Future 3, the Baron had brought his new monster to life with SAP and ABAP looking on in horror. Meanwhile the author had finished his DDIC elements and example programs, and was ready to move on to the transactional side of things. What unspeakable horrors await all three “actors” in this waking nightmare? And what is this “Floorplan Manager Show” of which the Baron speaks? Find out in this week’s episode of the Rappy Horror abapGiture show….
The 39 Steps (book/film)
https://en.wikipedia.org/wiki/The_39_Steps_(1935_film)
There are 36 steps I have identified to prepare the downloadable code for the book, and we have got to number 13 now. Those with a mathematical bent will have by now calculated – or have been informed by their artificially intelligent digital assistant - that this means there will be 8 Rappy Horror blogs in total, with number 8 having the grand Floorplan Manager Show finale with bucket loads of songs.
Leaving SAP based songs aside for a moment – difficult though that may be - the main difference between the various new ABAP programming models and what went before (what SAP like to call “classical freestyle swimming way of programming”) is that before everything was jammed together, and the new approach is to have everything in layers, with each layer only knowing about what goes above and below it.
The lowest layer is the database tables. CDS views live above that and serve as a bridge between the different layers in that the business logic and indeed user interface can be generated from them. This is an important point to note – initially a CDS view seemed to be just like a database view i.e. a glorified SQL statement. In some ways that is exactly what it is, but with the advent of annotations and the so called “virtual data model” CDS views are positioned more as a form of living documentation for an “entity” (e.g. sales order or monster). They can be used for an application but I prefer to think of them as application agnostic which is why the UI annotations live in a separate metadata extension object – that way the CDS views are re-usable across applications.
Persist again, like we did Last Summer
Step 13 relates to the persistency layer – the idea is that evert time a program or class wants to access the database it must go through a dedicated persistency layer class.
This is primarily for testing purposes – you cannot do proper unit tests if the business logic code is mixed with code that does a direct SELECT statement, but with a database access class (persistency layer) you can create a test double of the database access class which returns hard coded values.
This means you need two artefacts at minimum – the interface and the base class. The caller only ever knows about the interface. This means in the actual class (or subclass) you can get the data any way you want – direct SQL read, via a CDS view, via an AMDP, via the BOPF framework, via RFC, whatever, and then are free to swop and change as you feel like it. As an example if I wanted an order status field, in ECC 6.0 by persistency layer class would read from VBUK, in S/4 HANA VBUK does not exist (as a table) so I would read from VBAK, and the caller would not know or care about the change.
So step 13 is to “Create Persistency Classes for each Business Object” which are:-
Initially you just want the CRUD operations, which come from the BOPF (for the ABAP programming model for SAP Fiori) and the transactional CDS view (for the RAP) but life is never that simple and you are bound to have occasions where you want to do a direct SQL read on one or more tables for whatever reason. As mentioned, having a dedicated database access class gives you that freedom.
So you define the interface first in each case, just saying what data comes back in response to what query, and then a base class using your retrieval mechanism of choice e.g. CDS views for entities, SQL queries for more obscure queries. The persistency class is hidden within the model class which is used by the various frameworks e.g. BOPF, Web Dynpro, RAP and so on. The end framework does not need to know about the underlying parts of the model, that is the whole purpose of OO i.e. encapsulation.
The end applications tend to have local persistency layer classes, which can of course also have test doubles for unit tests.
Oh! Oh! The OSQL Places you’ll go!
Step 14 is to “Test your SQL statements using OSQL”. This is referring to the test double framework for SQL statements. As mentioned just now it is quite likely there will be some direct SELECT statements on one or more database tables, and you can have unit tests for these right inside the persistency layer. That layer does not need to know what is going to call it, but you do need to know it is going to work in the first place for any given SQL query, and that is what the OSQL test double framework is all about.
(In the background the “intruder alert” light starts flashing. Nobody notices).
One big difference between the third version of the book and the earlier ones is that now every “transactional” chapter has a section on unit testing. SAP has gone one million tons of bananas in this area recently which is fantastic.
CDS VIEW: Hang on just one second! Hot Dog! Jumping Frog! I am the King of Database Access now – absolutely, why are you giving airtime to ABAP SQL statements?
PDH: That is a fair point. As time goes by more and more database access statements formerly using a direct SQL statement will go through a CDS view. So the CDS view needs a unit test as well.
Thus, step 15 is to “Test your CDS views using CDS test framework”. As you will see from now on pretty much every second step will involve doing automated unit tests on whatever the prior step has created.
You test the SQL statements in whatever program (database access class hopefully) that calls the statement, but CDS views live in their own special type of TADIR object. Nonetheless the ABAP framework provides a mechanism to run automated unit tests against them, once again this means the CDS view is tested independent of whatever might call it.
One Ring to Rule Them All, One Ring to Bind Them
Thus far we have created some persistency layer classes which can be consumed by the corresponding model classes (or anything else) to bring back the data from the database (or wherever). This is a fine example of the principle of abstraction.
Our business objects (which do not actually exist yet) – Monsters, Sales Orders, Deliveries and so on – can now get the data, lovely, but what can they do with it? In this hard life that we live, one does not simply “move” data from the database to the screen or vice versa – business logic is applied in both directions and a lot, if not all, of this could be described as applying business rules on the data.
So step sixteen is to “Create BRF+ Rules”. All applications are crawling with complicated rules that just get more complicated over time. SAP has lots of business rules frameworks, but the one inside ABAP is BRF+ so that is what I am sticking with.
In preparation for the latest book I went out for dinner with the inventor of BRF+ here in Walldorf and he told me all about the future of this technology and then of course I had to have a huge nosebleed during dinner. I am not saying that talking about BRF+ caused blood to start spurting uncontrollably out of my body but you never know.
In any event, this step involves identifying the business rules and storing them as a standalone object within SAP as a decision table or whatever in BRF+. This is just like a configuration table in the IMG just a lot more flexible.
(Enter MR T)
MR T: I pity the Rule that has not been tested. (EXIT)
PDH: Mr.T also makes a good point. So step seventeen, just seventeen, would be “Test BRF Rules - inside BRF+ & then test case framework”.
BRF+ has an inbuilt simulation framework where you can manually enter test data to make sure the right result comes out, and check every step of the logic, or you can pay extra to have the deluxe version where you can store test cases, or you can manually program the test case framework yourself (BRF+ is crawling with APIs).
Whatever you choose, the point is that you can unit test the rules in BRF+ until the cows come home to roost and jump over the moon, and the dish runs away with the spoon.
We’re just a ship of Business Rules
As you will have gathered by now the idea is to abstract as much as you possibly can. This is because any sort of business application has so many moving parts, all changing at different speeds, that you need to keep them separate connected by interfaces, so the guts of any one part can change independently of any other component. You cannot move at warp factor eight any other way.
Step number eighteen is “Create Business Rules Classes”. Then the model class can outsource the business rules logic to such a class – remember there has to be an interface above the business rules class, in fact pretty much every class has to have an interface to expose it’s public methods, otherwise you cannot do proper unit testing.
At this point you might think I have gutted the model class like a fish – the database access is done by a dedicated class, as is the business rules, as is anything else I can think of. That, in my mind, is wonderful. That is there is a clear separation of the WHAT (as described in the model class) from the HOW (which is coded in the helper classes). This is in fact, what fans of Functional Programming say is good about FP languages (like JavaScript) – you have to say the WHAT in the code without going all around the houses like I have.
Rescue Me
Talking about going all around the houses I had better go all around the castles soon – I get the feeling that SAP and ABAP and possibly Professor Hasso Plattner might be in trouble in Castle Frankenstein (after three books, I know what the Baron is like), and so I will pick them all up in my autonomous self-flying private Jet tomorrow morning so they can all make it to the SAP Press Gala Party at Castle Dracula on the Tuesday evening. If I leave right now I will probably get there about 2AM Tuesday morning - I hope they will not be in too much trouble by then.
NARRATOR: Meanwhile, back in the SAP Innovation Lab, the Baron had brought his new monster to life, and was busy making evil plans.
BARON FRANKENSTEIN: Now my new Monster is alive, we can all get ready for the Floorplan Manager Show. About 3AM tomorrow morning (Tuesday) would be a good time, and anybody around then will get dragged into it. I can have my man RICEF show you to your rooms so you can get a bit of shuteye before then.
SAP: We don’t want to stay for the night! All we want is to use the co-pilot digital assistant on your smartphone to call for help – a reasonable request which you have seen fit to deny!
BARON FRANKENSTEIN: Ooooh! How macho! (to ABAP) You must be very proud of him!
ABAP: I guess I am.
(Sudden loud alarm sounds, red flashing lights)
RICEF: Master! Master! The refrigeration system for the data centre has broken down. That means the database will come to life!
BARON FRANKENSTEIN: Blue Ruin! It’s not even a HANA database, it is a Relational Database Management System (RDMS for short) and I hate it and everything it stands for!
RICEF: Ready or not, here it comes!
(EXPLOSION)
(A huge hole opens up in the wall separating the stage from the data centre. Enter RDMS driving a Harley Davison (who run SAP by the way) Motorbike)
*----------------------------------------------------------------------------------------------*
Hot Pack R/2 Fruity
*----------------------------------------------------------------------------------------------*
RDMS: Whatever happened to Saturday folks?
When you programmed all night eating pizzas and diet coke
It don't seem the same since ITIL principles
Came into my life, I thought upgrades was simples
I used to do upgrades with a chick who'd go
And listen to podcasts on SAP radio
Buzzwords were flowing on a change control show
We climbed in the back seat, wow, then ran transaction SPAU
Hot pack install, bless my soul
Really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
My head used to swim when reverting to standard
My hands kinda fumbled with one million tons of bananas
I'd taste her baby pink lipstick and then think of HANA
She'd whisper in my ear “I love the upgrade planner”
Get back in front, with make-up she puts her face on
Buddy Holly was singing about continuous integration
With the upgrade complete, you get a huge … well I don’t like to say….
It felt pretty good, woo
Really had zero downtime
Hot pack install, bless my soul
Really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
BARON FRANKENSTEIN: I hate him! I hate him!
RDMS: Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
(Baron Frankenstein rolls out a Howitzer)
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
BARON: Bombs Away! (Fires Howitzer)
RDMS: I really love that (BANG!) (Dying Scream)
BARON FRANKENSTEIN: One must speak good of the dead. He’s dead. Good! Now I can get on with preparing for the Floorplan Manager Show. While I’m doing that everyone else can have forty winks – you will need all your energy later. So OK everybody, time for bed!
NARRATOR: Here we leave the horrific events on that – fateful – night. The Baron has made his monster and destroyed his former database. Meanwhile the author is about half way through the downloadable code, about ready to create the model classes. Meanwhile the Baron is dead set on dragging everybody into the “Floorplan Manager Show” whatever that is – and why is he so keen for everyone go to sleep first? You will find out in the next horrific episode of the waking nightmare that is the “Rappy Horror abapGiture show” …..
https://www.sap-press.com/abap-to-the-future_4751/
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..
https://blogs.sap.com/2019/02/26/the-rappy-horror-abapgit-ture-show/
https://blogs.sap.com/2019/03/05/the-rappy-horror-abapgiture-show-part-two/
https://blogs.sap.com/2019/03/12/the-rappy-horror-abapgiture-show-part-three/
https://blogs.sap.com/2019/03/19/the-rappy-horror-abapgiture-show-part-four/
NARRATOR: When we left things last time on that – fateful – night, the night before the SAP Press gala party to launch ABAP to the Future 3, the Baron had brought his new monster to life with SAP and ABAP looking on in horror. Meanwhile the author had finished his DDIC elements and example programs, and was ready to move on to the transactional side of things. What unspeakable horrors await all three “actors” in this waking nightmare? And what is this “Floorplan Manager Show” of which the Baron speaks? Find out in this week’s episode of the Rappy Horror abapGiture show….
The 39 Steps (book/film)
https://en.wikipedia.org/wiki/The_39_Steps_(1935_film)
There are 36 steps I have identified to prepare the downloadable code for the book, and we have got to number 13 now. Those with a mathematical bent will have by now calculated – or have been informed by their artificially intelligent digital assistant - that this means there will be 8 Rappy Horror blogs in total, with number 8 having the grand Floorplan Manager Show finale with bucket loads of songs.
Leaving SAP based songs aside for a moment – difficult though that may be - the main difference between the various new ABAP programming models and what went before (what SAP like to call “classical freestyle swimming way of programming”) is that before everything was jammed together, and the new approach is to have everything in layers, with each layer only knowing about what goes above and below it.
The lowest layer is the database tables. CDS views live above that and serve as a bridge between the different layers in that the business logic and indeed user interface can be generated from them. This is an important point to note – initially a CDS view seemed to be just like a database view i.e. a glorified SQL statement. In some ways that is exactly what it is, but with the advent of annotations and the so called “virtual data model” CDS views are positioned more as a form of living documentation for an “entity” (e.g. sales order or monster). They can be used for an application but I prefer to think of them as application agnostic which is why the UI annotations live in a separate metadata extension object – that way the CDS views are re-usable across applications.
Persist again, like we did Last Summer
Step 13 relates to the persistency layer – the idea is that evert time a program or class wants to access the database it must go through a dedicated persistency layer class.
This is primarily for testing purposes – you cannot do proper unit tests if the business logic code is mixed with code that does a direct SELECT statement, but with a database access class (persistency layer) you can create a test double of the database access class which returns hard coded values.
This means you need two artefacts at minimum – the interface and the base class. The caller only ever knows about the interface. This means in the actual class (or subclass) you can get the data any way you want – direct SQL read, via a CDS view, via an AMDP, via the BOPF framework, via RFC, whatever, and then are free to swop and change as you feel like it. As an example if I wanted an order status field, in ECC 6.0 by persistency layer class would read from VBUK, in S/4 HANA VBUK does not exist (as a table) so I would read from VBAK, and the caller would not know or care about the change.
So step 13 is to “Create Persistency Classes for each Business Object” which are:-
- Village
- Monster
- Reservation
- Sales Order.
- Delivery
Initially you just want the CRUD operations, which come from the BOPF (for the ABAP programming model for SAP Fiori) and the transactional CDS view (for the RAP) but life is never that simple and you are bound to have occasions where you want to do a direct SQL read on one or more tables for whatever reason. As mentioned, having a dedicated database access class gives you that freedom.
So you define the interface first in each case, just saying what data comes back in response to what query, and then a base class using your retrieval mechanism of choice e.g. CDS views for entities, SQL queries for more obscure queries. The persistency class is hidden within the model class which is used by the various frameworks e.g. BOPF, Web Dynpro, RAP and so on. The end framework does not need to know about the underlying parts of the model, that is the whole purpose of OO i.e. encapsulation.
The end applications tend to have local persistency layer classes, which can of course also have test doubles for unit tests.
Oh! Oh! The OSQL Places you’ll go!
Step 14 is to “Test your SQL statements using OSQL”. This is referring to the test double framework for SQL statements. As mentioned just now it is quite likely there will be some direct SELECT statements on one or more database tables, and you can have unit tests for these right inside the persistency layer. That layer does not need to know what is going to call it, but you do need to know it is going to work in the first place for any given SQL query, and that is what the OSQL test double framework is all about.
(In the background the “intruder alert” light starts flashing. Nobody notices).
One big difference between the third version of the book and the earlier ones is that now every “transactional” chapter has a section on unit testing. SAP has gone one million tons of bananas in this area recently which is fantastic.
CDS VIEW: Hang on just one second! Hot Dog! Jumping Frog! I am the King of Database Access now – absolutely, why are you giving airtime to ABAP SQL statements?
PDH: That is a fair point. As time goes by more and more database access statements formerly using a direct SQL statement will go through a CDS view. So the CDS view needs a unit test as well.
Thus, step 15 is to “Test your CDS views using CDS test framework”. As you will see from now on pretty much every second step will involve doing automated unit tests on whatever the prior step has created.
You test the SQL statements in whatever program (database access class hopefully) that calls the statement, but CDS views live in their own special type of TADIR object. Nonetheless the ABAP framework provides a mechanism to run automated unit tests against them, once again this means the CDS view is tested independent of whatever might call it.
One Ring to Rule Them All, One Ring to Bind Them
Thus far we have created some persistency layer classes which can be consumed by the corresponding model classes (or anything else) to bring back the data from the database (or wherever). This is a fine example of the principle of abstraction.
Our business objects (which do not actually exist yet) – Monsters, Sales Orders, Deliveries and so on – can now get the data, lovely, but what can they do with it? In this hard life that we live, one does not simply “move” data from the database to the screen or vice versa – business logic is applied in both directions and a lot, if not all, of this could be described as applying business rules on the data.
So step sixteen is to “Create BRF+ Rules”. All applications are crawling with complicated rules that just get more complicated over time. SAP has lots of business rules frameworks, but the one inside ABAP is BRF+ so that is what I am sticking with.
In preparation for the latest book I went out for dinner with the inventor of BRF+ here in Walldorf and he told me all about the future of this technology and then of course I had to have a huge nosebleed during dinner. I am not saying that talking about BRF+ caused blood to start spurting uncontrollably out of my body but you never know.
In any event, this step involves identifying the business rules and storing them as a standalone object within SAP as a decision table or whatever in BRF+. This is just like a configuration table in the IMG just a lot more flexible.
(Enter MR T)
MR T: I pity the Rule that has not been tested. (EXIT)
PDH: Mr.T also makes a good point. So step seventeen, just seventeen, would be “Test BRF Rules - inside BRF+ & then test case framework”.
BRF+ has an inbuilt simulation framework where you can manually enter test data to make sure the right result comes out, and check every step of the logic, or you can pay extra to have the deluxe version where you can store test cases, or you can manually program the test case framework yourself (BRF+ is crawling with APIs).
Whatever you choose, the point is that you can unit test the rules in BRF+ until the cows come home to roost and jump over the moon, and the dish runs away with the spoon.
We’re just a ship of Business Rules
As you will have gathered by now the idea is to abstract as much as you possibly can. This is because any sort of business application has so many moving parts, all changing at different speeds, that you need to keep them separate connected by interfaces, so the guts of any one part can change independently of any other component. You cannot move at warp factor eight any other way.
Step number eighteen is “Create Business Rules Classes”. Then the model class can outsource the business rules logic to such a class – remember there has to be an interface above the business rules class, in fact pretty much every class has to have an interface to expose it’s public methods, otherwise you cannot do proper unit testing.
At this point you might think I have gutted the model class like a fish – the database access is done by a dedicated class, as is the business rules, as is anything else I can think of. That, in my mind, is wonderful. That is there is a clear separation of the WHAT (as described in the model class) from the HOW (which is coded in the helper classes). This is in fact, what fans of Functional Programming say is good about FP languages (like JavaScript) – you have to say the WHAT in the code without going all around the houses like I have.
Rescue Me
Talking about going all around the houses I had better go all around the castles soon – I get the feeling that SAP and ABAP and possibly Professor Hasso Plattner might be in trouble in Castle Frankenstein (after three books, I know what the Baron is like), and so I will pick them all up in my autonomous self-flying private Jet tomorrow morning so they can all make it to the SAP Press Gala Party at Castle Dracula on the Tuesday evening. If I leave right now I will probably get there about 2AM Tuesday morning - I hope they will not be in too much trouble by then.
NARRATOR: Meanwhile, back in the SAP Innovation Lab, the Baron had brought his new monster to life, and was busy making evil plans.
BARON FRANKENSTEIN: Now my new Monster is alive, we can all get ready for the Floorplan Manager Show. About 3AM tomorrow morning (Tuesday) would be a good time, and anybody around then will get dragged into it. I can have my man RICEF show you to your rooms so you can get a bit of shuteye before then.
SAP: We don’t want to stay for the night! All we want is to use the co-pilot digital assistant on your smartphone to call for help – a reasonable request which you have seen fit to deny!
BARON FRANKENSTEIN: Ooooh! How macho! (to ABAP) You must be very proud of him!
ABAP: I guess I am.
(Sudden loud alarm sounds, red flashing lights)
RICEF: Master! Master! The refrigeration system for the data centre has broken down. That means the database will come to life!
BARON FRANKENSTEIN: Blue Ruin! It’s not even a HANA database, it is a Relational Database Management System (RDMS for short) and I hate it and everything it stands for!
RICEF: Ready or not, here it comes!
(EXPLOSION)
(A huge hole opens up in the wall separating the stage from the data centre. Enter RDMS driving a Harley Davison (who run SAP by the way) Motorbike)
*----------------------------------------------------------------------------------------------*
Hot Pack R/2 Fruity
*----------------------------------------------------------------------------------------------*
RDMS: Whatever happened to Saturday folks?
When you programmed all night eating pizzas and diet coke
It don't seem the same since ITIL principles
Came into my life, I thought upgrades was simples
I used to do upgrades with a chick who'd go
And listen to podcasts on SAP radio
Buzzwords were flowing on a change control show
We climbed in the back seat, wow, then ran transaction SPAU
Hot pack install, bless my soul
Really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
My head used to swim when reverting to standard
My hands kinda fumbled with one million tons of bananas
I'd taste her baby pink lipstick and then think of HANA
She'd whisper in my ear “I love the upgrade planner”
Get back in front, with make-up she puts her face on
Buddy Holly was singing about continuous integration
With the upgrade complete, you get a huge … well I don’t like to say….
It felt pretty good, woo
Really had zero downtime
Hot pack install, bless my soul
Really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
BARON FRANKENSTEIN: I hate him! I hate him!
RDMS: Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
(Baron Frankenstein rolls out a Howitzer)
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
I really love that change control
Hot pack install, bless my soul
BARON: Bombs Away! (Fires Howitzer)
RDMS: I really love that (BANG!) (Dying Scream)
BARON FRANKENSTEIN: One must speak good of the dead. He’s dead. Good! Now I can get on with preparing for the Floorplan Manager Show. While I’m doing that everyone else can have forty winks – you will need all your energy later. So OK everybody, time for bed!
NARRATOR: Here we leave the horrific events on that – fateful – night. The Baron has made his monster and destroyed his former database. Meanwhile the author is about half way through the downloadable code, about ready to create the model classes. Meanwhile the Baron is dead set on dragging everybody into the “Floorplan Manager Show” whatever that is – and why is he so keen for everyone go to sleep first? You will find out in the next horrific episode of the waking nightmare that is the “Rappy Horror abapGiture show” …..
https://www.sap-press.com/abap-to-the-future_4751/
- SAP Managed Tags:
2 Comments
