In my blog "Six kinds of debugging tips" Fabian Geyer raised a very good point about the trouble during ERP Application trouble shooting.

Let me just quote his good statement:

"Several ERP applications (esp. Financials) often use a "message collector" technique especially when handling "multiple objects", where after the application ist "detecting" an error it will be "stored" to an "error collection" and after all checks have been done the list of maybe many erros is shown in a popup or list.

In these cases, when the message is "shown" is far to late to analyze, because the application data/situation which is causing the error is analyzed somewhere else (far earlier in the runtime). In these cases I often use breakpoints in FM "MESSAGE_STORE".

Actually in CRM application the error message handling logic is the same. Let me just use the example of Service Contract processing as example:

How to find the code where the nessage CRM_ORDERADM_I with number 505 is raised?

Approach1: Use the source code scan

For more details about how to use source code scan, please refer to my previous blog.

When I am using this approach to write the blog, it just took me several minutes to find the exact code position.

First we use the source code scan tool ( search keyword = 505) to find the constant ITEM_TYPE_NOT_FOUND for message number 505,

Then use the source code scan once again, this time the search key would be "item_type_not_found".

We get seven candidates, then just set a breakpoint at each and repeat your scenario.

The third one in result above is proven to be the location we are just looking into:

Approach2: Use function module BAL_LOG_MSG_ADD

This tip is suggested by Fabian Geyer and is also very good. Just set a breakpoint on functon module BAL_LOG_MSG_ADD and repeat the scenario in service contract. The breakpoint is triggered( you can observe the FM is now displayed in the top-most of callstack ) and the code position we found this way is just exactly the same as Approach1.

In this case the Approach2 is even more efficient than Approach1 to quickly locate the code we look for. Thank Fabian for sharing us such useful tip.

Why neither approach works for me? Why the breakpoint is not triggered in my application?

Still use service contract for example, the business transaction like Sales Order, Service Order and Service Contract are implemented via so-called One Order Framework. And as clearly described by Fabian which I quote in the beginning of this part, the error detection logic of One Order Framework, in this example is the logic in form DETERMINE_ITEM_TYPE, is ONLY done for the first time the item is inserted. Once an error is found, the respective function module in the function group CRM_MESSAGES will be called to persist the error message. Later on when the erroneous service contract is opened once again, there are no item type check any more, instead the error message is fetched via read function module in the function group and displayed in the UI.

When I delete one item product in the service contract, the obsolete error message for that item would also be deleted by the corresponding FM CRM_MESSAGES_DELETE.

So when I am trouble shooting the error message raised in Business Transaction application, I will either delete the old erroneous item then recreate it, or create a new one from scratch. Of course if we need to do debugging in production system, both could be inappropriate.

In this case if you can ensure that the error message raised in customer production system could also be reproduced in your dev system, then you can still use the tips in this blog to find the position in an efficient way.