A workflow interface that executes a workflow requires initializing a
WorkflowClient instance, creating
a client side stub to the workflow, and then calling a method annotated with @WorkflowMethod.
There are two ways to start workflow execution: asynchronously and synchronously. Asynchronous start initiates a workflow execution and immediately returns to the caller. This is the most common way to start workflows in production code. Synchronous invocation starts a workflow and then waits for its completion. If the process that started the workflow crashes or stops waiting, the workflow continues executing. Because workflows are potentially long running, and crashes of clients happen, this is not very commonly found in production use.
If you need to wait for a workflow completion after an asynchronous start, the most straightforward way
is to call the blocking version again. If
WorkflowOptions.WorkflowIdReusePolicy is not
AllowDuplicate, then instead
DuplicateWorkflowException, it reconnects to an existing workflow and waits for its completion.
The following example shows how to do this from a different process than the one that started the workflow. All this process
needs is a