Overview
This node implements a custom messaging pattern using a message broker with topic exchanges. It allows users to publish messages to a specified exchange with a routing key composed of a prefix and a user-defined pattern. The node can optionally wait for a reply message, making it suitable for request-response communication patterns.
Common scenarios include:
- Sending commands or queries in a CQRS (Command Query Responsibility Segregation) architecture.
- Integrating microservices via asynchronous messaging.
- Implementing event-driven workflows where messages are routed based on dynamic patterns.
For example, you might send a query message with a routing key like query.user.get to request user data, then wait for the response before continuing the workflow.
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 is "query". |
| Pattern | The suffix pattern appended after the prefix to form the full routing key. This defines the specific routing path. Required. |
| Exchange | The name of the exchange to which the message will be published. Default is "cqrs". |
| Exchange Type | The type of the exchange; hidden and fixed to "topic". |
| Payload | The JSON payload to send as the message body. Required. |
| Wait for Reply | Boolean flag indicating whether the node should wait for a reply message after publishing. Default is true. |
| Spread Response | If the response is an array, this option spreads each item into individual output items. Default is false. |
| Options | Additional options for the queue and message publishing: |
| - Alternate Exchange | An alternate exchange to route messages if the main exchange cannot route them. |
| - Arguments | Custom arguments for the message publishing method (key-value pairs). |
| - Auto Delete Queue | Whether the queue should be deleted when no consumers remain. Default is false. |
| - Durable | Whether the queue survives broker restarts. Default is 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 if "Wait for Reply" is enabled. If the response is an array and "Spread Response" is enabled, each element of the array is emitted as a separate item.
If binary data is involved, it would typically represent message payloads, but this node primarily deals with JSON payloads.
Dependencies
- Requires connection to a message broker supporting AMQP protocol (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 for AMQP communication (likely amqplib or similar).
Troubleshooting
- Connection errors: Ensure the message broker is reachable and credentials are correct.
- Routing issues: Verify that the routing key prefix and pattern correctly match bindings on the exchange.
- No reply received: If waiting for a reply, confirm that the responding service publishes to the expected reply queue.
- Invalid payload: Make sure the JSON payload is well-formed and matches the expected schema of the receiving service.
- Queue options misconfiguration: Incorrect durable or auto-delete settings may cause unexpected queue behavior.