Zero-loss Queuing Solves Healthcare Company's Message Reliability Issues
Data transfer between systems, both external and internal, is an important component of today’s technology-driven businesses. Integration is at the heart of this interaction.
Unfortunately, without an appropriate integration solution, messages can be delayed or never arrive. More importantly, the business has little visibility into message performance, making it difficult to manage or retry these messages when needed.
Our healthcare client was experiencing these kinds of integration and business issues. They needed a solution that would significantly reduce the message loss they were seeing when transmitting large amounts of data between systems. Some messages failed due to target systems being unavailable. Others were accepted by the enterprise service bus (ESB) but rejected by the receiving system due to programmatic errors.
To solve the problem, a solution was developed using a reliable acquisition flow pattern and leveraging the MuleSoft ESB to store the messages for processing.
MuleSoft’s application acknowledges the message is received and places it into a message queue. The messages are processed asynchronously after receipt, and a listener application ensures that messages are processed according to established business logic.
Messages are stored in the queue for a configurable length of time. Should a message repeatedly fail, it’s moved to a separate queue for manual intervention. This “dead letter queue” triggers an email notification or help desk ticket to alert users to the need for correction and reprocessing.
With the new system in place, the client has guaranteed delivery of their message and a means of gracefully handling transmissions in need of attention. The “hold and retry” mechanism is automatic, removing the need for intervention. And visibility and alerting into failed messages improves the error handling for only those transmissions in need of attention.
ADOPTION & EXPANSION
+ Number of APIs
+ Business coverage
+ Number of contracted apps
+ API usage
+ API reuse
EFFICIENCY & COST SAVINGS
+ Number of APIs in each SDLC stage
+ Time spent in each SDLC stage
+ Cost and time to build an API
+ App development velocity
+ Number of launches per year
+ Number of defects
SECURITY & VULNERABILITIES
Time since the last version was published
Number of throttling issues
+ Time to onboard
+ Number of deployments
+ Number of incidents
+ Percentage of customers impacted. per incident
+ Time to resolve incidents