Clovertech

Unable to read ACK

› Clovertech Forums › Cloverleaf › Unable to read ACK

  • Creator
    Topic
  • August 24, 2020 at 3:27 pm #117706
    Ryan Vachon
    Participant

      Having trouble receiving an ACK from a vendor who is building a new product. We’re able to send them an HL7 message successfully over tcpip, but when they try to send an ACK back to us we see “Nonmessage data” in the logs and cloverleaf tries to resend the message.

      Here’s the relevant section from the log:

      **** navigater_out/mmc_save_ob_msg – msg 54064 SENT at 2020-08-24 15:07:06
      MSH|^~\&|EPIC|MMC|NAVIGATER||20200821143135|13748|ADT^A01|54064|T|2.4
      EVN|A01|20200821143135||ADT|13748^LIBBEY^LAUREN^A^^^^^MH^^^^^MMC|20200821143000
      PID|1|E2597029^^^MEPI^MEPI|E2597029^^^MEPI^MEPI|E2597029^^^MEPI^MEPI|TEST^ONBASE||19820403|||||||||||101
      4190
      PV1|1|E|EMERG^A05^^MAINE MEDICAL CENTER^R^^^^EDACA|Emergency||||||||||Home/Work|||1043259575^BRADY^BERNA
      RD^E^^^^^EPIC^^^^PNPI|EMER|10894429|||||||||||||||||||||||||20200821143000
      OBX|1|CW|72166-2^TOBACCO SMOKING STATUS^LN|1|266919005
      OBX|2|NM|PRIMARY_CSN|2|10894429

      mid free [0.0.2523566] 0x33e599f8
      [0.0.2523566] Handling CONTINUE
      [0.0.2523566] Update msg in recovery db to state OB reserved for IB Reply
      OB-Data queue has 3 msgs
      OB-Data queue has NO work
      Raw read with length 32768
      Wanted 32768; got 74
      Raw read got 74 bytes
      Wanted 32694; got -1
      input buffer accepted 74 bytes
      4d 53 48 7c 5e 7e 5c 26 |MSH|^~\&|
      7c 4e 41 56 49 47 41 54 ||NAVIGAT|
      45 52 7c 7c 45 50 49 43 |ER||EPIC|
      7c 4d 4d 43 7c 32 30 32 ||MMC|202|
      30 30 38 32 34 31 39 30 |00824190|
      37 30 37 7c 7c 41 43 4b |707||ACK|
      7c 35 34 30 36 34 7c 54 ||54064|T|
      7c 32 2e 33 0a 4d 53 41 ||2.3.MSA|
      7c 41 41 7c 35 34 30 36 ||AA|5406|
      34 0a |4.|
      Nonmessage data: 4d 53 48 7c 5e 7e 5c 26 |MSH|^~\&|
      Nonmessage data: 7c 4e 41 56 49 47 41 54 ||NAVIGAT|
      Nonmessage data: 45 52 7c 7c 45 50 49 43 |ER||EPIC|
      Nonmessage data: 7c 4d 4d 43 7c 32 30 32 ||MMC|202|
      Nonmessage data: 30 30 38 32 34 31 39 30 |00824190|
      Nonmessage data: 37 30 37 7c 7c 41 43 4b |707||ACK|
      Nonmessage data: 7c 35 34 30 36 34 7c 54 ||54064|T|
      Nonmessage data: 7c 32 2e 33 0a 4d 53 41 ||2.3.MSA|
      Nonmessage data: 7c 41 41 7c 35 34 30 36 ||AA|5406|
      Nonmessage data received. Enable tcp/read/info/0 to see detail
      Raw read with length 32768
      Wanted 32768; got -1
      Nonmessage data: 34 0a |4.|
      OB-Data queue has 3 msgs
      OB-Data queue has NO work

    • Creator
      Topic
    Viewing 0 reply threads
    • Author
      Replies
      • August 24, 2020 at 3:38 pm #117707
        Jim Kosloskey
        Participant

          Is this thread configured for mlp message encoding? If not what mechansm is being specified for message encapsulation?

          email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

          • August 25, 2020 at 8:07 am #117712
            Ryan Vachon
            Participant

              Hi Jim,

              I am using PROTOCOL:tcpip rather than PROTOCOL:pdl-tcpip. Under the data options section in the connection properties, I have it set to encapsulated.

              One thing I have been wondering is if the ACK message they are sending is malformed somehow? Maybe the hex values they are using to terminate the message are not correct?

              • This reply was modified 4 years, 8 months ago by Ryan Vachon.
            • August 25, 2020 at 9:24 am #117718
              Jim Kosloskey
              Participant

                OK well they are not properly encapsulating the acknowledgment. If you look at the hex of the message in the log you shared you will see neither the beginning nor ending characters are provided.

                The message should start with a hex 0b, then the message, followed immediately with a hex 1c0d.

                But that is not all – it appears to me each segment inside the message is not properly terminated (hex 0d).

                Sounds like it will be fun teaching this vendor how to do HL/7. Something they should have done before advertising they can do HL/7 and charging for it.

                email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

              • August 25, 2020 at 11:47 am #117719
                Ryan Vachon
                Participant

                  Thanks! I was starting to suspect something like this after comparing what the vendor was sending me to examples from other working interfaces this morning. I’ll reach out and try to explain this to them!

            • Author
              Replies
            Viewing 0 reply threads
            • You must be logged in to reply to this topic.