Skip to Content

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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Mark Förster Post author
    What I of course deliberately forgot to mention: If fixing problems would be too easy, then I would have to search for another job. And there are even many funny situations you can have with SAP error messages, for sure.
    (0) 
  2. Kumud Singh
    Hi there,

    Totally agree. while reading this blog, I could myself visualize many such errors encountered and then had to debug to understand what is the actual reason.(in possible scenarios)
    It is really a blog to be read in the mid of a working day to lighten yourself and then get back to work. Thanks.

    (0) 
  3. Augusto Cristicini
    Look at the error message, go look somewhere else and then come back and look at the error message again and realize hey maybe this means something else.   That seems to be the theme and although there is an art to trouble shooting, your right it should be easier not too easy though!

    As per the JAVA, well this was not a good product to start with when SAP purchased it from Toptier and although they have reengineered it to look like SAP it really is still different and behaves at a lower level of performance.

    I remember once opening a message for a SAPINST error and the support was so slowly analyzing the problem, which eventually got development to produce a new (6 weeks later) SAPup program for us.  The problem with this was that the program was never updated on the Market Place with our solution, so we had to continue to use our own SAPup and miss out on all the improvements with the newer versions.  Each time it asked us to get the newer version we had to ignore it, what!  Please this is terrible.  Somewhere they have broken what was once a good process.  I believe it to be due to the growth.  They have to pay the Oracle law suit you know!

    (0) 
  4. Stephane Deboudt
    Hi Mark,

    Came across your post because it displayed on the SDN home page. You did well mentioning the “subjective” nature of your post.

    Sometimes non-SAP people ask me if it is a complex system. In general I respond with the following: Go to SAP Notes and count how many of them you will get. And then I tell them: If there are so many of them, and if you believe me that this is still a “stable” system, then it must be really hugely complex. I know of software packages that count less lines of code than that there exist SAP notes.

    Now, with respect to Error Messages and their Handling: What I find exciting about the SAP Application Object is that it is in general “configurable”, and when it is, in general part of the object contains some kind of an “evaluator” of the configuration of that object (e.g. when you set up Workflow as part of an SAP Solution, you almost inevitably will have an addendum program that “tests” the Workflow). When the evaluation fails, there is the Business Application Log where some of the components will write Error/Warning and so on messages in a standardized way, meaning that you can log distributed errors centrally. Sometimes that information is so useful that it is used as part of the “normal operation” of an external program, so that even “Business” people know what to do, because it is part of the Business Process at hand.

    I wonder why you did not mention the error “This error should never occur”.

    Now, when you get an error 500 Internal Server Error, this was meant for the end-user mainly. He/she does not have any clue anyway where to go from there, so it is useless to mention the error message at all. Now you could say “Why then mention 500 Internal Server Error”? Well because it was for the end-user “mainly”. The “500 …” part IS for System Administrators. The reflex is to exactly go to ST22, because the system quite surely “dumped” before displaying the HTTP error in the user’s browser. That’s not even a Java or what-else error if things went wrong in the ABAP stack. If you forward the dump to the programmer responsible, it is very likely that he/she will not be able to give you any clue, due to a lack of “context”.

    Same applies when you hand over errors logged as part of tRFC to Administrators. Stands in a queue with a red light icon. Administrators do not like that color, because it clutters up the queues, but what to do with it when the error mentions “Partner Function SP does not exist for BP 9000..23”. Still this IS the 100% correct information to be able to solve the error. So, in this example there must be coordination between the “business” responsibles and the “System Administrators”.

    It was amusing to read this on an early morning, thanks. There is always room for “Food for thought”.

    (0) 
    1. Mark Förster Post author
      Initially I thought of writing a blog which contains funny SAP error messages, but then I realized that such compilations already exist. (And one of my all time favorites from transaction STAD had simply vanished.) So the scope got more generic and I dropped more and more specific error messages.

      I could of course have also added messages like “This error should never occur.” or “SY 002 system in trouble”, but somehow I thought that the current state was somehow finished and the blog ready for publishing. At least I couldn’t find anything to improve, but as long as some people find it an enjoyable read then I succeeded.

      Maybe someone else feels encouraged to write something similar? The SAP universe is so vast and I could only spotlight some small topics.

      (0) 
  5. Michelle Crapo
    I love that answer.  It’s one that always applies to SAP.

    Notes can drive me crazy.  Sometimes needle in a haystack comes to mind.

    You are BASIS.  Oh you are a poor, wonderful individual!  The BASIS team here, works almost 24/7 at least the person on call does.

    We are constantly adding more systems.  Adding more complexity, and hoping our BASIS team can help us out.  I am an ABAPer.  We tend to trust you to help us find some of our issues.

    Now on to Holidays.  Here we try to avoid the bigger holidays.  But when BASIS works on a holiday sometimes we all have to work.  It just depends… (Lovely answer) on what they are doing.  Kernel patch – they stay, we test.   Upgrade – they stay, and we stay.  This is a big deal.  *OK, it not upgrade anymore it’s Enhancement Pack.

    I love some of the error messages.  There was one something like “The processer is busy, go get a cup of coffee”.  That one was posted on our wall for a long time.  It’s probably gone by now.  But it was a fun one!

    BR,

    Michelle

    (0) 

Leave a Reply