Overview
This node implements a custom messaging pattern using a message broker with topic exchanges. It allows users to publish messages with a routing key composed of a prefix and a user-defined pattern, send a JSON payload, and optionally wait for a reply. This is useful in scenarios where you want to implement command or event-driven architectures, such as sending commands to microservices or triggering workflows based on specific routing keys.
Practical examples:
- Sending a command message to a service listening on a specific routing key pattern.
- Publishing events with dynamic routing keys for selective consumption.
- Waiting for a response from a service after sending a command.
Properties
| Name | Meaning |
|---|---|
| Routing Key Prefix | The prefix added before the defined pattern, separated by a dot, forming the first part of the routing key. Default: "command". |
| Pattern | The suffix pattern appended to the routing key prefix to form the full routing key. Required. |
| Payload | The JSON payload to send with the message. Required. |
| Wait for Reply | Boolean flag indicating whether to wait for a reply message after publishing. Default: true. |
| Exchange | The name of the exchange to which the message will be published. Default: "cqrs". |
| Exchange Type | The type of the exchange; hidden property set to "topic". |
| Spread Response | If the response is an array, this option spreads each item into individual output items. Default: false. |
| Options | Additional options for the queue and message publishing: |
| - Alternate Exchange | An alternate exchange to route unroutable messages. |
| - Arguments | Custom arguments for the message publishing (key-value pairs). |
| - Auto Delete Queue | Whether the queue should be deleted when no consumers remain. Default: false. |
| - Durable | Whether the queue survives broker restarts. Default: true. |
| - Headers | Custom headers to add to the message (key-value pairs). |
Output
The node outputs JSON data representing the response received from the message broker or the service that processes the published message. If the "Wait for Reply" option is enabled, the output contains the reply message's content. If the response is an array and "Spread Response" is enabled, each element of the array is output as a separate item.
If binary data is involved (not explicitly shown in the provided code), it would typically represent raw message payloads or attachments.
Dependencies
- Requires connection to a message broker supporting AMQP protocol with topic exchanges (e.g., RabbitMQ).
- Needs configuration of an API key or authentication token to connect securely to the message broker.
- The node depends on an underlying library or framework for AMQP communication (implied by references to AMQP channel publishing options).
Troubleshooting
Common issues:
- Incorrect routing key patterns may result in messages not being routed to any queue.
- Misconfigured exchange or queue options can cause message loss or failure to receive replies.
- Network connectivity problems with the message broker can cause timeouts or errors.
Error messages:
- Errors related to publishing messages usually indicate invalid exchange names or permissions.
- Timeout errors when waiting for replies suggest the target service did not respond or the reply queue was not properly configured.
Resolutions:
- Verify routing key prefixes and patterns match the expected bindings.
- Ensure the exchange exists and the user has permission to publish.
- Check network connectivity and broker availability.
- Adjust queue options like durable and auto-delete according to use case needs.