Coordination of multiple workflows

Community Support
1

I have a daily schedule and a hourly schedule. Because workflows created by the daily schedule and workflows created by the hourly schedule will compete for the same external resources, they shouldn’t be run concurrently.

I have two ideas of implementing this:

  1. The first activity of the hourly workflow is to pause the daily schedule, the second activity is to wait for ongoing daily workflow to complete (if any), and the last activity is to resume the daily schedule. Add similar activities to the daily workflow too.

  2. The first activity of the hourly workflow is to check whether there is an ongoing daily workflow, and if there is one, skip remaining activities. Add a similar activity to the daily workflow too.

Which way is more idiomatic? Or is there a more idiomatic way?

2

Another option is to run only the hourly schedule and let workflow decide if it has to run the daily or hourly functionality.

3

I thought about that too. We actually have hourly, daily and weekly schedules. It seems to be cleaner to keep them separated, because, besides running on schedules, we have a service that triggers each of these schedules on demand based on external inputs.

4

When you trigger them directly, you can pass a parameter to choose which one to execute. Or you can have a top-level workflow that starts child workflows. When doing on-demand runs, execute these workflows directly.

5

How do I pass params when triggering a schedule? The ScheduleTriggerOptions struct only has a Overlap field.

6

ScheduleWorkflowAction contains input arguments.

7

I see what you mean now. Thank you!

8

When doing on-demand runs, execute these workflows directly.

If I execute a workflow directly (skipping the schedule), will SKIP/BUFFER_ONE overlap policy take running workflows into consideration even though the running workflows were not created by the schedule itself?

9

No, as the schedule doesn’t check for other workflows with the same type.

10

hmm… that means, if I execute a workflow directly, I will still need to add an activity to pause the corresponding schedule at the beginning, and an activity to resume the schedule at the end, similar to my original idea #1

11

I see. Then you don’t want an activity. Use signals as in the mutex sample.

12

In the mutex sample, the SampleWorkflowWithMutex releases the lock as the last step. If the workflow is terminated before it reaches that step, the lock won’t get released (until unlock timeout exceeds), right? It would be difficult to set a reasonable unlock timeout when the range of workflow execution duration is large.

13

Don’t terminate workflows as termination by definition doesn’t support cleanup.

As a workaround you can add some activity to the mutex workflow to check the status of the workflow by periodic polling if you want to support termination.