best way to setup an inbound thread that takes flat file of DFT HL7 messages?

[Jason]

What I have is a flat file of DFT HL7 messages, well, let’s back up. I don’t have that yet, I have it in a SQL Server table that I will extract to a flat file. So assuming I have that: A) can the flat file contain multiple HL7 messages? Or is it one HL7 message per file? B) How would I setup the inbound thread to read this? I’m going to direct it to a simple outbound TCP/IP thread.

Thanks and sorry if this is a basic/noob question but most of my limited time so far with Cloverleaf has been with TCP/IP inbound threads.

Topic

[James Nelson]

Yes, you can have multiple records in your input file.

Format the file with one record per line with a newline at the end.

Use the FileSet-local protocol and in the Style field, select ‘nl’ for your inbound thread.

[Jason]

James,

got it, but what stops the inbound thread from reading the input file over and over again?

[Jason]

also, what’s the difference between the file and fileset protocol?

[Jason]

think I figured it out, file is just one file and fileset is multiple files, and it looks like file can spit out the read file into dev/null so that answers my previous question about how it knows to not read it again

[Jim Kosloskey]

Actually the Fileset Protocol (which is what I would use) deletes each file after reading.

With this protocol, you have control of which files discovered should be read and which files processed should be deleted via UPoC if you do not like the default.

Personally I try to use one message per file. The file names need a date/time stamp and typically a counter to break ties otherwise files could get overwritten.

This minimizes the potential a file being read while it is being written to and simplifies resending from the source system if that is necessary.

There are discussions on this forum with techniques to minimize the read/write collision potential which would be wise to use if you decide to place multiple messages per file.

I think even in the current release neither protocol will inform you when you have reached end of file if that is important to you. Someone can correct me if this has changed in current releases.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jason]

sorry question, for the nl style in fileset protocols, doesn’t that mean newline? and if that’s the style for file separation, isn’t newline usually the segment separator?

the way my file is now, the the newline separates the segments and the 0x1c and 0x1b separates the messages… which style should I pick in this case? Single?

thanks and sorry for the confusion

[Peter Heggie]

Does the SQL Server table have one row per message? Is the entire message in one column? If so, then you could use a database inbound protocol to read the table , with some criteria to avoid pulling in the same rows every time. You can configure the protocol to treat each row as a separate message.

If multiple messages are concatenated into one column, then you have a different problem to solve. Usually HL7 messages have a NL or CR after each line – each segment – and then there is an EOF at the end of the message. You may need TCL code to keep reading until you find the next occurrence of “MSH”, and then you take all that you have read so far, and put it into a new message. Then start over with the next MSH.

Peter Heggie

[Jason]

yeah I thought about reading it from SQL as well but I wanted to try to see if I could do it file-based before I jumped into using database protocol.

the other thing is, the messages in SQL are formatted weird, it’s one HL7 segment per row, so I need to pivot multiple rows into one row just to make a complete message and it’s a real pain to figure how to format this thing

[Jim Kosloskey]

I firmly believe in utilizing Stored Procedures with DB Interactions via Cloverleaf – even if using the built in DB protocol.

There are a number of reasons for that preference. Included is the exact complexity you describe in getting a single message out. If you would like to discuss my thoughts vis-a-vis the use of Stored Procedures off line, email me.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Author]

Replies