Business process and signals

Training
1

I’m still working my way through the training. But, one thing that I’m still trying to wrap my head around is using temporal for business process that could have an indeterminate amount of time in between people performing actions. Assume for a moment that I have a workflow that requires a couple of levels of approval, with each of those approvals causing an activity to be completed, like in the following pseudocode

workflow(itemId) {

activity.submitItem(itemId)

Workflow.await(() → approval1)

activity.approval1()

Workflow. await(() → approval2)

activity. approval2()

}

The action that invokes this workflow blocks until the whole workflow is done. But, I don’t really want submitting the process to block. I want it to return before finishing the workflow and to leave the workflow open until I send a signal to restart because the approval has happened.

If someone has a good suggestion for an example to follow, I would really appreciate it.

2

If I understand your question correctly, you’re asking how you can submit a Workflow Execution request without blocking as you wait for the result.

If so, here’s an example (in Go, but it’s similar for the other SDKs):

https://github.com/temporalio/money-transfer-project-template-go/blob/main/start/main.go

The Workflow Execution request is submitted on line 37 and returns a value (the wevariable) that you can later use to retrieve the result. Lines 38-45 will run immediately after line 37; they don’t block. Where the blocking occurs is on line 46, with the we.Get call, which retrieves the result (and therefore will block until the Workflow Execution is complete so the result will be available).

The process that submitted the Workflow Execution request can exit whenever it wants and some entirely different process can later retrieve the result of that execution, given its Workflow ID and Run ID.

3

Thanks, Tom. I think that will get me there. There is a slight difference. I’m looking for the line 46 we.Get to not need to exist at all. It should start the workflow and just proceed. If I’m reading this equivalent java example correctly, the following line starts the workflow and exits immediately. the workflow is then free to take as much time as it needs to finish:

4

If I’m reading this equivalent java example correctly, the following line starts the workflow and exits immediately. the workflow is then free to take as much time as it needs to finish:

Correct, will unblock when execution is created (started), not waiting for its result.

Just note you also want to try/catch around WorkflowClient.start and handle
io.temporal.client.WorkflowExecutionAlreadyStarted
and
io.grpc.StatusRuntimeException