This transaction manages services for transactions. There are many services performed for a transaction , as configured in the workflow service order (DBISRO).
The second panel in MGRTSK has a list of every service and each can then be configured by double clicking the row to switch to the dedicated panel for configuration. The configuration panel will show an Activation check box , plus any service specific switches that need to be set up.
The list of tasks is drawn up by reading all workflow entries (from table WFE) waiting for any of the services that are marked to be executed by this instance of the Task Manager.
The corresponding transaction for an entry in the task list ready for execution is then opened. All services for this transaction are then executed, if they are marked to be executed and are waiting for execution, or will be waiting for execution following the successful completion of other services on the same transaction (thus optimizing the required reloads of transactions)
NB. Managers running in foreground mode always need to be started manually.
'Polling' versus 'Non-Polling' Services
Services starting with SRVPD (i.e. SRVPDS, SRVPDP, and SRVPDA) and SRVCOM are called polling services. Any number of retries are possible for these services until the required condition ;('D'one) has been reached. For all other services, a 'R'etry status for a transaction should be a rare, transient event. Thus, for any non-polling service the workflow entry is set to status 'E'rror, if a retry status is given for the third time.
If a service returns an error 10 consecutive times, an event for this service is generated and the service is automatically stopped. This is because the system assumes that there is technical problem with this service and it is therefore trying to avoid too many workflow entries going to error status. This would cause additional manual work after re-establishing the connection.
Statistics for executed services are updated internally after every execution of a service in table SYB whenever the list of of workflow entries is updated from table WFE.
If the SRVPDS or SRVPDA services recognize that the transaction has been rejected, or sent for correction, the current workflow entry is set to 'C'ancel and any entry open or waiting (with the exception of SRVCLN) is set to 'S'kip, so that 'SRVCLN' then becomes the next waiting service.
Events and Notify Messages
The successful execution of any service and the last retry of polling services are marked within the workflow entry.
For errors, cancel and retries on non polling services, a notify message is send to the user responsible and two event entries are created:
for the service
for the transaction
The event information from the workflow (Table WFE) and additional events for the transaction (Table EVT with objects of type TRN) are moved either from Table WFE or EVT into a text block within the transaction record (TRN\EVTTXT) by Service SRVCLN. This limits the size of these tables.
When a service is automatically stopped (i.e., if a service is canceled after 10 consecutive errors), a Notify message is sent to the administrator user (ADMUSR), in case this user has been defined.
If the task manager runs in the background in a Unix environment, it accepts the following commands via IPC (e.g. sent by the transaction SYSMGR running on the same system)
|S||<filename>||Write status to <filename>|
|TAPPL||<level>||Control trace information in process log|
|0||Switch off application trace|
|>= 1||Minimum trace (i.e. Start, Stop, Reception of IPC commands)|
|>= 3||Report every reread from table WFE|
|>= 5||Report result of every service call|
|>=6||Report start of every service call|
|T+||<level>||Set server execution debug level (cf. td2 server documentation)|
|T-||<level>||Reset server execution debug level (cf. td2 server documentation)|
The restart period is always measured relative to the time of the last start. Many entries create little waiting time. Fewer entries create longer waiting times and a parallel higher level of interactive performance.
Storage Location of Outgoing Message Files
Message files that are generated by the outgoing services are usually stored in subdirectories of the partition Data.
Thus, relative path names for defining the output directories are relative to the partition Data. If, for organizational reasons, it is required, absolute path names can also be defined. In doing so, the usage of the prefix n 'db:' (files in databases) is also possible.
In addition, it is possible to set the location of the message file with a customer specific rule GetOutDirRel.
Note: A file can include more than one message. In case an error occurs in this file when processing the content of the message, but other messages have already been processed correctly in this file, the file be moved to arc (for archiving the successfully processed messages) AND to error (for messages that have not been processed successfully).
If message are to be stored in a client-specific directory, the checkbox Separate Directory per Entity must be checked.
If this checkbox is checked, a new level with the name of the external key of the entity <ETYEXTKEY> (e.g. 'HAMBURG') is added beneath the output directories (xxxOUT).
Thus, the messages will immediately be directed into folders of the respective client-specific entity. The same applies for erroneous files/messages. This level will then also have arc and error subdirectories (archive and erroneous messages).