SAP EM Blog Series #11 – Troubleshooting tips
In my last blog we described the various Web Services that you can use to interact with SAP Event Management. Now let’s look in to SAP EM troubleshooting and providing some tips. Please feel free to add your own comments to keep a running list of tips and tricks…
On the Application System
If the Event Handler or Event message fails to reach the SAP EM system what steps should you take?
- Check messages issued during Application Object creation and Event creation. You should see a count of relevant objects being sent to SAP EM that corresponds to your expectation. (Transaction: /SAPTRX/ASAPLOG)
- Check for any RFCs stuck in the outbound qRFC queue (Transaction: SMQ1) – The queue name is typically EM_<BPT> where <BPT> is the applicable business process type. If the status is “SYSFAIL” then check short dumps in SAP EM (Transaction: ST22)
- Check that the QOUT Scheduler is Registered for the SAP EM Destination (Transaction: SMQS)
- Check for any short dump entries (Transaction: SM21 / ST22)
- Check for any stuck transactional RFCs (Transaction: SM58)
- Check that the QIN Scheduler is Registered (Transaction: SMQR)
- Check for any RFCs stuck in the inbound qRFC queue (Transaction: SMQ2) – This queue is used to process the inbound acknowledgement to table /SAPTRX/AOTREF – The queue name is typically EM<GUID> where <GUID> is the corresponding EH GUID from SAP EM
On the SAP EM System
If the Event Handler or Event message fails to post in SAP EM system what steps should you take?
- Determine if the Event or Event Handler arrived using one of these reports
- Event Handler List (Transaction: /SAPTRX/EH_LIST)
- Last Report Event List (Transaction: /SAPTRX/EH_LAST_EVT)
- Event Message Processing Error List (Transaction: /SAPTRX/ER_MS_LIST)
- The Event Message processing list (Transaction: /SAPTRX/EVM_STATUS)
- Check the SAP EM relevant jobs are running (Transaction: /SAPTRX/EMJOBS)
- Manually run the locked EH and EHS reports (Transaction: /SAPTRX/LOCKED_PROC and Transaction: /SAPTRX/LOCKED_PSET)
- Check the Application Log for any messages issued there (Transaction: SLG1)
- Check the system log for ABAP dumps (Transaction: SM21 / ST22)
- Check the RFC trace log for RFC issues (Transaction: SM59 on the application system)
- Check for locked EHs in table /SAPTRX/LOCKEDEH. Run the locked EH job (/SAPTRX/PROCESS_LOCKED_EH) to ensure that all events have been posted
- Check table /SAPTRX/RP_AOID for entries. It stores the application object IDs that could not be posted due to locking issues. Run job /SAPTRX/R_REPOST_AI_LOGS to re-post the data accordingly.
- If no EH has been created, then also check these 2 settings:
- EH Type condition – Make sure that it is defined to your requirement
- The applicable Parameter Mapping profile is created and assigned to the application system sending the object for tracking
- If the Event Message was received but did not post correctly, then Reprocess Messages in Simulation mode to determine where the issue lies
- Lastly, check table /SAPTRX/EH_HDR for new Event Handlers and work back from there to find out what went wrong.
- See if the message made it to table /SAPTRX/EH_EVMSG – If it is in this table but is marked as irrelevant then check that the event code has been registered as an acceptable unexpected event in the EH type definition
- For Event Messages gone missing check table /SAPTRX/EVM_HDR and work back from there to find out what went wrong
Please feel free to comment on this procedure and add to it… Thank you.
Thanks a lot for very useful information. I have one question out of this as, is it possible to re-generate Event handlers for unprocessed event messages?