EM TM process

[former_member193027]

Hi,

I would like to know the TM-EM process flow related to queues.Like when reporting event , I would like to know the sequence as how smq1 and smq2 gets updated in TM and EM system. Also in case the processing time of queues are slow how we can resolve the isssue

[kevin_wilson2 · Accepted solution]

Dipak,

TM works the same as ECC in this instance. qRFC is the traditional method used to call the 2 BAPIs that ultimately create the EH and Event messages in EM.

To give you a quick rundown on how these 2 queues work and some tips here goes...

SMQ1 - Outbound qRFC queue

1. This is where you'll find the BAPI calls to create EH and EVM
2. Configure using SMQS
   1. For Performance issues consider increasing Max connections
   2. Configure the Queue name extractor to leverage multiple queues in SMQ1 so that you can leverage the Max connections setting. i.e. If you execute a bulk transaction what you would like to see is 15-20 queues working in parallel on TM and in SAP EM, 15-20 dialog process processing the BAPI calls.
3. Performance is also affected by SAP EM processing so ensure that your Rule Set is very well structured
   1. Make use of True rules in the rule set to avoid unnecessary logic being performed
   2. Turn off task tracking and the application log
   3. Don't store history on the EH
   4. Ensure your rule set is in the sequence of most frequent events at the top and less frequent at the bottom
4. Remember that if this queue gets stuck you can just delete the entry as the corresponding BAPI will not be called in EM and the data won't exist there

SMQ2 - Inbound qRFC queue

1. This queue is used to update the table in TM called /SAPTRX/AOTREF with the EH GUID
   1. We often use this table in our relevance functions. i.e. If there is an entry already there then my object must be relevant, if not then it isn't. Using this mechanism means that you only need to do an expensive relevance check on creation and after that it's simple
   2. You can turn this entry off if you wish, in customizing
   3. Not critical for performance

Hope that helps.

Kevin

[former_member193027 · Accepted solution]

here the transaction smq1 and smq2 , are you referring it to in TM only.

If yes, whats the implication of smq1 and smq2 in EM system.

Also if queues are mostly in ready status and the No of count almost remains the same what can be the probable root cause and how do we find the exact event which is causing the queues to run endlessly.

[Former Member · Accepted solution]

Hi Dipak,

I could see some implications if the inbound and outbound queue stuck in source or EM system.  You will not have a real time update in both systems.  The customer can report that they can see incorrect data in EM or source system.

If the queues are in ready or waiting status, it could be different reasons like temporary network communication error, Non-EM queues failed or blocked (happens occasionally), other EM queue has failed due to Update terminated error or BLDAT table error or different error.

For example -

1. Failed queue has status as Update Terminated error or BLDAT table error or different error.  You can double click on status, again double click on status then it shows you a list of functional modules and where it has failed.

2. If you want to know which specific expected event is failing frequently, you can select one queue inside and double click on "TID" number.  If you check "Table Value (LZH compression)" and scroll down little bit to find out your expected events causing the issue.

The queues are in ready or waiting status due to unknown reason, you can debug directly the queue to know the root cause.

Regards

GGOPII

[former_member193027 · Accepted solution]

I,

Thx.

Can you be more precise -If you check "Table Value (LZH compression)" and scroll down little bit to find out your expected events causing the issue. In which table and how do I know which event is causing the queue issue.May be screenshots will help.

Secondly in terms of process sequence I would like to know the data flow from TM to EM including smq1 and smq2 in both system.Since I am confused at which point of time we need to check smq1 and smq2 in EM and TM system respectively.

[Former Member · Accepted solution]

Hi Dipak,

First:

1. Run Tcode SMQ1

2. Double click on your queue name

3. Again double click on queue name

4. Now you can see queue stuck in status failed, running, waiting or transaction recorded statues.

5. Scroll down to right until "TID" column visible

6. Select first row of queue

7. Double click on TID which will be like "ABCDEFGEEFS1213232ABCD"

8. Scroll down little bit to  "Table Value (LZH compression)" header name

