Ever wanted to connect BMC Remedy with Message Broker Systems like RabbitMQ? Now you can.
In the last 15 years, we have designed and built many integrations between BMC Remedy and various partner systems. While the partner systems varied the requirements for the integrations had a lot in common:
failsafe connections - even if one partner system is not available it should not break
scalability - nearly all needed to support high availability, high throughput or both
To fulfil these requirements we usually created some kind of interface queue where outgoing events were stored until the partner system polled them. While this had many advantages it came with a few major drawbacks:
delay in communication - the queue is only polled every so often
not very scalable - a queue form requires exclusive access
technology dependency - the partner system needs to be able to talk to the queue from
When we designed our new generic interface framework for BMC ITSM it was clear for us that we needed something better. We still wanted to loosely couple the systems but we wanted instant communication. We also wanted our framework to scale well for high availability and high throughput.
Common design patterns to solve these problems are message queues. Their history reaches back to the early mainframe days but even today their advantages are still valid. Many modern microservices use message queues for asynchronous communication and remote process execution. We were sure that message queues were the way to go for us. There was only one problem: BMC Remedy can’t talk to them.
Our solution
We first wanted to create a vendor form plugin. This would allow us to create messages on a queue like normal records in forms. But it would also require a fair amount of configuration on the customer side and we need to rebuild the plugin with every BMC Remedy release, service pack and hotfix. That wasn’t an option. We needed something else.
BMC Remedy can talk to outgoing web services out of the box. So we created a gateway/bridge that provides a soap endpoint. Each request to the endpoint will publish a message on the broker.
ITMS -> AMQP Bridge architecture
We can address this bridge from every Set Fields action in filter workflow. It accepts an exchange name, a routing key and a message as options.
Example usage of the bridge in a set fields action
The bridge will return success if the message was published on the exchange or error if anything went wrong. An additional message is provided for errors.
With this bridge, we achieved instant communication for our generic api framework for BMC Remedy ITSM and we also made sure it is ready for high availability and high throughput.
We believe the AMQP Bridge can help you as well to build better integrations. We, therefore, decided to make it available as open source. Feel free to use it in your projects. Any contribution is welcome. Happy coding!