No announcement yet.

Reprocessing PART of a destination chain

  • Filter
  • Time
  • Show
Clear All
new posts

  • Reprocessing PART of a destination chain

    OS: Mirth Appliance
    Mirth Version: 3.5.1

    I have a channel that accepts an HL7 message. I have 3 destinations chained together. Destination 1 (d1) performs a SOAP web service call to another system. We receive a value back in the response. I then perform a different SOAP call with destination 2 (d2). Finally we use a database writer on destination 3 (d3) to log the success/error state of the previous calls in the chain.

    This works as intended. But some failed SOAP calls have needed to be reprocessed after we changed some transformer rules. We cannot rerun destinations that processed properly the first time as the receiving system state has changed and we do not want to modify it again. But d2 needs the response from d1 and d3 needs the response from both d2 and d1.

    Is it possible to reprocess these destinations and read the pre existing responses or do I need to rethink my entire channel design?

  • #2
    Wow, no takers at all? I place some blame on the 4th.

    I will post a dirty solution I found to help others who may have this same issue. I am not sure if this behavior is frowned upon by the board. oh well.

    Instead of using destination chains one can make each destination a full channel. The input to the channel would be a custom message that contains both the source message and the response from the previous channel.


    Channel 1. HL7 message ----> Web service
    create custom message in a response transformer that has values from response and all fields from hl7 that are needed. Route message to channel
    1st Custom --> database writer channel
    1st Custom --> web service 2
    create 2nd custom message in response transformer.
    2nd Custom --> Database Writer channel
    2nd Custom --> final channel/web service/HL7/Whatever

    Now this creates a horrid maintenance nightmare. It is very hard to follow each step of a message. But this does get the job done because each step saves all values from the previous step(s).

    If anyone has a better solution, please stop this madness from coming forth into existence.