Announcement

Collapse

Mirth Connect 3.12.0 Released!

Mirth Connect 3.12.0 is now available as an appliance update and on our GitHub page. This release includes database performance improvements, improves visual HL7 representation, message pruning, keystore handling, PDF generation, community contributions, and fixes several security vulnerabilities. This release also contains many improvements to commercial extensions. See the release notes for the list of fixes and updates.

Download | See What's New | Upgrade Guide | Release Notes

For discussion on this release, see this thread.
See more
See less

which way is the better one?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • which way is the better one?

    Hi

    We are building an interface which receives hl7 messages, extracts certain fields from them and stores them in more than 30 tables in the database
    We were doing this using C++, but the traffic of packets is now exceeding so much that we are having loss of data.

    So, can this problem be solved using Mirth?

    And if so, which approach is better for this task?

    1.) We recieve the packets,process them and store the data in the database using single channel.
    In doing so, if the traffic is large,does Mirth have the buffer large enough to store the packets?

    2.) We recieve the packets in one channel and store them in the database without processing,and in the second channel we retreive
    packets one by one from the database, process them and strore the extracted fields in the
    differnt tables in the database.

    Please help us with this dilemma,if Mirth is feasible for this,we will be happy to embrace it,and also
    buy the support facilities.

  • #2
    Re:which way is the better one?

    A few questions to consider - how many messages per second do you need to process? Is the rate of messages consistent, or do they come in bursts?

    At one point, I had a similar problem. I found that instead of having a single listener channel doing all of the work, creating a simple LLP listener that received and queued messages to other channels which did the real work solved a bunch of timeout errors on the sender's side.

    Also consider the backend database that Mirth uses. Additional horsepower there can significantly improve how quickly Mirth processes messages.

    Comment


    • #3
      Re:which way is the better one?

      Hi mnowlin,

      1.)Per second we are getting 200-500 messages.
      2.)The rate of messages vary, sometimes its continuous,but some clients send messages in batches,so they come in bursts..
      3.)Also, we are using Sybase as our database,can we stil use the database of Mirth?
      4.)Also, out real problem is that we have a channel which receives hl7 messages and stores it in the database,and from there when we retrieve the messages for processing in Mirth, they are received as String, which we have to transform in hl7 format again for mapping,where errors are comming.

      Can you please send a sample channel doing so..or some help regarding it..

      Thanks

      Comment

      Working...
      X