To schedule a job is to make sure that its execution is triggered not by an interactive user action (such as pressing a button), but by the system clock reaching a specified date and time.
The execution of scheduled USoft jobs is usually triggered in one of two ways:
- By an iterated decision.
- From the OS command line.
You can also schedule from a looping Benchmark procedure or by using the T_APP_TIME table. These strategies are becoming obsolete. They are covered at the end of this article.
Scheduling by an iterated decision
To trigger jobs automatically and without user interaction, you can start a Rules Service that calls an Iterated Decision. You set up such a Rules Service by setting the following 2 parameters during its configuration:
- Iterated Decision = (the name of the decision you want triggered)
- Decision Interval = (the frequency with which you want this to happen)
Each time the interval expires, the Iterated Decision is called. The effect is just the same as if you activated the decision from a script, by calling:
ActionDecision( decision )
A Rules Service that calls an Iterated Decision is dedicated to doing just that. It is a Windows service “background” process for your USoft application that listens to the system clock and that runs independently from, and in parallel with, "foreground” user processes that allow end users to interact directly with your USoft application.
The decision itself is defined as per normal in USoft Definer. You can only call a single decision as Iterated Decision (but you could have multiple distinct Rules Services calling different decisions). You cannot pass input parameters: the decision designated as Iterated Decision is not allowed to refer to input parameters.
How to set up Iterated Decision calls
To set up Iterated Decision calls:
- Define the decision in USoft Definer (see next section for tips).
- Install and configure a Rules Service.
- During configuration, set Iterated Decision to the name of the decision, and Decision Interval to the desired frequency (ie., to a different value than the default 'Never’). Instead of doing this during configuration, you can also configure and test the Rules Service as per normal, and then go back using the Previous button to make these 2 additional settings.
How to define an iterated decision
Decisions give you access to all stored data and they allow branching and looping, so you have complete freedom to decide what is to happen each time the interval expires.
A typical approach is that you model facts around job scheduling in your application. You could have a table SCHEDULED_JOB that contains the names of multiple jobs to be triggered, and the time and date when they must be triggered. You could have child tables for parameters and parameter values.
In a very simple scenario with just job names, the decision could look something like this:
WHERE last_fired < CURRENT_DATE()
update-resource( 'it_job:' || :1 )
set quitzeroRows False
set quitOnError True
invoke batchrunner.runjob with select
Scheduling from the OS command line
If you have the support of a Windows administrator, you could schedule jobs by placing a RUNBATCH.EXE command in a .bat file and trigger its execution at OS level using the system clock.
The RUNBATCH.EXE command could trigger a single top-level USoft job that is responsible for calling the execution of any scheduled subjobs with the correct parameters and values. This strategy is appropriate or convenient if you have nightly consolidation batches, especially if these are a combination of USoft and non-USoft routines.
C:\USoft\bin64\runbatch.exe -ddoracle -ddowner MY_DD_OWNER -oracle -database MY_DATABASE -u MY_USER -owner MY_OWNER -pw MY_PASSWORD -logfile c:\USoft\logs\MY_JOB.log -wlogfile -app MY_APP -exe "job(MY_JOB)"
Older strategies for scheduling jobs
These strategies are becoming obsolete.
Scheduling from a USoft Benchmark procedure
Write a decision that will call the jobs to be executed, much in the same way as you would write an iterated decision as explained earlier in this article.
Now write a USoft Benchmark MY_PROCEDURE procedure that contains the following 2 steps:
Action = ActionDecision( MY_DECISION )
Procedure = MY_PROCEDURE
The procedure calls the decision, then calls itself, so it executes in a loop.
Define a BenchMark test associated with the procedure.
Run the 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.
Scheduling with the Application Timer
By default, USoft constraints cannot be scheduled: they execute in response to data manipulation but not in response to the system clock. An old use is to set up an Application Timer. This consists of writing the current date and time constantly to a table called T_APP_TIME (a table with a single record), and then writing constraints that refer to this record.
A disadvantage of this technique is that the application timer must run continuously. Another disadvantage is that you cannot commit batch processing on a record-per-record basis.
The T_APP_TIME table is delivered by USoft as a default. If you use this default, an INVOKE constraint that triggers a scheduled job could look like this:
INVOKE batchrunner.runjob WITH
FROM scheduled_job s
, t_app_time t
WHERE s.last_fired < char_to_date(
, ' '
, 'DD-MM-YYYY HH24:MI:SS'
To set up the process of writing the current date-and-time to the T_APP_TIME table:
- In USoft Binder, from the menu, choose Item, New, check Application Timer, then click Add. An Application Timer item is added to the entry list:
- Right-mouse-click the Application Timer and choose settings. Press OK.
- Double-click the Application Timer item to start. The process appears in a foreground CMD box.
You can stop the process from Task Manager by selecting USCLOCK.EXE and then pressing End Task.