Diese Transaktion führt Services für Geschäftstransaktionen aus.

Die Liste der Aufgaben wird erstellt, indem alle Workflow-Einträge (aus der Tabelle WFE) gelesen werden, die auf einen der Dienste warten, die für die Ausführung durch diese Instanz des Aufgabenmanagers markiert sind (siehe auch allgemeine Beschreibung zum Workflow). Die entsprechende Transaktion für einen Eintrag in der Aufgabenliste, die zur Ausführung bereit ist, wird dann “geöffnet”. Alle Dienste für diese Transaktion werden dann ausgeführt, wenn sie von dieser Instanz des “Task Managers” als auszuführend markiert sind und auf die Ausführung “warten” oder nach dem erfolgreichen Abschluss anderer Dienste derselben Transaktion auf die Ausführung “warten” werden (wodurch die erforderlichen Nachladungen von Transaktionen optimiert werden).

Mit dem Schalter “-I <Name der INI-Datei>” in der Befehlszeile für den Aufruf von MGRTSK vom Betriebssystems aus, können verschiedene Instanzen des Task Managers gestartet werden mit unterschiedlichen Einstellungen z.B. welche Services für diese Instanz als aktiv gekennzeichnet sind (z.B. um eine separate Instanz des Task Managers für ausgehende SWIFT-Nachrichten zu haben, falls dies aus technischen Gründen notwendig ist).

Services, die zusätzliche Parameter wie Drucker und Verzeichnisnamen haben können, haben jeweils ein separates Konfigurations-Panel, um diese zusätzlichen Werte eingeben zu können (Details siehe unten).

Wichtig: Im Vordergrund laufende Manager-Prozesse sind grundsätzlich manuell zu starten.

Alle Services, deren Kürzel mit “SRVPD” beginnen (z.B. SRVPDS, SRVPDP und SRVPDA) sowie SRVCOM sind so genannte “pollende” Services.

Für diese Services ist eine unbeschränkte Anzahl von Wiederholungen vorgesehen, solange, bis der Service für einen Transaktionssatz das Ergebnis “erledigt” (“D”one) liefert. Für alle anderen Services sollte ein Wiederholungsstatus (“R”etry) für eine Transaktion ein seltenes, vorübergehendes Ereignis sein. Deshalb wird für nicht pollende Services der Eintrag im Workflow auf den Status “Fehler” (“E”rror) gesetzt, wenn der Wiederholungsstatus zum dritten Mal erreicht wird.

Wenn ein Service zehnmal hintereinander das Ergebnis “Fehler” zurückgibt, wird ein “Ereignis” (Event) für diesen Service erzeugt und der Service wird gestoppt, weil das System ein technisches Problem mit diesem Service vermutet. Hierdurch wird erreicht, dass bei einem fortdauernden technischen Fehler (z.B. bei unterbrochener Verbindung zum SWIFT-System) zu viele Workflow-Einträge auf einen Fehlerstatus gesetzt werden, was nach Wiederherstellung der Verbindung zusätzliche, manuelle Arbeit auslösen würde.

Statistiken für ausgeführte Services werden intern nach jedem Ausführen eines Services in der Tabelle SYB aktualisiert, sobald die Liste der Workflow-Einträge aus der Tabelle WFE aktualisiert wird.

Wenn die Services SRVPDS oder SRVPDA erkennen, dass die Transaktion zurückgewiesen oder zur Korrektur geschickt wurde, wird der gegenwärtige Workflow-Eintrag auf “Löschen” (“C”ancel) gesetzt und jeder WFE-Eintrag, der offen ist oder wartet (mit Ausnahme von SRVCLN), wird auf “Überspringen” (“S”kip) gesetzt, so dass SRVCLN der nächste wartende Service wird.

Die erfolgreiche Ausführung jedes Services und der letzte Wiederholungsversuch von sendenden Services werden nur innerhalb des Workflow-Eintrags durch dokumentiert.

Bei Fehlern, Löschen und Wiederholungen bei nicht pollenden Services wird eine Benachrichtigung an den verantwortlichen Benutzer gesendet und zwei Ereigniseinträge werden erzeugt:

• für den Service
• für die Transaktion

Die Ereignisinformation aus dem Workflow (Tabelle WFE) und zusätzliche Ereignisse für die Transaktion (Tabelle EVT mit Objekttyp TRN) werden durch den Service SRVCLN entweder von der Tabelle WFE oder EVT in einen Textblock innerhalb des Transaktionssatzes (TRN\EVTTXT) verschoben. Das wird gemacht, um die Größe der Tabellen WFE und EVT klein zu halten.

