ODT30 TM EM Visibility Scenarios

[ZenonK]

Hello Gurus.

I'm presently implemeting ODT30 for several customers.

When I post an Actual Event (e.g. Load Begin) in the TM Execution tab it calls  EH_POST and /SAPTRX/BAPI_EH_ADDEVENTMSG_02.

In EM this recreates the EH and then reposts all the old messages and then posts the new message LOAD_BEGIN.

I'm considering changing the design  so that EH_POST is not used when posting an Actual event.  If changes are required to any EH Parameters I can pass those changes in /SAPTRX/BAPI_EH_ADDEVENTMSG_02 at the same time as sending the Actual Message for LOAD_BEGIN.

I think this design would be more efficient and add performance.

Any thoughts?

Cheers.

Zenon.

[former_member186607 · Accepted solution]

Hi Zenon,

the recommended approach would be to implement a relevance function for the application object type, which fits to your scenario. You are right, the relevance functions, which is delivered with the ODT30* AO Types are not very specific and therefore every change on the freight document leads to an update of the corresponding EH. But as soon as you know which updates of a freight document are relevant for your EH, you can implement a much more specifc relevance function and by this prevent all the unnecessary updates of the EH. This is also mentioned in this document: http://scn.sap.com/docs/DOC-53299

However, normally the EH should not be recreated and no reprocessing of all reported event messages should happen, if a "dummy" update is done after reporting an event like Loading Begin. Normally the recreation of an EH only takes place if the expected events are updated.

Best regards, Daniel

[ZenonK · Accepted solution]

Hi Daniel.

I checked your document and tested  /SCMTMS/IF_SEND_TOR_DATA~GET_ADDITIONAL_DATA.

How does this work?

I guess we add the addiional data to table ct_additional_data then reference this table in the normal extractor functions (e,.g. Control Parameter Extractor)

Thanks,

Zenon.

[former_member186607 · Accepted solution]

Hi Zenon,

yes, your are right. Did you already check the example implementation in class /SCMTMS/CL_GET_ADDITIONAL_DATA? There you can see an example on how the additional data tables can be added to CT_ADDITIONAL_DATA. These can later be accessed again (e.g. in extractor functions) like the standard application tables by using the "tabledef", that you used when adding the tables.

Best regards, Daniel

[ZenonK]

Thanks for the input...

[former_member190756]

Hello Zenon,

another option is EH_CHANGEABLE flag if you really sure that you don't need any updates through EH_POST.

The EH_CHANGEABLE flag disables all updates through EH_POST but allows normaly Event Message processing.

But for the TM scenarios the way from Daniel with the relevance function should be the better one.

Best regards,
Steffen

[ZenonK]

Hello Steffen.

Is EH_CHANGEABLE the flag I can see in the EH list?

Is this only set via abap and RuleSet? 

Yes Daniels document looks good for the TM Scenarios.

Thanks.

Zenon.

[former_member190756]

Hello Zenon,

yes you can set it in the Rule Set:

To unlock it i only know method:

/SAPTRX/CL_EH_DET_INTF_CNTRL=>UPDATE_EH_HDR_STATUS

So you should be careful here.

Best regards,

Steffen

[Former Member]

Hi Zenon,

When you consider this approach we have to think twice whether you can apply this design.  Because Event Message BAPI doesn't hold few things like Application object ID, Acknowledgement data etc

The following table provides an overview of which data you can add, change, or delete through BAPI event message only, so if you are expecting anything on event handler BAPI, then you need to incorporate into the BAPI message.

	Add	Change	Delete
Info parameters	X	X	X
Control parameters	X	X	X
System parameters	-	X	-
Query IDs	X	X	X
Tracking IDs	X	X	X
Additional tracking IDs	X	X	X
Event handler statuses	-	X	-

Again, if you have custom BADI /SAPTRX/BADI_EH_S called on your EH_POST then you need to consider on your design,

This approach quite tricky and cumbersome work.  When you do SAP EM upgrade then need to check any new methods implemented and called in EH_POST by SAP, then you need to implement in your new BAPI message design.

I have always request customer to leave the standard SAP designs (Can call both EH POST and EM Message) and copy and make custom on according to their requirements.  Because down the line, it will cost TCO on customer side if we break the standard changes.

Regards

GGOPII