Idoc To JDBC Szenario EOIO overtaking messages

[Former Member]

Hi guys,

I have an idoc to EOIO scenario, where some messages of different idoc types upsmas & chrmas have to be processed in the same order they are created in

the SAP ERP Backend.

To achieve this behaviour I use the the option "rule name" in the partner profile we20 according to this blog.

Messages of both idoc types upsmas and chrmas have the correct queue name in the ReliableMessaging section.

The messages are processed via JDBC adapter.

In the message monitoring the qualtiy of service and conversion id (queue name) is correct.

Some time some messages overtake each other so that the sequenz number in message monitoring is incorrect, older message has a higher number than the newer message.

for upsmas messages there is one more step during processing. These messages are splitted during receiver determination, 2 receiver are defined.

The sender SAP system and the the database.

Why do these messages overtake each other?

Is there some kind of sequenz number in ABAP stack?

could be the multiple receiver the reason for the wrong order of the messages?

Hopefully you could give me some advice, I appreciate your help.

Kind regards

Jochen

[Former Member]

EOIO works also with IDoc if the queueing is enabled in we20 and queue name rule is specified in we85

Kind regards

Jochen

[andreas_brandhorst]

That's right. I think with splitting the messages xi will loose the order of messageprocessing.

the best would be to split the messages by different scenarios and services in your xi. Disadvantage is creating 2 idocs for different logical systems in your SAP backend.

After that, you still need entries in IDXQUEUE for keeping the order of your messages and getting the qos EOIO.

Best regards

Andreas

[Former Member]

Hi guys,

unfortunately this issue is not resolved yet and the error situation occurs again.

According to your comments I think the message split in receiver determination could be the reason for the incorrect order of the messages.

To clarify the situation I will describe the needed business case once more.

During this scenario customer master data have to be tranfered form SAP ERP 6.0 to an MS SQL database.

The main part of this data is transfered using different idoc types e.g. CHRMAS, KNOMAS, UPSMAS

During the processing the order of messages have to be maintained, so I use the quality of service EOIO, which works fine so far.

The UPSMAS is a special idoc in this scenario.

It determines the end of a data package an triggers an stored procedure in the database. There fore it is created last in SAP ERP.

But there is the requirement to get an receipt to the UPSMAS idoc. This receipt is used to update the transfering status int the SAP ERP.

Therefore I added two receivers in the receiver determination for the UPSMAS idoc, one for the database to call the stored procedure and another one back to the sender SAP ERP to update the status. This receipt message is sent via ABAP proxy, in the execute method a funtion module is called to update the transfer status.

As I said above the idocs are received in the correct order in SAP XI. But sometimes the order changes form apab to java stack for UPSMAS messages (the ones with two receivers)

In sap help I found following statement according to idoc serialization

http://help.sap.com/saphelp_nw70/helpdata/en/14/80243b4a66ae0ce10000000a11402f/frameset.htm

>

> The sequence at the Integration Server inbound or outbound channel can only be guaranteed if only IDocs are processed, and not if different protocols (for example, IDocs and proxies) are processed together.
> 

how could I meet the business case, but remain the order of the messages?

I appreciate your help

Kind regards

Jochen

[former_member206760]

Dear jochel

As you told CHRMAS, KNOMAS, UPSMAS are coming in sequence in XI ....but coz u have specified 2 receivers in the receiver determination for UPSMAS message you lose the sequence .......well in that case

1. create a RD like

source sys : ECC_BS +

outbound Mi : UPSMAS

receiver sys : ECC_BS( this would be same as source sys)

2. you specify two inbound interfaces one for JDBC and other for proxy say MI_IN_JDBC and MI_IN_PROXY

3. create only one interface determination

source sys : ECC_BS +

outbound Mi : UPSMAS

receiver sys : ECC_BS( this would be same as source sys)

give to interface mappings here one for JDBC other for proxy...

and now you ca use " maintain order at runtime " as the reciver is only one i.e ECC_BS

4. now you will have two receiver agreements.

source sys : ECC_BS

inbound interface : MI_IN_JDBC

Receiver sys :ECC_BS

give your jdbc channel

source sys : ECC_BS

inbound interface : MI_IN_PROXY

Receiver sys :ECC_BS

give your XI adapter channel..

in short ECC_BS can function both as SAP and thirdparty system,,,

