...
| Note | ||
|---|---|---|
| ||
The message headers & body will depend entirely on the actual message being sent. The messages in this mockup are probably not an accurate representation of the final presentation format. (Specifically, the Origin and Destination headers will probably be queue names, in the form "jms.queue.some.queue.name.x.y.z") |
This UI communicates with the DDF backend to list all messages that could not be delivered internally. An admin will be able to select any number of the messages
and then choose to either resend the messages to their original location or delete the messages, clearing room. The UI will be accessible from the Admin UI (https://localhost:8993/admin) under the "Message Broker" app (working name).
- The UI mockup shows that the "Undelivered Messages" UI tab will be a separate tab from the configuration, similar to the "Sources" tab, under the "Catalog" app.
- There will be two actions available to the admin, "resend," which attempts to redeliver the selected messages and "delete," which removes the messages from the UI and underlying dead letter queue.
- Below the two action buttons will be a line of text saying how many messages out of the total have been selected. There will be an option to select all messages, as shown in the mockup.
- The main portion of the UI will be a table. The initial UI table will consist of 3 columns: a checkbox column, to select/deselect messages; a timestamp column, the time the message was originally sent; and the message, the full text message of the body.
Future Capabilities, features, ideas:
- Instead of full body of messages, an expandable preview
- Include message headers (separate column?, in the message body?, etc)
- Origin/Destination columns (where was the message coming from, where does it intend to go)
- Extend this capability to other queues as well, so an admin can see if a queue is getting backed up
- metrics on the DLQ and others (how many messages have i gotten in the past hour/minute/second/month/etc) (possibly a graphical representation of this)
Improvement idea checklist:
(Some are copied from "Future Capabilities, features, ideas" but some are just code improvements)
- Instead of full body of messages, an expandable preview
- Include message headers (separate column?, in the message body?, etc)
- Origin/Destination columns (where was the message coming from, where does it intend to go)
- Extend this capability to other queues as well, so an admin can see if a queue is getting backed up
- metrics on the DLQ and others (how many messages have i gotten in the past hour/minute/second/month/etc) (possibly a graphical representation of this)
- keep checkboxes in the UI
- update colors/fonts to match the Admin UI
- include which Camel Context a message came from in the body
- include the "message type" in the message or headers (need to identify what this means)
- limit body size from backend to help performance
- Tell user when messages are successfully deleted
- improve the polling code (specifically how to store the intervalId)
- instead of sending a jolokia request for each message, send one with a list of messages
- Only render a subset of messages for performance
Decision
Projects needing this kind of functionality adopted Hawt.io instead for these features.