How to represent Activity Diagram with multiple scheduled background jobs?

I would like to know what is the correct way to visualize background jobs which are running on a schedule controlled by scheduling service?

In my opinion the correct way should be to have an action representing the scheduling itself, followed by fork node which splits the flow for each of the respective scheduled jobs.

Example. On a schedule Service X is supposed to collect data from an API every day, on another schedule Service Y is supposed to aggregate the collected data.

I've tried to research old themes and find any diagram representing similar activity.

Your current diagram says that:

• first the scheduler does something (e.g. identifying the jobs to launch)
• then passes control in parallel to all the jobs it wants to launch
• no other jobs are scheduled after the scheduler finished its task
• the first job that finshes interrupts all the others.

The way it should work would be:

• first the scheduler is setup
• then the setup launches the real scheduler, which will run in parallel to the scheduled jobs
• scheduled jobs can finish (end flow, i.e. a circle with a X inside) without terminating everything
• the activity would stop (flow final) only when the scheduler is finished.

Note that the UML specifications do not specify how parallelism is implemented. And neither does your scheduler: whether it is true parallelism using multithreaded CPUs or multiple CPUs, or whether it is time slicing where some interruptions are used to switch between tasks that are executed in reality in small sequential pieces is not relevant for this modeling.

The remaining challenges are:

• the scheduler could launch additional jobs. One way of doing it could be to fork back to itself and to a new job.
• the scheduler could launch a variable number of jobs in parallel. A better way to represent it is with a «parallel» expansion region, with the input corresponding to task object, and actions that consume the taks by executing them.
• if the scheduler runs in parallel to the expansion region, you could also imagine that the schedule provides at any moment some additional input (new tasks to be processed).