Possible to Add FO/FB Handler Type to Event Message???

[Former Member]

Question:

Is it possible to add the FO/FB handler type to an event message posted to the FO/FB and then resend the message to each FU within the FO/FB?

Question 2:

Can this be done through standard configuration without creating Zfunction modules? If not can it be done with the creation of a z function module, please help if so.

Issue I'm trying to resolve:

We have events that are reported FO/FBs that need to progagate down to the FUs; HOWEVER, depending on the FO/FB type will determine within the FU handler whether or not to resend the event to SAP VMS? I'm having issues figuring out how the FU event handler can find out the FO/FB handler or TM document type.

Any ideas are greatly appreciated.

[former_member194343 · Accepted solution]

I think I would try to handle this in TM, because propagation of event messages from FO/FB to FU is purely handled by TM in the standard. There is a determination DET_EXEC_AV in the EXECUTIONINFORMATION node of the TOR object which handles this. So I would start from this very determination to evaluate whether to send a message to SAP VMS. Of course, in this case it is easy to check the type of the successor FO/FB and apply some logic to decide on the sending.

[Former Member · Accepted solution]

Michael,

Thanks for the response. I'm a business analyst so if I go the route of using TM propagation where would the determination logic go to determine whether or not the event should be pushed to the VMS EVENT HANDLER? Is this going to need to be developed or can it be configured?

Just asking the questions.

Note: TM is not aware of the VMS event handlers. We are using the 'RESEND' method to send the events from the FU handlers to the VMS handlers based on a control parameter on the FU handler. My ideal solution would be to some how check the successor handler type or send the handler type to the FU handler and then have a condition in the RESEND rule to only resend to VMS handler depending on the FO/FB type...

[former_member190756 · Accepted solution]

Hi Jacob,

you can create a Condition Function and inside you could check it.

But i don't see the advantages to your current solution with the Control Parameter.

Best regards,

Steffen

[former_member186607 · Accepted solution]

Hi Jacob,

I would propose the following in this case:

1) Use the standard propagation for the events in SAP TM to handle the propagation between FO/FB and the assigned FUs -> configuration only

2) Create your own extraction function modules in SAP TM for the event types that shall be sent to SAP EM. Here you can add the TOR Type of the related FB or FO as a parameter in the event message -> Z function modules needed

3) In SAP EM you can easily determine in the rule set if RESEND shall be done since you have the FO/FB type available

Best regards, Daniel

[Former Member · Accepted solution]

Daniel,

I like you answer thus far. It's the closest solution in our current situation. I'm new to SAP EM and just need a bit more clarification and a picture possibly.

Question 1:

So when you say extraction function which type of extraction function are you referring to? Event Data Extractors???

Question 2:

When does the extraction function get executed? How does that flow??

Event message (tracking ID FO) comes into EM, goes through ruleset and sends to TM FO, propagates to TM FU, SOME SORT OF trigger for the extraction within EM FU handler, THEN EM FU handler ruleset is executed, RESEND condition is checked, and if condition is true the event is send to the VMS handler???

Thanks in advance for the patience.

[former_member186607 · Accepted solution]

Question 1: Exactly, Event Data Extractors. Here you can define what data shall be sent with the event message from TM to EM.

Question 2: EvMsg is reported to FO in EM -> propagation to FO in TM -> propagation inside TM to the assigned FUs -> this triggers extraction for this FUs and the event extractor is called for the new event -> EvMsg is sent to FU in EM -> rule set is executed -> RESEND condition is checked

More information regarding the propagation of the events you can find in this scenario guide: http://scn.sap.com/docs/DOC-33550

Best regards, Daniel

[Former Member · Accepted solution]

I'm liking this answer so far. 1 additional question; Where on the Event Message would you add the FO/FB document type to use in the rule condition configuration?

[former_member186607 · Accepted solution]

In your event extractor you can add an entry in table CT_TRACKPARAMETERS to add a parameter to the event message sent to SAP EM. The single fields could be populated like in the following example:

EVTCNT -> reference to the related entry in CT_TRACKHEADER

PARTYP -> possible values are 'C' (control), 'I' (Info) or ' ' (Event Message Parameter), more details on this below

PARAM_NAME -> e.g. Z_CAPA_TOR_TYPE

PARAM_INDEX -> not needed

PARAM_VALUE -> <FB/FO TOR Type>

