Commit c8a8065a authored by Oana Schiopu's avatar Oana Schiopu
Browse files

refactor-signals-worklows-description

parent bee99b1e
......@@ -2621,15 +2621,19 @@ The *Signal API* is a high-level API that enables users to interact with running
That is, it allows a job to expose specific signals (e.g., `soft_stop` to properly finish a job) that can be triggered by users from the *Workflow Execution portal* or *Scheduler portal*.
You can try the <<_examples_2,examples>> below to better understand how it works.
In summary and for simple use, just go to <<_proactive_studio, ProActive Studio>> and use the predefined templates in the _Controls_ bucket, _4. Signal Templates_ project: for example: *Check_For_Signals*, *Wait_For_Signals* or *Wait_For_Signal_With_Variables*.
In summary and for simple use, just go to <<_proactive_studio, ProActive Studio>> and use the predefined templates in the _Controls_ bucket, _4. Signal Templates_ project: for example: *Check_For_Signals*, *Wait_For_Signals*, *Wait_For_Signals_Reactive* or *Wait_For_Signal_With_Variables*.
Fill up the Task Variable *SIGNALS*, and use those templates in your own workflow to be able to receive input from, for instance, the Workflow Execution portal or Scheduler portal.
*Check_For_Signals* is a template workflow that sends a ready notification for all the signals specified in the variable SIGNALS, then loops until one signal among those specified is received by the job.
This workflow is composed by two tasks. The first sends a ready notification for all of the signals. The second task checks if the signals are received and triggers the first task in a loop untill all of the signals are received.
*Wait_For_Signals* also sends a ready notification for all the signals specified in the variable SIGNALS, loops until one signal among those specified is received by the job and then removes the signal.
Unlike _Check_For_Signals_, _Wait_For_Signals_ workflow contains a single task that sends a ready notification for all of the signals and then checks if the signals are received. This task is executed in loop untill all of the signals are received.
*Wait_For_Signal_With_Variables* is a template workflow that waits until one signal (with input parameters) that is specified in the variable SIGNAL is added to the set of job signals.
The signal's input parameters have predefined values that can be changed when sending the signal.
The workflow contains a single task that sends a ready nofication for all the signals with input parameters and waits untill all signals with parameters are received.
*Check_For_Signals* is a template workflow composed by two tasks. The first sends a ready notification for all of the signals specified in the variable SIGNALS. The second task checks if one signal is received, and if not, the workflow iterates in a loop where each iteration lasts one minute.
This workflow allows users to do an iterative processing, and decide at each iteration to continue this processing or not, i.e., (i) declare being ready to receive one or more signals, (ii) do some processing, then (iii) receive signals and decide whether to continue the processing or not.
*Wait_For_Signals* is a template workflow that contains a single task, which sends a ready notification for the signals specified in the variable SIGNALS, then checks if one or more signals are received by the job. If not, the workflow iterates in a loop where each iteration lasts one minute.
This workflow allows users to iteratively wait for the reception of one or more signals, then trigger some processing.
*Wait_For_Signals_Reactive* is a template workflow that sends a ready notification for all the signals specified in the variable SIGNALS, then waits until one signal among those specified is received.
This workflow contains no loop. It performs a blocking wait, then immediately triggers some processing at the reception of a signal.
*Wait_For_Signal_With_Variables* is a template workflow that deals signals having input parameters. It contains a single task that sends a ready notification for all the signals (with input parameters) specified in the variable SIGNALS, then waits until one signal (among those specified) is received. The signal's input parameters have predefined values that can be changed when sending the signal.
At a more detailed level and advanced use, the Signal API allows jobs and users to exchange signals using a communication channel provided by the <<_task_synchronization_api,synchronization API>>.
The typical usage scenario of the Signal API is the following:
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment