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:
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.
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.