The Loch Ness MONSTER
Writing a Book for SAP Press – Part Four
Table of Contents
To Be Continued
Back Back Back Back, Back to the Start
I have been writing a series of blogs about writing a book for SAP Press, a book all about the woes of being a programmer in the employ of Baron Frankenstein. The latest ABAP features also get a look in as well. The last such blog was:-
I am trying to get through this as fast as I can, but I have been delayed by a disaster. When I first joined SCN (SDN as it was then) back in about 2001, the only way to do so was by using your “S” number. The problem is, what if your S number ever changes e.g. you move jobs? In other words a disaster waiting to happen, especially now we have “gamification” which encourages us to get “points”.
I have not moved jobs, but my company did move from regional licences to a single global licence (3 years ago) which meant I got a new S number. I did not notice, but after 3 years SAP cancels dead S numbers, so that was that for my poor old SCN account.
It might seem childish to miss all those points I had amassed, about 3000 odd, and start again with the one point for setting up a new account, but it was not as if there was any choice. However the good news is that SCN are working on a way to “merge” dead accounts with new ones when this happens.
Anyway that’s my problem, not yours, so let’s talk about some exciting new SAP technology and why I felt it vital to the future of the universe to talk about this in print.
In earlier chapters I had talked about unit testing and static code checks, to try and pre-empt bugs before the program was ever run. However there are always going to be bugs, which is why we programmers (yellow shirts) spend so much time in front of the debugger. As you all know with the advent of ECC 6.0 we have the “new” debugger with all sorts of extra functionality.
In the West Country of England where I grew up it is quiet common for a stranger to walk into a pub and the whole place stops talking and looks at them in a threatening manner. Then someone will come up to them and say “we don’t like unfriendly strangers in here”. It is often the same when SAP developers encounter some new technology like the “new” debugger when it walks into the room.
As a result many developers switch the new debugger off on the day after the system is upgraded and they see the debugger has changed.
In the same way there are four billion bacteria in the room you are currently in, the programs we write are always riddled with bugs at the start, hopefully not four billion – though with some program I have seen I wonder.
If someone tells me a program I have written does everything that was desired with no errors the very first time it is run in DEV or QA I am deeply suspicious, it is rare that anything works perfectly first time.
As a result we expect the first few tests – by ourselves or others – to return unexpected results. Hopefully we first see these as a result of failed unit tests before anyone else goes anywhere near our lovely new application, giving us a chance to fix the problems in our code before anyone else can pick them up and sneer at us.
Then it is time to sit in front of our program, type in /H to start the debugger and sit in front of our screen for hours stepping through the program a line at a time trying to work out the exact point where everything goes horribly wrong.
I once heard our BASIS department get a request from an HR consultant to extend the time before a debugger session times out from the default 45 minutes. If you need to spend more than 45 minutes at a time debugging a program then “something is rotten in the state of Denmark” as someone somewhere once said.
Where be that problem? I be after ‘e. It be up that Wurzel Tree and I be after ‘e.
As mentioned just now, in version 7.02 of ABAP the debugger changed dramatically. The look and feel was so different a lot of people looked for the option to change the debugger back to the way it used to be, set that flag, and then forgot there was ever such a thing as the new debugger. Tempting as that is I tend to feel that hiding your head in the sand like an ostrich is not going to let you take advantage of the myriad of added features in the new debugger, of which I think debugger scripting is one of the most useful.
Why are things always in the last place you look for them?
Because you stop looking when you find them.
— Children’s Riddle
Let us have a look at a pretty picture of what we tend to do whilst debugging.
Figure 1: Debugger Timeline
As can be seen the vast amount of time is spent debugging.
It could be said that spending 80%+ of your time looking for the problem is a horrible waste of time, even if it makes you feel like Sherlock Holmes. It has been suggested that Starship Captains, when menaced by aliens, should think of the last thing that could possibly work, and then try it first, to avoid wasting time, and in the same way if we could knock off some of the squares on the left and discover the problem sooner, then the day would be a lot less boring and we could proceed straight to the code writing activity that we love more than life itself.
The Robots of Death to the Rescue
Doctor : What do you do? What do any of you people do when you have a job that is too difficult or too boring for you?
Investigator Poul : I call for a robot….
Doctor Who and The Robots of Death – Terrance Dicks
The other day I was asked to check if there were any materials with duplicate legacy numbers (BISMT, as in Admiral Nelsons dying words to me which were “BISMT Hardy!” ) in our development system. I could have just dumped out table MARA in a spreadsheet, sorted the data and done a formula to compare each cell value with the one above it. That would have worked but I course I didn’t solve the problem that way – I am a programmer so I wrote a quick program to do the exact same thing.
If I can possibly solve any sort of problem by means of writing a program then that is the route I take. Let us say you have got to the situation where you know something is wrong with your program and are merrily debugging it. The fifth time you are in the debugger and find yourself doing the same steps, with no end in sight, you start thinking how boring this is and wishing you could make your life easier.
Solving this problem is what debugger scripting is all about, so I felt a small chapter on this subject in the book is the way forward. I wonder if anyone except me and my matey Brian O’Neill is actually using this. If you are please share what you think. I myself think it is so good all the programmers in your organisation should jump up out of their cubicles and do a Bollywood style musical number down the corridor singing the virtues of this “new” technology.
I want it all, I want it all, I want it all. And I want it now.
That about does it for testing, notice the first five chapters of the book – a third of the book – are all about improved development tools and quality control, or to put it another way “writing code fast and writing it right” the idea of which should make management types bounce up and down with joy i.e. the faster you bring the new thing to the table the more money the company makes.
In regard to the company making more money because of the programs you write, I read a blog by Chris Whealy the other day about Functional Programming
His position (I think) was that Functional Programming languages as pushed by universities were all about “purity” of the language i.e. “you do all the right things for all the right reasons” whilst imperative languages like ABAP were all about “making money. Mind you some CFOs view IT as a cost centre which can never have any sort of positive benefit to the top line.
I may have utterly misunderstood the above blog but I wonder if it is possible to square the circle. Is it possible to still make the money for the company (or make Government more efficient thus costing taxpayers like me less) by doing things right in the first place? Even more, can doing things right even make your programming faster than the traditional quick and dirty way? I hope so, which is why I focus so much on quality control.
User Exit – Stage Left
The first section of the book was all about programming tools, but I could not let you go without giving you a “game for a laugh” badge and mentioning something that has been around for a while now but was not mentioned in the “Next Generation ABAP Programming” book, namely the Enhancement Framework.
I think that (Enhancement Framework) is the bee’s knees, though some development departments in assorted companies ban the use of this. As an actual use case, here is what I had to deal with:-
As an example when creating a sales order via the standard VA01 transaction if you press the “create with reference” button then the default tab on the popup is to create the order with reference to a quotation. Once upon a time the business users wanted the contract tab to be the default, but after some debugging I found that what tab popped up first was hard coded (at least in the version of SAP I was using) as opposed to being read from a customizing table, and at that time there was no user exit to change this behaviour. So we had to live with it.
Enter the Enhancement Framework and you can insert some code in the standard so this does in fact read some sort of customising table rather than following hard coded rules.
As can be imagined many companies have found that standard SAP programs almost exactly fit their needs, but need one or two tweaks, so the desire was to somehow change the standard SAP program. User exists solve the problem to a large extent but as you might have noticed they are not everywhere that every single company in the world might need them, so the answer was to do a “repair” which is in fact anything but a repair it is changing standard SAP code. I’d just like to stress that in the vast majority of cases you can get round modifying standard SAP but sometimes you just have to do this as there is no other way of satisfying the business.
A long time ago SAP used to recommend you take a copy of the standard program, creating a “clone” that started with a Z, and then make your changes there.
As this was official SAP policy at the time many SAP customers did just that, and created an army of cloned programs. Then SAP belatedly realized this was the worst thing you could possibly do, as during an upgrade the original program would change (bug fixes and extra functions) but not the clone. Then came what can best be described as the “clone wars” with customers writing “clone hunter” programs, which eventually became part of standard SAP.
The revised policy was not to have clones, but to use the modification assistant to insert your changes directly into standard SAP code. Then, during an upgrade the SPAU process would recognize such changes and make you decide if you wanted to keep them or not.
This was a lot better, but if you have a fair number of such modifications to the standard system (and a lot of companies do, even ones with a “no modification” policy) then at upgrade / support stack time the SPAU process can take quite a while.
The enhancement framework can drastically reduce such overheads at upgrade time by replacing such modifications with enhancements. It is more than possible you could virtually eliminate the SPAU overhead during an upgrade or support stack application. As a specific example the form based user exits like MV45AFZZ are based on you modifying a standard SAP program, so at support stack time they have an alarming habit of removing all the code you added and on rare occasions this does not even show up in SPAU. Adding the code using enhancements rather the modifications is a lot safer.
The needs of every company vary dramatically so it is impossible to give a specific example that is useful to everybody, but here are a few potential ways to replace “repairs” with enhancements.
· Let us say we have a standard SAP executable program which makes vendor postings, let us say the ERS process, but the document date is hard coded to today’s date via SY-DATUM. You want the flexibility to able to choose the posting date. You could use the enhancement framework to add some code right at the start of the program to add a new parameter for the user to input the date. Then at the start of the FORM routine which makes use of the posting data you can change the value of the variable that holds that date to the value of the input parameter.
· You may want to add extra commands to a standard SAP screen or menu for whatever reason. Adding the button or menu entry is always going to be a modification, outside of the Web Dynpro framework. However, responding to that new button or command does not have to be a modification. Usually there is a CASE statement in the SAP program to respond to the various standard commands, and 99 times out of a hundred there is no WHEN OTHERS at the end. This means you can add an enhancement at the end of that routine with a new CASE block to respond to your new command.
As can be seen the possibilities are almost limitless. I think this is one of the best tools SAP has ever given us, but to use the phrase “not only, but also” there is another side to the enhancement framework.
I have written a whole bunch of blogs on how to try and design an SAP system for use in multiple countries.
The answer there was to use BADIS (which go in and glove with the enhancement framework) so you can have a core system that is the same for all countries and yet each country can still do all the country specific weird things it wants to do.
When a country wants to change something, the new functionality is added, but the core program is not changed. This is a staple of OO programming called the “Open-Closed Principle”.
If you were to read any books on object orientated programming this principle would jump you at you almost at once.
In essence the idea is that you have a program that works perfectly and any change to that program might break it, so therefore you don’t want to change it. However you have been given the job of giving that very same program some extra functionality.
So the open-closed principal is all about making the program do something new without changing it. That’s obviously impossible you would think, so much so that when I explained this to one manager I could see he was thinking about committing me to the nearest madhouse.
When you look a bit deeper you will however see that SAP programs can be made to do different things by changing customizing values or implementing user exits – and all of this was well before SAP even looked at trying to be object orientated.
Warning! Warning! Danger Will Robinson
At long last it is time to turn to the business logic of programs, but once again I cannot stop myself going into broken record mode and turning back to the subject of quality This time I felt the need to waffle on about exception handling, specifically exception classes which I am not convinced many people are using, despite them having been around for ages.
There is nothing much I can say here which I did not say in the following blog:-
Earlier chapters talked about how you can prevent errors in the first place, errors in the program itself. Here I talk about the concept of “Design by Contract” which is designed to root out program errors before the program hits production, and also the normal use of exception classes which is (a) to handle situations which are “impossible” but you suspect might happen anyway, and (b) situations where things go wrong which are totally out of your hands but the program must react to anyway.
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.
I got interviewed the other day by a chap from the American SAP User Group (ASUG)
Have a look at the comments at the bottom. Some are very strange indeed, clearly written by some sort of automated comment writing robot.