web stats
Mirth to Mirth 3.7 TCP connection causing random number .dat files file writer. - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 03-06-2019, 08:59 AM
PCman911 PCman911 is offline
What's HL7?
 
Join Date: Mar 2019
Posts: 1
PCman911 is on a distinguished road
Default 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
File Type: zip Test Read Write TCP.zip (2.5 KB, 2 views)
File Type: zip Test TCP Write Files.zip (2.2 KB, 1 views)
Reply With Quote
  #2  
Old 11-15-2019, 09:09 AM
abenavidescr abenavidescr is offline
What's HL7?
 
Join Date: Jan 2015
Posts: 1
abenavidescr is on a distinguished road
Default

Hi, could you solve this behavior? I have the same problem.
Reply With Quote
  #3  
Old 11-20-2019, 06:23 AM
odo odo is offline
OBX.3 Kenobi
 
Join Date: Feb 2017
Location: Luxembourg
Posts: 144
odo is on a distinguished road
Default

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.
Reply With Quote
  #4  
Old 11-20-2019, 08:29 AM
agermano agermano is offline
Mirth Guru
 
Join Date: Apr 2017
Location: Indiana, USA
Posts: 1,031
agermano is on a distinguished road
Default

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.
Reply With Quote
Reply

Tags
dat file extention, file reader, file transfer, file writer, tcp

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 07:32 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation