Best Place to Trigger an Event Upon Handler Creation

[Former Member]

I'm wondering where the best place might be to trigger an event against a FO/FB handler when the FU is planned? If the FU is unplanned and replanned again I need the event to post to the FO/FB being planned.

Our guess is that the best place to do this would be under '/SAPTRX/IF_EX_BADI_EH_S~AFTER_EH_SAVE' we then have the following condition checks for posting the event:

1. Is there a TOR_TEC trackingID codeset?

2. As the event been posted?

Issue:

This location appears to work great when we FIRST plan the FU into a FO/FB. However, if we unplan and then replan the event doesn't seem to trigger. Why might this be? Is this not the best approach to triggering an event upon FO/FB handler creation?

Thanks

[Former Member · Accepted solution]

Hi Jacob,

the best place is an Event Type in TM with a proper relevance condition function and an Event Type extractor.

Best regards,

Steffen

[Former Member · Accepted solution]

Steffen,

Doesn't the Event Type extractors only execute when an event is posted from within TM?

What I'm trying to do is post an event to the FO/FB upon creation of the FO/FB? Where should I trigger the event itself?

[Former Member · Accepted solution]

Hi Jacob,

no. They are triggered everytime you change a TOR object (FO, FU etc.)

With the relevance functions you control if you want to send an event or not.

In your case you create an AO Type for your FO/FB and also an Event Type.

In the relevance function you have to make sure that the event is only sent for creation and not later when the FO/FB is changed.

Best regards,

Steffen

[Former Member · Accepted solution]

Steffen,

The issue we are having now is determining the best relevance condition for the event. Again we are trying to only report the event when a FO/FB document has been created.

Any ideas on the best condition to use in the event type in order to determine when it should be triggered?

Thanks

[Former Member · Accepted solution]

Hi Jacob,

There is a field in TORROT called CHANGE_MODE. See if it helps for creation mode indicator. If not other possibility is checking the TORROT structure  for current values and before values.

Try this:
   ASSIGN i_event-maintabref->* TO <fs_tor_root>.
   ASSIGN i_event-mainoldtabref->* TO <fs_tor_root_before>.

Now compare <fs_tor_root> and <fs_tor_root_before> for the Freight Order. Not having FO in before and having FO in current structure is an indicator that it's a creation and not updates.

Try it out and let me know.

Thanks,

Vishnu

[Former Member · Accepted solution]

Thanks Vishnu for the advice. It turns out I believe we have it working now to only trigger the event when the FO/FB is originally created. Now what seems to be strange is that the unexpected event is showing up twice in on the FO/FB as a duplicate??? I thought before it was because we weren't updating the event with the source location but once we added the location it shows up in the FO/FB as being propagated twice; then in the FU 1 is propagated and the other is read from EM....

Any thoughts??

[Former Member · Accepted solution]

Hi Jacob,

Is yours a custom Event Type? Also, is your ruleset custom?

In the past, I had the similar issue due to my Event Type coding. I was not checking EXECUTION-PARENT_NODE_ID EQ TORROT-NODE_ID.

For FB/FO, propagated twice means, it went through the TM rule twice successfully and for this:

1) Make sure you have SNDNAM field is properly maintained

2) There are really no duplicates and only one event is posted

3) Check the tracking id's on the both events are what you wanted and if any particular event is relevant for both Event Handlers ( FO/FB and FU ) based on tracking ID.

For FU, one propagation and one read from EM means ( provided location is not an issue 😞 The event is reported on EM, propagated to TM via rule and came back to EM via Event Type. This time it's not propagated to TM due to rule check on SNDNAM and that's why it says read from EM.

Check and let me know.

Thansk,

Vishnu

[Former Member · Accepted solution]

Vishnu,

Yes we are using a custom Event Type and a custom ruleset. For the custom ruleset maybe it would help if I better understood the flow of the event when setting it reported from the Event Type?

1. So the event type is extracted from within TM upon creation of the FO.

2. Before this function is complete the ls_trackingheader information is set up for the event I'm wanting to report. (Where exactly does the SNDNAM get set? FYI I'm not a developer; however I have knowledge of the code and logic. )

3. This is where I'm confused how does the event get propagated from EM to TM. Doesn't the Event Type logic being executed send the information to EM FROM TM. We would want the sender to be TM. The rule set checks the sender and because it's TM it will not propagate the event up to TM but instead just report it on the handler.

4. But if I'm correct on (3.) then the event isn't propagated from the FO/FB to the FU, is it?

Another question:

