IDOCs from XI into R/3 waiting in queues

[Former Member]

all,

I have a file to IDOC scenario. Based on filters, the file can create 2 types of IDOCs "A" and "B" and then sent via BPM (due to another filter) to R/3 using 2 IDOC channels

The challenge is, somehow the IDOCs alternate as "A" , "B" in SAP_ALE_XI_nnnnn queues on R/3 visible in the WEINBQUEUE tcode and when an IDOC "A" is in error, it holds up the whole queue.

This transaction was not meant to be EOIO nor is it set anywhere?

How can I get them to process in parallel without acting serial ?

m

[Former Member · Accepted solution]

Hi,

You can do this in BPM in the Block step by setting the mode to ParForEach.

Hope it Helps.

Regards,

Joslyn

[Former Member · Accepted solution]

Hi Joslyn,

therefore he needs a multiline container element. As I understand, this is not the case.

regards Mario

[Former Member · Accepted solution]

Mario - Thanks for your response..

But in response to your first answer, the IDOCs are being routed to separate IDOC adapter channels...with different names obviously..

m

[Former Member · Accepted solution]

so the problem is on the R/3 side (receiving system)?

Regards Mario

[Former Member · Accepted solution]

Yes - issue in R/3 !!! Everything has cleared XI successfully. When the IDOC during posting has an error, it holds up the queue. So, there is a need to monitor WEINBQUEUE, remove IDOCS in error and let others proceed. Seems like a bad way to manage.

Would adding entries in IDXQUEUE help? Seems like it will force EOIO in a specific queue. My challenge is to not have EOIO

m

[Former Member · Accepted solution]

Thats the way I would do it (but I am also an ABAP developer)

1) Find out the processing function module for you IDOC Typ

2) copy this function Zfunction

3) modify the coding: select the "bad " queue > somthing locked > unlock

4) replace the origin function with the Zfunction for processing the IDOC

*******************+

On the other hand, try a different forum (SAP BASIS)

Good luck

Regards Mario

[Former Member · Accepted solution]

Hi,

For this particular idoc types, in we20 put the processing mode as 'Trigger by Background Program'....this way the IDOc will be in 64 status and not be processed immediately...

Schedule the report RBDAPP01 to process idocs in status 64..

Thanks.

[Former Member · Accepted solution]

Deepu - Will this help in making the processing parallel without putting it in queues? Thanks!!

m

[Former Member · Accepted solution]

Hi,

I have worked on scenarios where IDocs are sent from XI in tRFC mode...

I assume in your case it is qRFC..right?

My earlier answer pertains to tRFC...

How are you sending it usinf qRFC ? logically if the partner profile setting is process later , then the idoc from the qRFC inbound queue should keep this in 64. Then the RBDAPP01 just reprocesses it later. It is a disconnected process and does not affect the inbound idoc queue.

Thanks.

[Former Member · Accepted solution]

you are using the "queue processing" in the IDOC receiver adapter...right ?

That means the EOIO gets transferred and the IDOCs are in qRFC...here if an IDOC processing fails..the queue is stuck...this is ..i would say a desired behaviour...you need the sequence to be maintained is it not?

However, if you do not need the queued behaviour, switch of the "Queue Processing" flag in your recevier IDoc channel.

Thanks.

[Former Member · Accepted solution]

Hi -

Do you have two inbound interfaces (corresponding to your 2 idoc types) configured in your interface determination?

If so, uncheck the "maintain order at runtime" checkbox.

Regards,

Jin

[AntonioSanz · Accepted solution]

I had the same issue, and in my case I have uncheck the "maintain order at runtime" checkbox as Jin Shin commented and that solved my problem.

Regards,

Antonio Sanz

[Former Member]

Hi Maddux,

you wrote the IDOCs pass BPM. Why don't you create a branch

a) branch A for A

b) branch B for B

In every branch give a queue name in the send step.

I do not surely know if this will work.

Regards mario