7.1

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 nonblocking 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 a 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 conditions, 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 topics that support 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
vRealize Automation or the outside system.
Replyable Event Topics
Some event topics support replies from the subscribed service. The service that registered the replyable
event topic can accept a reply event that provides the workflow output, usually as a result of an
interaction with a system or user. The reply output parameters must meet the criteria defined in the reply
schema so that the vRealize Automation service that published the original replyable event can process
it. For example, pre-approval and post-approval workflow subscriptions are replyable. If you create a
workflow that sends an approval request to an external system, the reply, approved or rejected, is
processed by vRealize Automation and the catalog item is provisioned or the user is notified that the
request was rejected.
The reply can be the output from the vRealize Orchestrator workflow or it can be a failure if the workflow
times out or fails. If the reply is from the workflow output parameters, the reply must be in the correct reply
schema format.
Best Practices for Creating vRealize Orchestrator
Workflows for Workflow Subscriptions
A workflow subscription is based on a specific topic schema. To ensure that the subscriptions can start
the vRealize Orchestrator workflows, you must configure them with the correct input parameters so that
they work with the event data.
Life Cycle Extensibility
VMware, Inc. 21