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 errors?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”.
Similar handling is needed in case the BC Application Log-technique is used (SLG0, SLG1 etc.) a breakpoint in FM BAL_LOG_MSG_ADD can help.“

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 message 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. Since I know the program CRM_STATUS_CON has defined constants for all status, then I execute the search report with the parameter below:

And here is the result:

Then use the source code scan once again. The question is how to specify the input parameter?

(1) We know that service contract is implemented via one order framework. Just display function module CRM_ORDER_* for example CRM_ORDER_READ, and get its package name CRM_ORDER:

(2) execute the search report with the following input:

Nothing found. Then I change CRM_ORDER to CRM_ORDER*. This time 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 function 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 Approach 1.
In this case the Approach 2 is even more efficient than Approach 1 to quickly locate the code we look for. Thank Fabian for sharing us such useful tip.

Setting breakpoint in function module BALW_BAPIRETURN_GET2 would be another good attempt.

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.

要获取更多 Jerry 的原创文章，请关注公众号 ” 汪子熙 ”: