Sending messages exactly in order

[Former Member]

Hello,

I am setting up the following scenario: IDocs from R/3 are handed over to XI. There is a message mapping to an inhouse XML format. During this message mapping, a counter is increased and mapped into the inhouse xml format. That means every message contains an element with a counter as unique ID, so that every message can be 100% identified and referenced. These messages are then sent to external partners, e.g. with FTP/File-Adapter.

The problem is: The partner only accepts the messages when they are received in the correct order concerning the counter inside the messages (first counter 154, then 155, then 156 and so on). That means: The messages MUST be sent exactly in the order in which they are handed over from R/3 to XI.

Normally everything works fine, but what happens if there is for a short moment an error in the adapter (e.g. ftp connection problems)? That might cause a problem, for example: Message with counter 98 is tried to be sent, there is an error in FTP adapter, the message will get status "waiting" and will be retried in a few minutes. But in the meantime the message with counter 99 is tried to be sent, and there is no error in the adapter. That means the partner get the message with counter 99 before the message with counter 98, which won't be accepted.

Is tehre any possibility to avoid this situation? Is there some kind of "exactly once in order" processing for outbound messages? The adapter engine should just process the messages exactly in the order in which they are received from the integration engine.

[Former Member]

Hello,

If you use...EOIO, you need to specify the queue name in which files will be processed in sequenece.....if any entry is struck up in the queue, remaining will be in waiting state..

Regards,

Sreenivas

[Former Member]

Hello,

any feedback to my last reply? I am still not 100% sure how this EOIO works in detail and how it can be extended to the adapter engine...

Thanks,

CHRIS

[Former Member]

HI Chris,

Has this issue been resolved. I am also in a similar situation, so looking out for a solution.

Regards

Shirin

[Former Member]

Hi

I think the following thread meats your requirement and follow their solution to solve your problem

Regards

Sridhar Goli

[ParvathyS_SAP]

Q0S:

http://help.sap.com/saphelpnw04/helpdata/en/41/b714fe5ffc11d5b3ea0050da403d6a/frameset.htm

adapter types and QoS:

http://help.sap.com/saphelpnw04/helpdata/en/0d/5ab43b274a960de10000000a114084/content.htm

http://help.sap.com/saphelpnw04/helpdata/en/ae/d03341771b4c0de10000000a1550b0/frameset.htm

http://help.sap.com/saphelpnw04/helpdata/en/7b/94553b4d53273de10000000a114084/frameset.htm

serializing IDoc XML

[Former Member]

Hi Christoph,

Do you mean serialize the Idocs at the Sender side.

For this you can go throgh the following link to serialize the Idocs.

How to change QoS Exactly-Once-in-Order Processing in the Adapter Engine

http://help.sap.com/saphelp_nw70/helpdata/en/45/13b942f14d29efe10000000a114a6b/content.htm

Regards

Sridhar Goli

[Former Member]

Hello,

thanks for the very interesting answers. Some further questions:

@ Sridhar Goli: The first SAP help link you provided seems very interesting. But I do not understand it in detail: What does it mean exactly? What does it describe? Is it just about activation EOIO for adapter engine?

Must I first activate IDoc serialization in R/3 via WE20? And than I have to use this link in order to configure also the adapter engine to work in EOIO?

Another question to IDoc serialization: What exactly does CONSTANT:EDIQUEUE mean? Can't I define individual queue names, e.g. one queue per external partner?

Another question to your link to the similiar SDN discussion. There you wrote:

"The IDOCS would come in sequence to PI the way they are generated in ECC. 1001 always reches first and then 1005 and then 1010.

You can again utilize "Maintain order at runtime" in PI-Interface Determination to send them in teh same order to Receiver system using File adapter."

Let me guess: That only makes sure that the messages are sent in the same order to the adapter engine. That does not make sure that the adapter engine sends the messages exactly in the order in which they are transmitted from integration engine to adapter engine, does it? That means: When message 1 arrives at the file adapter, and there is an temporarely error, it might happen that the next message is sent although the message befotre has still the status "waiting"?

Let me once again try to explain my problem in short terms: The adapter engine (e.g. file adapter) should send the messages to external partners exactly in the order in which they are received from the integration engine. If a messages in the first attempt gets an error, all other messages for this partner should not be processed, until the prior message was sent successful.

Thanks a lot.

CHRIS

[bhavesh_kantilal]

Hi,

When the Idoc comes into the Integration Engine as EOIO message with the Queue Name as needed, the messages are handed over to the Adapter Engine in a EOIO fashion and the file will also get written in a EOIO fashion.

EOIO in XI is end to end and its transparent and internally makes sure that the hops from one component of XI to other does not stop EOIO processing.

You can be rest assured that turning on Idoc serialization from SAP solves your issue.

Regards

Bhavesh

[Former Member]

Hello,

thanks again for the feedback.

So what I understand so far: Turning on IDoc serialization in R/3 has the effect that messages are sent in EOIO mode to XI. I have to activate EOIO processing also in the Interface Determination. The messages will be processed in EOIO mode not just on Integration Engine, but also on the Adapter Engine. Everything right so far? Some additional questions:

--> What does that CONSTANT:EDIQUEUE stand for? Can I define my own rules / queues?

--> When I turn on IDoc serialization in R/3, does that JUST affect the partner in whose partner profile I turned on serialization?

--> The messages in my scenario are handed over to XI, where they are collected in a BPM and merged into one IDoc. Will the messages still be in EOIO mode after the BPM?

Thanks again.

CHRISTOPH

[bhavesh_kantilal]

EDIQUEUE is the name of the QUEUE.

Withing your BPM, in every send step you would need to provide a Queue Name ; and then all Idoc's will be processed end to end in a EOIO fashion.

As for the Serilization; if you look into the table entry that you need to make; it is tied to the Sender Port, and the idoc type and hence it is common to corresponding idoc from the R3 system and not tied to the partner profile.

Regards

Bhavesh

[Former Member]

Hello,

thanks for the feedback. But this raises again more questions for me.

1. Must I use this EDIQUEUE or can I define different queues e.g. for differnt partners / messages?

2. I do not understand your statemant about serialization. In my opinion, I define serialization in we20 partner profile. There I define it for certain IDoc types (e.g. INVOIC). As I make this definiton in a cartain partner profile, I would assume that serialization is just activated for THIS partner and IDoc type?

3. What do I have to define in my BPM? The same queue name as in WE20? That would affect ALL partners, as I use just one BPM for all partners?

Thanks,

Chris

[bhavesh_kantilal]

Chris,

I am confused as well 😮

Where and how are you trying to configure Idoc serialization -

Is it on the R3 system ( WAS >= 6.40 ) or

On the XI system in IDXQUEUE

From your answer it looks like you are doing this in the SAP System. In this case, I fear I don't have the answer now and will have to dig into it myself.

From a BPM Perspective, you can give either the same queuename or a different Queue Name.

I would prefer a Different Queue Name as this would make sure that Send Step and the BPM processing are not coupled together. But you can be sure that the Serialization will be maintained.

Regards

Bhavesh

[Former Member]

Hi,

you can use a function module for specifing the queue name that should be used through processing.

Follow this blog for defining the queues on the sender side (SAP R/3) using transactions we20, we85 and se80

This order will be mantained during processing in XI.

You can check the queue and the QOS in the header section of your message in XI, have a look at the entry ReliableMessaging.

At Adapter Engine you can also check the QOS in the message mapping. Just open the detail view of a message and have a look at

the first tab.

Hope this will solve your issue.

Kind regards

Jochen