PDL for inbound XML interface

[John Hervatin]

Hello!  We are trying to build an TCP/IP interface to receive inbound XML messages.  We are assuming we need to use PDL-TCPIP protocol, but what PDL should we use.  The incoming message appears to have no start encoding characters, and to terminate with 0x0a.  Is this standard for XML interfaces?  Is there a PDL available consistent with this?

Since we didn’t know what PDL to use, we emulated an existing HL7 terface and used mlp-tcp.pdl, but this looks for the HL7 MLP control characters.  Of course, that does not work.  To make it work with the XML message, would we just make a variant of mlp-tcp.pdl that defines no start character and an ending string of 0x0a?

Thanks in advance for any insight you folks might have,

– John Hervatin

Here is the dump of the incoming message:

3c 3f 78 6d  6c 20 76 65  |.<| 2f 6f 69 6d  3e 0a        |/oim>.|

Topic

[Jim Kosloskey]

John,

Why not check with the sending system and see if they can length encode the message (this is pretty common in the TCP/IP world)?

If they can length encode then use the TCP/IP not PDL protocol.

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

[John Hervatin]

Thank you Jim!

We’ll follow that lead.  We had been considering having the vendor encapsulate the message with the mlp characters, but your suggestion seems more sensible.

Our next question would be what is typical as far as sending an ACK/NAK back to the sender?  What exactly needs to be sent back and how is this accomplished?

— John

[Jim Kosloskey]

John,

Well if the vendor has no requirements for acknowledgments then you get to negotiate that with them.

Ideally you would want something from each message that uniquely identifies the message (like the MSH-10 field in Hl/7).

All of the good message standards seem  to have that.

However, if the  vendor does not have an acknowledgment specification, it is doubtful the vendor has given any thought to that. If that is the case, it is beginning to sound like this is not a very sophisticated vendor.

OK at a minimum you need to have some sort of message you send back that indicates success or failure with the message. Given the vendor seems to be XML biased, I am guessing they will want an XML structured acknowledgment.

Hopefully they do not care, in which case you can send something a simple as a one byte message (pretty efficient – not so practical).

Were it me I would want to send something kind of human readable (like ACK and NAK) along with something from the inbound message that makes it unique or at the very least a date/time stamp associated with the message (maybe you could use the mid from the metadata – that will be relatively unique I would think and you can then associate it with the inbound message in SMAT).

Just make sure you and the vendor agree on how acknowledgment handling will work and have that documented and signed off.

By the way, would you like to share who the venodr is so we can all be prepared should they show up on our radar?

Just a suggestion – put your organization and contact information in your profile.

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

[John Hervatin]

Thanks for all your help, Jim.

The vendor system is Oracle Identity Manager and is being installed by an outfit called Entology who has been very cooperative, though we have both been learning as we go in building this interface.  

Since most of our existing inbound tcp-ip interfaces use mlp_tcp.pdl which looks for x0b start and x1c0d termination, I asked the vendor to encapsulate their xml message with these characters, and the message handoff was then successful.  I also constructad a very simple reply in xml format that is sent back over.  It’s always a “success” message built by a reply gen tcl in the Inbound TPS., meaning simply that we took possession of the message, but not necessarily that it is sound.  That appears to be adequate for now, at least.

We have also successfully built the interface on the receiving side (Cerner Millennium) and managed to post our first couple of transactions to achieve the expected changes in the target database (woo hoo!).

One remaining issue is a snag with message flow.  It appears that OIM opens a connection and then closes it with each message.  When several messages are sent in quick succession, the first one processes through but the second get gets a “connection refused”.  I figure it’s because the Cloverlef thread also terminates when the client goes away, and has not quite released the socket by the time the second message tries to open a new connection on that port.  The sender evidently jost stops, without retrying.

Entology says they can’t just avoid closing the connection, as each new message will open a new one.  They are on Linux OS running a jBOSS application server (whatever that is).  

Anyone have any advice on how to direct this vendor?  Would I be correct in asking them to configure their interface to either build a delay between their messages or to have it retry repeatedly if a connection is refused?  If so, what is a typical configuration?  Continue trying for what length of time and at what kind of intervals?

I mentioned that we encapsulated the XML messages with the MLP start and termination codes.  On a philosophical level, though, isn’t an XML message self-decribing.  Would it not be sufficient for the Cloverleaf driver to just look for the beginning and ending root element tags to determine the start and end of message (but the tags need to remain part of the message.  Wouldn’t this suggest a general-purpose PDL that recognizes xml messages generically?  Does such an animal exist already and not need to be re-invented?

And, as for ACKing or NAKing the message, there is a practical limit to the amount of validation that the inbound TPS tcl script can do to decide if the message is sound or not.  In the Xlate process, there is built-in functionality in Cloverleaf that validates the incoming XML message against the referenced XML Schema.  So, we could be accepting and ACKing a message in inbound TPS that will later be rejected by the Xlate.  Is there a way to draw upon this XML validation in order to ACK or NAK the incoming message?

[Author]

Replies