There is a MONSTER in my pocket!
Writing a Book for SAP Press – Part Five
Table of Contents
Background
Business Object Processing Framework
BRFPlus
Exception Handling
To Be Continued
Background
This is the latest in my series of blogs about writing a book about monsters for SAP Press. They insisted it should be all about monsters and I had to fight tooth and nail to get some mentions of the latest features in ABAP inserted here and there. The last such blog was as follows:-
http://scn.sap.com/community/abap/blog/2015/04/25/the-loch-ness-monster
As might be imagined it is becoming more and more difficult to find blog headings with “monster” in the title, but hopefully I am going to run out of chapters before I run out of monster headings. I’m half way through already should I should be OK.
As mentioned in earlier blogs SCN does not much like people doing big adverts for their own book e.g. just saying “look at this” and then listing the table of contents. So I have been focusing more on the actual process of writing a book i.e. deciding what to add and what to leave out, and putting in material that was cut from the actual book due to lack of space. My original manuscript stretched to the moon, and so had to be edited down a bit.
In earlier blogs I talked about the reasoning behind the chapters in the first section – developer tools. Now we move to filling up the next section which is all about business logic.
MMMBOPF, Ba Duba Dop
When writing a list of exciting new SAP tools from the last few years, the “Business Object Processing Framework” (BOPF) sprang straight to the top of the list. The interesting thing about the BOPF is that it arrives via a support stack as opposed to by an upgrade. Where I work we have a 7.02 system and the BOPF arrived last week, as a side effect of upgrading the support stack level of the “business suite foundation”.
This cannot be stressed too much – support stacks now add extra functionality, which was not previously the case.
Anyway the problem I had was that the series of blogs by James Wood about the BOPF were so amazingly good,.
http://scn.sap.com/community/abap/blog/2013/01/04/navigating-the-bopf-part-1--getting-started
How could I write anything on the same topic without looking like the biggest plagiarist in the universe? He seemed to have covered everything.
Buddy, Can you Spare a DYNPRO?
Since I had to take a radically different approach I thought I would compare the BOPF to traditional DYNPRO programming as opposed to the OO way of looking at it. This is the sort of approach which could get me tarred and feathered – you will hear the six guns sound, as they drive me out of town.
What’s so good about BOPF anyway?
I like to start any discussion of a new tool not with the the “how to” but the (to me) more important “why” as in “why is this framework better than the twenty million frameworks that came before it?” The clue is in the fact that there have been so many attempts previously.
The History of SAP Business Objects
For the sake of argument let us say I have a new custom object type – a monster – that I want to set up in SAP. There are a wide variety of ways in which I could go about this. Let us examine them briefly one at a time, starting with the oldest.
In every case the idea is the same – this is the “model” in our “model – view – controller” framework, a model contains the business logic as to how a particular real world object behaves and what attributes it has.
Let us look at the “Famous Five” frameworks that preceded BOPF, try and work out which one of them is Timmy the Dog ( he’s so licky ) and then see that BOPF is proud to be the sixth in the series.
SWO1 Business Objects
I am a big fan of SAP Business Workflow (which was laughingly renamed “webflow” briefly during the dot com boom) and that works using business objects defined and maintained using transaction SWO1.
This is the earliest example of an object orientated framework in SAP with attributes and methods and events, and even inheritance as you can “delegate” the standard SAP business object like a purchase order to your custom version and programs that call the standard object start using the custom one without knowing.
Nobody could argue this approach was perfection itself but it did a really good job especially considering how long ago this was created.
BAPIs
If you call transaction BAPI you will see a tree where you have a wide variety of business objects, each one either represented by an SWO1 business object or by a BAPI set of function modules.
Business Application Programming Interfaces (BAPIs) were created with an external view in mind i.e. an external system wants to created / read / update / delete sales orders in SAP and needs an interface (signature) so that it can provide the needed instructions in the correct format.
The problem here was that the signatures were amazingly complicated (in order to try and give as much functionality as possible) and were (with a few exceptions) very poorly documented, the naming conventions were all over the place, and they still did not deliver all the functionality you could get by doing a BDC on the standard transaction (to be fair replication all online functionality was probably impossible for sales orders).
Nonetheless this was a still usually a step up from BDCs for performance reasons (no need to render the screen in the background) and 99% of the time they did not break during an upgrade (I had some grief with the purchase order BAPI moving from 4.5 to 4.7).
Classes
The day dawned when the tasks in workflow had two options for picking which objects you wanted to use – traditional SWO1 objects or custom classes you define yourself using SE24. Your custom class had to implement a few interfaces and the workflow system could then talk to it.
Apart from the perceived absurdity of having two frameworks that looked almost identical doing the same thing, there were still some gaps in that the new Z classes could not do everything an SWO1 object could within the workflow system.
This led to crazy situations, like the time that, because of one such gap, I created an SWO1 object and then delegated every method to an equivalent SE24 class.
In addition a lot of people have wondered why SAP did not create a series of classes to represent the same objects that SWO1 covered – sales orders, purchase orders, leave requests and so on.
Instead you get the result than ten thousand different programmers create a ZCL_SALES_ORDER class (I know I have) in their own system, all different to a smaller or greater degree.
This has led to “Project Objectify” an open source project on SCN which was first postulated by Matthew Billingham and then taken up by Bruno Esperança to try and unify all these disparate efforts to a uniform set of classes for business objects.
http://scn.sap.com/community/abap/blog/2014/03/22/project-objectify--continued
This is not actually at odds with the BOPF, as we (I would like to get involved in that project) want to develop a set of business object classes that can be used with any SAP business object framework – past, present or future.
Persistent Objects
The SAP database model was not really designed with OO programming in mind. To address this gap SAP came up with the idea of “persistent objects” which was a framework that provided a uniform way to handle transaction processing for classes that represented real world objects – locking, database updates, queries and the like. This was also known as “object services”.
You will see in SE24 there is a flag to enable a class to be persistent (instances can be saved in the database) which makes the class implement IF_OS_STATE and generates some “co-classes” to enable your new class to work with this framework.
A whole SAP Press book has been written on this subject, but this concept does not seem to have caught on as well as SAP would have liked. Many people perceive this framework to be over-complicated and crawling with limitations e.g. at one point data structures had to have their fields be in alphabetical order for some reason.
CRM Business Object Layer (in ERP)
Not everybody has the SAP Customer Relationship Management (CRM) system implemented, but if you have an ECC 6.0 system you may be surprised to know that the CRM “Business Object Layer” (BOL) has found its way into the core ERP system.
If you go into transaction SE80 and look for package CRM_BOL you will see the whole framework sitting there quietly, with most programmers blissfully unaware of its existence.
In contrast to the persistent object framework I have never heard any programmer say anything bad about the BOL. If anything programmers who have worked on this in a CRM system wax eloquent about how this is the greatest thing since sliced bread.
Again it is pointless to go into detail here except to bring to your notice that this exists, and to stress just how many ways there are in SAP of achieving the same thing,
BOPF
The Business Object Framework came in with ECC 6.0 EHP5 “Business Suite Foundation” Support Stack 11, SS5 in EHP6 and as standard in EHP7. It is also used in the SAP product “business by design”.
This has the same aim as all the previously mentioned business object frameworks generally and in particular the persistent object framework / object services – to not only provide a representation of a real word object within SAP but to also provide a uniform way to handle things like authorizations, transaction management, locking and so on.
In summary the main benefits of BOPF are to automate certain areas which you would usually have to code yourself whilst writing programs, and to give you a clear place to put each piece of functionality, separated in such a way as to make your program more “anti-fragile” i.e. resistant to change.
I would also like to briefly touch on two of the benefits not related to coding a transaction – integration with the persistency layer (shared memory) and UI layer (Floorplan Manager).
Use of Shared Memory
I would guess that 99% of the time you would want a business object to be persisted in the database, but it is also possible to have BOPF objects that live only in shared memory.
I have yet to see many practical uses for this, but as always it is good to be aware of the possibility.
Integration with the Floorplan Manager
Do you remember the song “I Spy for the FBI”? In this case FBI stands for “Floorplan Manager Business Object Integration” i.e. it should really be FMBOI but that would take all the fun out the acronym.
This lets you create a Web Dynpro application for creating and maintaining instances of your BOPF business objects with dramatically less coding.
SAP also claim that their “target architecture” for the future involves something similar to the FBI which will integrate BOBPF with UI5 in the same way
.
BRFPlus
When I worked in Heidelberg at lunchtimes I used to go to the beer garden round the corner, and whilst eating my chicken wings (or Flammkuchen) I would be reading the book by Carsten Ziegler about BRFPlus, the Business Rules Engine., which promises to replace the IMG, the condition mechanism for pricing and output, and the internal combustion engine, all whilst giving “the business” greater ownership of their own business rules.
Probably because Heidelberg is just up the road from Waldorf, none of the middle aged guys who were eating their lunch at that drinking establishment seemed to think it odd I was reading a book with a big SAP logo on the front.
Whilst I was gone our Australian subsidiary upgraded to ECC 6.0, so as soon as I got back I was bursting to find a problem worthy of the attention of BRFPlus. None of my colleagues had even heard of the thing, and had no idea it was sitting there in the system, ready to use.
I did in fact find lots of valid business uses for this, so it had to go in the book, although BRFPlus has been available since version 7.02 of ABAP so it some sense it is not “new”. Nonetheless it is evolving at a breakneck pace, my understanding is that at any given time there is a huge backlog of features to be added which a team of SAP developers are working on.
In case I completely stuffed everything up (i.e. everything I wrote turned out to be wrong) I sent my draft chapter to Carsten Ziegler himself, and he was kind enough to not only review the chapter but also arrange a screen share session so I could look at the development system in Germany and have a sneaky peek at the future of BRFPlus.
He also put my mind to rest on the two areas of BRFPlus I was worried about – namely performance of the tool in general, and ease of data entry.
BRFPlus lives inside the ABAP system but the front end is Web Dynpro which makes it look a lot different to the IMG or similar SM30 type transactions where you are used to entering data for business rules. I had horrible performance problems using BRFPlus at first, staring at a big whirling circle for minutes on end whist entering data. It turns out that most of that is a one off hit the first time a screen gets called up, the same way you get the “compiling XXXX in a different session” message when you start doing SAP GUI transactions after a support pack installation.
The remaining performance problems are constantly under investigation and get addressed in the huge bunch of OSS notes that come with every support stack. The runtime of BRFPlus is never going to be an issue, the rules get compiled into ABAP code when first accessed and thereafter involve no database access at all.
My other concern was the ease of data entry – filling out a decision tree, or a line in a decision table seemed to take an awful lot of button clicks and drop downs compared to the IMG/SM30 equivalent. If BRFPlus is going to take off it has to be just as easy or easier to use as the thing it is replacing – just like OO programming is easier to use than procedural programming (tee hee hee)! Once again, the team at SAP are on the case, investigating an easier way to enter data.
A lot of people have squawked like a duck because in its natural form you cannot change business rules directly in production, whereas in the past with Z tables the developer has the choice to enforce changes being made in development and transported through the landscape, or to have the table able to be directly maintained in production.
SAP might say to us customers - “why in the world would you want to change data directly in production”. A lot of customers would answer “because we do” which in the end is the only answer that counts. If someone has the ability to do something they want right now, and you are trying to convince them to take on a new tool which can’t do the thing they want, you are not going to get very far.
I will give a concrete example – in my company we have a table which controls which plants have certain interfaces active. If the device at the plant breaks down you need to switch the interface off right there and then, to enable manual entry at the plant of the information which was coming from the device. Waiting a day for a transport just will not cut the mustard. So we have a Z table controlled by the helpdesk which can switch an interface off directly in production.
It’s the same with a table which says what raw materials come from which quarry. If we have a huge cyclone like we did the other day, the power at the quarry goes out along with the phones, and we may wish to change the table to another source of supply right there and then. If we had to wait for a transport, by the time it went through the rain would be over, and the quarry back on line again, and then we would have to do another transport to reverse the change. In the meantime any plant relying on that material would be stuffed.
The other day a blog came out explaining one way to maintain such rules in production:-
You can see in the comments at the bottom that another way is to use the separately licenced product “Decision Services Management” which lets you do a remote simulation of the effect the change will have before it hits production, approval etc. Lovely, but it costs extra.
At my company we built our own application to do this (simulation / workflow approval) because it was deemed cheaper than buying the DSM licence. I am sure Carsten would be amazed that we did this. Mind you the programming bar at my organisation is very high – much as I like to blow my own trumpet I am not even the best programmer, there is another guy ten times better than me. Not every organisation is in that position.
Regardless, I think BRFPlus is the future of IMG type rules, and my chapter on the subject was probably the one I was most satisfied with in the whole book.
To Be Continued
To end with the same paragraph as the prior blogs on book writing, in subsequent blogs I will continue to talk about the thought process behind how I chose what topics to include in the book, enriched with some content that was cut from the final version of the book for reasons of space.
Cheersy Cheers
Paul
https://www.sap-press.com/abap-to-the-future_3680/
PS I think the “Timmy the Dog” award should go to Persistent Objects.
- SAP Managed Tags:
8 Comments
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
