IDOC communication from PI to ECC - parallelization - priorization

[helmut_skolaut3]

Dear all,

I currently face into following issue:

I have to transfer SHPCON Idocs from a legacy application to ECC where with processing the SHPCON in ECC also a printout is generated at the packing station, so it has to be transferred as soon as possible.

In PI i have message priorization so everything in the pipeline goes through very quickly. But then it sits in the tRFC layer. When the system is very busy, the backlog of tRFCs is growing and growing (in WE20 process IDOC immedeatly, so it waits until application post was completed before next LuW is processed). What is the concrete approach to let some messages in tRFC with a higher priority? Can I setup some kind of message parallelization (I have read a bit about SMQS and SMSR, but not sure if this is the right place to play with).

The ideal situation would be to have a certain number of messages that will be allowed in paralell (e.g. 5 sessions?) for those message that are time critical and another "Queue" for all message where it doesn't matter if 1 minute or 30 minutes ....

Any ideas? Any howtos already existing that I have not found yet?

Thanks

   Helmut

[engswee]

Hi Helmut

I'd suggest that you change the partner profile setting to "Trigger by background program" and schedule program RBDAPP01 to process the IDocs in the ECC system.

This is the best practice when dealing with high volume inbound IDoc interfaces.

Refer to my responses in the following threads for further explanation on how it works. My answer in the first thread also includes an SAP Note that recommends such an approach.

Rgds

Eng Swee

[helmut_skolaut3]

Hello Swee,

I had this idea initially. But as mentioned in the initial post, external warehouse system is posting GI (using SHPCON) and the delivery note needs to be printed out from delivery in SAP. If I go through "Collect IDOCs", I need to schedule RBDAPP01 every minute and even so, I have at least a average delay of 30 seconds just due to this !!!

For the moment; I have solved it as I have created an extra RFC destination for those critical SHPCON messages as a copy of the original one. Those SHPCONs now are not longer blocked by other messages that are not time critical (yes, those I could switch to "Collect IDOCs" but then I have to review it for each single case and the next consultant setting up a new connection will use again "Process immediately" 😉

I also saw Note 1051445 but it was already implemented in our system ... And I am playing with "Max Connection Time" parameter currently in SMQS ...

Regards

   Helmut

[engswee]

Hi Helmut

If your requirement can't allow a 30 seconds delay, I guess the background option is out then.

For your solution, can you clarify that you created an additional RFC destination in SM59 and used it in a separate IDoc receiver channel solely for the SHPCON interface? If yes, I guess you can additionally tweak the "new" RFC destination to have more max connection and increase the time as mentioned in the following Wiki

tRFC process slow in SM58 and Max.Conn is not fully used in SMQS - ABAP Connectivity - SCN Wiki

Rgds

Eng Swee

[helmut_skolaut3]

Thanks again Eng Swee,

you have got exactly my point and what I did. What you have mentioned in the wiki article in your last post is also was is describted in the note 1051445, but the wiki explains it better 😉

I have always a bottleneck in the afternoon on tRFC so I will check the situation this afternoon again and can report if my changes helped.

Regards

   Helmut

[Harish]

Hi Helmut,

One option is to package the IDOC in ECC so it will less connection to PI. this way you can improve the performance.

refer the below doc

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/2016a0b1-1780-2b10-97bd-be3ac6221...

[helmut_skolaut3]

Hi Harish,

the problem is to send messages from PI to ECC not vice-versa in your reply. The document was interesting to read, but the problem I am sure, will not be solved by packaging, as the bottle-neck is is the sequential processing of the messages!

Regards

   Helmut