Start eines Vorgangs
Jedem Teilprogramm werden bei der Generierung der Anwendung oder mittels dynamischer Konfiguration ein oder mehrere Transaktionscodes zugeordnet.
Der Transaktionscode des ersten Teilprogramms eines Vorgangs hat dabei eine besondere Funktion, da über diesen der Vorgang gestartet wird. Dieser Transaktionscode wird auch Vorgangs-Transaktionscode oder kurz Vorgangs-TAC genannt. Für jeden gestarteten Vorgang richtet openUTM einen spezifischen Kontext ein (Speicherbereiche etc.).
Der Vorgangs-TAC kann auf die verschiedensten Arten eingegeben werden, z.B. unmittelbares Eintippen am Terminal, Wahl eines Menüpunktes in einem alphanumerischen Format, Mausklick an einem GUI-Client oder auch über einen Web-Browser.
Zusammen mit dem Transaktionscode kann eine Nachricht an openUTM übergeben werden, die die für die gewünschte Verarbeitung notwendigen Daten enthält.
Dialog-Schritt und Verarbeitungsschritt
Im einfachsten Fall umfasst ein Vorgang nur einen Dialog-Schritt, d.h. zur Bearbeitung der Anforderung (Service-Request) sind keine weiteren Interaktionen notwendig: Auf die Eingabe des Vorgangs-TACs folgt die Ausgabe des Ergebnisses, z.B. "Alles erledigt".
In vielen Fällen wird dieses Schema jedoch nicht ausreichen. Zusätzliche Daten müssen angefordert werden, Zwischenergebnisse angezeigt, individuelle Wahlmöglichkeiten und Verzweigungen im Vorgangs-Ablauf vorgesehen werden: Ein Vorgang umfasst also oft mehrere Dialog-Schritte.
Ein Dialog-Schritt beginnt mit einer Dialog-Nachricht, die ein Kommunikationspartner an die UTM-Anwendung sendet, und endet mit der Dialog-Nachricht, die der Vorgang demselben Kommunikationspartner als Antwort sendet. Zwischen diesen beiden Zeitpunkten werden die Daten verarbeitet, es findet keine Kommunikation mit diesem Kommunikationspartner statt.
Bei verteilter Verarbeitung kommuniziert ein Vorgang nicht nur mit dem Benutzer, der den Vorgang gestartet hat, sondern auch mit einem oder mehreren Partner-Vorgängen: Ein vom Benutzer gestarteter Vorgang sendet also die nächste Nachricht möglicherweise nicht an den Benutzer, sondern an eine andere Server-Anwendung. Da es sich um keine Antwort handelt, spricht man in diesem Fall nicht von einem Dialog-Schritt, sondern von einem Verarbeitungsschritt: Ein Verarbeitungsschritt beginnt mit dem Empfangen einer Dialog-Nachricht und endet mit dem Senden der nächsten Dialog-Nachricht. Diese kann eine Antwort an denselben Partner sein (dann entspricht der Verarbeitungsschritt einem Dialog-Schritt), oder auch eine Nachricht an einen Dritten.
Ein Vorgang kann also in mehrere Dialog-Schritte gegliedert sein, ein Dialog-Schritt - bei verteilter Verarbeitung - in mehrere Verarbeitungsschritte.
Bild: Dialog-Schritte und Verarbeitungsschritte
Abwechseln von Eingaben und Antworten
Für den Aufbau von Dialog-Vorgängen fordert openUTM einen "strengen Dialog", d.h. auf jede Nachricht muss eine Antwort folgen. Nach dem Senden einer Nachricht an einen Vorgang muss also erst eine Antwort empfangen werden, bevor wieder eine Nachricht an diesen Partner gesendet werden kann.
Dieses Schema - zusammen mit dem verarbeitungsschritt-modularen Vorgangs-Aufbau - ermöglicht es openUTM, die Prozesse optimal zu nutzen (siehe die nächsten beiden Abschnitte).
Verarbeitungsschritt-modularer Vorgangs-Aufbau
Wenn ein Vorgang mehrere Dialog- oder Verarbeitungsschritte umfasst, besteht der Vorgang in der Regel nicht aus einer Service-Routine, sondern setzt sich aus einer Folge separater Service-Routinen zusammen, die Teilprogramme genannt werden. Im Standardfall entspricht dabei ein Teilprogramm einem Verarbeitungsschritt, d.h. ein Teilprogramm liest eine Nachricht und gibt am Ende eine Nachricht aus. Der Prozess wird automatisch sofort freigegeben und steht für andere Aufträge bereit. Das nächste Teilprogramm startet erst, wenn die nächste Nachricht vom Kommunikationspartner eintrifft.
Während z.B. der Benutzer am Terminal die Ausgabe liest und die nächste Eingabe vorbereitet, wird vom Vorgang kein Prozess belegt. Wenn der Terminal-Benutzer dann seine Eingabe abgeschlossen hat, übernimmt - ohne dass der Benutzer oder das Teilprogramm dies bemerken - u.U. ein anderer Prozess die Fortsetzung des Dialogs.
openUTM sorgt so für eine optimale Auslastung der Prozesse, was sich positiv auf die Performance auswirkt. Dieses Dialog-Konzept, auch "pseudo-conversational" genannt, setzt openUTM nicht nur beim Dialog mit Terminal-Benutzern ein, sondern auch bei der Programm-Programm-Kommunikation.
Das verarbeitungsschritt-modulare Grundschema vereinfacht zudem das Design von Anwendungen und sorgt für übersichtliche Programme. Es engt den Programmierer jedoch nicht ein, da es flexibel eingesetzt werden kann und openUTM diverse Variationsmöglichkeiten bietet.
Beispiele für Mehrschritt-Vorgänge und nähere Informationen zur Teilprogramm-Verknüpfung finden Sie im Abschnitt „Strukturierung von Vorgängen".
Asynchron-Vorgänge
Mit openUTM können Sie nicht nur Vorgänge definieren, die im Dialog mit dem Benutzer ablaufen, sondern auch Vorgänge, die entkoppelt vom Benutzer gestartet werden. Die in openUTM integrierte Message Queuing-Funktionalität ermöglicht es z.B. besonders umfangreiche oder zeitunkritische Aufgaben - wie langlaufende Statistikberechnungen oder Sortierarbeiten - von Online-Dialogen zu entkoppeln, ohne dass auf Transaktionssicherheit verzichtet werden müsste. Die Message Queuing-Funktionalität steht nicht nur für Verarbeitungsaufgaben, sondern auch für die Ausgabe von Nachrichten zur Verfügung, z.B. für Druckaufträge, Nachrichten an ein Terminal oder Nachrichten an Service-gesteuerte Queues ("Nachrichten an Service-gesteuerte Queues").
Das Message Queuing-Konzept und die Einsatzmöglichkeiten werden im openUTM-Handbuch „Konzepte und Funktionen“ vorgestellt, weitere Informationen finden Sie im vorliegenden Handbuch in Abschnitt „Message Queuing (Asynchron-Verarbeitung)".