The cult of the SAP error message

[Former Member]

Albert Einstein must have been using a SAP system to get his insight:
"Insanity: doing the same thing over and over again and expecting different results"

Often, I find myself reminded of this scene. I am getting an error message which simply refuses to vanish. Remembering Einstein I try all different kinds of variations, much to the indifference of the error message. SAP systems are quite flexible, so typically you have lots and lots of options you can try. So you need persistence and creativity to finally discover the one (and only?) way which circumvents the error. I don't mind if my "solution" is paradoxical as long as I can continue my work.

Scripture Studies (RTFM)

Playing around with the available options cannot be a good approach. We are trying to be professional, aren't we? So why don't I just follow best practice and RTFM (read the fine SAP manuals)? There are really lots of really helpful SAP guides to different topics and there is also the SAP online documentation. I know about that and I DO use the manuals, but what about ERROR MESSAGES? Does SAP document error messages? If yes, where? The answer must be of course: "It depends."

There is a whole slew of different kind of SAP software. Many products were once developed outside of SAP and bought up or otherwise incorporated into the SAP universe. And what is the best place to study their distinctions? By researching where/how they write error and log messages! There are exemplary cases like e.g. MaxDB. From a database you expect a sound design and philosophy of its message logging together with a public availability of their documentation. A database wouldn't be taken seriously otherwise. And then there are cases where we could start a heated discussion. Are SAP syslog messages documented? I mean really documented? I mean for people with S-users, not C-users? And what about the BR*tools? They have some structure in their error messages, a section "explanation", "program response" and "user action". Sounds great, doesn't it? When I read such a brilliant user action "Correct the error and retry the operation" I somewhat start doubting the usefullness. On the other side, I would be really glad if every SAP component would have such a good message documentation like the BR*tools!

The Gatekeepers

First of all, when you encounter a problems with SAP, you have the option of opening a support call. Sounds reasonable, right? Not sure. I always have a strange feeling when opening a support call. After some time you'll be familiar with the correct message queue to put your call in, but this doesn't help much. Because much more important seems to be the correct message priority for your support call. Of course everyone would like to open his/her calls with priority 1, so you need a really good explanation why you want to open a priority 1 call for your (productive) system. There seems to be some tendency to open priority 2 calls for all the rest, especially if you consider the somewhat sluggish response times from the 1st level support. I once started my SAP carrer as a 1st level support agent myself, so I guess I am familiar with the specific setup of support organizations. However with SAP you'll enter what I call the "priority lottery". Quite often opening a well formulated priority 4 call provided a much faster solution to my problem than fighting through a priority 2 call. Worst of all seems to be to use the "speedup" feature via the telephone hotline. If your support call already made up its way to the top of the priority 3 queue and is manually moved to the priority 2, it will start at the bottom of that queue, so you cannot expect much gain from this change.

Having worked on support calls myself, I know of the importance of providing relevant information for the processing of calls. SAP even provides the possibility to list which SAP notes have already been checked and were not helpful. So I wonder why time and again I get answers from 1st line support about irrelevant SAP notes. I wouldn't mind the questions much, but the waste of time is often really frustrating.

Time is the central issue with support calls and being stuck in 1st line support is the worst issue you can have. I even have heard of normally really polite people who get deliberately rude on 1st level support people in order to get a faster escalation to 2nd level support. That's nothing I can approve of, but it is understandable. I cannot prove that by hard facts,  but lower level support people seem to be fond of playing a game called "call ping-pong".

The Keepers of the Holy Grail

Much of SAP's ERP success might be attributed to it being open source. Of cours the ABAP code is copyrighted by SAP for very good reasons, but being able to fix bugs manually, improve code or analyzing specific issues with SAP's ABAP coding without the help of SAP is impressive. I don't advocate to release all sources or internal documentation, but for me there seems to be a strong tendency by SAP to keep documentation on error messages internal. (Higher Level) SAP Support is the keeper of the holy grail and all you get is sometimes a glimpse of their encyclopedic knowledge. For non-trivial issues, all you can hope for is to fight down 1st level support to get help from the enlightened ones. There is definitely no shortage on information from the software. Most software from SAP makes it quite simple to raise the trace level to be bombarded by internal tracing messages. Unfortunately, that information is only usable for SAP developers.

SAP Basis Intitiation Rites

Frequently, I am copying SAP systems or installing new SAP systems with the help of sapinst. Or should I say desipte the usage of sapinst? I am unfair here, but most often I tend to think this tool is simply happy to forward whatever exception it finds as some useless pop-up to the user. Error handling is definitely not a strength of sapinst, and sapinst error messages are hardly ever documented. Time after time it insists on some really stupid task, which of course tends to fail due to its uselessness. My conclusion is that sapinst alone would justify the forums on the SAP Developer Network! We can subsume such problems as some kind of initiation rite. Once you have successufully installed your first SAP system from ground up (no trial version!) then you really have some intimate knowledge of SAP Netweaver basis. Doing this on many different platforms will make you without a doubt a SAP basis professional. The crown of complexity and variety of error messages you'll encounter would be of course SAP Netweaver ABAP+Java on Windows/Oracle and some kind of clustering software. It makes me shiver just to think about it. (I don't say such a combination is necessarily a bad idea, I just believe this combination has the highest complexity and potential for really difficult problems. You have been warned.)

AS Java: A Test of Faith

Did I just mention java? So I kept the best for the end. Speaking of SAP error messages wouldn't be complete without speaking of the AS Java error messages. My favorite SAP error message of all times comes from the SAP portal:
    500 Internal Server Error
    Failed to process request. Please contact your system administrator.
Yoohoo! I AM the system administrator! So what should I do with this?

But that was just from the web frontend. I didn't believe my eyes when I first saw real AS Java error messages, and still I think "this cannot be true". Error messges in the range of tens of kilobytes? When ONE occurence of a problem writes more than 10 KB messages! Repeated over and over again. Long lines of irrelevant information where you have to search for the ONE relevant line which explains (hopefully) what is going wrong? Come on! SAP must be kidding here. Maybe I would have another opinion if I were a java programmer, but I am a basis administrator. You can get used to it, sure. You can get used to hardly anything if you are patient, open minded and willing to learn, but AS Java raises the bar to completely new levels. And my personal opinion is that SAP does not make any real progress there, it just tries to work on the symptoms e.g. by improving the Java Log Viewer. This must be the pinnacle of the cult of the SAP error message, comprehendible only to a relatively small group of adepts who have their own slang, worldview and rites.

Closing the Circle

Maybe at the end, I should return to AS ABAP. To be fair, it is not only AS JAVA which produces long and clumsy error messages. For many years, the most common of all SAP error message was within shortdumps. If you have produced a shortdump and checked it in transaction ST22, then you were greeted with this highly ironic message:
"Short dump has not been completely stored. It is too big."
At least the high priests of SAP Development have a good sense of humor.