Refer to documentation Implementation
Presentation
The batch task management is carried out in a single tab. A batch task is characterised 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 :
A batch task is defined either by the name of a function or by the name of a process. If the task is defined as a function, the transfer parameter conditions and authorization parameters (authorized sites, amongst others) are inherited. A task of this type can be included in a batch task group.
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 standardised with ADONIX AGL, as well as to describe the associated function.
A batch process can have a need for dynamically entered parameters 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 parameter entry screen and returns the corresponding values for the execution, either directly (if the task is launched directly) or in a differed fashion.
Close
Fields
The following fields are present on this tab :
Block number 1
| A "batch" task is a program that can be executed by the server periodically or at the request of a user. |
| Title associated to the previous code. |
Block number 2
| This check box is used to activate or deactivate the current record without losing its content. A deactivated record cannot be used (by calling its code) in other records (documents, setups, etc.) or during mass processings. The authorizations for a given function can prohibit the creation of an active record. In this case, the box is cleared by default and it can only be modified by an authorized user or via a signature circuit defined by Workflow. |
| Module belonging to the setup. This field is used to specify whether the screen has to be created in the folder database. It is specified when the module linked to the screen is active in the folder. |
Block number 3
| Indicate if it is an Adonix process or a script executed in the operating system (DOS script, shellscript). |
Block number 4
| 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. |
| 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. |
| 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. |
| This priority is a number between 0 and 49 that affects the system priority for the task. The coding is used by the operating system when it has a sense (In UNIX™, this corresponds to the nice value of a process : 49 is the lower priority). |
| This field makes it possible to force the utilization of an Adonix service. If it is not assigned, the default application service is used. |
| 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
| 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. |
| The name of the process or the system script is entered here, when the task is not defined by a function code. |
|   |
| 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 helpfor the function is indicated before the field to guide the user). |
Block number 6
| 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. |
| 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. |
| By responding "yes" to this question, the user that launches the task will be warned of its correct completion or not. |
Block number 7
Close
In order to conform with Web development standards, a batch task must respond to the following criteria :
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.