- This topic has 10 replies, 6 voices, and was last updated 15 years, 5 months ago by
.
-
Topic
-
-
Replies
-
-
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!
-
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
-
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 -
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, 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.
-
-
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
