How to fail one message in a message split scenario during runtime and process it later?

[former_member377886]

Hi All,

I have an interface where following conditions must be met.

1. Source message is split into message 1 and message 2 in message mapping.

2. Condition is, if there are no UKMS Lookup errors, create only message 2 and do not create message 1.

3. If there are UKMS Lookup errors, create message 1 to send error emails to concerned teams. Also, message 2 should be created and should go to error in runtime, such that once UKMS Lookup table is updated, message 2 can be reprocessed from PI.

The current configuration I've made fulfills 2nd step. When there are no errors, it's only creating message 2 in message mapping as well as in runtime.

But when there are errors, only message 1 is being created in runtime. But as per requirement, even message 2 should be created and it should go to error.

Please let me know how to solve this glitch.

[former_member190293 · Accepted solution]

Hi Poornima!

You could use SOAP Loopback approach to fulfill your requirement. File is splitted into chunks and is sent to second ICo where SOAP sender adapter is used in EOIO mode. So if the message is failed in second ICo (you can raise exception in message mapping, for example), the queue is stopped. And CMBA could be used to send e-mail alert if exception occurs.

Regards, Evgeniy.

[weberpat]

Just a thought:
Could you avoid failing the messages altogether, sending them to an error receiver and re-triggering them from the backend once the issue is resolved? Failed messages get re-tried periodically even if the issue was not resolved yet, thereby creating unnecessary workload on the system. Also by following this approach, you could think about raising an alert e-mail via UDF (see here for example) and avoid a message split.

[former_member377886]

Hi Patrick,

Thank you for sharing this approach. But the limitation here is, source file is a very huge file ( around 200MB with 100,000 records). Therefore, it has to be split into multiple chunks in EOIO for processing . The requirement is here that, say if first and second chunk gets processed and third one has data error, third one must fail in PI and has to send error email to concerned contacts. and rest of the chunks in queue must be in holding until third one is either re-triggered or cancelled.