Within my ruleset if the sender is TM all I'm supposed to do is not send it back to TM, correct? I still let it report? This seems to be how standard events are setup with the multi-task activities.

[sukumar_perumalsamy · Accepted solution]

Hi Jacob,

1) valid only if event is generated and reported in TM

2)  SNDNAM  = TM ,  by default sender name is populated to control the event update between EM and TM.

3)sender to be TM only if the event is reported or propagated between the TM documents.

sender name validation in EM rule set required to control the event update to TM.  i.e event is already exist in TM and no updates required from EM.

EM to TM event reporting Sender name depends on the type of event reporting channels ( EM WebUI  or Interface sender name). you can design the rule to send the custom event to TM or maintain the reported event in EM.

~Sukumar

[Former Member · Accepted solution]

Hi Jacob,

In addition to Sukumar's response,

If you goto any event type for TMS_TOR, you will see TM is defaulted for SNDNAM

/scmtms/cl_scem_int_c=>gc_sendername_tm.

This statement will/should be used to block event in ruleset from coming back into TM. This way, you just let it report to Event Handler in EM.

Thanks,

Vishnu

[Former Member · Accepted solution]

Steffen,

The issue I'm having is how to report event within the Event Data Extractor. We are doing it this way at the moment:

These issues seem to remain:

1. The event shows up on the FO handler with no location

2. Since the SNDNAM = TM within the FO handler it is not sent to TM

     - The event does not show up on the FO within TM; and such is not propagated to FU within TM.

Is there something we are missing? I'm struggling to understand how the event will be reported to the FO handler then propagated to TM FO and over to FU then down to FU handler; starting from the Event Data extractor.

Any ideas?

[Former Member · Accepted solution]

Hi Jacob,

In the screen shot I do not see gv_evtcnt assigned to location structure.

If not then please add "lwa_locationid-evtcnt   = gv_evtcnt" before appending. Atleast one of your might get resolved.

Also, look at the following document ( page 11 show flow ).

SAP Event Management - Scenarios for SAP Transp... | SCN

[sukumar_perumalsamy · Accepted solution]

Hi Jacob,

check the Logic for SCHEDULED event in extracor /SCMTMS/EXTR_EVT_FU_SCHEDULED and apply the same logic when you generate the custom event from TM to EM.

For TM unexpected event propagation between FO document to FU you have to include the logic in below method.

/SCMTMS/CL_TOR_A_PROC_EXEC    PROPAGATE_TO_PREDECESSOR

/SCMTMS/CL_TOR_A_PROC_EXEC    PROPAGATE_TO_SUCCESSOR

~sukumar

[Former Member · Accepted solution]

Vishnu,

I had actually just mentioned the gv_evtcnt before I read your message today. Thanks for the catch though too.

We are getting closer so here's what I think is happening:

1. I have an Event Data Type in which the whole goal is to post this custom event.

2. After running through the logic the event now reports to the FO handler and through the rule set is propagated to TM FO (NOTE: in order for this to happen I had to remove ' ls_trackingheader-sndnam = /scmtms/cl_scem_int_c=>gc_sendername_tm.', if I left in the sender being TM then the event only reports to EM and is not propagated to TM FO).

3. Even though the event is propagating to the TM FO it is not propagated next to the FU. Shouldn't this be standard as long as the event has a maintained 'Stop Category' within TM? From what I read the unexpected events can be propagated through standard propagation BUT the unexpected event has to have an assigned 'Stop Category'.

[Former Member · Accepted solution]

Sukumar,

Thanks for the reply please see my above reply to Vishnu.

[Former Member · Accepted solution]

Hi Jacob,

As for the ruleset, I would not remove TM check in the ruleset but rather assign SNDNAM = NON-TM ( something meaningful) so that the event is propagated to TM and at the same time if an event is triggered via Event Type ( where SNDNAM = TM ) it is not propagated back to TM from ruleset.

So,

1) If Event is generated from Event Type, SNDNAM = TM ( flow is TM->EM)

2) If Event is Reported directly to Event Handler ( EM ) then SNDNAM = NON-TM ( flow is EM->TM)

For you second question, the event should have been propagated to FU as well internally. Check the FO type config and see if Propagate Execution info is checked or not.

- Also check FU type config and see if you are excluding any events for FU type

- Check TM tracking config ( TM->Integration->Track and Tracking of Processes and Documents->Define Transportation Activities->Events for Business Doc ) and see if the events are relevant to both FO and FU.

See if you can narrow down the issue further.

Thanks,

Vishnu

[Former Member · Accepted solution]

Vishnu,

Thanks again for the reply.

