If you want to initiate batch jobs from within the USoft product set, you can use a recursive BenchMark procedure calling the job at regular intervals.
This can be used for jobs that run at regular intervals, but also for jobs that depend on clock time. In the latter case, use date fields, the CURRENT_DATE() function, or join with the T_APP_TIME table.
Batch scheduling is made independent of the environment USoft is deployed in. It has maximum maintainability because batch scheduling is registered in the application database.
A disadvantage is that a BenchMark session must run continuously.
The following example discusses an application where jobs are scheduled to execute at a certain date and time registered in a date field.
To schedule batch jobs using a BenchMark procedure:
1. | In the user application, create a SCHEDULED_JOBS table. This table includes at least a JOB_NAME field and a date field FIRED_AT indicating when it should run. |
2. | Define a EXECUTE_JOB decision, with SQL Statement: |
SELECT job_name
FROM scheduled_jobs
WHERE fired_at < CURRENT_DATE()
Yes Action:
job(:1)
No Action:
action-do-nothing()
3. | Define a BenchMark test procedure P1 with at least the following steps: |
Step 1 Action = action-decision(EXECUTE_JOB)
Step 2 Procedure = P1
| This means the procedure calls the decision, then calls itself, so that the decision call is repeated endlessly until the BenchMark test playing the procedure is stopped manually. (You will set an interval between decision calls in step 5.) |
4. | Define a BenchMark test associated with the procedure. |
5. | Perform a first test run by clicking the Player icon in the BenchMark toolkit window and selecting the new test. Before running, click the Settings button, set the interval at the required number of milliseconds between each decision call and click Save Settings. |
6. | To run the job scheduler, define the batch job(s), make an entry for each of them in SCHEDULED_JOBS, then start the job scheduler by playing the BenchMark test. |
| You have flexibility in designing one-time or recurrent scheduled jobs, or any other type of construction, because the scheduling information is part of the application itself. By creating a child table for the SCHEDULED_JOBS table, you can manage any number of job parameters. |
|