Announcement

Collapse

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

Acknowledgment from LLP Listener or TCP Listener

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Acknowledgment from LLP Listener or TCP Listener

    I am trying to receive messages from another hospital's in-house system and put the results in a database. They seem to be sending messages that conform to the LLP/HL7 2.x standards. However, if I use LLP listener as source, the connection just hangs waiting but connected, before they send a message. If I change to use a TCP listener as source, the message comes through fine, but then their sender crashes because it doesn't like the acknowledgment my destination is sending back. I have tried using the post-processor script below but it doesn't help.

    responseMap.put("Destination 1", ResponseFactory.getSuccessResponse('AA'));

    Please could someone help me work out what is going wrong, or at least indicate how I can get detailed logging information about the sequence of events.

    I can provide a channel definition file if that would help, but currently I have two, one for LLP and one for TCP.

    Thanks

  • #2
    Re:Acknowledgment from LLP Listener or TCP Listener

    can you post your LLP channel on this?.... I would particularly like to take a look at your Source tab.

    Comment


    • #3
      Re:Acknowledgment from LLP Listener or TCP Listene

      Thank you very much for offering to look at my channel file. LLP_to_SQL_Server.xml (54751 bytes)

      Comment


      • #4
        Re:Acknowledgment from LLP Listener or TCP Listene

        I've now turned on full tracing for both LLP and TCP. I tried TCP because LLP was failing completely. With TCP I am actually receiving the message but the connection is then crashing.

        I'd be very grateful if someone more expert than me could have a glance through the log messages below and give me some idea about what to do next to fix this problem.

        With LLP I get the following messages and nothing comes through from the source system. The problem seems to be with the expected terminator.

        TRACE 2008-07-15 10:32:11,830 [593af036-c88d-4668-ba71-b73b99110bb1_source_connector._mllpEndpoint#174469 4424.receiver.1] com.webreach.mirth.connectors.mllp.MllpMessageRece iver: Server socket Accepted on: 5240
        INFO 2008-07-15 10:32:11,830 [593af036-c88d-4668-ba71-b73b99110bb1_source_connector._mllpEndpoint#174469 4424.receiver.1] com.webreach.mirth.connectors.mllp.MllpMessageRece iver: TCP connection from /192.168.163.226:4128 on port 5240
        INFO 2008-07-15 10:32:11,845 [593af036-c88d-4668-ba71-b73b99110bb1_source_connector._mllpEndpoint#174469 4424.receiver.6] com.webreach.mirth.connectors.mllp.protocols.LlpPr otocol: Message terminator was: 56 Expected terminator: 0
        DEBUG 2008-07-15 10:32:11,845 [593af036-c88d-4668-ba71-b73b99110bb1_source_connector._mllpEndpoint#174469 4424.receiver.6] com.webreach.mirth.connectors.mllp.MllpMessageRece iver: Closing listener: /192.168.141.43:5240

        ----
        With TCP I get a message coming through, but then there is a problem with the source system reading the acknowledgment and the connection fails with a socket timeout:

        TRACE 2008-07-15 10:40:31,330 [7f28dd56-bc72-4a7c-b619-c413616365fc_source_connector._tcpEndpoint#1536543 890.receiver.1] com.webreach.mirth.connectors.tcp.TcpMessageReceiv er: Server socket Accepted on: 5240
        INFO 2008-07-15 10:40:31,345 [7f28dd56-bc72-4a7c-b619-c413616365fc_source_connector._tcpEndpoint#1536543 890.receiver.1] com.webreach.mirth.connectors.tcp.TcpMessageReceiv er: TCP connection from /192.168.163.226:4138 on port 5240
        DEBUG 2008-07-15 10:40:36,345 [7f28dd56-bc72-4a7c-b619-c413616365fc_source_connector._tcpEndpoint#1536543 890.receiver.2] com.webreach.mirth.connectors.tcp.TcpMessageReceiv er: Message Received from: tcp://127.0.0.1:5240
        DEBUG 2008-07-15 10:40:36,345 [7f28dd56-bc72-4a7c-b619-c413616365fc_source_connector._tcpEndpoint#1536543 890.receiver.2] com.webreach.mirth.connectors.tcp.TcpMessageReceiv er: MuleMessage{id=[uniqueId not supported], payload=java.lang.String, correlationId=null, correlationGroup=-1, correlationSeq=-1, exceptionPayload=null, properties={
        receiverSocket=Socket[addr=/192.168.163.226,port=4138,localport=5240]
        }}
        TRACE 2008-07-15 10:40:36,345 [7f28dd56-bc72-4a7c-b619-c413616365fc_source_connector._tcpEndpoint#1536543 890.receiver.2] com.webreach.mirth.connectors.tcp.TcpMessageReceiv er: Message Payload:
        MSH|^~\&|PPM||||20080715104030||ADT^A08|6119238430 0001|P|2.4|||AL|NE
        PID|||A99999920|A99999920~000020~~~11111199~~~~|PA TIENT^TEST^^^||19520327|M|||PORTACABIN^BUILDING SITE^HALIFAX^ ^HX1 1AA||01484342000|||S|4E||07|||A|||||||
        PD1|||^^D81631^^|G9310050^^^||||||
        INFO 2008-07-15 10:40:41,611 [7f28dd56-bc72-4a7c-b619-c413616365fc_source_connector._tcpEndpoint#1536543 890.receiver.2] com.webreach.mirth.connectors.tcp.protocols.Defaul tProtocol: SocketTimeoutException on read() attempt. Socket appears to have been closed: Read timed out
        DEBUG 2008-07-15 10:40:41,611 [7f28dd56-bc72-4a7c-b619-c413616365fc_source_connector._tcpEndpoint#1536543 890.receiver.2] com.webreach.mirth.connectors.tcp.TcpMessageReceiv er: Closing listener: /192.168.141.43:5240

        Comment


        • #5
          Re:Acknowledgment from LLP Listener or TCP Listene

          Hrm...

          Code:
          webreach.mirth.connectors.mllp.protocols.LlpProtocol: Message terminator was: 56 Expected terminator: 0
          I agree that your terminator sequence looks off. That doesn't seem critical, but some extra bytes are being tacked on to the message or your encoding chars are janky.

          IMHO in this case one of the best tools you can use right now would be Wireshark (or tcpdump if you don't have a GUI). Set it up to capture a new message and an ACK between the two machines and see what you get.
          Jon Bartels

          Zen is hiring!!!!
          http://consultzen.com/careers/
          Talented healthcare IT professionals wanted. Engineers to sales to management.
          Good benefits, great working environment, genuinely interesting work.

          Comment


          • #6
            Re:Acknowledgment from LLP Listener or TCP Listene

            Thanks for the help.

            I have set Wireshark to capture the traffic, but I'm ashamed to say that I don't really understand the output it is giving me. I got the following when using the TCP connector (and listener port 5242).

            1 0.000000 192.168.163.226 192.168.141.43 TCP 4318 > 5242 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
            2 0.000032 192.168.141.43 192.168.163.226 TCP 5242 > 4318 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
            3 0.000507 192.168.163.226 192.168.141.43 TCP 4318 > 5242 [ACK] Seq=1 Ack=1 Win=65535 Len=0

            Comment


            • #7
              Re:Acknowledgment from LLP Listener or TCP Listene

              To follow the true data interchange in wireshark right-click at one of the rows and select "Follow TCP stream.."

              The problem you're having in Mirth seems to be related to a bad use of MLLP protocol by the sending application.. so you'll have to use the TCP connector.

              Post edited by: albertosaez, at: 07/15/2008 06:36

              Comment


              • #8
                Re:Acknowledgment from LLP Listener or TCP Listene

                Thank you very much for all your help. In the end the solution to my problem was very simple. I'd set the LLP listener frame type to ASCII when it should have been HEX.

                Comment


                • #9
                  Re:Acknowledgment from LLP Listener or TCP Listene

                  Colizobble wrote:
                  Thank you very much for all your help. In the end the solution to my problem was very simple. I'd set the LLP listener frame type to ASCII when it should have been HEX.
                  Glad you solved it, and thank you for posting your solution!
                  Jon Bartels

                  Zen is hiring!!!!
                  http://consultzen.com/careers/
                  Talented healthcare IT professionals wanted. Engineers to sales to management.
                  Good benefits, great working environment, genuinely interesting work.

                  Comment

                  Working...
                  X