Controlling file names at CSC client

We are running CSC4.0 and I had the same requirement to control the filename.  What I ended up doing, with lots of help from James McPheron, was to add a proc to CSCs TCL proc stack for the client and add a reference in custom_main to schedule that proc to run on the client.  What the proc does is run every N seconds and scan the output directory to see if there is anything in it.  If all you need to do is control the extension then the proc could easily roll through those files and rename them with a new extension.  What I needed to do was control the entire filename and I was delivering both HL7 and a PDF via the same connection.

The PDF complicated things dramatically because I needed to base64 encode it and then decode it on the client side.

The solution in my case was to set the message up in Cloverleaf (before it ever gets to CSC) so that the first line in the “message” is the filename and the rest of the message is the message content.  What I found was that I could open the file and fconfigure the filehandle then perform a read which gave me just the first line in the file (the filename) and subsequently perform a gets against that filehandle which gave me what remains in the file.

To make a very long story much shorter, it works very well and if you still are struggling with this I will be glad to get you the procs that you need.

I should also point out that CSC 4.0 does not properly source the soc_outbound_upoc on a file-based connection and does not source the soc_inbound_upoc on the other types of connections.  That is why this work-around is required.

As I understand it, those UPOCs are properly sourced in later versions and would be the correct place and method for performing this task.  I will know for certain soon because I am bringing up a CSC 4.1 box currently.

Scott,

I’m also facing the challenge of specifying the name of the file the Client is receiving.

So, two things:

1) did you find any diferent behavour with 4.1?

2) would you please forward your solution to me?

Thanks,

Neil

We ended up skipping to 4.3 instead of 4.1.  That said, we have more control over the resulting filename with 4.3 but our solution for 4.0 still stands because we wanted to be able to use the filename that came in to us, we didn’t just need the filename to be unique.

CSC 4.3 (and 4.1 I think) does properly source the upocs so the solution is significantly easier than it was in 4.0, if you are using 4.0 I would definitely recommend that upgrade because the 4.0 solution is a pain.  I will post both of them here on Monday as it will take me some time to assemble them together.  Have a great weekend!

Sorry this took so long but without further adieu, attached is our solution to controlling the filename in CSC on both 4.0 and 4.3.  Some caveats:

1.  These assume that you have set the message up using cloverleaf before they get to CSC.  Setting up the message means to add the filename on as the first line in the message and that line needs to be newline terminated.

2.  Once the first line has been added it is also assumed that you base64 encoded the message.

3.  The 4.3 solution shows only the csc_outbound_upoc because we do a bunch of custom stuff in the other upocs as well and they are specific to us so I did not include them here.

4.  The c_file_ext.tcl file must be sourced in your cloverleaf tab on CSC for the client you are setting up.

The way that the 4.0 version works is that it delivers the file as the default filename that CSC uses (soc_), it then runs every X seconds on the client and renames that file to the filename that you want it called.  This means that the receiving system needs to know not the pick up every file in that directory or you need to make modifications so that the files are placed in one directory and renamed into the directory that the receiving system is looking in.

The 4.3 version is much more straightforward, it grabs the filename from the message, writes the file out with that name, and then kills the message.

Oh, one more thing, our solution is the way that it is because we wanted to keep the ORIGINAL filename, your solution would not have to include all of those caveats if you just want to control the filename.  This is because the outbound filename does not have to ride along with the message, in that case you would just create the filename in the c_file_ext.tcl or in the csc_outbound_upoc and use that to write (or rename) the file.

Care should be taken (regardless of your requirements) that you understand the fconfigure command in TCL or you WILL be pulling your hair out when trying to send out a PDF or other image file.

The usual jargon applies here in that I do not warrant that this solution will work for you.  It does work for us in many different instances but you need to test it and understand exactly what it is doing before using it.

Good luck!