Message Resend setup in NetConfig for Thread – TCP/IP protocol

Clovertech Forums Cloverleaf Message Resend setup in NetConfig for Thread – TCP/IP protocol

  • Creator
    Topic
  • #118751
    Gordon Koch
    Participant

      The documentation in Cloverleaf has improved greatly with newer versions, but I am looking to get some more nuance and confirmation that I am setting up the message resend properties correctly in an outbound thread. For a variety of reasons, I need the engine to only resend the HL7 message once, after five seconds, for any reason the message was not sent out originally. This would include the receiving system not sending the acknowledgment in a timely fashion, or the receiving connection being down for network or server downtime (planned or not).

      In the Thread pane of the Properties tab, Retries is set to “1”. Does this override all other settings?

      In the Outbound Data pane of the Outbound tab, Retries is set to “1” with Interval set to “5”. In the Inbound Replies pane, Timeout is set to “5” (obviously with the Await Replies box checked). How do these two settings in this tab interact?

      Any information is appreciated.

      Thank you.

       

    Viewing 5 reply threads
    • Author
      Replies
      • #118850
        Robert Kersemakers
        Participant

          The Retries/Timeout in Outbound Data is for when Cloverleaf can’t send out the message because network/receiving server is down. Normally the values are -1/10; just leave them like that. As the message is not sent, the messages are not saved in SMAT.

          If the message is sent, the message is saved in SMAT and Cloverleaf will wait for a reply (if Await Replies checked). If it will not receive a reply within the Timeout set in Inbound Replies, Cloverleaf will do what is indicated by Timout Handling… . Normally the message will be resent again (Resend OB message), indefinitely.
          If a reply is received then TPS Inbound Reply will determine whether to accept the reply. With normal HL7 messaging the proc (validateReply60) will decide whether the reply is an ACK or NACK. In case of ACK: kill reply and send next outbound message. In case of NACK resend the message of number of times (say 3); if still receiving a NACK then put the message in error and sent the next message.

          So to do what you want: you could set Retries/Timeout in Outbound Data to 1/5. Set Timeout in Inbound Replies to 5 as well and use a (self made) proc in Timeout Handling to only resend the message once.

          Not sure what you want to achieve with this. If the network/receiving system is down, why only resend once? Why not let Cloverleaf queue the messages until messages can be sent again?

          Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

        • #118853
          Gordon Koch
          Participant

            Thank you Robert for the detailed response – it is rather helpful. The reasoning behind this setup is that the messages sent to the receiving system from the engine are very time sensitive, and become “stale” quickly due to the overall workflow. I was told that it is better for the receiving system to not receive the message if delayed, as subsequent workflow generates a new “fresh” or updated message with the same order information.

          • #118854
            Charlie Bursell
            Participant

              As Robert said the Retries/Timeout in Outbound Data is only used if the send fails at the protocol level.  This would be extremely rare with TCP/IP.  It was introduced back in the old serial interface (RS232) days where, as you know, interfaces  at the protocol level were not very stable.

              If using Await Replies, again as Robert stated, the engine will wait the requested amount of seconds (-1 = wait forever) and if no reply received pass the message to the TPS IB Reply proc, if there, to be handled.  You can use a proc to either resend of Kill the message at that point.  Cloverleaf supplies procs to handle this.  Use hcitpsmsgkill to Kill the message or  cl_resend_ob_msg to resend the message.

              If you get a reply and want to check it, use cl_check_ack.  These procs are supplied in $HCIROOT/tclprocs in files recover.tcl and tps.tcl .  You could also copy one of these and modify to suit your particular purpose.

              One point.  If the interface is not UP (Opening or Down), the engine will not attempt to send.  So if the other side is implemented properly where they will send FIN messages when dropping the connection, you should not be attempting to send to an interface that is down.

              Personally, I think 5 seconds is much too short a time to wait.  I usually set mine at 30 or 45 so not so many resends in case the other side is busy and cannot answer right way.

              Another tip.  Check Outbound Only on the IB tab.  That way, if the reply is late and not received during the wait period it will not be received and treated as data.

            • #118870
              Gordon Koch
              Participant

                Thank you Charlie for the information – this is exactly the insight I am looking for.

                I agree that 5 seconds is normally too short of time, and we have the Timeout field (Inbound Replies pane, Outbound tab) set to a minimum of 30 seconds for all our interfaces (except this one for the special circumstances).

                Finally, in the Thread pane of the Properties tab, what does this “Retries” field indicate or control?

                Thanks again!

              • #118873
                Charlie Bursell
                Participant

                  From the docs:

                  This is the maximum number of times to attempt message transmission:
                  <ul id=”qkh1491837518991__ul_5AEF46A7ADEA48509517591274BBF02B” class=”ul”>
                  <li id=”qkh1491837518991__li_603B8C32DEF0427D8E2E1C73A740A96C” class=”li”>0 is the initial transmission only.
                  <li id=”qkh1491837518991__li_9085FECB009646B18E18C90C42544B06″ class=”li”>1 is the initial transmission plus one retry.
                  <li id=”qkh1491837518991__li_B3742B2C65C24D5090622D2C6FE25ACD” class=”li”>-1 is unlimited <mark class=”highlight”>retries</mark>.

                • #118874
                  Gordon Koch
                  Participant

                    Thanks again Charlie. I was wondering this setting in the Properties tab interacts (or overrides) the others discussed in the Outbound tab.

                Viewing 5 reply threads
                • You must be logged in to reply to this topic.