No event handler created for FOs

[petra_just]

hi experts,

today, we are facing again the issue of no Event handlers created. Only FOs. We have a process where we create FOs automatically via an FU Event Z-CREATE-FO. It creates a freight order and assigns this FU to it. When this Background process is Happening, the Event handler is not created.

The EM Queues are empty. It cannot be the reason why the Event handlers are not created. To be on the safe side, we could create the Event handler for the Background FO in development (like it is possible manually in TC SAPTRX/EH_CREATE). I prefer finding the root cause of the Event handler creation problem, but if thats not possible, I will do that. Which Standard Report could be used to create an Event handler? What other reasons apart the EM Queue could be there that lead to non created Event handlers? If Event hanlders are not created, can we run reports regularly that do the creation of Event handlers every 5 minutes. Since the FO is created in Background, could it be a locking issue? I have one FO type only that does not create the Event handler and it does not create it from the Cockpit manually and not from the Background Event. It must be something in the FO type.

Points for helpful and correct answers will be awarded quickly.

Regards

Petra

[petra_just · Accepted solution]

hi Michael,

thx for your tip with Debugging the class. yes, the fo type application object type is ok. The error was due to a Queue entry that has blocked the EM Queue. As I understood from the name of the Queue, it was by FO type. That explains why the Event handler creation was only problematic for one FO Type. After unlocking the queue in SMQ1, the event handler creation worked again both in Background and in foreground. As suggested in a previous post from Gopi, the CCMS Monitoring has to be set up to send us an email if the Queue is blocked, so that we can unlock it. I do not understand why the whole Queue is blocked just because of a short dump for one FO. If someone knows how to avoid that, I am interested.

Thanks for your help, Picture of CCMS Monitoring attached.

[former_member194343 · Accepted solution]

Hm, guess this queueing is a quite simple way to prevent crossing messages (e.g. a "Change" message posted before the "Create" message), so it would be difficult and maybe not advisable to change this. Of course, sometimes it could be questionable why a certain error has to lead to a short dump, and this could be tackled somehow. BUT: I'm not very much in all those RFC queueing things (What defines that there's one queue per FO type and not one for every single FO ID?), so maybe someone else has a better explanation 🙂

[Former Member · Accepted solution]

Petra,

You can control how you want your queues to be. You can add FO Number as suffix like EM_TMS_TOR_<1234567890> or have 10 or more queue names ( Kevin Wilson's design ) in total and assign your FO to any one of the queues.

This way atleast your good FOs will be processed instead of getting blocking in one queue due to issue in one of your FO.

Goto you BPT and scroll right and you will see queue extractor. You can add your custom queue logic here.

Thanks,

Vishnu

[petra_just · Accepted solution]

excellent. Will try this tomorrow. If it works, I set ur answer as correct. For the time being helpful.

Thanks a lot!!!

[Former Member · Accepted solution]

Hi Petra,

This is the Kevin blog for parallel queue SAP EM ABAP - Using parallel queues in SAP Event Management 4.0 - Code Gallery - SCN Wiki

Regards

GGOPII

[Former Member · Accepted solution]

Since Petra is using standard integration, Kevin's blog is not completely applicable here.

However, in queue extractor, /SCMTMS/EXTR_QUEUE_TMS_TOR_TYP ( copied to Z ), the following Kevin's logic can be added:

-----------------------------------------------------------------------------------------------------------

v_result = v_int mod v_no_queues. " V_int_mod = FO Number


    v_cres   = v_result.

    concatenate in_queue v_cres into out_queue.

    condense out_queue.
------------------------------------------------------

[petra_just · Accepted solution]

hi Vishnu, we have used your advise and have created one Queue per FO instead of one Queue per Fo type. As a consequence, when we receive an error, Event handler creation is blocked for one FO and not for all FOs with the same FO type. This was very critical to us. To assign the Queue extrator described by Vishnu, the following FM can be found in customizing as follows:

the FM can be enhanced as follows or a custom function module can be added:

[petra_just]

Further info: the reason why the Event handlers were not created can be found in Transaction SMQ1. It will show an error in the Queue. The reason why the Event handlers of a certain FO type were not created is because the Queue stops and blocks any following Event handler creation for the same FO type. By makign a Queue by freight order id and not freight order type, we avoid this Problem, but the solution for the error itself has to be searched in ST22. by deleting the Queue entry, you can unlock the rest of the Queue. you will still have the entry in st22. you can also create the Event handler manually using transaction /SAPTRX/CREATE_EH.

[former_member186607]

Hi Petra,

using one queue per Freight order ID definitely solved the problem of blocked queues. But I have some remarks regarding this:

• Do you have always single processing of freight orders in TM? So always exactly one freight order that is changed in one transaction? If not, how do you handle cases in which multiple freight orders are changed? You then could have a situation in which FO A and FO B are changed in transaction 1 and processed in queue EM_TMS_TOR_<A>. In the next transaction another change (e.g. new carrier is assigned) is done for FO B, which will be processed in queue EM_TMS_TOR_<B>. If now processing of the queue EM_TMS_TOR_<B> is done prior to queue EM_TMS_TOR_<A> you have the risk of introducing inconsistent data for the event handler for freight order B in EM (e.g. wrong carrier).
• Do you only track freight orders in your scenario or also other TORs (like freight unit, transportation unit, freight booking)? If yes, you will not have single TOR per transaction as soon as you do some planning - then at least one e.g. FU and one FO will be changed in one transaction together.

It is possible to use multiple queues for posting EH data from TM to EM, but to ensure that there will be no data inconsistencies in EM, you have to be careful when implementing the queue name extractor and take the specific circumstances in your scenario into account. Topmost priority should , of course, always be to get rid of the short dumps that block your queues!

Best regards, Daniel

[petra_just]

Daniel,

thank you for sharing your concerns. It helps us thinking about the effects of the Queue Name. Changes to one FO always come from the same phone. the Fo is assigned to one Driver and each Driver has one phone. So, each Change will come from there. The Driver can load and unload FUs. FUs will be processed with another Queue (different tor type and with the new System anyway). What can happen is that a load is blocked and the unload arrives before the load. That is not ideal, but we can live with that in exceptional cases. the Event handler has the Event with the correct time and it will just be processed later.

For us, the effect that all These Event handlers are NOT created is much bigger because the Events do not come in and users cannot see the Progress of the trucks and FUs. So, we are ok with our decision to make a Queue by FO number. But, again, your advise was helpful there and lets see how it goes.

We are still a little newbie with the errors in the queue. Today's problem "current application has triggered a termination" is cryptic. I will open a separate discussion for it.

Many thanks, Daniel, for your help. Ist highly appreciated.

Regards

Petra

[former_member194343]

Hi Petra,

guess you already checked the FO type customizing (set to Execution tracking with external EM and assigned application object type). If so, my first idea was to debug this. You could start from /SAPTRX/CL_EM_UTILITY (this is the class managing the EM calls from TM). Be sure to enable Update Debugging, otherwise you won't grasp the EM calls.