adding error channels to the matrix

Mon, Apr 23, 2012

Time for a blog post methinks and good timing too as I’ve recently updated the Matrix provisioning system to support Invalid Message Channels in its routing engine. An invalid message is any message that can’t be processed for whatever reason including if the target system is down. This turns out to be quite convenient as the messages can be rerouted to the target topics when the system is back up.

Matrix Provisioning

The basic flow is:

  • GrandsonOfPliers, aka the Extractor pulls new and updated account information from SITS and transforms the business events into domain messages. Matrix domain messages that is, which wrap user information in some XML along with what to do with the message once it reaches a target system.
  • The message is sent to the maitrix JMS topic where it is routed to the activedirectory JMS topic using a transacted route. This means the message will be rolled back to and persisted on the matrix topic if the whole lot goes down before the consumer can pull the message from the activedirectory topic.
  • The gizmo that pulls messages from the activedirectory topic acts upon them and adds/updates/deletes the account in Active Directory accordingly and if all goes well it sends the message to the adprocessed topic back at the broker. The routing once again kicks in and the message is broadcast across all other target systems in parallel now that the base account has been provisioned.
  • If the Active Directory gizmo (strictly speaking, a Matrix::System AD specific implementation) fails to process the message for whatever reason it sends it back to the aderror topic at the broker and proceeds to pull the next message from the activedirectory topic.
  • When the bum message reaches the aderror topic the broker adds a retryCount header and sets it to 1. It then delays the message and routes it back to the activedirectory topic, where it is once again ingested by the Active Directory gizmo. If the message is still not a valid message it ends up back in the aderror topic and the broker increments its retryCount header. When a preset limit for the value of retryCount has been reached the broker routes the message to the adimc topic where it lives indefinitely until something comes along and pulls it out to see why it’s a bum message.
So messages are persisted at the broker if there is something wrong with them which also covers the situation where the target system is having a nap. The broker acts as the butler ready with the tray of accounts once sir has awoken from his midday slumber.

comments powered by Disqus