As for the ruleset I have not removed the TM check. What I was trying to say is that I have removed the ' ls_trackingheader-sndnam =/scmtms/cl_scem_int_c=>gc_sendername_tm.' from the Event Type. This means that when the event is generated from the event type SNDNAM=NON-TM. If I don't do this the event doesn't propagate to even the FO in order to eventually propagate to the FU (once I get it working ).

So,

1) We are generating the event from the Event Type with SNDNAM = NON-TM. Again if I put TM then the event doesn't appear as propagated to TM on the FO but rather 'Read from EM' which is fine but I need the event to propagate to each of the FUs within the FO.

2) I have made the following checks and they all seem fine:

a. FO Type config is set to propagate execution information

b. FU config doesn't appear to be excluding the event. When you say excluding the event what are you referring to?

c. Lastly, the event is configured as 'Stop Category - Outbound' and is relevant for FO/FB/FU documents.

Any thoughts?

Additional question or my thought, if the Event Data is meant to report the event TM -> EM then how does propagation happen to the FU? What I'm saying is that through Event Data if I have SNDNAM = TM, then EM will no propagate up to TM FO and then over to TM FU. hmmmm....

[Former Member · Accepted solution]

Hi Jacob,

Give me your scenario and I will try to check. We are still trying to stabilize TM FU/FO creation in our system but let me see what I can do by configuring it.

For TM->EM:

What is the source or event? Are you reporting directly on FO?

If not directly reported, what is your tracking code?

For EM->TM:

Are you using EM WEB-UI?

What is your tracking code?

Thanks,

Vishnu

[Former Member · Accepted solution]

Vishnu,

I'm trying to report a custom event 'Z_TREQ_C' when a FO or FB has been created. This event needs to be reported at the FO/FB level and then propagated to the FUs. It's important to ensure the event is reported on the FB/FO and propagated to the FU because we have an Event Data extractor used by the FU that will extract the FO/FB type into the event message from TM->EM so I can use the FO/FB type within my rule set.

As suggested we are trying to accomplish this within an Event Data Type extractor. The issue I think I'm seeing is that this is not directly reporting the event to the FO/FB TM document and hence is not propagating the event to the TM FU.

For TM->EM:

The source for event we are not reporting directly on the FO? (For example we are not manually reporting from Execution Tab.) At this time we are just creating the message within the Event Data extractor using (TOR_TEC = FO#). Is this the ideal place to systematically trigger the event on the FO/FB. If I don't include SNDNAM then my FO rule set will propagate the message to TM (however this isn't even sending to the FU for some reason); if I DO include SNDNAM = TM then my FO ruleset will NOT propagate the event to TM hence TM FO says 'Read from EM'.

For EM->TM:

I don't think it's relevant for this scenario but we are reporting them via WE19 IDOC.

[Former Member · Accepted solution]

I don't think I need to enhance these:

/SCMTMS/CL_TOR_A_PROC_EXEC    PROPAGATE_TO_PREDECESSOR

/SCMTMS/CL_TOR_A_PROC_EXEC    PROPAGATE_TO_SUCCESSOR

Because if the unexpected event is configured with a 'Stop' category and it is propagated from EM FO -> TM FO, shouldn't it propagate to the FUs through standard logic? I think it is suppose too, no?

[Former Member · Accepted solution]

Hi Jacob,

The standard propagation is working for me if the event is reported directly on FO/FB from execution tab. I confirmed it in my system. The event is propagated to FU and the Source of Execution says "Propagated from Successor Document". I just enabled standard LOAD_BEGIN.

Let me try to create event during FO creation without going to execution tab and see if it propagates to FU or not.

[Former Member · Accepted solution]

Just to add, mine is custom AO Type, standard Load_Begin Event Type, Custom EH Type, Custom Ruleset.

Pretty much all custom objects.

[Former Member · Accepted solution]

Vishnu,

Thanks again for looking into this. I confirm that if I report an event from the FO on the execution tab it does indeed propagate to the FU as well.

[Former Member · Accepted solution]

Hi Jacob,

Assuming standard propagation will not happen ( haven't checked yet during creation ) without reporting on document, you can have this way:

1) Z_TREQ_C is generated during FO/FB creation using Event Type. ( what you have now )

2) Resend the event from ruleset of FO/FB using RESEND activity to FU EH provided you are bringing in the FU value to FO/FB EH.

When you resend to FU, you can also have FO/FB type as parameter which you can use in FU ruleset for your rest of the processing.

This way, you can see your event on FU and as well have FO/FB type in FU ruleset for you to use.

