Book Review – ABAP 7.4 Certification Guide
SAP Press were feeling a bit sad and despondent that very few people were reviewing their books on the internet. As an example, when my book was published I had only three reviews, one very negative, one very positive and one in the middle.
In fact the latter was about two sentences along the lines of “not bad, I suppose” which whilst not precisely a ringing endorsement could have been a lot worse.
So the new approach is to get SAP Press authors to review other recent releases in their area. So I get ABAP and the other sort of things I write about in my own book, such as UI5. As a disclaimer I get the e-book free that I review.
I have included a hyperlink to the launch page for the ABAP certification book at the end of this blog.
While I may indeed by a certified lunatic I have no formal qualifications in ABAP whatsoever, apart from a few pieces of paper saying I have attended assorted SAP training courses, and an “SCN Topic Leader” award. I am entirely self-taught, over the 17 years I have been doing SAP programming. I programmed a bit in other languages before that of course, starting at age 14. And I have an O level in Computer Science!
Anyway, the launch page for the book under review begins “Getting ready to take your ABAP C_TAW12_740 certification exam?” I love the catchy name of the exam. I hadn’t really thought about ABAP exams, and to be honest did not even know they existed.
To give fair evaluation of this book I would have to picture myself as a beginner, which would be a very difficult task given all those years of ABAP experience would be bound to colour my view. At the very least perhaps I could picture myself as someone who would not be able to get another job unless I had some sort of formal ABAP qualification. I have encountered organisations that value qualifications over experience, so that is not just a gigantic leap of imagination to make.
I will make some sort of attempt to present my impressions in some sort of logical order, but I don’t hold out much hope. I will keep branching off on all sorts of tangents.
This is the 3rd edition of the book, I imagine the exam itself gets updated every so often, and the ABAP language certainly changes rapidly, and that pace of change has gone into overdrive in recent years. I know from experience it is very difficult to decide what older elements to cull – in this case the authors are also constrained by the exam. If the exam asks questions on obsolete technology then of course that technology has to be explained in this book.
I am willing to bet that the name of the exam “e.g. 7.02 certification, 7.31 certification, 7.40 certification” changes a lot more frequently than the contents of the exam.
So it is not that great a shock when I started reading the book and found a lot of references to innovations made in 2006 and 2007. To me that does not seem that far in the past – I still can’t get used to it being the 21st century, it just cannot be, we are not all living in Mars and flying around on Jet Packs – but 2006 is ten years ago now.
In the same way the authors of the book talk about downloading a trial ABAP system onto your PC. These days you would go to the CAL and do the equivalent, which is almost as difficult, but does not take up vast amounts of memory on your PC.
Need to Know BASIS
You can tell a lot about the state of thinking at SAP by what they consider important on their ABAP exam. If marketing were in charge it would all be about products that had been released ten minutes ago, and you would get penalised for not knowing the latest names of all the products, an impossible task as every SAP product rotates at the rate of 1,980 rotations a minute, changing its name during every rotation, whilst emitting a beam of electromagnetic radiation containing the new product name. Or is that a Pulsar?
At the start of the book you are informed of which subjects are more important than others. Naturally we will never know how SAP decided on this weighting; a wild guess would be what would be most useful in the day to day work of a “typical” programmer.
There are eleven categories given in decreasing order of importance, so to grossly over-simplify, anything between 1-6 is vitally important to the future of the universe, and anything in the 7-11 band is a “nice to have” but does not really matter.
As a sample, here are some topics, and their exam weighting (as I said, 1 is most important).
1 is ABAP programming in general (shock, horror)
4 is GUI DYNPRO Programming
7 is ABAP Objects
8 is Web Dynpro
UI5 and other new things like CDS views have not made it onto the list as yet, which is not a surprise, it takes a while for such things to worm their way into the curriculum. I went to an ABAP training course in about 2001 and whilst they mentioned “ABAP Objects” that area was not part of the actual test.
Many years ago the TV advert for the British Magazine “Radio Times” used the slogan “I never knew there was so much in it”. This can be applied to SAP as well, as it is such a vast system with hundreds of developers adding features day after day for decades, you are bound to end up with so much functionality no one person can possible know more than a small fraction of it.
One big benefit for someone like me, self-taught, in reading a book like this is that I find out a lot of new things that could be construed as “basic” and I really should have known many years ago.
I can’t mention all of these “new” things I learned of course, I am not here to repeat the contents of the book, but as an example every day I search for data elements and domains and what have you in transaction SE11. After reading the appropriate chapter in this book I discovered that by taking the menu option EDIT -> SETTINGS from the repository browser, I could control how I searched for DDIC objects i.e. by ticking the. “all selection criteria” box. I had been manually expanding the selection box, every day, for the last 19 years, so I could get all the selection options I wanted, as the ones I typically require are not on the small version of the pop up box. Didn’t I feel like an idiot, but oh well, better now than learning about this on the day I retired.
Moreover the more basic the chapter seems, the more it seems like the sort of thing that of course I know back to front, because I have been working with this day in day out for such a long time, the more likely I am to find a whacking great surprise.
Selection Screens for example – one of the very first things you get to grips with on your first day programming. There cannot be anything I don’t know about that can there? Of course not! But I had just better read the chapter anyway, just to be through, and hang on, what’s that? OH DEAR! Arrrrgggghhhh!
As another example, one of many, I am also probably the last person in the ABAP world to find out about bookmarking lines of ABAP code, bookmarks being like soft breakpoints that you define and can then go back to later. I had first heard of this in ABAP in Eclipse, and had thought “what a great new thing, why can’t you do that in SE80?”
In essence the point I am making is that no matter how much experience you have, you cannot know it all, and sometimes reading a book like this lands you with some useful surprises.
Painter Man, Painter Man, Who want to be a Painter Man?
In regard to the “classical” DYNPRO Screen Painter – the book says the default is the non-graphical screen painter. That cannot still be correct in this day and age – surely?
Testing, Testing, 1, 2, 3
Each chapter ends with a big bunch of “practice questions” which is a test on the contents of the chapter. These are usually multiple choice and are not actual questions you will find on the test, but very similar in nature.
I was not arrogant enough to think that just because I had been programming in SAP every working day for the last 17 years I would be able to fly through the questions, getting them all right. Which was just as well – when I started going through the questions about the ABAP workbench I was in big trouble very quickly.
I knew about half of them straight off – thank goodness – but struggled with a fair few and found some of the questions strange e.g. how many options in SE80 – that must change all the time, as new technology is introduced.
Debugger Me – It’s SLAD the Impaler
Chapter 5 is all about the Debugger. This may seem a non sequitur, but I remember the Monty Python sketch “Salad Days” in which a lot of posh UK people at a garden party have horrible gory accidents and die in agony.
This brings me to transaction SLAD – Software Layer Aware Debugging. I had heard of this many years ago, but never got around to using it.
One thing this book is good at is giving real world examples of why you want to use a particular feature of ABAP – there is always such a real use case at the start of each chapter.
In the case of SLAD we get the perfect example of debugging a user command from a standard ALV function/method. Many times I have had to step through the standard SAP ALV code for handling a user command before the dynamic call back to my own Z program. Naturally you want to be able to jump straight to the Z code. SLAD defines different layers, some of which you can choose to skip over whilst debugging. I am not sure you can have the entire “Z*” space as a layer, maybe you can, that would be ideal.
I wondered why I had never looked into this more. As a test I introduced a colleague who had been programming in SAP for 20 years to transaction SLAD and we both had a look at it to try and work out if, with no training at all, it was intuitive enough that we could find out how to use it to stop at user exists in VA01.
The answer was no, neither of us could work it out! Oh dear! Still, you get clear instructions in the book. I’ll follow them next time I want to debug user command processing in an ALV report, and then share the joy with my colleague.
I was a bit puzzled in regard to the questions about the debugger, and this of course is a reflection on the designers of the SAP ABAP test, rather than the authors who are just trying to prepare people for it.
Half the time you must assume the question relates to the old debugger, but if the question refers to ability the old debugger does not have, then you assume the question relates to the new debugger. Very strange, considering the “new” debugger is over five years old now…. It’s rather like in Australia where we have the beers “Tooheys Old” and “Tooheys New”. The “new” beer was created in 1931. If SAP had been the brewery they would have renamed the original beer to “Tooheys Classic”.
Data Types and Onion
In the examples in the data type chapter, and indeed throughout the book, there is lots of the so called “Hungarian Notation” e.g. MARA_LS TYPE MARA. Now I am not in a position to get on my high horse about this, as my first book was also crawling with the exact same notation, and I made a huge effort to get rid of it for the second edition. Since this is all about taking an official SAP test, and SAPs official position is not to use prefixes, maybe they should not be there.
The book – no doubt because of the exam – says you need to have a TYPE-POOLS statement in your program, but you do not as of 7.02. The exam probably should not dwell on TYPE-POOLS anymore; in the OO world you tend to instead use publically available types and constants from global classes.
Going back to things I never knew, and had not even thought about, up pooped the topic of Text Literals vs String Literals which ae different because they have different sorts of commas around them. The string literal has “back quotes” and spaces are not ignored, whereas when you use the other sort of quotes spaces are ignored.
I had spent hours trying to insert a space while moving various string elements together, and cursing when it kept vanishing, prior to the days of “pipes”.
Now I know what to do, everything works fine though I spent five minutes looking around my keyboard to try and find the other types of quotation marks you can put around a text literal. When written down, or even on the screen they look identical so I had never even suspected there were two different sorts.
Header Line Dancing
We now move on to Internal Tables and the “fact” that an internal table with a header line can only have a line type that is a flat structure. That is mentioned many times. I understand that when preparing someone for an exam and you have an important point you want to get across, saying that same thing lots of times might help it sink in. It may, however, be an idea to say that same thing in a different way each time, to avoid boredom.
Anyway I was not so sure that it was true, so just to prove I was not going mad I did a little experiment:-
DATA: BEGIN OF itab_deep OCCURS 0,
vbeln TYPE vbak-vbeln,
posnr TYPE vbap-posnr,
celltab TYPE lvc_t_styl,
o_log TYPE REF TO zcl_bc_logger,
END OF itab_deep.
LOOP AT itab_deep.
That compiled and ran fine, as well as structures with tables in them you can have object instances in header lines, so I am not sure what is meant here. Some standard SAP tables which use header lines seem very deep indeed to me, with rows that contain tables which themselves contain tables. I am probably not understanding the meaning of “deep” as in the Housemartins song “we’re not deep”.
I can imagine the header lines of structures like the one in the example singing:-
“And I know, and I know, what you think about me,
Thoughts like that sink home,
To you we’re not Deep”
Chapter 8 is all about SQL statements and updating and reading database tables I notice logical databases still get a look in here, as a recommended technique. I think they are supposed to be obsolete? I think the version of ABAP SAP uses for in-house development there are no logical databases anymore.
I had forgotten about transaction SD11 which shows data models and a graphical representation of the relationships. It is probably over ten years since I last looked at it. I imagine these days all those relationships are getting re-implemented as CDS view associations.
The chapter also said those familiar with later releases will know all about transaction ATRA. I had never even heard of it! SAP is just so gigantic.
I was interested in the recommendation not to use the names of transparent tables in user interfaces. I think we are talking about classical DYNPRO here where it was really common to use VBAP as the work area. I think the idea is to use structures instead so you still get the automatic DDIC value helps and checks, but you are insulated from changes to the actual database table design.
Get With the Program
The chapter with the highest “weighting” in the book is Chapter 9 which is all about Basic ABAP Programming.
My favourite bit is at the start when the book says that ABAP supports a lot of language specific features and after release 6.10 – even Unicode! Gasp! This must have been from an early edition, as there is now a dedicated Unicode chapter a bit later on.
To give credit where it is due, there was a very good explanation of the difference between “pass by value” and “pass by reference”, the best explanation I have ever read in fact. The standard SAP documentation in this area leaves something to be desired, it took me ages to get my head around it all those years ago. It suddenly occurred to me you can a parameter called WIND and then get into a heated argument about the best way to pass it. However, let’s not go there.
I did want to put my head in my hands and weep when the time came to talk about how to design the interfaces for methods of classes. In the example you were basically told to raise exceptions in the exact same way as for function modules, and class based exceptions did not get a look in. It took me a long time to warm to class based exceptions but now I think they are the bee’s knees. Perhaps the designers of the ABAP exam are still in the “warming” phase and eventually will start to take exception to classic exceptions.
Talking like you’ve swallowed a Dictionary
We now move on to the ABAP dictionary. The trouble with writing a book is that because you get edited, and this goes through several iterations involving different people making suggestions, at the end of the process I cannot read anything without applying the same sort of rules myself.
It is the same since I started going to “Toastmasters” which is all about public speaking. I now cannot listen to a politician without counting how many times they say “um” and “ah” and use other filler words.
So when I saw a picture of the SE11 screen without instructions as how to get to that screen (i.e. use transaction SE11) I was horrified. I would not have got away with that!
Another thing that drives me mad in any sort of documentation is trying to describe what something is by repeating its name back to you. If you press F1 on a standard SAP field you generally get this i.e. if you press F1 on a field called “Self-Sealing Stud-Bolts” sometimes you just get the name with no description, sometimes you get the description “Self-Sealing Stud Bolts : Stud Bolts which are Self-Sealing” and you are no better off than before.
When I got to the section on how you classify a custom table I got really excited. Some people I know classify custom tables using the customer specific option, because they were “customers” but were never able to tell me what benefit they got from doing that, others just choose “transaction” or “master data” whatever seems best, again without really knowing why, except that transaction data clearly takes up more space.
I thought maybe know I would find out the difference between “master” and “organisation” data and why what I choose mattered and when to use the customer option. As it turns out I found out that the two customer options are provided for the customers and should be used by the customers. I had sort of guessed that already. I see that you need to create your own tablespace or something to store such tables, but I wonder what you would use these for in real life.
The Da Vinci Unicode
Even though this is the least important part of the exam – no doubt because 90%+ of SAP customers converted to Unicode many years ago – I found it the most fascinating chapter so far, as I had never really thought about the subject over and above running transaction UCCHECK or fixing syntax errors.
This chapter does a brilliant job of describing how things work in a Unicode system as opposed to a boring square non-Unicode system, and why you need to do the things you need to do to keep your programs working.
They mention that before SAP Version 3.0 you could not have customer appends on tables. That must have been painful; luckily I started on version 3.0 in 1997, so I have always been OK. Then comes a really good explanation of why you have that annoying “table must be classified” message when checking custom tables or structures.
One thing that drives me nuts is that when you try and classify a structure or table you get a big warning message telling you that you have not yet done the thing you are attempting to do. That is self-evident – if you had already done it, you would not be trying to do it now. Maybe I am a lunatic but I can’t see the harm in adding the classification options to the bottom of the technical settings screen rather than (a) hiding them and then (b) have them jumping on you when you forget to fill them out and try to save the table and then (c) jumping on you again with another warning message when you try and solve the first warning message.
Screen and Screen Again
Now comes the chapter on GUI DYNPRO screens. It transpires that this topic is given minimal weight in the exam and the reason given is “you are not likely to have to write a custom dialog program in a project”.
Sadly my experience is that, even after 10 years of Web Dynpro and its successor UI5, you probably still will find yourself writing such a “module pool” type of program. I fact the usage is still so common I use the DYNPRO terminology in my book to explain new concepts such as BOPF, WDA and even UI5 to an extent, not because they work much like a DYNPRO (they don’t) but because the vast majority of ABAP people are comfortable with the good old module pool design and think in terms of it.
Just as a real-life example in my last project I was tasked with creating a dialog program in the SAP GUI as the initial user interface, but always to bear in mind that one day in the not so distant future people would be accessing this on a smart device. That focuses your mind on separating the business logic from the DYNPRO specific parts of the program, which is a Good Thing.
This chapter gives a fantastic overview of how to write a dialog program; as far as I could see no stone was left unturned.
I learned a shed load of things I did not know were possible in the flow logic and after careful consideration decided none of them were actually that useful.
For instance in the screen flow you can use the keyword VALUES to call a module if the values in a field fulfil a Boolean condition, or do a database read straight from the flow logic and send an error message if it fails.
In both cases this is mixing up UI logic and business logic in a horrible fashion, making the MVC concept scream in agony. As I have said I have never done either, as I did not know you could, and even if I had known I would have steered well clear.
In actual fact a lot of people (thousands probably, all working separately) have created their own DYNPRO MVC framework and just reduced the flow logic to two modules, one for PAI and one for PBO, in an attempt to make something never designed for MVC to work in that fashion. My position is to let the DYNPRO UI do UI specific things like EXIT-COMMAND and not spend half of my life building something that is already there in a “clean” way, so you can try and replicate the functionality of ON-CHAIN-INPUT or similar by using half a million lines of code.
If you have ever tried to debug the ME21N transaction, which uses a sort of MVC framework you will know how agonising this is, as opposed to debugging a normal DYNPRO transaction. There is such a thing as being too clever for your own good – if you do something really fancy but then cannot debug your program easily as a result, and your colleagues cannot work out what you have done, are you in fact better off?
I do try and outsource all the business logic to re-usable classes, for reasons described above.
We are coming up on Re-Selection-Screen Day
I got all excited about learning about something I should have known about years ago called VALUE CHECK.
The other day I had a problem whereby a user putting in an invalid value as the sale organisation in a SELECT-OPTION, due to the good old fat fingers problem, and did not get an error saying it was an invalid value.
I noticed some of our consultants years back did half a million AT-SELECTION-SCREEN events for every field to check for things like this, but that is so much effort very few of us do this.
The ABAP Basics book suggests the following, I did a quick test, it works, but is bog all use.
First of all it does not work for SELECT-OPTIONS
Secondly the field has to be OBLIGATORY
Lastly, it does not work at all in most cases e.g. the one above does not work at all, you can put any value you want for WERKS with no error.
I put “X’ as the plant and “X” as the company code, the plant value is not queried, but the system moans the X is not a valid company code, as indeed it is not. The internet explains it thus, with a great looking web page which looks somehow familiar:-
OO The Places You Will Go
I was happy to see this was not a really tiny chapter, even if it is not an important subject in the ABAP exam. There are still so many people in SAP world, even now, who just see OO programming as a load of old nonsense.
There was a fine explanation of the basic concepts here. One gripe I do have, and this is not the fault of the authors, they are just copying what 99.99% of articles about OO programming seem to do.
This is using a “pun” which is defined in this context as using the same word throughout a chapter or book, that same word having different meanings depending on where you find it. The English language is full of places where this is OK as in the case of the Architect who has a complex about designing complex complexes.
In this case though we have the term “user” meaning different things. Sometimes it is the person in front of the computer who uses the program. Sometimes a “user” is the developer who creates the program. Sometimes the “user” is the program itself.
In the vast bulk of writing about IT the term “user” is short for “end user” being a human who uses the application, so it is probably best to use the terms “developer” or “calling program” for the other two use cases. But no-one ever does.
ALV Grid Lock
This was very good, comparing CL_GUI_ALV_GRID and CL_SALV_TABLE. You still need to use the former, as the latter is not editable, which makes it useless, which of course cannot be mentioned in a book like this.
The elephant in the room with CL_SALV_TABLE is that it does two clever things, creating the field catalogue dynamically and also creating its own screen just like RESUSE_ALV_GRID used to do. Other than that it is about as over-complicated as it is possible to be, with less functionality than its predecessor, which is insane.
Furthermore the powers that be at SAP refuse to admit they have made a mistake, and naturally you cannot take steps to solve a problem until you acknowledge the problem exists in the first place.
I like to spend ages getting the names right on variables in my programs, so I was very interested in a terminology problem the authors had in this chapter when talking about CL_SALV_TABLE. As you may know that class has lots of attributes which are themselves classes, and these classes also have attributes which are classes.
For example the main class has an attribute which is a class describing all the columns and that column class has an attribute which is a table of classes representing each individual column.
Nothing wrong with that, good OO design with each class doing one specific thing, one thing only, and doing it well. However how do you describe this? The authors quite rightly said that although this is a hierarchy of sorts, it is not the superclass / subclass hierarchy as the component classes are not subclasses of the parent class.
They chose to use the terms “superobject” and subobject” to describe the nodes in this hierarchy, which is good enough I suppose, but a bit too close to “superclass” and “subclass” for my liking. These component classes could also be described as “dependencies” as in good OO design the “top dog” class, in this case CL_SALV_TABLE should not do everything itself (acting like a “God Class’) but instead depends (hence the term dependency) on a whole bunch of smaller classes to look after all the individual tasks that it is choreographing.
What a Tangled Web we Blue Weave
Now comes the tricky subject of Web Dynpro. This is not a vitally important part of the ABAP examination as things stand. It will probably become less important once UI5 is added to the syllabus.
I had to write an explanation of how to create a Web Dynpro application in my SAP Press book. This is such a difficult subject to get across, I kept comparing it to classic DYNPRO, even if I knew the two things were not actually that similar and assorted people would seethe with rage at the comparison.
As it transpires the authors of this book start off by saying that the concepts in normal DYNPRO and Web Dynpro are pretty much the same (actual quote “this is similar in concept to DYNPRO programming”) therefore I am not utterly alone in my madness.
Or am I? Right at the end of the chapter, we have the opposite statement “this is a paradigm shift from existing types of DYNPRO”. The term “paradigm shift” is my favourite buzzword bingo word, if I had 5 airline points for every time I heard the term at an IT conference I could fly to Pluto for free. The rule is, if you are sitting listening to an IT presentation and the speaker says “paradigm shift” then the audience has to do a Mexican wave.
At the risk of sounding like a politician both of those contradictory statements are true, more or less. Web Dynpro works in a totally different manner to DYNPRO technically, but on an abstract level the concepts are indeed the same.
Going back to conferences, if the speaker says “game changer” the audience all have to pretend they are in a roller coaster and have just started the downward descent i.e. throw both arms into the air and scream.
This is like the Rocky Horror show when Frank N Furter says “Prepare the Sonic Oscillator!” and the audience all shout “Oh no! Not the Sonic Oscillator!”. SAP conferences are the same as the Rocky Horror Picture show in a lot of ways. If the speaker mentions Uber and/or autonomous vehicles everyone in the audience has to pretend they are KITT from “Knight Rider” and shout “Yes, Michael!” in a high pitched voice.
I was reading the chapter describing Web Dynpro whilst eating my steak and chips, and drinking a bottle of “Dirty Granny” cider, and the more I read, the more one thought kept occurring to me.
There was nothing wrong with the way the authors here explain the various components of Web Dynpro and the way they fit together. They do the best they can, the best it is possible to do, as indeed I tried to, and many other authors and bloggers and all sorts have tried to do.
It is just that the Web Dynpro framework is just so ludicrously, amazingly, incredibly, unbelievably, ridiculously over-complicated and the more you read about it you more you want to cry. Eventually you get to the stage where you understand it, but no-one could describe the process as fun or easy.
Thousands of moving parts, controllers that are not controllers, a framework that tries to enforce the MVC paradigm but lets you get around it. None of this makes you want to dance around the room with joy.
What is strange is how the Web Dynpro framework is very similar to the SE24 programming environment for object orientated programming, yet different in lots of little ways. You do not actually use SE24 for the coding, but something that looks very similar but is just different enough to keep throwing you.
In the chapter the authors mention that you use the self-reference WD_THIS to address a controller, but this is not the same as using the self-reference ME in a normal ABAP class. They don’t say what is the difference, just that it is different. I think to myself, why should it have this unspecified difference, why cannot both use the same mechanism?
The screen painter is another thing that throws people moving from not only the classical DYNPRO screen painter, but from a wide variety of graphical screen painters from lots of different products from time immemorial. In all the “old” ones you drag a UI element onto the screen and where you drop it, that is where it goes.
In Web Dynpro you drop it on the screen and it goes either nowhere, or decides where to go itself based upon what is already on the screen and the general settings for the layout. With subsequent graphical screen painters e.g. BUILD you are back to actual drag and drop once again. Welcome back, I say!
Everyone sees things differently but I found the learning curve for UI5 so much easier than for Web Dynpro, about 10% of the effort, and that involved having the view and the controller in different languages than ABAP!
Up Cast Top Ranking
Back we come to the subject of object orientated programming. This time however the whole world has changed around us. Earlier in the book the exam did not seem to give two hoots about OO programming. Now suddenly it is the most important thing in the world:-
“there will be a higher percentage of questions covering this chapter than any other chapter”. This is because of the direction of the ABAP language. Well I cannot argue with that – that direction was set in stone in the year 2000 and has not changed ever since.
So now is the time to learn about inheritance and interfaces and the like. Everything is explained very well though an example of where a singleton would be a good thing rather than saying “sometimes it can be” would have been a plus.
I have found that people don’t embrace OO just because you tell them it is good. They need practical examples. Still this book is all about preparing to answer questions so maybe you don’t need examples, but they can’t hurt.
I would like to give a gold star to the explanation of upcasting and downcasting. This does have examples and very good examples at that. Of all the OO concepts this is the one I struggled with the most at the start and it took me years to get my head around the need for it.
I saw it (upcast / downcast) all the time in the RTTI classes and sang the following song:-
“I wake in the morning and I go outside (to do some programming), and I take a deep breath and I get real RTTI, and I scream at the top of my voice “What’s going on!”
If I had read the explanation in this book near the start of my OO experiments life would have been a lot easier. Of course these days “Upcast Downcast” has been replaced by “Downton Abbey”.
Enhancing, with Tears in Our Eyes
I am glad to see the exam has a section on user exists and other forms of enhancing standard SAP. Everyone does it, after all, so it is no use sweeping this under the carpet.
This chapter was a very comprehensive guide to all the various user exit techniques, right from good old MV45AZZZ to the enhancement framework. I liked the explanation of what enhancement spots and composite enhancement spots were all about. That concept can make your head spin, us old school types just are not used to such ideas, and a leopard cannot change its enhancement spots.
One thing that puzzled me was several times in the chapter there was an implication that you, as a programmer, invent the signature for BADI methods, as in the following quote:-
“you can work only with the data supplied by the method parameters for enhancement, which you define”.
Possibly something got lost in translation there, as far as I am aware a BADI has a defined interface, and you define methods of a class that implements that interface. You cannot go around changing global variables willy-nilly like you can do in MV45AFZZ. If the interface method says the method can only change the values of the scrunges, then you cannot add a new parameter to change the value of the widgets. Unless I have missed something really obvious?
Did I Build this Table Relationship to Wreck?
The final chapter is all about the host of in-built goodies that the ABAP environment allows you to attach to data elements – search helps, check tables, parameter IDs and the like.
I use these so often it is easy to forget how good the whole thing is. Life would be agony without them. Naturally all of this is DYNPRO based, so it is naughty to keep on using such things. You shouldn’t be using a DYNPRO application in the GUI at all with all this in-built tool support, you should be coding it all yourself in your UI5 application.
There was a very good explanation of the “cardinality” fields that pop up when you create a foreign key relationship for a table field e.g. 1:CN or whatever. The system lets you leave the boxes blank, so most people do, including a load of SAP developers by the looks of things. I always used to leave them blank, as it did not seem to make any difference.
Knowing what the fields mean is a good thing, and whilst it might not make a difference in the grand scheme of the universe whether these fields are full or not, having the correct values in them gives me a warm fuzzy feeling.
Another point raised in the chapter, something SAP do all the time, but most “customer” sites do not, is to attach a search help to a check table. This can help the in-built F4 drop down support like nobodies business. A lot of people do not even know the “extras->search help” option is even there when defining a transparent table.
Now is the time for a quick summary. As you no doubt noticed I spent most of these blogs bouncing around related matters, as each topic made me think about assorted ABAP matters.
I saw a book review on Amazon which said that this book was such that no-one could understand even a single chapter. I think that was a bit harsh, I would say that if you cannot understand the contents of this book then not only would you not be able to pass an ABAP exam, but you would be hard pressed to do any sort of ABAP programming.
The authors have to follow syllabus of the ABAP exam, which at times seems a bit bizarre, and behind the times, but since the vast majority of SAP installations are quite behind the times as well that is probably a good thing.
In conclusion I would say that for absolute newcomers you may struggle a bit with the vast amount of information here, for people with a small amount of practical experience (e.g. consultants learning on the job at customer sites – do consulting companies still do that?) this is probably just the thing to bring you up to speed, and for experienced self-taught programmers like me, you would be amazed at how many “basic” things you didn’t know.
This week I have been mainly eating carrots. The next book to be read/reviewed will be the SAP Press book on Gateway/ODATA which I will no doubt pepper with observations about the actual real life usage of that technology I have encountered in my day job.
The King is a Hyperlink