Integration middleware on tomorrow's Platform Call

1

We had a number of discussions around application level events and integration middleware in OpenMRS over the years. We’d like to coordinate efforts and unify the approach. I’ve created TRUNK-6507 to move the work forward.

Please join tomorrow’s Platform Call to discuss TRUNK-6507.

2

Thanks again for joining everyone!

The additional key takeaways for me are:

  1. When choosing a broker, put emphasis on queue visibility and management via UI so it’s a lower learning curve. Consider a demo on a follow up call.
  2. Make sure there are clear code examples with tests and docs on how to guarantee message delivery and failure handling so events are not lost.
  3. Touch base with @wikumc on integrating with Apache Flink.
3

@Mekom I missed your voice on the call! Do you use brokers in your integrations? I know you use Debezium and Camel, but is there any broker involved?

4

Here’s a good documentation on what the UI console looks like for ActiveMQ Artemis: Artemis

And RabbitMQ:

Artemis provides much more insight into the actual queue content than RabbitMQ. You can even inspect individual messages and move them between queues. RabbitMQ is simpler to use and gives a good overview of what’s happening in the broker, but you have no insight into message content and you cannot change messages in queues.

5

No, currently we store all the events in a management database first, which includes some retry logic to guarantee message delivery. From the DB, the events are wired into Camel routes for further processing.

openmrs-db-sync project uses ActiveMQ as a JMS broker, @wyclif can comment on the experience of using ActiveMQ?

2 Likes