[sukumar_perumalsamy · Accepted solution]

Hi Jacob,

schedule the batch job in TM /SCMTMS/PROCESS_TRIGGER_BGD to process the locked execution information.

EM-TM event reporting : check the table /SCMTMS/D_TOREXE for the actual reported event if entry exist then only it will be propagated to other documents.  if no entry exist then it shows "Read from EM".

~Sukumar

[Former Member · Accepted solution]

Hey Vishnu,

I was really hoping to avoid propagating the event myself through the ruleset. I was hoping to just use the standard TM propagation.

IF I was to resend to the FU handler I've got a question that have seen in the past with trying to use RESEND_MULTIPLE. The reason I would use RESEND_MULTIPLE is because there will be many FUs within a FO/FB.

The issue I've noticed is the following:

1. Within the FO ruleset use activity function RESEND_MULTIPLE

2. Parameter Name = C

3. Parameter Type = ODT20_ASSIGNED_FU

4. Now, the function /SAPTRX/RESEND_MULTIPLE uses the same Parameter Type passed in 'ODT20_ASSIGNED_FU' as the code-set for resending the event. This isn't very useful though because the FU doesn't have 'ODT20_ASSIGNED_FU' as a code-set tracking ID??? How does this make the RESEND_MULTIPLE event useful, I wish the standard would allow me to pass the code-set to use...... Any thoughts?

Again it would be nice to not EM propagate the event.... haha

[Former Member · Accepted solution]

Hi Jacob,

I tried in my system and the event is not hitting the propagation methods when you do it without reporting on document. I tried with Event Type during creation and changes ( kept my custom event type relevance wide open) but no propagation due to execution data not being triggered.

Having said that, options may be exploring the propagation BADI in TM or RESEND_MULTIPLE or (ZRESEND_MULTIPLE) based on your parameter setup.

Let me know if you need help in custom ZRESEND_MULTIPLE and I can quickly show what you need to make this happen.

Thanks,

Vishnu

[Former Member · Accepted solution]

Vishnu,

Thanks again for the testing, it's good to know we aren't that far apart. We are also looking into a possible different location to trigger the event upon the initial creation of the FO/FB. Not sure where that is going to lead but we are trying. The hardest thing is that we need the event o post on the FO/FB when the TOR_TYPE is available as well. Heck we could even post on the FU as long as we had the created FO/FB TOR_TYPE at creation.

Question for ya:

1. Do you happen to know a scenario where RESEND_MULTIPLE is practically used? I can't think of any case where you would use the field name for a Control/Info parameter as the Tracking ID codeset to resend the event too. Too me this seems like a bug in the RESEND_MULTIPLE logic.

[Former Member · Accepted solution]

Hi Jacob,

I haven't used the standard one but customized RESEND to handle multiple events a few times before and it worked for me. I usually create Z activities to suit my needs if standard doesn't help;)

Thanks,

Vishnu

[Former Member · Accepted solution]

Hi Jacob,

in the malfunction scenario it is used and for that purpose it was designed:

For the docu:

Notes

The following is an example from the production malfunction visibility process. When a malfunction notification is created, the unexpected event Machine Breakdown is sent to all related manufacturing orders, that is, to multiple event handlers with event handler type Order. Related manufacturing order numbers are stored as control parameters in the Notification event handler.

In this example, the parameters would be:

Parameter-1: MANUF_NO (name of the control parameter and the tracking ID code set)

Parameter-2: C (control parameter)

Parameter-3:  MACH_BREAK (internal event code that is sent to the manufacturing orders)

Best regards,

Steffen

[Former Member]

Hi Jacob,

Just curious to know if you figured out the solution. Maybe it will be helpful for me in my future projects.

Thanks,

Vishnu

[Former Member]

Vishnu,

You bet I can keep you posted. Unfortunately we had some issues in another area that effected us for a couple days. We are back up now though and it doesn't look like the solution we discussed in the thread is going to work for us so we have decided to move the logic to the EH Upd.Acty 2 within the Event Handler type. At this point we should have all the information we require to post the event to the FO/FB handler and then let TM propagate it to the FUs.

I'll try to remember to come close this post out once I confirm this is working for us.

Thanks again for all of your input thus far.

[Former Member]

Vishnu,

Per my previous reply we are close but not quite there. Unfortunately we still don't have the FB/FO Source location available to use it seems in the EH Upd Acty 2 the first time the activity is triggered??? This means that I can't post the event with the source location. This leads to 2 events appearing in the FB/FO and then the 1 propagate event in the FU. Not quite what we want...

FB:

