SAP – Digging for Answers

A long time ago, one of my friends once told me I was a digger.  I don’t think that really set in for me until I started to look at myself.  When he was talking about that, I had just gone through sifted through a lot of code, some custom tables, and found a solution that we could implement quickly.

Looking back, I finally get exactly what he meant.  One of my biggest skills in SAP is knowing how to dig for information.  So most consultants are really good at getting tables and field names, and even doing some debugging of screens.  What really separates the good from the great consultants is how persistent they are in finding the answer 🙂

I wanted to talk a little about my process, and I’ll give you an example.  A client of mine has some custom code to do lots of stuff within a notification.  Well, like any custom code, somehow a record got corrupted.  It had to do with a task record, and because of the fields that got wiped out, you could no longer make changes to the notification.  So I started digging.  Here’s what I did (not necessarily in this order).

1.  found the BAPI’s for updating a notification.  I even tried running them in SE38 and doing the commit.  I got no errors, unfortunately no changes to the notification either.
2. Next, I looked up the table and found it was QMSM.
3. Then I went to Txn: Se11 and pulled up the where used of that table.  Unfortuantely, it was a rather large list.
4. So I look that list, and when to SE38 and ran my favoriate report:  RPR_ABAP_SOURCE_SCAN
   1. I entered in the list from the where-used, and looked for anyplace with the term update (since I needed a way to update the record without doing all the standard checks).
5. Then it was a bit of trial and error to look at each of the results.  Luckily, I even found a different piece of custom code that I could execute.  and happily, everything got fixed.

Now, there is also the alternative of changing fields in debug.  I was in production for this event, so that wasn’t an option, and it’s also something you need to be very careful doing, as you are likely to run into unexpected results 🙂  so try that in development first.

None of this is rocket science, but some days I’m just too persistent to know when to quit.

Thanks for reading,

As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,
Mike