IDoc Packaging with PI 7.11 (and above)

[Former Member]

Topic sounds very familiar? Yes, it is!

Although, this had been discussed many-a-times in the past across blogs/documents it's only been put down to share it from a different perspective : Practical usage of various related parameters while doing configuration for IDoc packaging.

So, instead of discussing it again from scratch idea here is to quickly analyze & understand the relation between parameter values mentioned in IDoc sender adapter, package size in partner profile and value set in report used for sending IDocs in a batch.

Each of us will be aware of below basic configuration steps used to collect multiple IDocs in a batch and create single/multiple messages.

Configuration in ECC System using collect IDocs option with partner profile

Define package size in PI with IDoc sender adapter.

Report (RSEOUT00) which will be executed/scheduled as a background job to send IDocs at once to PI.

So, once this report is executed all IDocs will be send to PI in a single/multiple messages depending upon various values set across ECC & PI. But, for desired output one often think "what" values should be maintained in those parameters. Here is analyis snapshot :

Now, sometimes this IDoc packaging is required with same IDoc in PI but used across numerous intergration scenarios. And for each & every such scenario has a different collection pattern which is intended to be used for creating a single message/file for vendors.

Say, integration scenario 1 needs data for 100 IDocs in a single file while scenario 2 needs data for 200 IDocs in a single file. In such a case, if IDoc sender adapter has a parameter value as "150" it will suffice for 1st case but not for other.

Tip: In that case, we can set package size in IDoc sender adapter to a maximum possible value (when evaluated across all such interfaces). Afterwards, no of files/messages to be created will be based upon parameter value set/used in partner profile/batch job keeping package size in PI constant.

Hoping, this will be useful for technical as well as functional experts (to understand behaviour, for peculiar IDoc collection requirements) at a glance and can serve as quick reference while deciding parameter values with feasible options for improved design.