This has worked for me

[Former Member]

Hi Tarang,

thanks for your answer.

I already thought about a solution like this, but never thought I could be so easy and the behaviour of splitting in interface could be different vrom the receiver split

I changed in test system and will try it,

Unfortunately this kind of error is quite rare, so it will be hard to test it.

thanks for helping, it will give a feedback as soon as possible

Kind regards

Jochen

[Former Member]

Hi Tarang,

unfortunately today the error occurs again.

The solution using the same receiver with two interface and two communication channel doesn´t work.

When i looked at the incoming idoc messages, there are some queue order information

the KNOMAS comes before UPSMAS, but during the processing the order changes so that the sequenz number of KNOMAS is higher than UPSMAS.

any ideas how to solve the issue?

Kind regards

Jochen

[Former Member]

Hi guys,

I changed the scenario.

I removed the answer message to the sender, so that there is no message split in XI.

Unfortunately this change doesn´t solve my issue.

There still messages which comes in the correct order, with the quality of service EOIO and the same queue name, but are processed in the incorrect order.

I found following information

The incoming idocs have an serial no in the SOAP-Header section => IdocInbound => SAP:SERIAL

When I look at this serial the idocs are in the correct order.

For all idocs an individual mapping is done, which differs in duration. I assume that the order should be maintained during the whole processing in XI, so that a successor will be waiting until the predecessor has been finished.

When I look at the sequenz number in message monitoring the order of the messages changed

Is that an Error in SAP PI??

What could I further check?

We are using 2 java nodes AdapterEngine. Could this have any influence on that issue?

When I´m looking at the SOAP-Header => RunTime in sxi_monitor there is an element <SAP:QIdInternal>XBQO31__Z_IDES_CALL_SP</SAP:QIdInternal>

The content of this element differs for the message, which is processed to early.

Could this also be an factor? Where could I influence this value, I thought this done during inbound handling of the incoming idoc.

Kind regards

Jochen

[andreas_brandhorst]

Hi Jochen,

in the sender Idoc-Adapter you have no settings for serialize messages. To make sure of that, make an entry in the table IDXQUEUE with the idoc-messtype and the assigned queue-ID, you want to use. The name of the queue-id can be free chosen. That will solve your problem.

Regards,

Andreas

[Former Member]

Hi Andreas,

in my scenario I need different queues for the same idoc type from the same sender depending on the content of one field.

I haven´t used IDXQUEUE, yet, but how to achieve such a dynamically queue?

please have a look at this thread, there is the same issue discussed

It seems that the order is correct while the messages are arriving in XI. May be the receiver determination with 2 receivers causes my trouble.

Could somebody verify this.

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

> Inbound messages with the same receiver are processed in the same sequence that they arrived. The messages are also sent in this sequence to their respective receivers; because they have the same queue name that was supplied by the application, they are placed in the same outbound queue.
> If an error occurs in the processing, the incorrect message blocks the queue to preserve the processing order.
> However, if the messages have different receivers, the sequence does not have to stay the same.
> The message is persisted again once it has been sent successfully. Once the message has been processed successfully in the target system, the Integration Engine executes an implicit database commit. Otherwise, it executes an implicit database rollback.

Kind regards

Jochen

[dharamveer_gaur2]

Hi

In case of WAS 6.40 only checking "Queue Processing" mode in communication channel is enough. No need to configure XI Queue.

[Former Member]

Hi guys,

thanks for helping.

I haven´t tested the scenario without the splitting step, yet, because I would prefer a solution containing this step.

The splitting is done in the receiver determination step. There 2 receivers without any condition are defined.

I don´t know the parameter "mantain order at runtime" in the receiver determination step, I know this option in interface determination.

This option was deactivated for one interface determination, I activate it know.

In which communiction channel should I use the parameter "queue processing"

The scenario is Idoc sender to jdbc receiver, so at sender side I don´t have an CC.

There is such a parameter in a idoc receiver CC, but I don´t use idoc receiver.

perhaps there are more ideas .

Kind regards

Jochen

[Former Member]

Hi

You have used maintain order at runtime at receiver determination

Are you doing splitting at Mapping level or receiver determination level?

Check with your splitting.

Thanks

Gaurav

[Former Member]

Hi,

the problem seems to be with the splitting step. did u test the scenario removing the splitting step.

Regards,

Sukarna.