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

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Soarian Financials protocol inbound for charges, A08, etc.,

  • Creator
    Topic
  • #50800
    Wendy Holmstrom
    Participant

    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?

Viewing 9 reply threads
  • Author
    Replies
    • #67566
      Todd Lundstedt
      Participant

      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!

    • #67567
      Glenn Friedenreich
      Participant

      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

    • #67568
      Russ Ross
      Participant

      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

    • #67569
      Todd Lundstedt
      Participant

      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.

    • #67570
      Charlie Bursell
      Participant

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

    • #67571
      Jim Kosloskey
      Participant

      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

    • #67572
      Todd Lundstedt
      Participant

      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.

    • #67573
      Charlie Bursell
      Participant

      Todd:

      Send money  😀

    • #67574
      Jim Kosloskey
      Participant

      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

    • #67575
      Charlie Bursell
      Participant

      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  😀

Viewing 9 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
4,968
Forums
28
Topics
9,108
Replies
33,633
Topic Tags
248