XI message synchronization problems

[Former Member]

We are having a problem with XI that is related to timing of transmissions from a Legacy Mainframe system to our R/3 system. This is the scenario:

Update 1 is transmitted from the mainframe at 1:00pm and contains an update for item “Y”. The update fails on the R/3 system due to a lock error so the XI system waits before trying to do the update again. Update 2 is transmitted at 1:05pm and contains an update which is also for item “Y” and the update is successful on the R/3 system. At 1:07pm Update #1 (that originally failed due to a lock on item “Y”) retries and it is successful. The result is that we have updates to item “Y” in R/3 that are out of sequence and in some instances puts item “Y” in an invalid state.

I know we could resolve the problem by creating a serial queue but this is not an option because we have many updates for many items being transmitted via these queues. I need to know if there is a way for XI to know that item “Y” contains an update that was locked out (and is in a retry state) and to hold any additional updates for item “Y” until the first update is successful.

[udo_martens · Accepted solution]

Hi Ed,

you could create a business process, which is receiving from Legacy Mainframe as long as no positive Acknowledgement came from last send message. That means you design a process where you receive (while 1 = 1) and send messages. If you receive a positive acknowledgement AND no other message is to be send, than stop the process.

Of course a BP does not upgrade performance at all

BTW: You should consider using EOIO...

Regards, Udo

[Former Member]

Thanks everyone for your comments. I might not like it but I know what I have to do now.

[Former Member]

Thank you for the responses. The problem I see with the EOIO option is that the communication channel handles transmissions for many individual items. If one of these items is locked then all transmissions on the channel will get backed up until the lock is released.

[Former Member]

yes,you are right but that will also make sure that you don't have duplicate updates,if you don't want to serialize your messages(EOIO) then you need to use BPM,but before implementing BPM just make sure that it won't affect your performance too much

Thanx

Aamir

[Former Member]

Hi,

I think you need to consider EOIO option. Since this will ensure that for any item, the updates gets processed in order. This may prevent enqueue locking issue in R/3 system as the same item getting processed in parallel is avoided.

Any reason why the lock error occurs in your interface in R/3.

Regards,

S.Santhosh Kumar