This transaction manages “services” for transactions.

The list of tasks is drawn up by reading all workflow entries (from table WFE) which are waiting for any of the services that are marked to be executed by this instance of the Task Manager (see also general description of Workflow). The corresponding transaction for an entry in the task list, being ready for execution, is then “opened”. All services for this transaction are then executed, if they are marked to be executed by this instance of the “Task Manager” 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).

Several instances of the Task Manager can be started using the “-I <name of inifile>” switch in the command line of the runtime system. The instances can be started with different settings (e.g. which services are set as enabled). It is useful to have a separate instance of the Task Manager handling outgoing SWIFT messages, if this is necessary for technical reasons.

Those services that can take additional parameters such as printer and directory names have a separate panel where these additional values can be entered (for details see below).

Important: Managers running in foreground mode always need to be started manually. 

Services starting with “SRVPD” (e.g. SRVPDS, SRVPDP and SRVPDA) and SRVCOM are called “polling” services.

Any number of retries are possible for these services until the required condition “done” ('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” ten times consecutively, an “event” for this service is generated and the service is automatically stopped. This is because the system assumes that there is a technical problem (e.g. in case the Swift connection is interrupted) with this service. It is trying to avoid too many workflow entries going to error status, as 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 WFE-entry open or waiting (with the exception of SRVCLN) is set to 'S'kip, so that 'SRVCLN' then becomes the next waiting service.

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 is done to keep the size of the WFE and EVT tables small.

When a service is stopped automatically (i.e., if a service is canceled after 10 consecutive errors), a Notify message is sent to the administrator user (ADMUSR), if 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)

The same commands can be send via DNGAPI.

The restart period is always measured relative to the last start time of the manager. If the load is high, this results in an overall low waiting time during which the manager is inactive.

Thus, low load creates greater waiting time of the manager (in order to be able to use more resources for interactive processes in favor of better performance).

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 “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 will be moved to 
 * "arc" (for archiving the successfully processed messages) 
 * and copied to "error" (for messages that have not been processed successfully).

If messages 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 below 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).

The document printing service SRVPRT manages all print outputs for outgoing documents. Typically, there are several instances of SRVPRT, which allow the user to print different copies (original, file copy, customer copy) at different points in time within the workflow.

The “Print” panel contains the print settings for the “Task Manager” and applies to all Services which need printing. Details on application and technical forms can be found in the documentation on the Printing.

If the option “Create Postscript Files” is enabled, a PostScript file is created, which is sent (together with the selected printer name) to the script “tdprtcmd” (resp. TDPRTCMD.BAT) to be forwarded to the printer queue or to be passed to the respective output device. Sorted by printers, all requests are merged in one PostScript file, so that all printouts belonging to one transaction are printed one after another. The PostScript file is sent via the script “bin/unix/tdprtcmd” to the Unix print queue (resp. to the script TDPRTCMD.BAT for further processing under Windows).

If the option “Windows Server Print” is selected, on Client Server installations with a server running under windows the user can print on windows printers which are “known” by the server.

If 'Separate file' is checked, all documents are printed separately, not concatinated into one file for each print queue / printer.

With structured messages such as SWIFT, DTA or allNETT, selecting “Both” in the “Format” selection list for the “Technical Forms” grid means that both the raw format and the PrettyPrint are printed out. For unstructured messages such as letters or mails, this selection only leads to the formatted form being printed.

When resending the message via the transaction Resending Messages - Possible Duplicates a phrase is added to the header text that indicates the messages e.g. as a “copy” or “duplicate”. This term can be freely entered at the bottom of the “Print” panel in the field “Duplicate”.

Some outgoing messages can be send over MQ Series. Therefore it is necessary to configure this interface.

The following fields have to be defined:

If just one of the optional parameters is not filled in, all optional parameters are taken from the MQSERVER environment variables.

MQ Series Error Codes will be passed 1:1.

More information about these error codes can be found in the MQ Series documentation.

If messages have to be send over MQ Series, the following definition is necessary:

The checkbox “Send over MQ” has to be checked and the following fields have to be defined: “Manager” “Queue” “CCSID”

