cancel
Showing results for 
Search instead for 
Did you mean: 

Issue with message splits using jdbc reciever

former_member585940
Participant
0 Kudos

Hi Experts,

We have one idoc to jdbc interface.

Message spliiting is done at Interface Determination level.Idoc will be splitted to three reciever interfaces. All three flows are connected to same database..

It has to execute the message in EOIO.

The other flow should not get executed until the first is completed.

To achieve EOIO, we have checked "Maintain order at runtime" box in ID.

The issue is: when the idoc gets created with program,it comes to PI and gets splitted to three flows.but it gets failed in PI because sometime the 2nd flow gets executed before the first one.

If we reprocess it manually, it ll be successful.

If we trigger the same idoc using WE19, it gets processed through PI successfully and in CORRECT ORDER.

All three flow are using same channel to connect to database.

Please share your views.

Thanks

Vikram

Accepted Solutions (0)

Answers (3)

Answers (3)

former_member585940
Participant
0 Kudos

Hi All,

In JDBC reciever channel, we have Transaction isloation level option under Advanced tab..

We changed it to serializable and it worked.

Thanks for your inputs.

Former Member
0 Kudos

Hi Vikram,

Thats the normal behavior if its following the same queue. Ideally it should not allow you to restart the 2nd message after split if the first is in error.Is this happening in all environments?

Can u try creating 3 different channels with different collaboration agreements in your Dev?

regards,

Sriram

Former Member
0 Kudos

Hi Vikram,

Ideally Maintain Order at Runtime should work at am Interface Determination level as it would sequence the 1st executed OM in the interface and then 2nd and then 3rd. Can you also explore the options of having an EOIO QoS determined based in ABAP logic from your ECC system.

Regards,

Sriram

former_member585940
Participant
0 Kudos

Hi Sriram,

from ECC, we ll get only one idoc at a time which will be splitted in PI at interface determination level.

So, ideally when the idoc gets splitted in PI, it should not hit the second flow until the first flow is completely executed.

Regards,

Vikram

Former Member
0 Kudos

Hi Vikram

If the idoc sent from WE19  executed in the correct order, then the idoc from program should also get processed in the same order.

Have you checked that all the messages after split are going to same queue or not?

former_member585940
Participant
0 Kudos

Hi Indrajit,

Thats what the strange part is.

All messages after split are foloowing the same queue.