soarian finacials sbo interface

Mason,

We are currently sending and receiving sbo data via XML format.

When we started sending /receiving HL7 adt, etc data to and from soarian , we request acking. They did not have ‘application’ level of acking available, at which we requested that they write and MLP protocol as we use this standard.  Siemens built it and it works wonderful with us.

On that note, when we started sending the XML, they asked us to use the MLP protocal. We have been using it, and now they have found issues. There has been some concern raised by Siemens development about the potential size of XML transactions and the buffer size required to transmit them in one data packet into SF. They’ve asked if  Cloverleaf has the ability to accept split packets inbound using the MLLP protocol? I don’t believe that Cloverleaf does and Siemens said that they’ve had these issues with other Cloverleaf customers. This is where it stands.  If anyone has any suggestions that would be helpful, please let  us (Mason and I kmow).

Wendy Holmstrom

Hi Mason – We’ve had the same issues with Soarian as Wendy has (Wendy and I chat about this from time to time).  I don’t believe we can split the packets using Cloverleaf.

As of right now, we’re in discussions with Simens about having them possibly set up an Openlink server on their side (we’re working to implement Soarian via ASP).  We would then copy the XML files to/from Openlink (via FTP, I assume), and let Openlink deal with the file transfers to/from Soarian Financials.

We had similar issues here with XML into SoarF.

They’ve asked if  Cloverleaf has the ability to accept split packets inbound using the MLLP protocol? I don’t believe that Cloverleaf does and Siemens said that they’ve had these issues with other Cloverleaf customers.

Cloverleaf certainly has the ability to accept multiple packets for a single message.  This is what encapsulation is all about.

e.g.

tcp packet 1: data…

tcp packet 2: …more data…

tcp packet 3: ….data

The message to Cloverleaf will be “data……more data……data”.

Interesting that they claim they have had issues with our MLP driver in the past…I would argue that this isn’t a problem unless there is a significant amount of time between packets.  The driver will eventually time out waiting for that end block to show up.  The length of this timeout is configurable in PDL.

Cloverleaf certainly has the ability to accept multiple packets for a single message.

Good old Siemens. In a weird way it is somewhat comforting to see they still have not changed their ways even with new software – make the customer adjust for your failings.

Tom: I suggest you concatenate the messages at IB TPS.  It would be much easier to do and maintain here vs in PDL.  Plus you are able to separate the application layer from the protocol layer.

The basic logic is this:

– if we receive a “not last” message, append the data to a global buffer and store the message handle in a global list.   hold the message handle – return nothing to the engine.

– if we receive a “last” message, append data to buffer.  create new message with contents of buffer. continue new message.  kill all “held” messages.  clear all globals.

The “hold messages” logic is important to make this recoverable should the thread be stopped in the middle of a partial transaction.  When the thread is restarted, all held messages will be replayed through IB TPS.

As an example, I have attached a TPS called “tpsDSCJoin” that will concatenate incoming HL7 messages using continuation pointer logic.

Hope this helps

Rob, thank you – I was on the same path – just not thinking of the IB TPS.  But that’s a better option.  We’ll ACK every msg and hold msgs until we get the last.

Thanks – and thank you for the code.