The most common thing we developers do when encountered an error message on SRM webui is to go to T100 table and search for message class and message number for the particular message. Once we have the details, we go to SE91 and do a where used list and figure out the places where this message is used, then start debugging. But what’s the fun if life is so easy 😉
In SRM 7.0, sometimes we end up in a situation where we know the message id and message number, but when we do a where used list of the message from SE91, we don’t get any hits. In those situations we usually start debugging from the point where we are 100% sure that the control comes to ( like doc_change_badi or doc_check_badi etc.,) and then move further step-by-step till we find this elusive message id and message number.
I have couple of tricks that I learned during my struggle with SRM issues that I would like to share them here
– FM BBP_PD_MSG_ADD
SAP uses this FM often to add messages to a global messages table during document creation/ update. So put a external / session break point inside this FM and execute the relevant scenario form SRM webui
– Class /SAPSRM/CL_PDO_MSG and methods /SAPSRM/IF_PDO_MSG_PROVIDER~ADD_MESSAGES or /SAPSRM/IF_PDO_MSG_PROVIDER~ADD_MESSAGE_STATIC
This class is heavily used SRM 7 to handle messages. Put a external / session break point inside above mentioned methods and execute the relevant scenario
Recently both of my above tricks did not work unfortunately for message 658 of class BBP_PD. The consequence of that unfortunate event was a 2 hour long laborious debugging session and finally I found that I have another trick up my sleeve
– Class /SAPPSSRM/CL_MESSAGE method CREATE
Same thing goes for this as well. Put a break point inside CREATE method and start executing the relevant scenario.
Hope this helps other developers
Keep blogging and Have a nice day 🙂