IDOC - cannot switch back from EOIO to EO...

[brian_arthern2]

Hi,

We had a couple of partner profiles defined for a particular Message Type and in order to test the solution to a particular problem, we turned on the Queue Processing flag in order to switch the QoS to EOIO. This worked - when I looked at the QoS in the Reliable Messaging section of the Inbound Message (in SXMB_MONI) it had changed to EOIO.

We then came to a point where we actually found an alternative solution and tried to switch it back to EO by turning off Queue Processing.

However, now when I send new IDOCs to XI it still sends the QoS as EOIO. I have even tried deleting the parameter entry from the partner profile and that made no difference.

Does anyone know what I have to do to reset the status?

thanks

Brian

[brian_arthern2]

After debugging the IDX_INBOUND_XMB function I resolved the issue.

Turns out it did not relate t o the Queue Processing flag, but to the Maintain order at runtime flag in Interface Determination.

If you have ever turned this on for an IDOC-related interface and sent IDOCs then an entry is added into table IDXQUEUE. If you later turn this off (which I had done) it does NOT delete this entry.

When IDOCs are processed, XI checks this table and automatically sets the mode to EOIO if an entry is found, regardless of whether Queue Processing is on or not in the sending system.

[Former Member]

Hi Brian,

Can you please tell me how did you debug IDX_INBOUND_XMB..

Thanks

[brian_arthern2]

Looking at the trace, I located the following informat:

<Trace level="1" type="B" name="CL_XMS_MAIN-CALL_UC_EXECUTE" />

- <!-- ************************************

-->

<Trace level="1" type="T">Message-GUID = B213034A12BD8241E10000000A620415</Trace>

<Trace level="1" type="T">PLNAME = CENTRAL</Trace>

<Trace level="1" type="T">QOS = EOIO</Trace>

<Trace level="1" type="T">Queue-Id = QE1_100_SD_LABEL</Trace>

<Trace level="1" type="B" name="CL_XMS_MAIN-CALL_PIPELINE_ASYNC" />

- <!-- ************************************

-->

<Trace level="1" type="T">Get definition of external pipeline = CENTRAL</Trace>

<Trace level="1" type="B" name="CL_XMS_MAIN-LOOKUP_INTERNAL_PL_ID" />

<Trace level="1" type="T">Get definition of internal pipeline = SAP_CENTRAL</Trace>

<Trace level="1" type="T">Queue name : XBQIQE1_100_SD_LABEL</Trace>

<Trace level="1" type="T">Generated prefixed queue name = XBQIQE1_100_SD_LABEL</Trace>

<Trace level="1" type="T">Schedule message in qRFC environment</Trace>

<Trace level="1" type="T">Setup qRFC Scheduler OK!</Trace>

So from somewhere the system is doing a lookup and decides that EOIO is required and generates a queueid. Does anyone know how to debug the IDOC adapter or the pipleine processing?

Below is the trace section for the EO IDOC:

<Trace level="1" type="B" name="CL_XMS_MAIN-CALL_UC_EXECUTE" />

- <!-- ************************************

-->

<Trace level="1" type="T">Message-GUID = 37FA034A12BD8241E10000000A620415</Trace>

<Trace level="1" type="T">PLNAME = CENTRAL</Trace>

<Trace level="1" type="T">QOS = EO</Trace>

<Trace level="1" type="B" name="CL_XMS_MAIN-CALL_PIPELINE_ASYNC" />

- <!-- ************************************

-->

<Trace level="1" type="T">Get definition of external pipeline = CENTRAL</Trace>

<Trace level="1" type="B" name="CL_XMS_MAIN-LOOKUP_INTERNAL_PL_ID" />

<Trace level="1" type="T">Get definition of internal pipeline = SAP_CENTRAL</Trace>

<Trace level="1" type="T">Queue name : XBTI0006</Trace>

<Trace level="1" type="T">Generated prefixed queue name = XBTI0006</Trace>

<Trace level="1" type="T">Schedule message in qRFC environment</Trace>

<Trace level="1" type="T">Setup qRFC Scheduler OK!</Trace>

[brian_arthern2]

Hi,

Nothing has been changed in either the IR or the ID. In the Sender Agreement and Communication Channel for sender IDOC adapter there is nothing to specify the QoS, so I could find nothing to change.

In all the help documentation and forum threads I have read it always states that to control the QoS, you have to turn on/off the Queue Processing flag in the appropriate partner profile on the sender system.

I noticed in reliable messaging that when EOIO is specified (i.e. Queue Processing is turned on). The system show a queue-id:

- <!-- Inbound Message

-->

- <SAP:ReliableMessaging xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="1">

<SAP:QualityOfService>ExactlyOnceInOrder</SAP:QualityOfService>

<SAP:QueueId>ZSDLABEL1</SAP:QueueId>

</SAP:ReliableMessaging>

For an IDOC where Queue Processing has NEVER been turned on it gives no queueId:

<!-- Inbound Message

-->

- <SAP:ReliableMessaging xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="1">

<SAP:QualityOfService>ExactlyOnce</SAP:QualityOfService>

</SAP:ReliableMessaging>

However, once you have turned the Queue Processing on ONCE, XI (or ECC?) always seems to remember this QueueId (perhaps somewhere in the IDoc adapter?) and tries to use it...

So I actually now have 2 problems:

1. How to locate this associated QueueId

2. How to handle a situation where, for the same Message Type I want to send some IDocs using EO, and some using EOIO (by having 2 outbound parameter settings in the partner profile and using the MESCOD field to distinguish between them).

[Former Member]

Hi,

please check whether the changes in IR / ID have been activated and (if necessary) been transported to the specific system. Also a chache refresh (sxi_chache) should be done!

Regards,

Kai

[Former Member]

Brian,

Have you tried to refresh cache after changing config. Refresh Full XI Cache and try again.

Hope this will help.

Nilesh