Task Management
This function is used to create new batch tasks or to modify the characteristics of existing tasks.
Prerequisites
Refer to documentation Implementation
Screen management
Entry screen
The batch task management is carried out in a single tab. A batch task is characterized by a code that makes it possible to call it and by a certain number of technical characteristics defining the process to be launched. A batch task can be :
- either an ADONIX program (processing)
- or a report (print)
- or system tasks defined by a command file (shell script under UNIX™, script under Windows™)
A batch task is defined either by the name of a function or by the name of a process. If a task is defined as a function, the transfer conditions of setups and authorizations (authorized sites among others). A task of this type can be included in a group of batch tasks.
The majority of batch functions are in this case, but a few rare functions, defined by the process name are not.
The creation of new batch tasks of the type Process assumes the creation of a process standardized with ADONIX AGL, as well as to describe the associated function.
A batch process can have a need for dynamically entered setups in a dialogue box at the time of each task submission (this screen can also then be called if the task is directly launched). The standardization of the development of batch tasks manages the call to a setup entry screen and returns the corresponding values for the execution, either directly (if the task is launched directly) or in a differed fashion.
Block number 1
| Task code (field CODTAC) |
|
A "batch" task is a program that can be executed by the server periodically or at the request of a user. |
| Description (field ZDES) |
Block number 2
| Active (field ENAFLG) |
|
Select this check box to activate the current record. Disabled records keep their content and setup but cannot be used by recalling their code:
The authorizations for a given function can prohibit the creation of an active record. In this case, the check box is disabled by default. It can only be modified by an authorized user or through a signature workflow. |
| Module (field MODULE) |
|
Select a module for the setup. Use this field to specify if the screen has to be created in the folder database. This is the case when the module linked to the screen is active on the folder. |
| Execution tag (field RTTAG) |
Block number 3
| Task type (field TYPTAC) |
|
Indicate if it is an Adonix process or a script executed in the operating system (DOS script, shellscript). |
Block number 4
| Time-out (minutes) (field TIMOUT) |
|
Makes it possible to specify a maximum time in minutes for the execution of the task. More than this time, the server will kill the task (if 0, there is no time-out). Warning this duration is the minimum duration. The actual delay beyond which the task will be stopped also depends on the general parameters for the server : in fact, the task stop test is made at a regular interval in time that can be defined by the parameterization. |
| Allowable delay (minutes) (field RETARD) |
|
Makes possible the specification of the admissible delay for the start of requests. A request which has not been executed on the planned start date + delay, will be marked 'out of time'. The request may not be started on time for several reasons :
A null retard indicates that the task has no lead time constraint on its running. |
| Authorization level (field NIVEAU) |
|
The level will be compared with the access level of each user who attempts to launch this task. It will be refused if the user level is insufficient. |
| Hourly constraints (field HOR) |
|
This code is used to associate an execution time constraint on the task to limit the possible execution times when they are directly submitted to the batch server. When is submitted by a group of tasks, only the time constraints attached to the group are applied. It is the same case for a recurring task : the execution times are not then controlled with respect to the task constraint code, but an exclusion calendar is defined directly in the recurring task). |
Block number 5
| Function (field FONCTION) |
|
When a batch task corresponds to the execution of a function, it is defined here. This is used to initialize the context and the verification of access rights. |
| Script (field TRAIT) |
|
The name of the process or the system script is entered here, when the task is not defined by a function code. |
| field AIDE |
| field PARAM |
|
When a batch task is defined by a function and this function acknowledges a parameter (code # in the function), the value of this parameter is entered here (the name defined in the field Entry help for the function is indicated before the field to guide the user). |
Block number 6
| Multi-folder (field MULTIDOS) |
|
If this box is checked, the task can be launched in a folder than the current folder. It is necessary to then specify the folder and the user code at the launch of the request. |
| Single-user (field MONO) |
|
If this parameter is set to yes, the task can only be executed as a single user : it will not be executed if the transfer to mono user is impossible. |
| Message - user (field MESSAGE) |
|
By responding "yes" to this question, the user that launches the task will be warned of its correct completion or not. |
Block number 7
Appendix technique
In order to conform with Web development standards, a batch task must respond to the following criteria:
- * The function that defines it must make reference to an action of the type "standard process" (GTRAITE), which contains no principal window.
- It may or may not contain an initial dialogue box.
- The action "OUVRE_BATCH" must contain the opening of the necessary tables for the control labels aforementioned dialogue box.
The previous batch task posting methodology described in version 120 remains valid, but it must contain the posting of the processes that will only function in client-server mode. It is therefore strongly advised that it is not used.