9. You can find your expected or unexpected events name which are blocking the queue in text row.

Second:

When expected or unexpected events are triggered from source system, the functional modules calls in sequence like this for example /SAPTRX/BAPI_EH_POST, BAPI_TRANSACTION_COMMIT, /SAPTRX/BAPI_EH_ADDEVENTMSG_02 BAPI_TRANSACTION_COMMIT (you can view in SMQ1)... once queue generated then it will go via SMQ1 (if you would have selected asynchronous) to update in SAP EM.

Either you can automate or manually monitor (every 1 hour) these SMQ1 and SMQ2 queues in source and SAP EM systems.

As suggested by Kevin, you have to split the queues to work in parallel.

Hope this information helps you.

Regards

GGOPII

[former_member193027 · Accepted solution]

almost all queues are in ready status and hence we would like to know how we can debug the queue to find the root cause. Appreciate a quick help on this

[Former Member · Accepted solution]

Hi Dipak,

1. Have you checked RFC connection and what is the outcome?

2. Has there any queue blocked quite often apart from SAP EM?

2. Have you maintained source system id in SAP EM IMG -> Event Management -> Event Handlers and Event Handler Data -> Parameters -> Define Parameter Mapping -> Assign Profile to Mapping Area -> Application System Field -> Change correct system id ?

3. If above things done, then you should have debug access in Production system as normally it is done through special ABAP debug access id.

4. When you debug the queue, your RFC userid should be changed to dialog user.

P.S. There are few SCN docs available online, how to debug the queue.

Regards

GGOPII

[Former Member · Accepted solution]

Hi Deepak,

Are you saying that the queues are never going to rurunning status on their own and always in ready status after they are created ?

If yes, please check SMQS/SMQR for queue schedulers that the destination and queue name are registered.

Thanks,

Deb

[former_member193027 · Accepted solution]

Hi,

Can you inform us if there is any way to find out the time taken to process the queues in TM and EM so that we can understand how much time it takes for a system to process the queues

[Former Member · Accepted solution]

Hi Dipak,

Yes it is possible through SAP statistics analysis tcode STAD based on user id and time window.  The qRFC processing time is reported as response time in STAD.

Talk to BASIS team because they know several monitoring and analysis options available in SAP EM and SAP TM.

Regards

GGOPII

[former_member193027 · Accepted solution]

Can you send me the scn documents , how to debug the queue.

[Former Member · Accepted solution]

Hi Dipak,

There is no specific debugging docs for SAP EM qRFC in SCN.  The debugging of qRFC shows CRM and APO Queue.

Regards

GGOPII

[kevin_wilson2 · Accepted solution]

Dipak,

What we have done in the past if we really need to debug the RFC call:

1) Break-point in the AI system just before it gets to the BAPI call to EM

2) Instead of running through the logic to use qRFC manipulate the Synchronous variable to have it call tRFC instead of qRFC

3) switch on System debugging and then step through in to the SAPTRX BAPI and you will be able to debug it.

Determining why it's taking a long time in the queue is VERY dependent on the EM system and how many resources are available to process the RFC there so when you experience slowness go and run SM50 in EM to see if there is anything holding it there - You may be able to catch the RFC doing it's thing there to see what tables its getting hung up on.

Remember it's generally a rule set activity that is ultimately the cause for slow EM processing.

Kevin

[former_member193027 · Accepted solution]

Hi,

We had faced a strange issue whereby we had deregistered the queues and then after certain hours the queues were registered but inspite of fact that during these hrs only approx. 4000 documents were created the EM TM queues value showed triple times. Does any one throw light on how the root cause can be known.

Also apart from smq1 and smq2 is there any database table available for queues monitoring

[former_member186607 · Accepted solution]

Hi Dipak,

