Für UTM-gesteuerte Queues und Service-gesteuerte Queues bietet openUTM verschiedene Steuerungsmöglichkeiten, die in die MQ-Aufrufe der KDCS-Schnittstelle integriert sind.
Quittungsaufträge
Zusammen mit der Nachricht an die Queue („Basisauftrag“) können bis zu zwei Quittungsaufträge formuliert werden, die an das positive bzw. negative Ergebnis der Auftragsdurchführung gebunden sind. Quittungsaufträge sind für folgende Arten von Basisaufträgen möglich:
Hintergrundaufträge
Ausgabeaufträge an Terminals, Drucker oder Transportsystem-Anwendungen
Aufträge an TAC-Queues
Quittungsaufträge werden ausgeführt, wenn der Basisauftrag abgewickelt ist. Mit den Quittungsaufträgen hat der Auftraggeber die Möglichkeit, auf ein positives oder negatives Auftragsergebnis zu reagieren. Ein Quittungsauftrag, der nicht zur Wirkung kommt - z.B. der negative Quittungsauftrag bei einem positiven Ergebnis - verfällt. Basisauftrag und Quittungsaufträge werden zusammen auch als Auftrags-Komplex bezeichnet. Das Verhalten ist je nach Art der Queue unterschiedlich.
Lokaler Hintergrundauftrag
Der positive Quittungsauftrag wird gestartet, nachdem der Asynchron-Service ordnungsgemäß beendet wurde.
Der negative Quittungsauftrag wird gestartet, wenn der Asynchron-Service abnormal beendet wurde und wenn keine erneute Zustellung aktiviert oder die maximale Anzahl erneuter Zustellungen erreicht ist (siehe "Erneute Zustellung (Redelivery)“). Das abnormale Beenden kann durch einen UTM-Aufruf im Programm (PEND ER/FR) oder durch einen schwerwiegenden Programmfehler verursacht werden.
Hintergrundauftrag an einen fernen Service (Remote Queuing)
Der positive Quittungsauftrag wird gestartet, wenn der Auftrag erfolgreich in die Queue des fernen Services übertragen wurde.
Der negative Quittungsauftrag wird gestartet, wenn eine solche Übertragung dauerhaft nicht möglich ist.
Ausgabeauftrag
Der positive Quittungsauftrag wird gestartet, nachdem die positive Abdruckquittung vom Drucker oder der Druckeradministration eingetroffen ist.
Der negative Quittungsauftrag wird gestartet:
nach Fehlern beim Aufbereiten der Nachricht durch VTSU-B oder beim Formatieren,
beim Löschen des Auftrags beim Verbindungsaufbau-/abbau von Clients, die mit RESTART=NO generiert sind,
falls ein Auftrag per Administration gelöscht wurde.
Der negative Quittungsauftrag wird jedoch nicht gestartet, wenn eine negative Abdruckquittung vorliegt, bei einer Zeitüberschreitung beim Warten auf die Quittung oder wenn der Druckauftrag wiederholt wird.
Auftrag an eine TAC-Queue
Der positive Quittungsauftrag wird gestartet, nachdem die Nachricht in der TAC-Queue erfolgreich gelesen und die Transaktion ordnungsgemäß beendet wurde.
Der negative Quittungsauftrag wird gestartet,
wenn die Nachricht mit DADM DL gelöscht wird und dabei explizit angegeben wird, dass der negative Quittungsauftrag gestartet werden soll (KCMOD=N),
wenn die Transaktion bei der Verarbeitung der Nachricht zurückgesetzt und keine erneute Zustellung aktiviert wurde oder die maximale Anzahl erneuter Zustellungen erreicht ist, siehe Abschnitt „Erneute Zustellung (Redelivery)“.
Zeitsteuerung
Zeitsteuerung ist für Hintergrundaufträge, Ausgabeaufträge an LTERM-Partner und LPAP-Partner sowie Nachrichten an TAC-Queues möglich. Dabei kann angegeben werden, wann der Auftrag frühestens ausgeführt werden soll bzw. wann die Nachricht frühestens gelesen werden kann. Diese Zeit kann relativ zum Zeitpunkt der Auftragserteilung oder absolut angegeben werden. Man bezeichnet einen solchen Auftrag als zeitgesteuerten Asynchron-Auftrag. Bei zeitgesteuerten Asynchron-Aufträgen wird die Bearbeitung von openUTM gestartet, nachdem der gewünschte Zeitpunkt erreicht ist und die notwendigen Betriebsmittel zur Durchführung des Auftrags von openUTM bereitgestellt werden können.
Erneute Zustellung (Redelivery)
Für Hintergrundaufträge und Nachrichten an Service-gesteuerte Queues lässt sich die Neuzustellung von Nachrichten steuern. Per Generierung kann man einstellen:
ob eine Nachricht an einen Asynchron-Vorgang nach dem abnormalen Vorgangsende erneut zugestellt wird,
ob die Nachricht an eine Service-gesteuerte Queue nach Rücksetzen der Transaktion erneut zugestellt wird,
und wie oft eine solche Neuzustellung maximal wiederholt werden kann. Für Hintergrundaufträge und Service-gesteuerte Queues sind unterschiedliche Werte möglich. Mit einer Obergrenze lassen sich z.B. Endlosschleifen verhindern.
Mit der Redelivery-Funktion kann man sicherstellen, dass die Nachrichten nach dem Vorgangsabbruch/Rücksetzen der Transaktion erhalten bleiben und nicht sofort gelöscht werden. openUTM stellt zudem einen Wiederholungszähler zur Verfügung, der vom Teilprogramm gelesen werden kann. Damit kann das Programm „Schleifensituationen“ erkennen und entsprechend darauf reagieren.
Wenn eine Nachricht erneut zugestellt wird, dann werden keine negativen Quittungsaufträge aktiviert.
Sicherung fehlerhaft verarbeiteter Aufträge in der Dead Letter Queue
Die Dead Letter Queue ist eine TAC-Queue mit dem festen Namen KDCDLETQ. Sie steht immer zur Verfügung und dient dazu, Nachrichten an Transaktionscodes, TAC-Queues, LPAPs oder OSI-LPAPs zu sichern, die nicht verarbeitet oder nicht zugestellt werden konnten.
Die Sicherung von Asynchron-Nachrichten in der Dead Letter Queue kann in der Generierung für jedes Nachrichtenziel einzeln ein- und ausgeschaltet werden.
Für Asynchron-TACs und TAC-Queues kann diese Sicherung alternativ zu Redelivery durchgeführt werden oder auch als letzte Rückfallstufe dienen, nachdem die maximale Anzahl von Redelivery-Versuchen erreicht wurde.
Um die Nachrichten in der Dead Letter Queue evtl. nach einer Fehlerbehebung noch verarbeiten zu können, können Sie die Nachrichten entweder ihrem ursprünglichen Ziel oder einem neuen Ziel zuordnen. Bei der Zuweisung eines neuen Ziels ist zu beachten, dass die Nachrichten immer nur an ein Ziel vom Typ des ursprünglichen Ziels verschoben werden können, also entweder TAC, LPAP- oder OSI-LPAP-Partner.
Das Nachrichten-Aufkommen in der Dead Letter Queue kann mit der Meldung K134 überwacht werden.
| Wie Sie die Sicherung von Nachrichten in der Dead Letter Queue ein- und ausschalten und das Nachrichtenaufkommen überwachen, ist im openUTM-Handbuch „Anwendungen generieren“ beschrieben (Parameter DEAD-LETTER-Q der TAC-, LPAP- und OSI-LPAP-Anweisung bzw. Parameter DEAD-LETTER-Q-ALARM in der MAX-Anweisung). Wie Sie Nachrichten aus der Dead Letter Queue verschieben oder löschen oder einen Pagepool-Engpass vermeiden, ist im openUTM-Handbuch „Anwendungen programmieren mit KDCS“ beschrieben, siehe KDCS-Aufruf DADM und „Pagepool-Engpass“). |
Administration von Message Queues
Die Bearbeitung von Nachrichten und Aufträgen in Message Queues kann über die UTM-Administration beeinflusst werden. Dies gilt gleichermaßen für UTM-gesteuerte als auch Service-gesteuerte Queues. Ein Asynchron-Auftrag oder eine Nachricht in einer USER-Queue kann z.B. in der Bearbeitungsreihenfolge vorgezogen oder auch storniert werden. Für die Administration von Message Queues steht der KDCS-Aufruf DADM zur Verfügung (siehe folgender Abschnitt). Alternativ dazu können Sie auch den grafischen Administrationsplatz WinAdmin oder WebAdmin verwenden.