ACTION -> 'C' (only needed for control or info parameter

Depending on how you want to handle the parameter value in SAP EM you have the following options on which parameter type you want to use:

(A) Event Message Parameter: By this the parameter will be persisted for every event message, additional configuration for event message extension table in SAP EM is needed for this

(B) Control/Info Parameter: By this only the parameter value of the last event message will be persisted on EH header level - no additional configuration needed

In the rule set you can access the parameter value like this:

(A) You can directly access the value via metadata tag for an activity parameter, e.g. <EVM_HDR_EXT-Z_CAPA_TOR_TYPE> (if the field name in the event message extension table is the same as the parameter name)

(B) You should add activity PARAMETER_CHANGE_NEW in you rule set at the beginning - this will update the control or info parameter - then you can access the parameter value e.g. via metadata tag <CNTRL-Z_CAPA_TOR_TYPE> for actitivy parameters

Best regards, Daniel

[Former Member · Accepted solution]

Thanks again Daniel this is great information.

From what you've suggested I would think to use 'CHECK_PARAM_VALUE' within a 'Multitask Activity' with the final task being a RESEND. I'm not as familiar with the Multitask activities as I am with the conditions. Am I going to be able to string multiple param value checks in a row in order to determine if RESEND should be executed???

If I was to do a condition it would like such:

IF Z_CAPA_TOR_TYPE == 'FO01'

  OR Z_CAPA_TOR_TYPE == 'FO02'

  OR Z_CAPA_TOR_TYPE == 'FB01'

But I'm not able to access the 'Z_CAPA_TOR_TYPE' in a Rule Condition am I? I mean of course I could probably have a Rule Condition Function that could be created but if I can avoid that would be great.

[former_member186607 · Accepted solution]

Hi,

rule condition would be no option here - anyway they should not be used if performance is critical.

But you could implement a rule condition function. There you could check the parameter value in I_EH_MODEL-MY_EVM_DATA_REF->PARAMETERS . Then you could do the evaluation right there and you would not need the above described activity to update the parameters on the EH first.

When using multitask activities you could use CHECK_PARAM_VALUE several times to do the evaluation without extra coding. Then you need first the activity to update the parameter values (e.g. PARAMETER_CHANGE_NEW) , then do all the checks and if one of the checks is successfull, do the RESEND:

Details of check task:

I think how to do this heavily depends on the number of TOR Types to be checked 😉

Best regards, Daniel

[former_member194343 · Accepted solution]

Had a similar question recently and I found no way to model such a parameter check with a multitasking activity, because you can't link the results from multiple activities with an OR operator (i. e. check whether a parameter has one of a set of values). Or was I just not able to find this functionality?

By the way: Thank you Daniel & Steffen for your excessive support here!!! Wish there was similar SAP involvement in the SAP TM community...

[Former Member · Accepted solution]

Just a note on what you said here?

'There you could check the parameter value in I_EH_MODEL-MY_EVM_DATA_REF->PARAMETERS . Then you could do the evaluation right there and you would not need the above described activity to update the parameters on the EH first.'

I think I would still need to update the parameters because how would the rule condition function be able to determine the FO/FB type if it wasn't added to the Parameters upon extraction from TM. Was this just an overthought or am I missing something...

[former_member194343 · Accepted solution]

Yes you are, but it also took me a long time to see clearly here (at least I hope I do now...).

When you post an event message with the PARAMETERS table filled, you can do different things with these entries:

a) You can use them to update info/control parameters on the event handler. Therefore you need to use PARAMETER_CHANGE(_NEW) activity in the ruleset.

b) You can just persist the parameters with the event message and leave the EH unchanged. Therefore you have to define an event message header extension, event message parameters, and the mapping from the PARAMETERS to the actual persisted parameters.

c) You may choose not to persist the entries in any way, but just evaluate them in the ruleset (and possibly send them to another system, for example TM). This is what Daniel suggested. In this case, you have to do neither of the things mentioned in a) and b).

[Former Member · Accepted solution]

I understand where you are coming from Michael but I think I'll have to pass the FO/FB type with the event message because:

1. I don't believe that within the FU Handler you are able to access the FO/FB type from TM without the parameter passing through the extraction function to get it into EM.

2. Secondly, even if you were able to access the FO/FB type for a FU how would you know which FO/FB the event was posted against; since a FU can/will be within multiple FO types and FB type.

Just my notes/thoughts.

My plan is use the extraction function to extract the event data including the FO/FB type to add it as a control parameter on the FU handler. Then I'll be able to use a rule set condition to determine when I want to send to the VMS handler.

[Former Member · Accepted solution]

Daniel,

I'm having an issue with the development/configuration of what you are suggesting.

1. The same event code is relevant for both FO and FU event handler so when the event extractor gets called it pulls the FU TOR_TYPE and adds it to the control parameter rather than the FO.

2. I'm sure there is another way to determine the FO type from the FU for my (1.) issue. However, what if the FU is planned within a FO and a FB. The event is posted against the FB handler how do I know to extract the FB TOR_TYPE and not the FO TOR_TYPE?

