PI to ECC: serialized IDocs - which best approach ?

[Former Member]

Hi,

before to continue in a way... I would like to be sure I'm the good path...

My flow is "File -> PI -> ECC idocs (unbounded)", but in ECC, IDocs DEBMAS should be processed in the exact same sequence as info was in the source file: DEBMAS_1 before DEBMAS_2, before DEBMAS_3 etc...

What's the best approach to do this Serialization on my DEBMAS IDocs ?

• serializing IDocs., easy in PI, but currently in ECC I'm facing to a more complex situation than expected... with idoc in status "75"...
• use of ALE Serialization based on Message Type.
• use of EDI_DC40-SERIAL: IDoc field.
• ?! ...

Many Thanks.

Mickael

PI 7.11 + ECC 6.0 (702)

[rajasekhar_reddy14 · Accepted solution]

Hi,

Use EOIO mode in file channel, it gaurantees sequence processing.

I have implemented serialization concept in sender IDoc scenarios using Serialization using message type,easy approach.

Thank you,

Raj

[Former Member · Accepted solution]

Hi Raj,

"Use EOIO mode in file channel, it gaurantees sequence processing." yes but this option is only inside PI (if I'm not wrong). Moreover as in my case I have only one daily file and as I create an "unbounded DEBMAS", in PI in fact I have only one XML message.... so... I'm not really concerned by EOIO inside PI... but more of what's happen after the receiver IDoc adapter... so in ECC.

My question is mainly in the receiver system (e.g ECC), which will open my "unbounded IDoc" to create several IDocs DEBMAS, and will process them (certainly not in the same sequence). Here, in ECC, my IDocs DEBMAS should be serialized.

Do you have done something like that ?  with an "unbounded" IDoc (MaxOccurs=Unbounded) ?

Any feedback is welcome 😉

Regards.

Mickael

[Former Member · Accepted solution]

Hi Raj,

I did a test, and in fact the queue name defined in Sender CC (file) is of course used in PI, but it also used in ECC (under WEINBQUEUE) when option "Queue processing" is used in CCR of Idoc: I have "SAP_ALE_MyQueueName". Good news... So that's solved my issue #2.

The side effect of that, it's the ECC queue is used for both ADRMAS and DEBMAS. So "Queue Processing" has to be flagged for both. Well, could be acceptable for this flow...

So that's solved my issue #1.

Last step: issue #3 : to automatize the process of these Queue entries.

Thanks.

Mickael

[Former Member · Accepted solution]

Hi all,

Issue #3 is solved: Messages are in fact automatically processed by SAP, no need to go in WEINBQUEUE to do something manually (except eif error).

Conclusion:

for my flow "file to 2 unbounded idocs: ADRMAS + DEBMAS", we should have ALL these options:

1. in Sender CC (file), use option "QoS = EOIO" + a queue name (eg. MyName)
2. in Interface Determination, for which we have a mapping to send ADRMAS and DEBMAS, use option "Maintain Order at Runtime".... just to have ADRMAS before DEBMAS process.
3. In Receiver CC of ADRMAS, use option "Queue Processing".
4. In Receiver CC of DEBMAS, use option "Queue Processing".
5. important: option "Queue Processing" HAS to be used for BOTH idocs: ADRMAS + DEBMAS.

And so,

1. in PI monitoring, we have queue: "XBQO0___MyName".
2. in ECC, we have queue: "SAP_ALE_MyName".
   1. both IDocs use this queue and are automatically process by SAP.
   2. if error, actions to do has to be done in Tcode WEINBQUEUE.

I will do some stress tests...

regards

Mickael

[MichalKrawczyk]

Hi,

>>>>serializing IDocs., easy in PI, but currently in ECC I'm facing to a more complex situation than expected... with idoc in status "75"...

why is this complex ? it's a typical and you can monitor this queue (weoutqueue, weinbqueue)

on the basis of the queue name (so debitor number for example) - does it get any better ?

I'm using this for debmas too (to handle adrmas) and it works without any issues,

BTW

all approaches also described in my book:

http://www.sap-press.com/products/Mastering-IDoc-Business-Scenarios-with-SAP-NetWeaver-PI.html

Regards,

Michal Krawczyk

[Former Member]

Hi Michal,

With Serializing Idocs, yes we have WEINBQUEUE... to monitor... but here the issues I have seen for the moment, which is for me (for the moment) not so easy as just flag option "Queue processing".

1. 1st issue:
   1. in PI, I have "unbounded" option on ADRMAS and DEBMAS.
   2. in PI, in Interface Determination I have option "Maintain Order at Runtime" with ADRMAS (1st) and DEBMAS (2nd)... coz I want my ADRMAS before my DEBMAS... and I do not want to do a serialization group in ECC (not for the moment).
   3. in PI, I have "Queue processing" only for the CCR of my DEBMAS, but not on this one of my ADRMAS.
   4. And... in ECC, in tcode WEINBQUEUE, what I have ? ADRMAS and DEBMAS in a the same queue "SAP_ALE_MMFSERIALIZE000".   This is for me the 1st issue !
   5. I saw perhaps a OSS note, but it was not for SAP BASIS 702.

1. 2nd issue:
   1. now, if I have a 2nd file, then... in ECC I will have my ADRMAS and DEBMAS in another queue, in tcode WEINBQUEUE, for instance "SAP_ALE_MMFSERIALIZE111".
   2. So that means my DEBMAS of this 2nd flow are not serialized with those of 1st file ! That's a big issue, which seriously limited the interest of having a serialization... in my mind.
   3. perhaps solution is table IDXQUEUE in ECC, but I beleived it was for oldest systems (SAP web AS 6.0 or lowest)...

1. 3rd issue:
   1. For the moment, my idoc are in status "75" in ECC... until... I use manually this tcode WEINBQUEUE in order to process this queue !
   2. Can we automatize the queue process ? (like in Abap proxy by just registring this queue in SMQR, for instance).  in standard ! not by a specific program like I saw !

1. 4th issue:
   1. With Status "75", I cannot used BD87 to reprocess this idoc. So this is not like "64". So Support Team has now to be sensibilized to WEINBQUEUE tcode.
   2. well, this 4th issue can be discussed, as it's more relating to training and process in the organization...

So now, you understand, before to search and find a solution for each of these issues, that I would prefer to know if option "serializing idocs" (Queue processing in CCR) is really THE solution. Easy ?!

Regards

Mickael

P.S: sorry but in your book, you did not really detail this case (only 2 or 3 pages and mainly for the flow ECC to PI). 😉

[Former Member]

Hi Mickael,

I had come across similar issue where we used to receive multiple files with each file sending multiple idocs to ecc. However this was for WMMBXY idoc. Even we could not implement serialization, so we set in partner profile not to process the idoc immediately and processed it through background job.

This may not be the best solution but might work for you.

Thanks,

Girish

[Former Member]

Hi Girish,

yes, in fact that's my plan B (or C): Procces in background + job on RBDAPP01 with a packet size = 1.

I would prefer a real serialization.... so I continue to investigate...

Thanks.

Mickael