soarian finacials sbo interface

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf soarian finacials sbo interface

  • Creator
    Topic
  • #50731
    Mason Miller
    Participant

    is anyone doing a xml interface from Soarian Finacials for SBO out to collections and from collections back into Soarian Finacials I am using cloverleaf for this and was looking to see if anyone has done this and what issues I may run into.  

    Thanks

Viewing 7 reply threads
  • Author
    Replies
    • #67292
      Wendy Holmstrom
      Participant

      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

    • #67293
      Glenn Friedenreich
      Participant

      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.

    • #67294
      Todd Lundstedt
      Participant

      We had similar issues here with XML into SoarF.

    • #67295
      Rob Abbott
      Keymaster

      Quote:

      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.

      Rob Abbott
      Director, Product Management - Infor Cloverleaf

    • #67296
      Tom Patton
      Participant

      Rob Abbott wrote:


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

    • #67297
      Jim Kosloskey
      Participant

      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.

      email: jim.kosloskey@jim-kosloskey.com

    • #67298
      Rob Abbott
      Keymaster

      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 Abbott
      Director, Product Management - Infor Cloverleaf

    • #67299
      Tom Patton
      Participant

      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.

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

Forum Statistics

Registered Users
4,966
Forums
28
Topics
9,106
Replies
33,627
Topic Tags
248