EOIO or BPM for receiver SOAP messages

[Former Member]

Hi all,

In our IDOC - XI - SOAP (R/3 4.7 - XI 3.0 SP17 - WebService) scenario we have a requirement from the receiving WebService that we cannot send two messages to close together (say within one second) in order to allow the WebService time to unpack the message, transform it and forward it to the legacy system. How the WebService is implemented with this restriction I do not know.

How do we solve this?

Will the QoS EOIO solve this issue? In that case, how do we make sure the Idocs is sent with EOIO from SAP and the SOAP calls from XI do the same? I cannot find any QoS for the receiver SOAP adapter.

Or do we have to setup a BPM that implements a wait step for each message? This seems a bit "insecure".

The last option as I see it is implement some logic in SAP to wait for the ALEAUD response message back from the legacy system (the whole interface is async) before it sends the next IDoc.

Can anyone help me find the easiest (and best) solution?

Thanks a lot in advance!

Br,

Kenneth

[stefan_grube · Accepted solution]

> Will the QoS EOIO solve this issue? In that case, how

> do we make sure the Idocs is sent with EOIO from SAP

> and the SOAP calls from XI do the same? I cannot find

> any QoS for the receiver SOAP adapter.

You can maintain the ABAP Table IDXQUEUE (with SE16).

In that case, the messages are stored in an EOIO queue.

When the receiving web service sends the OK only when it has finish all his work and is available for the next call, then this solution should solve your problem.

Regards

Stefan

[MichalKrawczyk · Accepted solution]

hi,

>>>>You can maintain the ABAP Table IDXQUEUE (with SE16).

but this is not a "real" EOIO

as messages from the SAP can come in ANY order right?

Regards,

michal

[stefan_grube · Accepted solution]

Hi Michal,

You are right. The IDOCs can come into XI in any order.

In the original post, there was not mentioned, that the IDOCs should come in the correct order.

Regards

Stefan

[Former Member · Accepted solution]

Yes, I did not mention it simply because it is not a requirement to have all messages processed in the right order. My thought was merely that the EOIO processing might help giving the receiving WebService enough time before XI sends the next message to the WS. But this might not be the case then.

Anyway, I think I will go for the BPM solution. BTW, if I implement a wait step of 1 minute (way more our requirements though, only a few seconds is needed), am I then sure that another message coming into XI at the same time does not start a new "instance" of the BPM, but uses the same instance as the first message? If a new instance is created then this will not solve my issue either, but if only one instance of the BPM is used then the BPM (and the wait step) must be finished before the next message enters the BPM, right? This is what I would want then.

Thanks again for your help!

-Kenneth

[MichalKrawczyk]

Hi,

>>>>how do we make sure the Idocs is sent with EOIO from SAP

cannot be done with your system (4.7)

>>>>Or do we have to setup a BPM that implements a wait step for each message? This seems a bit "insecure".

why ? but the smaller time in wait step is one minute I believe

Regards,

michal

[Former Member]

Thanks Michal!

My initial thought was that the wait step does not completely ensure that the Web Service is finished doing whatever it needs to do, although by increasing the waiting time we could make it very probable that it is finished.

But since it seems that EOIO is not an option then the BPM option is probably how we need to do it then.

Unless you have any other bright ideas?!

Thanks again, points awarded:)

[MichalKrawczyk]

Hi,

>>>>My initial thought was that the wait step does not completely ensure that the Web Service is finished doing whatever it needs to do

of course it does not but is this WS sync or async?

as if async you will never know if it finished

or not so the wait step is the only solution

if you have sp15 or more check the EOIO mode in the send step (a little workround):

http://help.sap.com/saphelp_nw04/helpdata/en/43/65ce41ae343e2be10000000a1553f6/content.htm

Regards,

michal