Usage > Batch server > Task management 

This function is used to create new batch tasks or to modify the characteristics of existing tasks.

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

Entry screen

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 :

  • either an ADONIX programme (process)
  • or a report (print)
  • or system tasks defined by a command file (shellscript 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 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 (field ZDES)

Title associated to the previous code.

Block number 2

  • Active (field ENAFLG)

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 (field MODULE)

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

  • 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 :

  • stop the request server.
  • priority to low if more tasks are pending that simultaneous executions authorized by the license.
  • blocking if it belongs to a group.
  • ...

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.

  • Priority (field PRIO)

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).

  • Service (field SERVICE)

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.

  • 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 helpfor 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

Close

 

Specific Buttons

Error messages

The only error messages are the generic ones.

Tables used

SEEREFERTTO Refer to documentation Implementation

Technical appendix

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.