Issues connecting to a server
poutena opened this issue · 7 comments
I've been using your library for integrating our services with a few other service providers, and it's been working wonderfully – except for one provider.
Sending them a message results in a HL7ConnectionException with message 'Response partially received. Timed out listening for end-of-message from server error. The message itself is sent, but I just can't get the response. If I relay the message through Mirth Connect (i.e., I set up a listener on Mirth which, upon receiving a message, sends it to the service provider) it works without any issues, and the ACK is properly returned.
I tried changing the response encoding (it's ISO-8859-1) and it didn't make any difference. Increasing the timeout to 2 minutes didn't change anything either, and through Mirth the response is immediate. Debugging $data and the socket status just before the exception is thrown shows that $data is empty and the socket had no errors (i.e., socket_last_error() === 0).
Using Mirth as a proxy works, but it's an extra point of failure and, since I'm still fairly new to this, I'm having trouble configuring it to return the ACK message, so I would love it if I could find a way to make this library work directly.
Can you do a packet capture (using tcpdump/wireshark) and see what the other end sends as a response?
It's the first time I used tcpdump, so apologies if I haven't captured what you were looking for. Thanks in advance!
No worries at all. I changed the extension from .txt to .pcap and opened in Wireshark for analysis. I could be wrong but it probably didn't capture the frames fully.
You may want to use the option -s 0 to ensure it captures full packets, and use the extension .pcap instead of .txt.
Also, since the while() loop is entering I'm guessing socket_read() did get some data. If possible can you dump $buf to check what it is? It may be bytes (as HL7 endpoints use 'MLLP' protocol to communicate, that prepends and appends certain bytes to each data sent) and non-printable ASCII characters, so you may have to figure out how to print that.
Unfortunately I'm a little preoccupied at this moment, so not sure how much I can help troubleshooting.
If nothing works, you can use a separate MLLP tool to send HL7 instead of using Communication class. There are several available for PHP and Nodejs.
capture.zip
Thank you so much! Feel free to reply only if / when you have the time to do so. Your library's been a lifesaver, and you've already helped more on this particular issue than I have the right to ask you.
For now, I've attached a new capture with the -s 0 option that you mentioned. I couldn't find a PHP MLLP tool, but I'll try to implement something (for example, using streams instead of sockets) to see if it makes any difference.
I can see the frame properly now in Wireshark. It contains the ACK message:
00 50 56 b0 77 e3 24 16 9d 62 01 81 08 00 45 00 .PV.w.$..b....E.
00 d5 35 ba 40 00 75 06 59 32 0a c8 fc bb 0a 31 ..5.@.u.Y2.....1
64 82 4a 4f b3 44 7e 52 41 12 da b0 c1 37 80 18 d.JO.D~RA....7..
01 ff b9 e8 00 00 01 01 08 0a 5d d6 49 c4 a6 89 ..........].I...
0c b5 0b 4d 53 48 7c 5e 7e 5c 26 7c 4d 45 44 4f ...MSH|^~\&|MEDO
52 41 7c 30 7c 4b 49 53 7c 7c 32 30 32 31 30 39 RA|0|KIS||202109
32 30 31 38 33 35 30 33 7c 7c 41 43 4b 7c 34 32 20183503||ACK|42
39 32 38 31 36 31 7c 50 7c 32 2e 32 7c 7c 7c 41 928161|P|2.2|||A
4c 0d 4d 53 41 7c 41 45 7c 32 37 7c 7c 7c 7c 42 L.MSA|AE|27||||B
45 45 30 30 30 31 5e 4f 20 72 65 6c 61 74 f3 72 EE0001^O relat.r
69 6f 20 61 70 72 6f 76 61 64 6f 20 6a e1 20 66 io aprovado j. f
6f 69 20 74 72 61 6e 73 6d 69 74 69 64 6f 2e 20 oi transmitido.
4a e1 20 73 f3 20 73 e3 6f 20 70 6f 73 73 ed 76 J. s. s.o poss.v
65 69 73 20 63 6f 72 72 65 63 e7 f5 65 73 2e 5e eis correc..es.^
0d 1c 0d ...
It does have the expected beginning marker 0b, ACK message, followed by the ending marker 1c 0d.
The problem is, there are few extra characters before the beginning marker 0b, so the code preg_replace('/^' . $this->MESSAGE_PREFIX ... fails (because of the ^)!
Can you please check with the vendor if those extra characters before 0b are of some significance, and if those can be removed?
Also, since the data is proper, I wonder if you're still getting the same timeout message, as it seems $data is getting populated?
I'm also getting that message - "Response partially received. Timed out listening for end-of-message from server"
This usually happens when the other end do not send with proper prefix or suffix to the message, or contains additional characters before prefix or after suffix. Check above message for details on what's expected. In summary, a message should start with 0b and end with 1c 0d.
The best way is to do a packet capture and see what is the other end is returning. Please let me know if you find nothing wrong in the received message, and the issue could be in this library.