SOST emails sent from which program

[Sandra_Rossi]

Is there a way or a table which I can find the program that is generating the emails being sent out in SOST?

[Sandra_Rossi]

You have to activate the SCOT trace before sending the email.

[Deep46]

With the help of program RS_ABAP_SOURCE_SCAN you can search the program name by giving the mail subject or text in the search string field.

[Sandra_Rossi]

@Deep46 RS_ABAP_SOURCE_SCAN is searching in the ABAP source codes, which takes huge time if you search everywhere. (Days?) Also, the titles are usually stored in message tables, text pools or translation tables for multilanguage texts, which happens very often.

[Deep46]

Ok that is time consuming but can you suggest other ways than this SCOT thing,because most of the cases you dont actual know by doing what process the mails are getting triggered.

[Sandra_Rossi]

The issue is not described well enough to propose a more precise solution. Users should know which business process is implied by simply looking at the email and the symptom would be reproduced and so could be traced.

[jolcy]

Yes. As mentioned by Sandra titles are always stored in different places. So, the issue here is that I have a huge list of emails in SOST and I would like to know what is the fastest way I am able to track back to which program are those emails generated from

[Sandra_Rossi]

First of all, did you investigate on the SCOT trace? First try on a DEV or QAS system. If you don't know how to generate an email, ask functional people to help you. If SCOT trace is fine, then discuss with your project/client if running this trace is an option.

[jolcy]

we have not run a SCOT trace yet as this will take up performance. The issue here is that we have alot of age old jobs probably running in the background and generating emails which are probably not valid anymore hence we want to see if there is any way possible to track back to where it is originating from

[Ryan-Crosby]

Do a where-used on both FM 'SO_NEW_DOCUMENT_SEND_API1' & class 'CL_BCS' in your dev box and look for Z*/Y* programs. Any standard program should be well understood by the functional folks and easy to trace, but I imagine you are looking for poorly documented and/or understood custom processes.

[Sandra_Rossi]

No performance issue with SCOT trace on DEV or QAS system. If you don't even try it, you can't make progress. Contact SAP support about sapconnect trace performance. I guess there's no issue with it. Though, the note 598718 says "Always deactivate the SAPconnect trace in a production environment with a large number of messages" (which doesn't say to not use it to analyze sporadic issues). Anyway, tell the admin to check the performance while the trace is running.