Some Event topics might support blockable events. The behavior of a workflow subscription depends on whether the topic supports these event types and how you configure the workflow subscription.
Non-Blockable Event Topics
Non-blockable event topics only allow you to create non-blocking subscriptions. Non-blocking subscriptions are triggered asynchronously and you can't rely on the order that the subscriptions are triggered or that the vRealize Orchestrator workflows run. Non-blocking subscriptions only return a response if the topic is replyable.
Blockable Event Topics
Some event topics support blocking. If a workflow subscription is marked as blocking, then all messages that meet the configured conditions are not received by any other workflow subscriptions with matching conditions until the first workflow is finished. If you have multiple blocking workflow subscriptions for the same event topic, you prioritize the subscriptions.
Blocking subscriptions run in priority order. The highest priority value is 0 (zero). If you have more than one blocking subscription for the same event topic with the same priority level, the subscriptions run in alphabetical order based on the name. After all blocking subscriptions are processed, the message is sent to all the non-blocking subscriptions at the same time. Because the blocking workflow subscriptions run synchronously, the changed event payload includes the updated event when the subsequent workflow subscriptions are notified.
You apply blocking to one or more workflow subscriptions depending on the selected workflow and your goals.
For example, you have two provisioning workflow subscriptions where the second workflow depends on the results of the first. The first one changes a property during provisioning, and the second records the new property, perhaps a machine name, in a file system. The ChangeProperty subscription is prioritized as 0 and the RecordProperty is prioritized as 1 because it uses the results of the ChangeProperty subscription. When a machine is provisioned, the ChangeProperty subscription begins running. Because the RecordProperty subscription conditions are based on a post-provisioning condition, a message triggers the RecordProperty subscription. However, because the ChangeProperty workflow is a blocking workflow, the message is not received until it is finished. When the name is changed and the first workflow is finished, the second workflow runs, recording the name in the file system.
Even if an event topic supports blocking, you can create a non-blocking workflow subscription if the workflow subscription does not have any dependant subsequent workflows. The workflow subscription is triggered and runs the vRealize Orchestrator workflow without further interaction from Cloud Assembly or the outside system.