Soarian Financials protocol inbound for charges, A08, etc.,

[Wendy Holmstrom]

Has anyone used Soarian’s ‘Last/Not Last’ protocol to send charges and a08 updates from Cloverleaf? They are not configured to use mllp.

Also, since Soarian Financial does not ACK/Nak at the application level (only Network level) how do you guarantee they got the record?

Topic

[Todd Lundstedt]

We, too, have now run into the Siemens mindset bottleneck.  In setting up our charge interface into Soarian Financials, it appears their system uses a proprietary protocol that begins with a 7 byte length encoding, in addition to the MLLP encoding characters that surround the message (exclusive of the header?).

Has anyone coded a protocol that will allow Cloverleaf to communicate with Soarian directly?  Lord help us if we are going to be stuck with Openlink forever!

[Glenn Friedenreich]

We too have the same issue.  Several months ago, we discussed with the Soarian folks the possibility of them supporting the standard HL7 MLLP protocol for their HL7 inbound (outbound from our Cloverleaf system) and having them also support a batch transfer solution (like sftp) inbound to Soarian for XML files.  We’re still awaiting a response from Soarian.

– Glenn

[Russ Ross]

A long time ago I setup a real-time charge interface to another system but the problem I ran into still applies and you need to be aware of it.

Real-time interfaces the way we set them up resend messages when an ACK isn’t received after a time out period.

So it is only a matter of time before duplicate charges are received by the down stream system due to resends.

I since have always avoided this problem by doing charge integrations via batch files.

If forced to do a real-time charge interface it is imperative that the integration be designed to properly handle the same message being resent without creating duplicate charges downstream.

Good luck.

Russ Ross
RussRoss318@gmail.com

[Todd Lundstedt]

Glenn,

I have heard back from Siemens re: why they chose a hybrid of custom length encoding and MLLP.  The indication was MLLP was not robust enough to handle large messages with an efficient resend method (why resend the entire message when you can resend only a portion of it?).  They did indicate they would convert to standard MLLP on our request, and would do what they could to ensure that customization was not lost during upgrades, but they did not recommend that action.

I have since set up the connection/protocol configuration in an OPENLink Interface Engine according to the documentation, and tried to send a charge record.  I am still not successful.

Russ,

Very, very good point.  Batch sounds like a much safer way to go for the charges.  Thx for that aside.

[Charlie Bursell]

I suppose you are aware that you can write a PDL that will support any length of lenth encoding?  Not a difficult task  😉

[Jim Kosloskey]

Werndy,

That sounds like a job for Bob, Jim, and the boys at Oakwood  😀 .

Then share it with the community so everyone benefits.

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

[Todd Lundstedt]

Charlie,

Yeah, I am aware I could do that… but it’s not just length encoding, it’s last/not-last identifier, data/reply type, ack/nak indicator, length-encoding value, and then MLLP encoding around the message itself.  It looks like a beast to do, not ever having done a PDL write myself.

The reasoning I was given from the developers on why that method was chosen doesn’t make sense for the financial application (smaller record lengths), where this encoding scheme is in place.  It would make sense on a system that receives results (much larger records) and would be more efficient, yet their results system defaults to standard MLLP, if I remember correctly.

The reason that made sense in my head was to force customers to use their interface engine, as it is just a few clicks to get it done, there.  😀  😀

As it stands, we are going to have them change their system to use standard MLLP encapsulation only.

[Charlie Bursell]

Todd:

Send money  😀

[Jim Kosloskey]

Todd,

Wow – talk about wearing suspenders and a belt!!!

Oh well the Siemens folks (previously SMS) never really understood what they were doing from a technical standpoint in my opinion.

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

[Charlie Bursell]

I accused a couple of friends at SMS a long time ago of getting real drunk one night and deciding to come of with an interface that would really peeve everyone off.  Thus TIF/RTIF was born  😀

Looks like they went on another bender  😀

[Author]

Replies