Beim automatischen Stoppen eines Services (d.h. wenn ein Service nach 10 aufeinander folgenden Fehlern beendet wird) wird eine Notify-Nachricht an den Administrator-Benutzer (ADMUSR) gesendet, sofern dieser definiert wurde.

Wenn der Task Manager im Hintergrund läuft, akzeptiert er die folgenden Kommandos über IPC (gesendet z.B. durch eine auf demselben System laufende Instanz von SYSMGR).

Die Restart-Periode wird immer relativ zur letzten Startzeit des Managers gemessen. Bei großer Last entsteht dadurch eine insgesamt geringe Wartezeit, während der der Manager inaktiv ist.

Wenig Last erzeugt damit größere Wartezeit des Managers (um zugunsten besserer Performance mehr Ressourcen für interaktive Prozesse verwenden zu können).

Nachrichtendateien, die von Ausgangs-Services erzeugt werden, werden üblicherweise in Unterverzeichnissen der Partition “Data” gespeichert.

Relative Pfadnamen für die Angabe der Ausgangsverzeichnisse sind daher relativ zur Partition “Data”. Wenn es aus organisatorischen Gründen notwendig ist, können allerdings auch absolute Pfadnamen angegeben werden. Dabei ist außerdem die Verwendung des Präfixes “db:” (Dateien in Datenbanken) möglich.

Ausserdem ist es möglich, über eine kundenspezifische Regel “GetOutDirRel” einen anderen Speicherort zu setzen.

Hinweis: Eine Datei kann mehr als eine Nachricht enthalten. 
Wenn bei der inhaltlichen Verarbeitung einer Nachricht in dieser Datei ein Fehler auftritt, aber ggf. schon andere Nachrichten in dieser Datei korrekt verarbeitet werden konnten, wird die Datei 
* sowohl nach "arc" (für die Archivierung der erfolgreich verarbeiteten Nachricht) 
* als auch nach "error" (für eine nicht erfolgreich verarbeitete Nachricht) verschoben bzw. kopiert.

Sollen Nachrichten in einem mandantenspezifischen Verzeichnis gespeichert werden, muss die Checkbox “Separates Verzeichnis je Entity” markiert werden.

Ist diese Checkbox markiert, wird unterhalb der Ausgangsverzeichnisse (xxxOUT) eine neue Ebene mit dem Namen des External Keys der Entity <ETYEXTKEY> (z.B. “HAMBURG”) hinzugefügt.

Dadurch werden die Nachrichten gleich in die Ordner der jeweiligen mandantenspezifischen Entity geleitet. Gleiches gilt analog für fehlerhafte Dateien/Nachrichten, denn diese Ebene enthält dann auch jeweils die “arc”- und “error”-Unterverzeichnisse (Archiv und fehlerhafte Nachrichten).

Der Dokumentendruck-Service SRVPRT hantiert alle Druckerausgaben für ausgehende Dokumente. Von SRVPRT gibt es typischerweise mehrere Instanzen, die es erlauben, verschiedene Exemplare (Original, Aktenkopie, Kundenkopie) zu verschiedenen Zeitpunkten im Workflow zu drucken.

Das Panel “Druck” enthält die Druckeinstellungen für den “Task Manager” und gilt für alle druckenden Services. Details zu Applikations- und technischen Formularen sind unter der Dokumentation zum Drucken zu finden.

Wenn die Option “Erstelle Dateien” aktiviert wird, wird eine PostScript-Datei erzeugt und mit dem ausgewählten Druckernamen an das Script “tdprtcmd” (bzw. TDPRTCMD.BAT) zur Weiterleitung an die entsprechende Drucker-Queue bzw. das entsprechende Ausgabegerät übergeben. Sortiert nach Druckern werden dabei alle Requests in einer PostScript-Datei zusammengefasst erzeugt, sodass am Drucker alle Ausdrucke zu einer Transaktion hintereinander gedruckt werden. Die PostScript-Datei wird über das Script “bin/unix/tdprtcmd” an die Unix-Drucker-Queue gesendet (bzw. unter Windows an das Script TDPRTCMD.BAT zur weiteren Hantierung übergeben).

Wird die Option “Windows Server-Druck” ausgewählt, kann bei Client-Server-Installation mit einem unter Windows laufenden Server, wahlweise auf den beim Server bekannten Windows-Druckern ausgedruckt werden.

Wenn 'Separate file' eingeschaltet ist, werden alle Dokumente einzeln gedruckt, nicht konkateniert in einer Datei für jede Druckerqueue / Drucker.

Die Auswahl von “Beides” in der Auswahlliste “Format” der Tabelle “Technisches Formular” führt bei strukturierten Nachrichten wie SWIFT, DTA oder allNETT zum Ausdruck des Raw-Formats sowie des PrettyPrints. Bei unstrukturierten Nachrichten wie Brief, Telex oder Fax führt diese Auswahl nur zum Ausdruck in formatierter Form.

Bei erneutem Versand einer Nachricht über die Transaktion Nachrichten neu versenden - Duplikatversand wird an den Text im Header einer Nachricht ein Begriff hinzugefügt, dass das Dokument als Kopie oder Duplikat kennzeichnet. Dieses Wort kann unten auf dem Panel “Drucken” im Feld “Duplikat” frei gewählt werden.

Einige der ausgehenden Nachrichten können über MQ Series versendet werden. Dazu ist es notwendig diese Schnittstelle zu konfigurieren.

Die folgenden Werte müssen definiert werden:

Wenn einer der optionalen Parameter nicht angegeben wird, werden alle optionalen Parameter aus der Umgebungsvariablen MQSERVER genommen.

MQ Series Fehler Codes werden 1:1 durchgereicht.

Weitere Information zu den Fehlercodes kann in der MQ Series Dokumentation gefunden werden.

Wenn Nachrichten über MQ Series versendet werden sollen, ist folgende Definition vorzunehmen:

Die Checkbox “Über MQ senden” muss markiert sein. Die folgenden Eingabefelder müssen definiert sein: “Manager” “Queue” “CCSID”

Die MQ Series Connection kann auf zwei Arten definiert werden. Entweder mit der Environment Variablen MQSERVER oder durch Markieren der Checkbox “MQ Verbindung setzen” und spezifizieren der folgenden 3 Felder “Kanal” “Typ” “Verbindung”

Wenn SSL Verschlüsselung genutzt werden soll, muss die Checkbox “SSL” markiert sein, sowie die “Schlüsselstelle” und die “Verschlüsselung” spezifiziert werden.

Einige der ausgehenden Nachrichten können über Kafka versendet werden. Dazu ist es notwendig diese Schnittstelle zu konfigurieren.

Die folgenden Werte müssen definiert werden:

Einige der ausgehenden Nachrichten können über FTP versendet werden. Dazu ist es notwendig diese Schnittstelle zu konfigurieren.

Die folgenden Werte müssen definiert werden:

Wird der XMLv2 Umschlag (Envelope) genutzt, können Target2 (T2 RTGS)- und SWIFT XML-Nachrichten gesendet werden.

Wurde XMLv2 Envelope ausgewählt, sind zusätzliche Konfigurationen erforderlich.

Wenn in einer ausgehenden Score Nachricht das Tag 23 X gefüllt ist (die Nachricht also Anhänge hat) werden alle angehängten Dateien im Service in eine .zip Datei mit dem in Tag 23X angegebenen Namen gepackt und diese Datei im unter “Zusätzliche Konfiguration für FileAct (SCORE Anhänge)” konfigurierten Verzeichnis zum Transport abgelegt.

Wenn “SWIFT Alliance Lite” als Format konfiguriert ist, wird diese Datei automatisch über FileAct versendet, anderenfalls muß das Anstoßen des Transports in der Kundenspezifischen Regel für den Nachrichtenversand (“SendMessageCust”) geeignet implementiert sein.

Nachrichtendateien, die von Ausgangsservices erzeugt werden, werden üblicherweise in Unterverzeichnissen der Partition “Data” gespeichert.

Relative Pfadnamen für die Angabe der Ausgangsverzeichnisse sind daher relativ zur Partition “Data”. Wenn es aus organisatorischen Gründen notwendig ist, können allerdings auch absolute Pfadnamen angegeben werden. Dabei ist außerdem die Verwendung des Präfixes “db:” (Dateien in Datenbanken) möglich.

Technische Nachrichten (z.B. SWIFT) die zum Kontrakt gehören, werden als Anhang zur TradeConnect Nachricht mit an den Empfänger weitergeleitet. Durch Markieren der Checkbox “Technische Nachrichten formatiert senden” wird eine solche technische Nachricht formatiert und als PDF beigefügt.

Der “Text für den Header” wird für alle Dateianhänge, die als PDF-Dokument erzeugt werden (z.B weitergeleitete Briefe oder SWIFT-Nachrichten) als Kopfzeilentext verwendet. Dadurch können die Dokumente bei der Anzeige oder beim Ausdruck nicht mit dem Original verwechselt werden.

Dieses Panel wird zum Bereinigen / Löschen von Daten mittels des Services SRVCLN verwendet.

Für Produktionssysteme wird das Aktivieren der folgenden Optionen empfohlen:

• Bereinigung Dateien + Tabellen - Informationen aus den Tabellen WFE, TRS und EVT, die für die Historie notwendig sind, werden automatisch in TRN\EVTTXT gespeichert. Wenn diese Daten in Produktionssystemen nicht zeitnah gelöscht werden, führt dies (insbesondere aufgrund der Füllung der WFE-Tabelle) zu verschlechtertem Antwortzeitverhalten.
• Lösche Ereignisse (EVT) - Informationen aus EVT, die für die Historie notwendig sind, werden automatisch in TRN\EVTTXT gespeichert. Nach dem Löschen ist nur die Auswertung solcher Informationen per direktem Zugriff auf die Datenbank erschwert.
• Lösche Before-Image-Dateien (BIM) - Diese Daten sind sehr umfangreich und werden nach Abschluss einer Transaktion höchstens zur Analyse von Fehlern benötigt.
• Lösche Transaction-Data-Dateien (DAT) - Diese Daten sind sehr umfangreich und werden nach Abschluss einer Transaktion höchstens zur Analyse von Fehlern benötigt.

Das Löschen von Display-Dateien sollte jedoch mit Vorsicht gehandhabt werden:

• Lösche Display-Dateien (DSP) - Display-Dateien sollten hier NICHT gelöscht werden, da in diesen die unter “Details” zu Transaktionen angezeigten Inhalte der Bildschirmmasken gespeichert sind (Display-Dateien werden je nach verfügbarem Platz entweder nach Zeitablauf (> 12 Monate) oder beim Archivieren alter Kontrakte gelöscht).

Als Voreinstellung sind die Checkboxen “Ber. Dateien u. Tabellen”, sowie “Lösche Before-Image-Dateien (.BIM)” und “Lösche Transaction-Data-Dateien (.DAT)” standardmäßig ausgewählt.

Details zur Konfiguration des Bolero Terminals siehe Konfiguration ausgehende Nachrichten.

Dieser Service überprüft die Korrektheit von SWIFT und allNETT Nachrichten. Wenn eine SWIFT Nachricht nicht korrekt ist, z.B. wenn die Nachricht ist zu lang ist, dann wird die Transaktion zur Korrektur geschickt. AllNETT XML Nachrichten werden gegen die dazugehörige xsd Definition geprüft. Sollte die Prüfung fehlschlagen oder die xsd Datei nicht gefunden werden, wird der Workflow Step für diese Transaktion auf Fehler gesetzt. Diese Prüfung kann über die Checkbox 'allNETT XML Validierung' ein- und ausgeschaltet werden.

Emails können über SMTP, Pickup Verzeichnis, Unix Sendmail oder MS Azure Cloud versendet werden. Die relevante Methode wird auf dem Email Service Config Panel selektiert.

Für MS Azure Cloud muß das MS Graph API für Email Lesen, Senden und Lesen/Schreiben im Batch Modus konfiguriert sein.

Task Manager
Service
Drucken
Freigabe
Unterschriften
Prüfe Limitstatus
Vorgänger
Bestätigung
SWIFT Versand
TradeConnect Versand
Check for pending ACK's
Bereinigung
TARGET
Target2
SWIFT XML
DTA Import L/C
DTA Export L/C
DTA Garantien
Order erledigt
Vorläufige Abrechnung löschen
Bolero
E-Mail Versand
Fax
Ausführungsdatum
DTAUS / IZV
Compliance Check
Ext. Bestätigung
Dokumenten Erzeugung Versand
Buchungen exportieren
allNETT
Sende Status Updates
RIVO
Prüfe Dokumente
SEPA
SIC / EuroSIC
EuroSIC
Text
TELEX Out
verkaufte Vermögenswerte
Finanzierungsantwort

(Für einzelne Services vgl. Beschreibung des Workflows)