inbound JSON thread

[Matthew Rasmussen]

I think I’m missing something simple here.   On a 19.1 engine, I have an inbound tcp/ip thread (no PDL) that is bringing in a JSON message.  It’s encapsulated USER Mode, no start block, end block is \n.  I am formatting the JSON before I receive it in newline format, and that works fine.  I’d like to be able to bring it in without that upstream manipulation, so it just reads in the file with CRNL at the end of every JSON line.  I think the solution is in changing the encoding blocks…  I’m thinking of injecting a special character upstream at the end of the messages, and using that character as the end block. Does anyone have a more elegant or standardized method to bring in a JSON on a TCP/IP thread?

Topic

[Jim Kosloskey]

If this is in a file (your post indicates File and TCP/IP), then perhaps setting the style on the Fileset Protocol to NL (assuming \n means newline in your post)  will get you what you want.

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

[Matthew Rasmussen]

Hi Jim,

Thanks so much for the reply.  No, sorry I didn’t specify – the source is a tcp/ip file stream.  I am injecting a very unique character sequence at the end of each message on the source before it gets to Cloverleaf, and I’m using that sequence as the end block in the encapsulating settings – that’s working ok.  I just didn’t know if there was a more standardized way to slice the message out.

 

[Jim Kosloskey]

Well normally in a TCP/IP (or any real time interface) one would want some sort of message encapsulation. For FHIR, MLP can be used and that matches up with what you would typically do with HL/7.

Typically the Source system would do the encapsulation before the message is sent out the TCP/IP connection.

It sounds like in essence you have the source system providing some sort of encapsulation that works for you.

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

[Matthew Rasmussen]

MLP! that would be the standardized approach.  It seems so obvious now that you mention it.  Here I was trying to reinvent the wheel, I just needed to emulate the wheel.  Thanks so much Jim!

[Charlie Bursell]

You say you are formatting the message before you receive it. How is that?  How do you access the message prior to receipt?  Is the message just text or is it XML?  Is the format of the data always the same?  For example does it start and end the same  way?

An example would be nice.

[Matthew Rasmussen]

Hi Charlie,
The message is JSON over tcp/ip to/from another integration platform.  So we have a little control over both ends of the interface, which is nice.  The start of the message has a lengthy, but finite pattern, but the end is a bit more unpredictable.  Our first approach several months ago was actually to latch onto that pattern for the start block. And we were able to make it work. But when I presented this to our director, he wanted to see a cleaner separation between the protocol and the payload.  I think I’m going to try to get them to emulate the good old MLLP start and end characters as Jim suggested. That should keep things standard on Cloverleaf.
The message is like this:

{“Status”:{“SourceSystem”:”CLOVERLEAF”,”Environment”:”TEST”…
“Data”:{“MSH”:{“MSH_1″:”|”,”MSH_2″:”^~\&”,”MSH_3″:{“HD_1″:”EPIC”}…}

From there, the Data block just reads on like a plain HL7 message in JSON clothes.  Just objects and strings, with [arrays] to represent repeating group/segment/field structures.  It’s been an interesting project.  Looking at the complexity and size of these JSON messages really makes you appreciate the simplicity and efficiency of HL7.
Thanks very much for the reply, Charlie.

• This reply was modified 3 years, 8 months ago by Matthew Rasmussen.

[Charlie Bursell]

Because you do not have consistent messaging it would be hard to make a clean interface without some help on the other end.

Since you have control at both ends I think the most ergonomic solution would be to make the message length encoded.  You have the option to meet any length encoded protocol, 2 bytes, 4 bytes etc.  With an encapsulated message the engine must read the entire message to find the encapsulation characters.  With length encoding it just read the first 2 or 4 bytes to know haw much to read.

Good luck with it.

[Author]

Replies