Clovertech

Ack/Nak handling

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Ack/Nak handling

  • Creator
    Topic
  • August 25, 2005 at 6:43 pm #47998
    Michael Lacriola
    Participant

      I have a situation where the vendor will Nak a HL7 message when “their” application cannot assign a value to it because of a broken database connection. There’s nothing wrong with the format of the message.

      What I would like to do for this particular thread is: when I receive an “AR” in the MSA segment, I would love to put the outbound thread on hold and page someone on the first “AR”. That message would then go to the error DB (know how to do). I know how to page someone through a tps proc, know how to use the tps send ok and TPS inbound reply stacks. What I don’t think I can do is put that thread on hold from within the tps inbound reply.

      Anyone have any ideas that would like to shoot my way?

    • Creator
      Topic
    Viewing 6 reply threads
    • Author
      Replies
      • August 25, 2005 at 8:10 pm #57257
        Michael Hertel
        Participant

          I have to deal with an interface just as you describe.

          Instead of erroring the message, I have a proc with the code below that runs under TPS inbound replies that runs before our generic ACK checker proc. I look for AR’s and kill the reply before the ACK checker has a chance to validate it. So the interface ‘times out’ on the Cloverleaf side and resends the message each time an AR is encountered. There is counting logic and I email “them” and me every 5 AR’s. You can page too.

          When the next AA comes in, the counter resets. This way I don’t have to worry about it, “they do!” 😈

          Code:

          run {
          keylget args MSGID mh
          set msg [msgget $mh]
          set response [vm_getHL7 $msg MSA 0 1]
          if {[cequal $response AA]} {
          set ARcnt 0
          }
          if {[cequal $response AR]} {
          incr ARcnt
          if {[expr $ARcnt % 5] < 1} { set notifylist "pgmmjh@vmmc.org pgmxyz@vmmc.org interfaceengine@abc.org" exec echo $msg | mail -s "$HciSite - ABC AR response(s) received $ARcnt" $notifylist } echo $module - ABC AR received - Message killedn$msgn return "{KILL $mh}" } lappend dispList "CONTINUE $mh" }

        • August 25, 2005 at 8:58 pm #57258
          Michael Lacriola
          Participant

            Yes, something like that. I’m thinking that if await replies is on and timeout set to -1, when I receive the first AR, send an email and kill the reply using a KILL instead of KILLREPLY, my messages will  back up (which is what I want) because it will still wait for a valid reply.

            Does this logic sound good? It will be reset once the thread is bounced or until I get a valid “AA” reply response.

          • August 25, 2005 at 9:22 pm #57259
            Michael Hertel
            Participant

              Retries should = -1 (Under Outbound data) so it will resend the same message forever.

              Timeout should be 30 or something greater than -1.

              If you set Timeout for -1, then it will wait forever and not try to resend.

              That’s bad. That’s why I watch my email and if I get more than 3 notices (15 AR’s @ 30 seconds each), I call ‘the other guys’ and ask them wassup?

              I’ll attach the full proc if you want.

              The logic is sound and works well for us.

              -mh

            • August 25, 2005 at 9:27 pm #57260
              Michael Lacriola
              Participant

                No, that’s ok, the code fragment you presented is fine. I having something similar in other areas. It’s making user that it resends the message forever until it gets an “AA” response that’s important. The other stuff is fluff.

                Thanks for the input.

              • May 17, 2007 at 10:40 am #57261
                Brian Goad
                Participant

                  MH,

                  Do you all use recover33 with that proc?

                  TIA,

                  Brian

                • May 17, 2007 at 12:36 pm #57262
                  Michael Hertel
                  Participant

                    Yes, this goes before the ack check proc.

                    Our’s is named tps_checkhl7_ack (or something like that).

                    It originally came from the recover33 procs.

                    -mh

                  • June 12, 2007 at 3:07 pm #57263
                    Dick Bly
                    Participant

                      Michael, you can put a thread on hold from an inbound reply, but in order to start the data flowing again you must stop and start the thread. DO NOT release the hold with the GUI or the message that caused the hold will not be sebt until the thread is cycled.

                      do the KILL on the reply instead of the KILLREPLY to keep any further messages from being sent, then exec the hcicmd in the background using & at the end of the line to put the thread on hold. the thread will stop sending because of the KILL and then go to hold state.  will work on unix and windows.

                  • Author
                    Replies
                  Viewing 6 reply threads
                  • The forum ‘Cloverleaf’ is closed to new topics and replies.