Personal Insights
The Rappy Horror abapGiture Show – Part Six
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/
https://blogs.sap.com/2019/03/26/the-rappy-horror-abapgiture-show-part-five/
NARRATOR: I would just like to recap what the state of affairs were in the last episode when we left the horrific events on that – fateful – night, the night before the SAP Press Gala party. The Baron had made his new monster and destroyed his former database. Meanwhile the author was about half way through the downloadable code, and ready to create the model classes. Meanwhile the Baron was dead set on dragging everybody into the “Floorplan Manager Show” whatever that is – and why was he so keen for everyone go to sleep first? You will find out in this week’s horrific episode of the waking nightmare that is the “Rappy Horror abapGiture show” …..
PDH: Here I am in my private Jet, travelling to Castle Frankenstein in the hope of rescuing SAP and ABAP and Professor Hasso Plattner, before the Baron does something horrible to them, so I can pick them up and take them to the SAP Press Gala party on the Tuesday evening. At the speed the jet travels I should get there in about two blogs time, just in time for the finale.
Meanwhile I have just passed the halfway point (18 steps out of 36) in creating the downloadable code for the book, which is just as well, as it has to be ready for tomorrow evening as well.
Nineteen Not Out
Step nineteen is to create the model classes for the various business objects e.g. Monster, Sales Order, Reservation and so on.
Model Classes are a big bone of contention in some quarters. When my first book came out someone wrote a great big series of blogs about the BOPF stating in no uncertain terms that there was no point in a model class.
However many people I greatly respect advocate the use of such classes – Thomas Jung wrote about the concept in his SAP Press book “Next Generation ABAP Development”, and Graham Robinson has defined his tow laws of reusability which go as follows:-
Law One: Encapsulate all business logic in re-usable classes.
Law Two: Encapsulate all business logic in re-usable classes.
I tend to agree that if you follow those two laws then you cannot go wrong. In the book the model classes are used by all sorts of different frameworks – BOPF, WDA, SEGW and the RAP to name just a few. Moreover if and when another framework comes along I can re-use the model class. In the new framework I add some framework specific code to call the model class. The model class does not know or care what framework(s) are using it, and that is as it should be.
As an example the argument was that the BOPF was the be-all and end-all, the final evolution of how to handle business logic in the ABAP world, so what is the point in having a separate model class? As it transpires the BOPF is now obsolete, as I rather suspected it might be one day, replaced by an equivalent concept in the Cloud RAP. Luckily, I could just plug my model class straight into the Cloud RAP framework, which I could not have done if it was welded to the BOPF.
In any event the model class contains the lifecycle methods for the object – the CRUD operations – plus any user commands (actions) and derivations and validations. Often the methods in the model class just consists of a call to another helper class e.g. the persistency layer class or the business rules class, via an interface in every case.
That is, the model class never knows the concrete subclass that it is using, just the interface i.e. description of what functionality is on offer. Thus the model class is separated from what framework the helper class is using e.g. the persistency layer could be using normal SQL statements, or CDS views, or AMDPs or the BOPF or CSV files or anything really, and the business rules class could be using BRF+ or hard code ABAP rules or, once again, anything at all.
On the B side, as I said the model class does not know what is going to be using it, and it will expose itself, as it were, via an interface as well, so the calling framework also does not know or care if a subclass of the model class is being used or not. So there is abstraction all over the place like a mad Monster’s breakfast.
Mr.Tickle likes Unit Tests
As mentioned in prior blogs one of the big changes in this version of the book is the unending focus on automated unit tests, the subject surfaces in virtually every chapter, as this is a big thing for me, I think this is one of the core pillars of the future of ABAP programming – a subject I will be talking about at various SAP Inside Tracks all over Europe this year. Mr. Tickle agrees, he is a huge fan of ABAP Unit and TDD, something which did not actually come across that clearly in the “Mister Men” books.
Anyway, based on this principle step 20 is “Test your Model Class using ABAP Unit”. I have written so many blogs on the subject of ABAP Unit over the years the main one being as follows:-
https://blogs.sap.com/2013/04/18/are-you-writing-evil-abap-code/
The model class is full of business logic of one sort or another, and all of this needs to be unit tested. In fact you write the tests in the local test class in the global model class before you start adding the various methods it needs in order to be called by the assorted frameworks that will be making use of it.
Frank BOPF
Step twenty one is “Create BOPF Business Objects”. Now SAP has announced that the BOPF (Business Object Processing Framework) is obsolete, it has reached end of life before 90% of ABAP programmers have even heard of it, but that is the pace of change these days.
Nonetheless until such time as the RAP becomes the dominant programming model for ABAP applications the BOPF has a central role to play, being the place where the business logic for “entities” lives.
Moreover SAP has “promised” that any BOPF definitions you may have created in the past, or create between now and the RAP becoming mainstream will not be a total waste of time, as there will be some sort of automatic conversion mechanism.
Anyway as at time of writing only 0.0000001% of SAP customers are using the RAP, BOPF objects are still quite important. I want to demonstrate the various ways a BOPF object can come into existence. You can create the definition manually and to demonstrate that the book goes through the process of creating the Monster Business Object manually. One change from the last book is that this time I use Eclipse rather than the various transactions in the SAP GUI.
Manual creation of BOPF objects is a bit “so ten minutes ago” from a fashion point of view, the better way to do this is to auto-generate the business object from a CDS view, so the Delivery business object is used to demonstrate this approach.
Those are two ways of doing this, the Sales Order business object will demonstrate yet another way where not only is the BOPF object generated from the CDS view, but in addition the service which will get consumed by the UI layer.
Mr. Tickle Objects
Mr. Tickle would like to point out that in recent years SAP has created specialised test frameworks for the various different technologies/frameworks you use to create applications in ABAP, and keeps coming out with new ones for the ones that don’t have such an automated testing framework as yet e.g. the “Process Orchestration” system got such a present the other day.
BOPF has an automated testing framework so step twenty two is “Test your BOPF using Bunit”.
This whole approach is somewhat like a production line where each person checks the work of the person before them before doing their particular tasks. The difference here is that our business applications are broken into small components (CDS, BOPF, UI5) and each of those components can be tested automatically in isolation. And end to end test of the entire application is still generally done manually, there are automated frameworks for this as well such as ECATT and HPQC but in the end you are always going to need humans getting involved at some stage, as Elon Musk found out last year with his fully automated Tesla production line, which he ended up ditching and going back to using real people as they turned out to be more efficient.
Thermos O’Flask – he can’t stop going with DYNPROS
Step twenty three may seem a very strange one, namely “Create DYNPROS for Business Objects”. Why would I want to do an old fashioned thing like that in the code base for a book all about the latest technology (i.e. web applications)? Well notwithstanding that I would bet a pound to a bucket of ferrets that as I write ten thousand ABAP developers around the world are at this very instant either making changes to existing DYNPRO applications or writing new ones, this is to prove the framework independence of the building blocks – CDS Views, Model classes and the like.
You still have an MVC architecture, but the UI layer in this case is a function module with a screen inside it. I don’t like the model and the view knowing about each other, so the controller for (say) the Monster Sales Order application calls the function module to show the screen (which has no logic at all, just shows the user the screen and data, and passes back the user actions to the controller) and then calls the public methods of the Monster Sales Order model class to manipulate the data.
What this proves is that the model class can be used by a traditional DYNPRO, a WDA application, the BOPF, a UI5 application, the RAP, and whatever SAP can dream up in the future, with no changes whatsoever. I keep on about this like a broken record, because I think the concept is important, as it gives you a point of stability in a world that changes faster all the time.
What a Tangled Web DYNPRO we Weave
By this point you will noticed that Baron Frankenstein has started to drop hints about his evil plans for his house (castle) guests, namely making them take part in something called the “Floorplan Manager Show”.
Step twenty four is to “Create WDA & FPM Applications for Business Objects”. In the book I go into great detail as to how to create the WEB DYNPRO application to maintain Monster Business Objects, and then do the exact same exercise again this time using the Floorplan Manager.
Once again, just like the traditional SAP GUI DYNPRO example in the previous step, the model class and underlying components are exactly the same. It is just the user interface that has changed – this time the WDA framework handles the controller and view, and the model class is the same as before.
Things are going well. I am up to step 24 (out of 36) and the private Jet is halfway to Castle Frankenstein where I can pick up SAP and ABAP and Professor Hasso Plattner. I would not be surprised if I landed before the end of the next blog. I wonder how things are going at the Castle at the moment.
NARRATOR: That is a very good question. Not well, would be the answer. Newly created Monster Rappy Horror has gone on the run, and the dogs have been sent after him. Meanwhile the Baron has had his servant RICEF show SAP and ABAP to the guest rooms to get some sleep whilst he prepares for the Floorplan Manager Show, whatever that might be.
Once left alone, SAP and ABAP start getting up to what any newly engaged couple would do in the pitch dark – they start coding a business application.
SAP: Oh ABAP!
ABAP: Oh SAP! This code is so great!
SAP: Oh ABAP!
ABAP: Oh SAP!
(Lights high. It is revealed ABAP is not with SAP after all but rather BARON FRANKENSTEIN)
ABAP: You!
BARON FRANKENSTEIN: Yes! How do you like my code, now that you have seen it “under the covers” as it were?
ABAP: I would never … I would never…
BARON FRANKENSTEIN: But it wasn’t ALL bad, was it? What do you think of THIS?
(ABAP screams and runs for the room. In the corridor she encounters RAPPY HORROR)
RAPPY: What is all the commotion about?
ABAP: Baron Frankenstein sneaked into my room pretending to be SAP. Then to make matters worse he showed me something truly horrific.
RAPPY: What was it?
ABAP: It was “The Art of Unit Testing: by Roy Osherove!
*———————————————————————————————-*
Song – Test Me
*———————————————————————————————-*
ABAP:
I was feeling done in, couldn’t win
My programs never worked before
C/4HANA:
You mean she puts untested code into QA, and indeed production, just like everybody else does?
MDG: Uh-huh!
ABAP:
I thought there’s no use getting, into TDD
It only leads to trouble and, regression testing
Now all I want to know, is how to create test doubles
I’ve made a code change that did not cause everything in the whole organization to self-explode once it went into production and I want more (MONSTERS: more, more, more)
I’ll put up no resistance, I want to stay the distance
I’ve got an itch to scratch, I need a digital assistant
Chorus:
Testa, testa, testa, test me
I wanna be bug free
Red phase, green phase, refactor
Tester of the units
ABAP:
Then if anything fails, during the continuous integration process,
I won’t bring production down (MONSTERS: down, down, down)
And that’s just one small fraction, of the main attraction
You need a friendly web based IDE, oh I need actions, validations and determinations
<Chorus>
C/4 HANA: Testa, testa, testa, test me
MDG: I wanna be bug free
C4HANA: Red phase, green phase, refactor
MDG: Tester of the units
ABAP:
Oh, testa, testa, testa, TEST ME
I wanna be bug free
Red phase, green phase, refactor
Tester of the units
RAPPY: Tester of the units
SAP: Tester of the units?
BARON FRANKENSTEIN: Tester of the units……
MDG: Tester of the units
RICEF: Tester of the units
C/4HANA: Tester of the units
RAPPY: Tester of the units
ABAP: TESTER OF THE UNITS!
RAPPY: That was wonderful. Let us go off and make beautiful testable programs together – though the Baron would kill me if he found out!
ABAP: SAP would not think much of that either – but never mind! Let’s do it! (EXEUENT)
(Enter Baron Frankenstein)
BARON FRANKENSTEIN: (To audience) I wonder where Rappy is. I need him for the Floorplan Manager show!
NARRATOR: So there we leave things on that – fateful – night, which is in fact now the – fateful – early hours of the morning of the day of the SAP Press Gala Party. The author is two thirds of the way through preparing the downloadable code, and is in his autonomous self-flying private jet flying to Castle Frankenstein. SAP and ABAP are being terrorised by Baron Frankenstein as he prepares for the “Floorplan Manager Show” whatever that may be, and at this very instant Professor Hasso Plattner is breaking into the castle intent on discovering the dreadful secrets within. What are these dreadful secrets? Find out in next week’s penultimate episode of the waking nightmare which is the Rappy Horror abapGiture show….