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