3. Lastly, I'm struggling just a bit understanding these event extractors. So do I require event extractor for each internal event code I wish to send to EM? It would appear that these extractors execute whenever my FO or FU gets updated. So it must be the case that the extractor function is not what determines what should be posted to the FU when the event is propagated from the FO, correct? The extractor function is just intended to extract all event data for EVERY event within the extraction function??

Within the document you suggested above I'm confused by this sentence: 'The Event extractor of the freight unit in SAP TM propagates...' If the event type is EM relevant then it's event extractor will ALWAYS execute and is not specific to the FU. So what is meant by 'event extractor of the FU'??

Thanks for the help.

[Former Member · Accepted solution]

UPDATE:

1. We have updated the event extraction function in the following way and it seems to work when we post against the FO.

2. We plan to now test with a FU that is planned within a FO and a FBing. I'll then post an event against the FB and see if the 'Z_TOR_TYPE' parameter is updated to the FB type. Then If I post an event against the FO will the 'Z_TOR_TYPE' parameter update to the FO type?

3. At this point this extractor will only extract the 'Departure' event. Do I need a separate extractor function for each event I plan to send from TM to EM? Is there an effective way to use just 1 extraction function? If I can use 1 extraction function for the events do I have to code in each internal event code? I ask this because if we add a new internal event it will require us to update the extraction function....

4. Additional Question: Am I using the 'PARAMETER_CHANGE_NEW' method appropriately in my rule activity? Should I be calling out the parameter directly or what I'm doing correct?

Thanks again for the help and I hope this post is a bit more focused.

[former_member186607 · Accepted solution]

Hi,

let me try to answer you questions:

1) & 2) I would recommend to determine the related FO/FB like this: Inside the extraction function module, you will determine the changed/created EXECUTIONINFORMATION node. In this you find the field ORIG_EXEC_KEY, which is the key of the EXECUTIONINFORMATION node which represents the original execution information, i.e. if the event has been reported for freight order X and then has been propagated to freight unit Y, the ORIG_EXEC_KEY in the EXECUTIONINFORMATION of FU Y is the key of the corresponding EXECUTIONINFORMATION of freight order X. This should also be availbale in the application table TOR_EXECUTION_INFO. Therefore you can simply read this one and there you find the ROOT_KEY which will give you the key to read in TOR_ROOT - and there you find the TOR_TYPE of the freight order to which the event has been reported.

3) You do not necessarily need an extractor function for each new event type. You can either use one extractor function for all your event types or you can implement a new one for each event type. If you want to use one single extractor function, you have to take care that you determine the right event code (and all other data if there are differences between the event types) inside your coding. But this should be not very complicated. 

4) If the information for parameter type, name, value and action is send along with the event message (in the TRACKPARAMETERS table) you do not need to use any of the activity parameters and the related parameters of the EH should be updated/created by this activity.

Best regards, Daniel

[Former Member · Accepted solution]

Daniel,

We’ve developed what you have suggested and we think we’ve got a working solution that has had minimal testing. I’ve been asked by the developer to ask a couple additional questions:

1. With your solution how do we identify the FU and FOR “Event” key(ORIG_EXEC_KEY) when we have both in lt_tor_execinfo when the Event Extractor is triggered?

          A working solution he is using is this:

Get Root node data for the
Execinfo Data from main table TOR_ROOT of events and based on tor category ‘TO’
or ‘BO’, read table lt_tor_root to find the TOR_TYPE.
Finally move move control parameter to
CT_TRACKPARAMETERS.

     2.  Additionally, he had questions about performance since this Event Extractor (extracting all of the events and determining the FO type) will be executed with any/all changes to FU/FO/FB. Are there performance concerns that should be considered within this function?

[former_member186607 · Accepted solution]

Here are my comments:

1) Assuming we are in the event extractor for the FU event -> identify the related EXECUTIONINFORMATION -> with ORIG_EXEC_KEY get the EXECUTIONINFORMATION of the capacity TOR -> take the ROOT_KEY to get the root node entry for the capacity TOR out of lt_tor_root -> take the TOR_TYPE and add it to the parameter table

2) The event extractor should NOT be executed for every change of a TOR - before the relevance function is executed, which should determine if an event shall be extracted or not. The determination of the TOR type should not be that expensive, since no new data has to be retrieved. All the necessary data is already available anyway. The READ statements should then all be done in most efficient way with BINARY SEARCH or primary/secondary key if possible. If you have configured the direct output agent to run in asynchronous mode, the execution time of the extractors will at least no add up to the dialog response time. More info regarding performance of the integration between TM and EM you can find in this document: http://scn.sap.com/docs/DOC-53299

Best regards, Daniel

[Former Member · Accepted solution]

Daniel,

Thanks again for all of you help we now appear to have a working solution.