Implementing a BPM system with composable activities

I am intending to implement a system that the user can create a combination of different tasks in different orders with many human involved tasks. For example, the user can create a workflow, starting with anyone adding a new record in some table, then the record will be send to his manager for approval, upon the approval of his/her manager, it will be sent to another person for more information and so on so forth. I’ve carefully studied the system and figured out a way to implement the system with temporal, but I am not sure if that is the recommended way of implementing this, and here is what I thought.

  1. Modeling each human involved task as an activity with very long timeout time (maybe for days)
  2. Setting up a message queue listener (redis for example) within each human involved activity, continuously listen to the event that completes the activity.

So my questions are:

  1. Is it possible to set the time out time to that long time?
  2. Is it recommended to use mq listener or there is a more elegant approach to this problem? It looks a bit heavy to maintain a listener for each human involved activity instance.
  3. Do I have to register the activities that will be dynamically used in different workflow every time?

Thanks a lot : )

Welcome to Temporal!

The recommended way for modeling human tasks is to have an activity that updates an external system that communicates the task to the user. This activity is expected to have a short timeout and an appropriate retry policy to deal with the other system outages.

Use SignalWorkflowExecution feature to notify workflow about human activity completion. Use a timer to take action if human activity is not complete for the specified time interval. No need to use an external queue for this use case.

So for your questions:

  1. You can have any timeout for an activity. But in your case, you don’t want to use long-running activities, but short activity and a signal.
  2. Using any additional queues is not recommended as they don’t bring any value besides additional complexity.
  3. Activities are registered with a worker that hosts them. They don’t need to be registered with a workflow.
1 Like

Thanks Maxim for your quick response that is really helpful!

I am still quite confused with SignalWorkflowExecution, are you suggesting letting the activity to do just the notification work but how can I let the workflow waiting after the activity returns? I’ve also seen an example here , looks like it registered a callback function to the external service and let the external service call Client.CompleteActivity(), is that also related to SignalWorkflowExecution you were mentioning as I didn’t see much documentation on it. I’ve seen it was mentioned here but not quite sure if there is also an example associated with that.

In the Go SDK signals are received through a channel. Use workflow.GetSignalChannel API to get reference to one. Here how you would wait for a signal up to a specified timeout using Selector:

		selector := workflow.NewSelector(ctx)
		selector.AddFuture(workflow.NewTimer(ctx, timeout), func(f workflow.Future) {
			logger.Info("timeout exceeded")
		selector.AddReceive(workflow.GetSignalChannel(ctx, "humanTask"), func(c workflow.ReceiveChannel, more bool) {
			c.Receive(ctx, &ack)
			logger.Info("human task completion signal received")
1 Like

Thanks Maxim I am trying it now! So I am supposed to set timeout to a relative large time (maybe a few days) is that right? What if the client is down while waiting for signals and I want to retrieve the exact state that I was waiting on? For example in the workflow, I have done activity1, activity2 and then a long waiting period …, when the workflow restarts is there a mechanism that allows it jumping directly to the waiting phase without having to rerun the previous two activities?

Workflow recovery is supported out of the box. So you don’t need to do anything to handle underlying process and infrastructure failures.

1 Like

ok thanks! I’ve only found SignalWorkflow under client, is that the same thing as SignalWorkflowExecution that you were referring to?

Yes, it is SignalWorkflow in Go SDK.

1 Like