No announcement yet.

Mirth to Mirth 3.7 TCP connection causing random number .dat files file writer.

  • Filter
  • Time
  • Show
Clear All
new posts

  • Mirth to Mirth 3.7 TCP connection causing random number .dat files file writer.

    First of all thanks to everyone who views this and responds.
    I am new to the Mirth Community, but not necessarily new to Mirth Connect.
    I have been creating HL7 in and out channels for over a year now.
    I have also created HL7 file reader and TCP connections.

    My situation:
    I have a Mirth connect 3.7 machine at a remote site connected through site to site vpn to a Mirth connect 3.7 at my site (main location).
    I am trying to read files dropped into a directory on the remote machine, send them over a TCP connection to the main site, and write those files to a directory on the machine at the main location.
    The file types could be Excel (xls), Documents (doc, rtf), PDF, and some postscript print files.
    On the remote machine I was able to create a single channel that could read (file reader) from those files from C:\test (source) and write (file writer) those files to C:\test2 (destination) and everything worked great.
    On the local machine I did the same and created a single channel that could read the same type of files from C:\test (source) and write those files to C:\test2 (destination).

    Now I cloned the channel on the remote machine and instead of using file writer for the destination, I am using TCP Sender (basic TCP not MLLP) to send the files to the local machine. The source is still file reader from directory.
    I cloned the channel on the local machine and instead of using file reader for the source, I am using TCP Listener (basic TCP) to receive the files. The destination is still file writer to directory.

    I am using binary and not text. I have * for the Filename Filter Pattern on the File Reader. I have ${originalFilename} in the file name field on the destination File Writer.

    Under template for both the reader and writer I have tried ${rawFile}, tried ${message.rawData}, tried ${message.encodedData}, tried ${originalFilename} with no luck.

    When I used file reader and file writer I could take example.pdf and example.doc and get them from one directory to another just fine.
    When I use the TCP sender and receiver the file sends from the remote machine, and is received at the local machine over VPN, but the file written to the directory has a name of numbers.dat (ie. 1551839902564.dat).
    If I rename the file back to example.pdf or example.doc that it was (using file size comparison) then I can open them correctly.

    So the files are getting transferred, just the name of the files are not.
    I found a few threads and on google posts about the .dat files being part of a transform, but I can not find these settings and not trying to change anything.
    Maybe I am over complicating this and should just use SFTP program to move the files.

    I am attempting to attach zip files of the 2 channels, the reader/sender and receiver/writer.
    Attached Files

  • #2
    Hi, could you solve this behavior? I have the same problem.


    • #3
      It looks like you did not define a proper filename in your destination. If you use e.g. ${originalFilename} it works fine when the file is read from filesystem as the inbound connector sets this variable. If it is however sent via TCP it does not possess a filename and mirth thus generates a generic name which is like the one you described.

      For solving your issue you would have to transfer your filename as well. You would also have to separate it from the binary itself with a character that would not appear in the filename itself (e.g. 0x00 or ':'). At the receiving side, you would have to split up both parts and set the received name as filename in the template.

      Check java.util.Arrays for the required operations.


      • #4
        Mush easier would be to use http senders/listeners. Send the file contents as the message content and send the filename in a query parameter.

        You could write your own ad hoc tcp framing protocol, but http already exists and is well supported in mirth.