Did you look at idxp and idxpw transaction? Do you have a scenario where ccBPM has to wait for long hours to aggregate Idocs? Doesn’t it hit performance? Is there a better way for handling this? Do you like to know some new feature? Read on!.
We could have come across a scenario where we have to aggregate 10 Idocs and send it to a file. All the 10 Idocs might not come at the same time. The simple solution that comes to our mind is to use a collect pattern in the ccBPM with a dead line-monitoring branch waiting for some X hrs. The problem with this approach is ccBPM has to be active until all the 10 messages are received which is memory intensive and time consuming. For Ex: 1st Idoc is triggered at 10 A.M and last Idoc is triggered at 6 P.M. ccBPM will be active once the first message is received and waits until remaining 9 idocs are reached. Or we might design a ccBPM to wait for 4 hrs and collect the idocs received within 4 hrs and post it as file. Both have a performance impact. We can get away with this bottleneck if the idoc adapter caches the idocs and sends it to a ccBPM at a single shot and we can re-design ccBPM to just wait for 1 or 2 minutes depending on the volumetric. Idoc message packages setting allows the idoc adapter caches the messages in the queue until the number specified in the maximum package entries is reached. It triggers all the entries in the queue once after the last idoc is reached.
Idoc Message Package Settings:
We have to apply the message package setting for every idoc that has to be cached in the adapter queue.
1.Pick the idoc number from idx5 transaction for the idoc that has to be processed as message package. Go to IDXSNDPOR table using SE16 or SE11 and pick up the field GUID (Message Id) for the idoc number.
2.We need to activate the Idoc message package option and that is done in idxpw transaction. We have to copy the GUID that is picked previously into the message id field of idpw transaction. Maximum Package Size tells the Idoc adapter that it has to send Idocs to the ccBPM only when it has received that many idocs. If we set it to 10 then idoc adapter caches the idocs in the queue until the last idoc is received. Once the transaction is executed successfully we can see the entries in the message filter and job through SXMB_ADM->Event Driven Message Processing.
3.We can monitor the entries in the transaction idxp .We can monitor idocs with message package settings here.
4.Once we have configurations are done we can trigger 2 idocs and check the messages that are waiting in the queue package using tcode sxmb_moni and ccBPM instance is not created. Now trigger remaining 8 idocs from the sender systems and check the tcode idxp, which displays that there are no messages in the Idoc adapter cache and messages are successfully processed by the ccBPM and we can see the PE instance in second figure shown below.
Screen shots when 2 Idocs are triggered initially:
Screen shot when the remaining 8 Idocs are triggered:
This approach is very useful as there is drastic impact in the performance. However the problem is “What happens if the 8 Idocs does not come even after 4 hrs due to some problems in the sender?”. We see all the messages stuck in the queue and file creation will be delayed which is not desired. We can schedule the SXMS_UNPACK_MESSAGES for every 4 hrs that can trigger the cached idocs even if the required number of idocs set in the package size parameter are not received by the idoc adapter. It will clear all the entries in the idoc adapter queue.
I have gone through the SAP help but did not get any useful pointers for achieving the feature. I explored it on my own and blogging as it can be useful for many. One more fascinating thing about this exercise is that I made it before XI champion michal.
15 Comments
