Mirth Connect 3.12.0 Released!

Mirth Connect 3.12.0 is now available as an appliance update and on our GitHub page. This release includes database performance improvements, improves visual HL7 representation, message pruning, keystore handling, PDF generation, community contributions, and fixes several security vulnerabilities. This release also contains many improvements to commercial extensions. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

Handling an acknowledgement

  • Filter
  • Time
  • Show
Clear All
new posts

  • Handling an acknowledgement


    do you know how to setup Mirth so that it makes an update to the DB AFTER getting an acknowledgement from the message receiver?

    Thanks for any help!


  • #2
    Re:Handling an acknowledgement

    What kind of connectors ...etc are you using in your setup ?

    I'm currently dealing with ACKs too


    • #3
      Re:Handling an acknowledgement

      Hi quimicefa,

      I'm using a LLP Sender as connector (see attachments)


      Svetlomir Bildschirmfoto.png (93274 bytes)

      Post edited by: Svetlomir Kasabov, at: 06/18/2008 11:57

      Post edited by: Svetlomir Kasabov, at: 06/18/2008 11:58

      Post edited by: Svetlomir Kasabov, at: 06/18/2008 12:00


      • #4
        Re:Handling an acknowledgement

        Here's my channel, which needs an acknoledgement in order to execute the update in the DB SENDERTASK_EBM.xml (7933 bytes)


        • #5
          Re:Handling an acknowledgement

          I've seen your screenshot and I think that your best way is:
          * use a transformer step in the destination to store the row ID of the message, to identify the row for the further update statement.
          * in the postprocessor step put a script like this one (pseudocode):

          var stat = responseMap.get('Destination 1').getStatus().toString();

          if (stat == "SUCCESS"){ // success means no timeout nor error happened
          // here you should get the field that you previously stored in the transformer
          var rowid = channelMap.get ...;

          // then open back a connection to the source db (take a look to the database JS functions)

          conn = drivermanager. .....
          sql = "update table .... where id=" + ${rowid};



          With this setup, after processing each message, if the destination has a SUCCESS status an update sentence is executed back to the source database. So, if you receive a timeout or an error, the same message will be processed again. Note that the timeout-related values in the LLP sender destination should be tuned with the timeout of the LLP system that receives the message.

          Hope that helps you!

          See you.


          • #6
            Re:Handling an acknowledgement

            Thanks for your advice quimicefa,

            it was very helpful. I tried it and worked for me. The problem is - if Mirth's communication partner sends the ACK too late, Mirth will generate the same message once again or more times while waiting for the ACK, because the data in the database wouldn't be marked as sent yet.

            Would you then advice me to execute the update directly after sending the message without waiting for the ACK? I don't really know which from the both solutions is better...

            Sorry for the often frequent and thanks for the time you invested.



            • #7
              Re:Handling an acknowledgement

              You're right

              But that's why I adviced you to setup the timeouts on Mirth side equals to their partner side. This way, if Mirth detects a timeout sending the msg, there is no chance to later receive the ACK from teir partner.

              Hope that helps!


              • #8
                Re:Handling an acknowledgement

                Thanks quimicefa,

                As far as I understood, after I set up the timers as you advised me, Mirth should behave this way:

                1. Mirth generates the message to be sent
                2. Mirth sends the message and waits for the ACK.
                3. IF ACK comes BEFORE the timer expires, Mirth updates the the DB and generates the message no more
                ELSE: timer expires and mirth won't wait for the ACK. (This will quickly generate the message once again when Mirth polls the DB(that will be good, because an unacknowledged message should be sent again). And so on until Mirth gets the ACK)

                Tell me if I understood it correctly

                See you



                • #9
                  Re:Handling an acknowledgement

                  AFAIK, Yes.
                  This is the behaviour expected if you let the same values for the timeouts on both sides of the interface.


                  • #10
                    Re:Handling an acknowledgement

                    If you choose "outgoing queues" in an LLP channel, then the default ouption is to retry if no ACK/NACK is received, as it's understood than the receiving system couldn't process the message.

                    It's a non-documented "feature"