Message Brokers actions

Services

Azure Service Bus actions

• Azure Service Bus: Cancel Scheduled MessagesCancel messages that Schedule Message put on a queue's schedule, by their sequence numbers. Sequence numbers are the only identifier the broker accepts here: a message ID will not do.
• Azure Service Bus: Create QueueCreate a queue. Requires Session, Requires Duplicate Detection and Enable Partitioning are IMMUTABLE: they can only be set at creation, and changing your mind later means recreating the queue and losing its messages. Lock Duration cannot exceed 5 minutes whatever is asked for.
• Azure Service Bus: Create RuleCreate a filter rule on a subscription: a SQL filter, a correlation filter, or a true/false filter, with an optional SQL action that rewrites matched messages. Filter rules are what make a topic worth using instead of N queues. Remember to delete the subscription's $Default rule afterwards: it matches everything, so while it exists the new filter narrows nothing.
• Azure Service Bus: Create SubscriptionCreate a subscription on a topic. Every new subscription ships with a $Default rule that matches everything: add a filter with Create Rule and then DELETE $Default, or the filter will appear to do nothing. Requires Session is immutable here too.
• Azure Service Bus: Create TopicCreate a topic. A topic on its own is a black hole: messages sent to a topic with no subscriptions are discarded and the send still reports success. Create at least one subscription before sending.
• Azure Service Bus: Dead-Letter MessagesReceive messages and dead-letter all of them with a reason and description: the receive-inspect-reject shape, in one step. This is the only dead-letter action that is not a disposition on a receive, and it still receives first for the same reason: a lock token cannot cross nodes, so there is nothing a standalone reject node could hold on to. To dead-letter conditionally, use Receive from Queue with Then = Dead-Letter behind a filter.

MQTT actions

• MQTT: Clear Retained ValueDelete a topic's stored last known value, so new subscribers no longer receive a stale reading. Live messages on the topic are unaffected.
• MQTT: Get Retained ValueRead a topic's last known value: the message the broker has retained. Use it to ask 'what is the current temperature?' without waiting for the next reading. Check the Found output to branch on whether the topic has a stored value.
• MQTT: Publish and Await ReplyPublish a request to one topic and wait for the answer on a reply topic: ask a device a question and get its response in a single step. Check the Replied output to branch on whether an answer came back.
• MQTT: Publish MessagePublish a message to a topic on an MQTT broker. Choose the delivery guarantee (QoS) and optionally retain the message so the next subscriber receives it immediately.
• MQTT: Wait for MessagePause the flow and wait for the next message on a topic, up to a timeout. Use it to wait for a device to report back mid-flow. Check the Received output to branch on whether a message actually arrived.