Details
-
Feature
-
Status: Deferred (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
-
All
Description
User Requirements
- I would like to provide to customers an alternative to JobSynchronize and Events Management with something similar but easier to understand and to use. The principle is to use scheduler_history instead of scheduler_event table and evaluate the records with a SQL query in a pre-processing function.
- The use could be the following:
- add a parameter CONSTRAINTS, containing a formula with all information for an SQL query.
- add a Java class as a pre-processing function, the class transforms the rules in SQL and executes the request until it gets a result.
- The formula can have the following format:
STATUS(SPOOLER/PATH/JOB) or EXIT(SPOOLER/PATH/JOB)=exit_code With STATUS = DONE, ERROR, SUCCESS, RUNNING
- The JOB could be /PATH/JOB if it is on the same SPOOLER or SPOOLER/PATH/JOB if it is another one.
- The rule can use conditions: | & and parenthesis
- For different frequency, we can precise the time window: SUCCESS(JOB#10:00:00) if the success happened in the last 10 hours.
- Examples:
CONSTRAINTS : SUCCESS(SCHEDULER/test/job1) | FAILURE(/job2) wait for the successful execution of /test/job1 on the spooler SCHEDULER or the failure of job2 on the same scheduler CONSTRAINTS : EXIT(SCHEDULER/test/job1)=2,4-8,12 & DONE(/job3) wait for the job1 ending with one of the following exit codes : 2,4,5,6,7,8,13 and /job3 not running. CONTRAINTS: FAILURE(/job3#01:00:00) wait for a failure happened in the last hour.
- This kind of syntax will greatly simplify the migrations because we could solve problems with multiple dependencies, dependencies between nodes and "and/or" conditions.
- Examples: