From the moment they are created, business transactions run through a series of steps called the “Workflow”. This Workflow consists of a sequence single operations called services.
Transaction rules manage the services that make up the Workflow. The service SWT (dispatching SWIFT messages), for example, is only included in the Workflow if the transaction generates a SWIFT message. Equally, print services can be set to react to the constellation of the data in the transaction.
Banking business sets a number of restrictions on the order/sequence in which services in a transaction are carried out (e.g. that a SWIFT message cannot be sent before the transaction has been authorized - i.e. all required signatures have been rendered). Such restrictions are defined in “Maintaining Service Order”.
The order defines the preceding and the succeeding services to be processed by the Task Manager. Because some services depend on preceding services being successufully executed, changes in the order should be made very carefully together with assistance of the support team.
The Workflow system requires the existence of at least the services below.
This is verified when checking the order of service.
Services are run by the “Task Manager”. It is possible to have several instances of the Task Manager with each one capable of running different or the same services. Manual access to the Workflow is permitted using “Repairing Transactions / Editing Workflows”.
A list of the active services can be found in the “SRVTXT - List of active Services” codetable.
The following table describes the modules and services available.
Service Module | Service | Description | Remarks |
---|---|---|---|
SRVANT | ANT | Send allNETT | Sends prepared allNETT messages to the defined interface. |
SRVBOL | BOL | Send Bolero | Sends prepared Bolero messages to the defined interface. |
SRVCHD | CHD | Check Documents | Checks if a prettyprint of the electronic message can be created without error, particularly for long messages with sequences. Otherwise entry is sent to correction. This service should be added before the signature service PDS. |
SRVCCS | CCS | Compliance Check | SRVCCS creates a text message or an XML output file in accordance with ETP/CCSTYP in the transaction “Maintaining Entity Group Transaction Profiles” (DBIETP). Note: If another process is required, a new value can be entered in the codetable. This table must be considered in “SRVCCS.SendMessageCus”. In business transactions, the following services are scheduled (via Level 5 rule), if the CCSTYP is empty or NON: SRVCCS for Compliance Check SRVPDC for ACK Check (confirmation) |
SRVCLN | CLN | Cleanup transaction | Deletes transactions from Workflow once all service have been completed. |
SRVCOM | COM | Commit transaction | Defines the transaction as irreversible. |
SRVFAX | EML | Send Email | An email in RFC 822/RFC 2045 is generated from the address data (recipient and CC details) for the message and/or cover sheet and any possible attachments that is then sent to a defined interface (e.g. sendmail or a pick-up directory). |
FAX | Send fax | Sends prepared faxes to the defined interface. | |
SRVFIN | FIN | Finalize order | Sets the ORD to 'Finalized' |
SRVGLE | GLE | Export Bookings | Writes the bookings into a file in the defined interface. |
SRVIZV | IZV | Send IZV | Sends prepared IZV messages (German money transfers) to the defined interface. |
SRVREL | REL | Control & Release | Ensures that transactions are only released when all relevant services have been completed. |
SRVPDA | PDA | Check Pending ACK service | Checks whether all confirmations of receipt have actually been received. |
SRVPDC | PDC | Check status compliance check (ACK Check) | See SRVCCS. |
SRVPDD | PDD | Check execution date | Checks whether the execution date entered has been reached. |
SRVPDL | PDL | Check limit status | Checks the status of limits in transactions that are relevant for the limit system. |
SRVPDP | PDP | Check preceding services | Checks whether preceding services are irrevocable. |
SRVPDS | PDS | Check pending signatures | Checks whether Control & Release has been executed successfully and all required signatures rendered. |
SRVPRT | PRT | Prints all items which are intended to be printed with the first print service. | |
PRR | Print 2 | Prints all items which are intended to be printed with the second print service. | |
PRS | Print 3 | Prints all items which are intended to be printed with the third print service. | |
SRVPDX | PDX | Recalculation | Recalculation of amounts using actual exchange rate |
SRVRVO | RVO | Send RIVO message | Sends prepared RIVO messages to the defined interface. |
SRVSEP | SEP | Delete temporary settlement | Deletes the records of the temporary settlement out of the settlement pool (SEP). |
SRVSPA | SPA | SEPA | Sends prepared SEPA messages to the defined interface. |
SRVSWT | SWT | SWIFT send | Sends prepared SWIFT messages to the defined interface. |
TAR | Send Target | Sends prepared Target messages to the defined interface. | |
SCO | Send SWIFT Score | Sends prepared SWIFT Score messages to the defined interface. | |
SRVTCO | DTA | Send DTA | Sends prepared DTALCR messages to the defined interface. |
DTE | Send DTE | Sends prepared DTAEA messages to the defined interface. | |
DTG | Send DTG | Sends prepared DTA guarantee messages to the defined interface. | |
TCO | Send TradeConnect | Sends prepared TradeConnect messages to the defined interface. | |
TCX | Send TradeConnectDocX | Sends prepared TradeConnect messages to the defined interface for document handling. | |
SRVTLX | TLX | Send telex | Sends prepared telexes to the defined interface. |
SRVTXT | TXT | Send TXT | In a transaction an unformatted ASCII text can be created as document (CORTYP='TXT') (is available as form set 'ASCII Text' in transaction “Maintaining Form Sets”). The service 'TXT' saves this message in an OUT directory. |
SRVWAI | WAI | Workflow blocked (Waiting) | It is set via icon ![]() |
The services actually used in a running system are installation-dependent and can include additional, installation-specific services, e.g. services to check scheduling against an external system.
A workflow entry can be assigned to one of the following conditions:
Status | Description |
---|---|
'O'pen | This workflow entry is not yet ready to pass through the service, as services in the service order that need to be processed before this one have not yet been successfully completed ('Done'). |
'W'aiting | All (if any exists) preceding services for this workflow entry have been completed successfully (i.e. 'Done') and this entry is waiting to pass through the respective service. |
'R'etry | The system has tried to perform the service but has not yet succeeded. The problem found is typically a temporary one. Retry later. The number of retries in unlimited only for 'checking' services (i.e. those beginning with 'SRVPD') and SRVCOM. For all other services a workflow entry is set to 'E'rror if the service could not be executed successfully (assigned status level D, C or S). |
'D'one | This service has been performed successfully. |
'E'rror | This service finally failed. The schedule for this transaction cannot be completed successfully. Manual intervention is required. |
'C'ancel | Cancelation of this transaction detected by this service (set by SRVPDS or SRVPDP (on cancelation of preceding service)) |
'S'kip | Service is no longer necessary. |
Whenever the status of a workflow entry changes, the system determines the new status for all workflow entries for the same transaction (e.g. if an entry changes from 'W'aiting to 'D'one, the system switches the status 'Open' to 'W'aiting for those entries, for which now all predecessors defined by the service order are now 'D'one).
Technically, a service is set from 'O'pen to 'W'aiting, when all of its predecessors have status level 'D'one or 'C'ancel or 'S'kip.