FU:

Again this is happening because the event we are reporting within 'EH Upd Acty 2' does not contain any location information (since it doesn't appear to be in any tables the first time 'EH Upd Acty 2' is called....

[Former Member]

Hi Jacob,

The data should be available in the model ( I_EAI ) even the first time.

Use the sample below in the UA2 FM and see if you can see data:

*************************************************************************

DATA: l_eh_data   TYPE /saptrx/eh_data,
         l_eh_flags  TYPE /saptrx/eh_access_flags.

"    To retreive all data for an event handler:
"
"  l_eh_data = i_eai-eh_model->eh_data( ).


"    To retreive data for the header and one or more EH tables,
"    set the corresponding flag(s) in l_eh_tables:
"
   l_eh_flags-cntrl = 'X'.

   l_eh_flags-expev = 'X'.
   l_eh_data = i_eai-eh_model->eh_data( l_eh_flags ).

***************************************************************************

Now you should be able to see your control param and expected events.

Check and let me know.

Thanks,

Vishnu

[Former Member]

Vishnu,

This worked GREAT we now have the event reporting with the 'Source' location. We are very close, the issue is now the event reports once on the FB handler and is then propagated to TM. HOWEVER, now the event won't propagate to the FU up in TM....

We may be facing a different issue however because it would appear that all unexpected events with a location aren't propagating to the FU????

[Former Member]

Hi Jacob,

It should propagate automatically even for unexpected events. Is the location on the unexpected events from one of the stop location( guessing to be true based on your UA2 usage ), then it should have propagated to FU from FO.

The screen shots from your Sep 10th shows that it's propagated( not exactly what you wanted for FB ).

Don't you see the event at all in FU with atleast "Read from SAP EM" as well?

Check whether you assigned the Event Code to FU on TM->Integration->track and trace.

Try to post an expected event as unexpected with a different location ( use one of the different stop location ) and see if it propagates to successor document.

Let me know.

Thanks,

Vishnu

[Former Member]

Vishnu,

Thanks again for the help unfortunatly the unexpected events that have a location provided are still not propagating to the FU:

1. I won't see the "Read from SAP EM" in the FU because the events are reported on the FB then propagated to TM, then over to FU and down to FU handler. At this time the FB does say "Propagated from SAP EM" however its not going over to the FU.

2. I attempted using a different stop location with no change....

I'm not sure what could be going on. Again if I don't provide a location then the event is propagated to TM, it propagates over to the FU, however the event is reported again on the FB with the stop location....

[Former Member]

Hi Jacob,

Do you mind adding screen shots of the following:

1) /SAPTRX/EVM_HDR record including trxcod/trxid/sndnam/locid1 which you posted.

2) Tracking tab from FB EH

3) Tracking tab from FU EH

4) Your applicable rules ( not complete ruleset ) for this specific event especially any resends.

I will try to simulate it if it's not too much change.

Thanks,

Vishnu

[Former Member]

Vishnu,

We have applied SAP Note 2099044 and that has seemed to help propagate the event to the FU. The only annoying thing now is that we still have a duplicate reporting in FB even though we send with the correct location...

[Former Member]

Hi Jacob,

I had similar issue sometime back on my side and it was a bug on my event type and relevance. Put a break point in Upd. Act2 and ruleset( very first rule or condition ) on the FB side and see if you are seeing 2 events.

If yes, I am sure there must be a issue on Event Type side ( put a break point there too ).

See if it's doing the following flow for FB.

FB Creation ->Event Type->EM Ruleset(FB)->Propogation to TM (FB)->back to Event Type(FB)->EM Ruleset ( FB).

Other scenario maybe:

FB Creation ->Event Type(FB)->EM Ruleset(FB)->Propogation to TM(FB)->Propogation to FU->FU Event Type ->FU Ruleset ->RESEND Activity on FU->EM Ruleset ( FB ).

Somehow EM is receiving 2 events for FB and issue might be on Event Types and it's relevance functions. Also, check the Tracking codes/ids.

See if you can narrow down.

Thanks,

Vishnu

[sukumar_perumalsamy]

Hi Jacob,

trigger an action update from FU BOBF and propagated the event to FO/FB .

Regards

Sukumar

[Former Member]

Hi Jacob,

The BADI interface /SAPTRX/IF_EX_BADI_MESSAGE-CHECK_MESSAGE & BEFORE_PROCESSING is called by BAPI /SAPTRX/BAPI_EH_ADDEVENTMSG and /SAPTRX/BAPI_EH_ADDEVENTMSG02.

Regards

GGOPII