Design Challenge

[Senthilprakash1]

Hi Guys,

I have two interfaces (Proxy (ECC) to Soap (.NET application)).

Interface 1 = UpdateInterface

Interface 2 = RequestInterface

Key FIeld (In both interface) : RequestID (field)

COndition: The two interface must be sent to the receiver application in sequnce for that specific RequestID field.

First Interface1 (UpdateInterface) has to reach the recevier and then the second Interface (RequestInterface).

1. If the UpdateInterface for that specific RequestID fails. then the corresponding RequetInterface Should be put on hold and should not be sent to receiver.

2. But other UpdateInterface and RequestInterface with different RequestID field should be processed normally. there should not be any dealy.

Existing Design Solution: I have achived this by setting EOIO in the Proxy (Queue ID= RequestID).

so each message with same RequestID will be in same queue (ie, UpdateInterface and RequestInterface), rest of the message with different RequestID will be different Queue and will be processed normal.

Problem Faced: We see that in the source ECC system for a RequestID the UpdateInterface and RequestInterface are generated at the sametime (with Millisecond difference) between them.

Hence what is happening in PI is that its processing the Intefaces in the same sequence and sending the UpdateInterface and RequestINterface to the receiver application with only MilliSec difference between them.

This is the problem, the receiver application sometimes process the requestInterface first and updateInteface second as the difference between them is only in milliseconds.

Question to you guys: what is the best way to design the interfaces in PI by which i can make sure that the updateInterface is processed in receiver system first and then the RequestInterface.

DO let me know which is the best and optimal solution for this design.

1. USe bpm to solve this design -- which i really want to avoid.

2. Implement delay in message maping using UDFs.

3. ask .net application team to implement EOIO - which is out of question.

4. ask ECC team to implement sequencing/delay in their system - which they are not agreeing to.

5. make it synchronous.

6. or is there any feature in PI which i am missing out for these kind of soultions.

do let me know.

Regards,

Prakash.

[markangelo_dihiansan · Accepted solution]

Hello,

Just a few comments:

1. Use bpm to solve this design -- which i really want to avoid.

Only use this approach if 4 fails. This would also require the most change in PI.

2. Implement delay in message maping using UDFs.

This approach will require the least effort and also the fastest to implement. The current system is retained without requiring a change to both the ECC and .Net part. The downside is that message mappings are not intended to be designed that way (we have BPM for delays).

3. ask .net application team to implement EOIO - which is out of question.

The issue could be fixed on the sending side so why ask to fix it on the receiver side?

4. ask ECC team to implement sequencing/delay in their system - which they are not agreeing to.

This is probably the best approach.

5. make it synchronous.

Making the scenario sychronous would require a change in all three parts, ecc, PI and .net.

6. or is there any feature in PI which i am missing out for these kind of soultions.

Unless I'm also missing one, no

Hope this helps,

Mark

[RaghuVamseedhar]

Hi Prakash,

I would recommend

If this message flow is very high per day then, go for u201C4. ask ECC team to implement sequencing/delay in their system .u201D

If this message flow is very less per day then, go for u201C1. USe bpm to solve this design u201D.

Reason: - If flow is high, then if you use BPM, IE has search all co-relation objects to determine to which BPM object new message belongs. It would be resource intensive.

Regards,

Raghu_Vamee