one update/creation of a TOR object in TM can lead to multiple entries in the queue (i.e. multiple updates for SAP EM). Update of TOR can trigger asynchronous follow-up processes like execution of change controller/save/create strategies and/or PPF actions. If these do updates to the same TOR as well, this can trigger again the data extraction to SAP EM and therefore add another entry in the queue. This can happen especially, if the relevance functions for the application object types are not very sophisticated. If e.g. the delivered standard relevance functions are used, every change will trigger the update to EM. Recommendation is to implement relevance functions which filter out all changes that are not relevant for EM and therefore no update for the corresponding EH is needed.

Best regards, Daniel

[Former Member · Accepted solution]

Hello Kevin ,

                       We have all the points mentioned in your post already applied. Still we see long processing time in SM50 for the RFC call from ECC for event message post. Please see the SM50 screen shot attached..

Thanks,

Shubh.

[Former Member · Accepted solution]

Hi Shubh,

If you look at current info column, it is trying to update expected events in table /SAPTRX/EH_EXPEV.  Double click the line item and you can see which program and report the event is stuck in system (not give much information).

Have you tried to debug the queue and login RFC?

If one event handler has more than 50 expected events and unexpected events, then it takes time to update.

SAP EM has more event handlers like above to update expected and unexpected events.  So, it takes time to process and the best way to identify an issue through ABAP debugging.

You can also raise SAP OSS message and post here to Daniel/Steffen to look out the issue.  SAP can directly login into your production system.

In my previous project, SAP has given customer specific OSS note that was for table update failures in SAP ECC queue while processing to SAP EM.

Try both options and let me know the results.

Regards

GGOPII

[Former Member]

Dear EM experts

we are facing issue related to outbound queue processing taking very long time to process from source system (ECC here) to target SAP EM system

entries are only getting added with very slow processing happening of old entries

Suddenly this behavior started in the system. There were no changes done in the system. Basis team has also checked and found that all is fine from their side.

Any suggestions/inputs will really help

Thanks!!

[Former Member]

Hi Tarun,

Have you checked my suggestion on this thread?

1. Check sales order holds more than 30 line items and trying to update in one event handler.  We had this issue before in Shipment that caused queue blocked.  This would happen most of the time in peak hours due to resource work process allocation also and same event handler locked to update.

2. Go to my suggestion which I mentioned in this to check "TID" in queue, take the sales order and find event handler how many events trying to update for one sales order event handler in SAP EM.

3. Also, Go to SAP EM and check any Lock event handler program running long in the system, that may blocked processing event handlers

Regards

GGOPII

[Former Member]

Tarunveer,

I would check the overall performance of EM ( ruleset and preprocessing ) especially if you have custom objects. One of the main reason would be the number of records in EM ( EH_HDR and EVM_HDR ). Also, you need archival/deletion strategy which will help you in overall performance.

Check SM50 and see what's the hold.

Thanks,

Vishnu

[Former Member]

Dear Gopi

Go to my suggestion which I mentioned in this to check "TID" in queue, take the sales order and find event handler how many events trying to update for one sales order event handler in SAP EM.

in SMQ1 in ECC source system, I followed the path as suggested but was not able to find any event information there

i also have archived old data from system using available SAP standard reports but again the issue is that queue is taking so much time to process we have daily entries getting added up in SMQ1

For last 6 months there was no change in the system and this set up is there since it was implemented and suddenly queues started taking extra time to process

Is there any specific reason we can for it

in EM system in SM50, i can see that in trace with help from basis team

/SAPTRX/CL_EH_EVENT_MSG_MODEL=CP

this is taking most of the time to process.

any suggestions are welcome

Thanks!!

[Former Member]

Hi Tarunveer,

The class /SAPTRX/CL_EH_EVENT_MSG_MODEL is heart of SAP EM, it sets everything which loads all SAP events create event handler, attributes, params, events, rule set etc etc.

There are 173 + methods on this class, so pointing to correct one very difficult for your issue.

Put the breakpoint on /SAPTRX/CL_EH_EVENT_MSG_MODE -> LOAD_EXP_EVENTS to check but it is just starting point for you.

The only way you can find out the root cause through debugging.

Regards

GGOPII