The MQ Connection can be defined in 2 ways: either with the environment variable MQSERVER or by checking the checkbox “Set MQ Connection” and specifying the three fields “Channel” “Type” “Connection”

If SSL encryption has to be used, the checkbox “Use SSL” has to be checked, the “key repository” and the “cipher” has to be specified.

Some outgoing messages can be sent over Kafka. Therefore it is necessary to configure this interface.

The following fields have to be defined:

Some outgoing messages can be send over FTP. Therefore it is necessary to configure this interface.

The following fields have to be defined:

If an outgoing Score message has the tag 23 X filled in (i.e., the message has attachments) then all the attached files in the service are packed into a .zip file with the name indicated in tag 23X, and this file is then placed in the directory configured in “Additional configuration for FileAct (SCORE attachments)” ready for transport.

If the format is configured as 'SWIFT Alliance Lite', then this file will automatically be mailed out via FileAct; otherwise initiation of the transport must be suitably implemented in the customer-specific rule for message dispatch (“SendMessageCust”).

Message for Target2 (T2 RTGS) and SWIFT XML can be send using XMLv2 Envelope.

When XMLv2 Envelope is selected, additional configuration is needed.

For a detailed description of the configuration of the Bolero terminal, see Configuration of outgoing messages.

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.

Technical messages (e.g., SWIFT) that belong to a contract will be forwarded to the recipient as an attachment to the TradeConnect message. By ticking the checkbox “Send technical messages formatted”, such a technical message will be formatted and attached as a PDF.

The “Text for the header” will be used as the header text for all file attachments that were generated as PDF documents (e.g., forwarded letters or SWIFT messages). This ensures that the documents will not be mistaken for the originals when they are displayed or printed.

This service is used to maintain / delete data using the SRVCLN service. For production systems, it is recommended that the following options are activated:

• Maintaining files + tables - information from tables WFE, TRS and EVT that is required for the history will automatically be saved in TRN\EVTTXT. If this data is not quickly deleted in the production systems, it will lead to slower response times (due to the WFE table filling up in particular).
• Delete events (EVT) - information from the EVT table that is required for the history will automatically be saved in TRN\EVTTXT. After a deletion, it is only the evaluation of such information via direct access to the database that is made more difficult.
• Delete Before-Image files (BIM) - this data takes up a lot of space and, once a transaction has been completed, would only be required for error analysis, if at all.
• Delete Transaction Data files (DAT) - this data takes up a lot of space and, once a transaction has been completed, would only be required for error analysis, if at all.

However, deleting display files should be done with care:

• Delete Display Files (DSP) - display files should NOT be deleted because the contents of the screen forms that are displayed under 'Details' of transactions are stored here (depending on the space available, display files will either be deleted after a certain period as elapsed (> 12 months) or when old contracts are archived).

The checkboxes “Maint. files and tables”, and “Delete Before-Image files (.BIM)” and “Delete Transaction-Data files (.DAT)” are checked by default.

This service checks the correctness of SWIFT and allNETT messages.
If a SWIFT message is not correct e. g. too long, this transaction will be sent to correction.
AllNETT XML messages will be checked against its corresponding xsd definition. If the check fails or the xsd file cannot be found, the workflow entry of this transaction will be set to error. This validation can be switched on or off with the checkbox 'allNETT XML Validation'.

Mails can be send via SMTP, pickup folder, Unix sendmail or MS Azure Cloud.
The relevant method has to be selected on the mail service config panel.

For MS Azure Cloud please make sure, that MS Graph API is configured for mail read, send and read/write in batch mode.

Task Manager
Services
Print
Release
Signatures
Check limit status
Predecessors
Commit
SWIFT Send
TradeConnect Send
Check for pending ACK's
Cleanup
TARGET
Target 2
SWIFT XML
DTA Import L/C
DTA Export L/C
DTA Guarantees
Finalize Order
Delete Temporary Settlement
Bolero
Email Send
Fax
Execution Date
DTAUS / IZV
Compliance check
External
Document Generation Send
Export Bookings
allNETT
Send Status Updates
RIVO
Check Documents
SEPA
SIC / EuroSIC
EuroSIC
Text
TELEX Out
Assets Sold
Funding Response

(For the purpose of single services cf. description of Workflow