This nice little solution was realised a couple of month ago in an Chicago project in the United States. Never seen the "Go-Live" light but nevertheless very useful for EOIO scenarios in Master Data Distribution Scenarios 😉
This Blog will give you a solution of distributing master data in content based and content dependent generated queues inames n an End2End scenario from an Sender Idoc communication via PI to an J2EE based Receiver Adapter.
Master Data Distribution and its Challenge
We all know that Master Data Distribution in SAP can easly be maintained with the Change Pointer Concept and its IDOC types. When the distribution of depending IDOC masters is needed (e.g. MATMAS has to be distributed befor an INFREC because of the needed master first befor processing the inforecord data) there has to be instanciated a mechanism which takes care about the right order of master data distribution.
Simple Example which might fail if you using even NO queue:
Step 1. Create a Material --> Distribute it --> Failes in PI Message Mapping --> Will not be delivered to Target System.
Step 2: Create a Condition Record for the previous created Material --> Distribute it --> Will be delivered to Target System --> Target System has not received Master record --> FAILURE !!!
The Inefficiency of using static EOIO queues
To distribute all master data correcty without over passing a recent master record by a previous master one might think of running/processing all the master records in one big "master queue". This solution is very unefficient because if e.g. the master with ID=13 fails (ok, its corresponding info record then would also fail what is correct in this case) BUT (!!) also the master record with ID=14 failes because it is running in the same queue. The master record with ID=14 and its corresponding info record (might) not have any relationship to the master with ID=13 and therfor the master with ID=14 should be processed even if the master with ID=13 fails in an EOIO scenario.
Solution using content bases dynamic master record depended EOIO queue names
Step 1
TA se37: copy existing function module for IDOC rule queue, e.g. IDOC_QUEUE_NAME_MESTYP and extend your rule logic with your own coding (I will provide sampe coding). DON’T change the FM signature.
"
Sample Coding for the Funktion Module will be provided via my webside.
Step 2
TA We85:Assign Function module to IDOC rule
Step 3
Assign rule as queue rule for outbound IDOC processing
Step 4
TA bd21: send a Material with MATNR=13 sequentially 2 times
Step 5
TA smq2: (Perquisite: The first message fails. Routing Errors, Mapping errors occur ones) Find the 2 entries in the same inbound queue XBQI00000000013. Here MATNR from Segment E1MARAM is suffix of queue name. Result: The content based (MATNR) queue name was generated and both messages are running in the same queue.
Step 6
Fix all errors in the integration engine and restart the message, Now monitor the message in the Runtime Workbench. (Perquisite: Error in File Adapter or any other wrong configured Java based Adapter). If instead an error occurs in e.g. a J2EE File Adapter on the Adapter Engine, you find 2 entries in the JAVA queue of the used Receiver File Adapter.Go to --> Component Monitor --> Adapter Engine --> Engine Monitor --> Additional Data --> Message Details.
There you see the same now JAVA based Message Context with the assigned queue name with its suffix '13'.
Step 7
Finally investigate the SOAP Message in the TA sxmb_moni and see the content based queue name
è voila. Now you are able to configure content based created queue names in EOIO queues in the idoc outbound processing.
CODING APPENDIX
2 Comments
