Profilketten
Manchmal ist man mit einem Problem konfrontiert, das in einem einzelnen Profil nicht lösbar ist. Für diesen Fall gibt es die Möglichkeit Profilketten aufzubauen, bei denen ein Profil jeweils ein oder mehrere Folgeprofil startet. Diese Profilketten können dabei prinzipiell beliebig lang sein, wobei man dabei die Performance im Auge behalten sollte. Es liegt in der Verantwortung des Anwenders/Entwicklers, dass über die hier beschriebenen Mechanismen keine Endlos-Schleifen entstehen, bzw. dass diese gehandhabt werden.
Zusatzmodule
Das Zusatzmodul Data Flow ist ein nützliches Tool, um Profilketten dieser Art zu visualisieren und analysieren.
Um die Konzepte der vertikalen und horizontalen Vernetzung (und die Einbindung Ihrer Mitarbeiter in diese) optimal zu unterstützen, bieten wir die Zusatzmodule Workflow und DataCockpit an. Werfen Sie einfach mal einen Blick darauf. Es lohnt sich. Ein konkretes Beispiel finden Sie in Abschnitt Automatisierte Workflows (→ Vertikale Integration mit Sub-Profilen).
Fehlerverhalten
Wenn ein Folgeprofil nicht gefunden wird, wird normalerweise eine Exception erzeugt. Dieses Verhalten kann geändert werden, wenn in der Konfigurationsdatei ./etc/startup.xml folgender Eintrag hinzugefügt wird.
<Set name="disposeMessageForUnknownProfile">true</Set>Erste Möglichkeit - Message und Daten
Ein Profil mit Antwortweg des Typs Message startet hierbei ein Profil mit Eingangsagent des Typs Message (dieses Profil muss aktiv sein). Hierbei empfängt Profil 2 im Eingang die Ausgangsdaten von Profil 1.
Zu beachten ist, dass beide Profile dieselbe Queue und denselben Kontext verwenden müssen. Sie können die Default-Werte eines neuen Profils verwenden. Genaueres hierzu finden Sie in der Beschreibung des Antwortweges/Eingangsagenten vom Typ Message.
Profil 1, Antwortweg
Profil-Name: <Name Profil 2>
Kontext-Name: System
Queue-Name: DWForwardReceiver
Zweite Möglichkeit - Message und Trigger
Ist man lediglich daran interessiert das folgende Profil zu starten und hat kein Interesse daran die Ausgangsdaten des startenden Profils zu übertragen, dann kann das folgende Profil (dieses Profil muss aktiv sein) auch einen zeitgesteuerten Eingangsagenten haben.
Zu beachten ist, dass der Inhalt im Antwortweg Message von Profil 1 auf Profil anstoßen einzustellen ist (die Kodierung ist egal).
Das folgende Profil erhält seine Daten dann über den ausgeführten zeitgesteuerten Eingangsagenten. Die Art des zeitgesteuerten Eingangsagenten ist hierbei egal, es muss lediglich in der Unterseite Zeiten/Ausführung die Option Trigger/Externer Aufruf und anderes Profil ausgewählt werden.
Hinweis: Es gibt einen Sonderfall in Profilen mit zeitgesteuerten Eingangsagenten. Dort können Sie "fest verdrahtet" auf selbe Art ein Folgeprofil anstoßen. Zu beachten ist dabei, dass in Folgeprofilen dann nicht auf Variablen mit Präfix MSG_CALL_ zugegriffen werden (Variablen sind im anstoßenden Profil in Phase 1 noch nicht initialisiert, siehe auch Abschnitt Variablen), außer das anstoßende Profil wird ebenso von einem anderen Profil angestoßen. Dessen MSG_CALL_-Variablen können dann durchgereicht werden.
Dritte Möglichkeit - HTTP-Response-Kette
Datenrückgabe über endlose Antwortwege des Typs Eigene Klasse
Es gibt Fälle, in denen ein Client, der ein Profil anspricht, eine Rückantwort von diesem Profil erwartet (z. B. bei HTTP-Requests bzw. Webservice-Aufrufen).
Ist es notwendig eine Kette von Profilen aufzubauen, würde man das normalerweise per Message an das Folgeprofil machen, allerdings wäre dann die Rückantwort an den Client vom Folgeprofil aus nicht mehr möglich.
Der Eingangsagent vom Typ HTTP (und alle zeitgesteuerten, per HTTP getriggerten Eingangsagenten) erlaubt eine dynamische Rückantwort (HTTP-Response) über die Antwortweg-Klassen PassBackDataResponse und DefaultWebServiceResponse (ebenso PassBackBinaryDataResponse und DefaultWebServiceResponseBinary). Setzen Sie dazu bitte im Eingangsagenten HTTP die Checkbox 'Eigene Klasse' oder 'Datenrückgabe' im Antwortweg des Profils und bei den getriggerten Eingangsagenten die Checkbox Daten zurückliefern.
Es kann also im Profil (Mapping, etc.) der Inhalt der Response dynamisch aufgebaut werden und über eine dieser Klassen zurückgereicht werden (an den Eingangsagenten und von dort an den Client).
Um diesen Vorgang nun über eine Profilkette auszudehnen, können die Klassen CallProfile (für Folgeprofile, die keinen zeitgesteuerten Eingangsagenten haben) und CallCronProfile (für Folgeprofile, die einen zeitgesteuerten Eingangsagenten haben) verwendet werden. Der Aufbau der Profilkette ist in der folgenden Abbildung dargestellt.
Wichtiger Hinweis: Das Folgeprofil, das mit Klasse CallProfile (oder CallCronProfile) aufgerufen wird, muss zwingend das Encoding in Phase 2 auf UTF8 gesetzt haben. Zudem müssen alle aufgerufenen Profile aktiv sein.
Hinweis: Wird ein Folgeprofil per Message gerufen (oder muss per Message gerufen werden), dann gibt es auch noch einen anderen Weg Daten zurückzureichen. Sehen Sie sich hierzu bitte die Postexecuter-Klasse TempFileReadPostExecuter an.
Datenrückgabe über einschrittige Antwortwege des Typs Message und HTTP
Alternativ kann in den Antwortwegen Message und HTTP die Option Daten zurückliefern verwendet werden. Details siehe dort.
Setzen Sie dazu bitte im Eingangsagenten HTTP (in Profil 1) die Checkbox 'Eigene Klasse' oder 'Datenrückgabe' im Antwortweg des Profils. Alternativ ist bei zeitgesteuerten, per HTTP getriggerten Eingangsagenten die Checkbox Daten zurückliefern zu setzen.
Wenn Sie einen Antwortweg Message verwenden, muss in Profil 2 auch eine der Antwortweg-Klassen (PassBackDataResponse, DefaultWebServiceResponse, PassBackBinaryDataResponse, DefaultWebServiceResponseBinary) verwendet werden.
Hinweis: Es kann im HTTP-Antwortweg auch ein Folge-Profil oder ein Fehler-Profil gerufen werden und von diesem die Response erzeugt und zurückgeleitet werden, anstatt direkt die Response des HTTP-Antwortweges zurückzuleiten (Details siehe in der Dokumentation des Antwortwegs). In diesem Fall muss im Folge-/Fehler-Profil auch eine der Antwortweg-Klassen (PassBackDataResponse, DefaultWebServiceResponse, PassBackBinaryDataResponse, DefaultWebServiceResponseBinary) verwendet werden.
Variablen setzen
Sie können über HTTP Request Header Variablen im Profil setzen. Enthält der HTTP Request z. B. den Header VAR_TEST , dann setzen Sie damit im Profil die Variable MSG_CALL_HEADER_HTTP_VAR_TEST (muss angelegt werden).
Vierte Möglichkeit - Funktionen
Die ersten drei Möglichkeiten können auch über die Funktionen trigger profile(a,b) und call profile(a[,b],c[,d)) verwirklicht werden.
Übergebene Variablen, Listen und Maps (Profilketten und Sub-Profile)
Variablen
Präfix
Bei der ersten und zweiten (nicht der dritten!) Möglichkeit werden die Variablen des aufrufenden Profils an das aufgerufene Profil übergeben. Dabei wird aber das Präfix MSG_CALL_ hinzugefügt. Das Präfix wird allerdings nur einmal vorangestellt. Es kommt also nie zu Variablennamen mit einem Präfix MSG_CALL_MSG_CALL_.
Bei der dritten Möglichkeit (siehe dort) können Variablen über HTTP Request Header gesetzt werden.
Variablen werden auch an aufgerufene Sub-Profile übergeben.
Zugriff
Das folgende Profil kann auf diese Variablen nur zugreifen (ab Phase 1), wenn sie dort auch definiert wurden. Hat Profil 1 also eine Variable var__Test, dann wird die Variable MSG_CALL_var__Test übergeben und Profil 2 muss eine Variable MSG_CALL_var__Test definieren, um auf den Inhalt der Variable zugreifen zu können. Groß-/Kleinschreibung ist zu beachten.
Ist im Folgeprofil das Mapping deaktiviert, sind auch keine Variablen definiert. Damit kann auf keinen der Werte der Variablen des aufrufenden Profils zugegriffen werden. Werden die Variablenwerte im Folgeprofil dennoch benötigt, ohne dass dort ein Mapping erforderlich ist, muss man sich mit folgendem Vorgehen behelfen.
Mapping im Folgeprofil aktivieren.
Dummy-Mapping (z. B. nur ein Feld) erstellen.
In den Antwortwegen des Folgeprofils als Inhaltstyp wie empfangen einstellen. Der im Mapping erstellte Zielbaum wird damit ignoriert.
Namenskonflikte
Soll eine Variable über mehrere Profile per Message weitergeleitet werden, sollte darauf geachtet werden, dass alle Folgeprofile keine Variablennamen verwenden, die eines der vorhergehenden Profile verwendet, da es aufgrund des vorangestellten Präfixes MSG_CALL_ sonst zu Namenskonflikten und unkalkulierbarem Verhalten bei der Variableninitialisierung in Folgeprofilen kommen kann.
Beispiel: Profil 1 ruft Profil 2, dieses ruft wiederum Profil 3 auf. In Profil 1 gibt es eine Variable Count. Diese wird als MSG_CALL_Count an Profil 2 weitergegeben. Gibt es nun in Profil 2 auch eine Variable Count, dann wird zweimal (und möglicherweise mit unterschiedlichen Werten) die Variable MSG_CALL_Count an Profil 3 weitergegeben. Einmal die in Profil 2 angelegte Variable MSG_CALL_Count (um auf die aus Profil 1 übergebene Variable zugreifen zu können) und dann die in Profil 2 angelegte Variable Count mit dem vorangestellten Präfix MSG_CALL_.
Profil-Neudurchlauf (Metadaten)
Wird ein Neudurchlauf für ein Profil gestartet, das Variablen von einem einem anderen Profil erhalten hat, dann sind diese verfügbar, da sie in den Metadaten gespeichert sind. Siehe auch Abschnitt Metadaten-Editor.
Control Center (Metadaten)
Die an Folge- und Sub-Profile übergebenen Variablen können Sie im Control Center (siehe Abschnitte Übersicht und Fehler) über den Metadaten-Editor überprüfen.
Listen und Maps (und Variablen in Map)
Um Listen und Maps an andere Profile zu übergeben (Phase 3), können Sie die Funktionen serialize map/list(a,b) und deserialize map/list(a,b,c) verwenden, bzw. den Autoserialisierungsmechanismus über die System-Variable VAR_AUTOSERIALIZE_DATA. Zudem kann die Funktion copy variables into map(a,b,c,d) benutzt werden, um alle Variablen des aufrufenden Profils in eine Map zu schreiben (und dann als Map zu übergeben), wodurch man sich die Verwendung des Präfixes MSG_CALL_ sparen kann. Siehe auch Abschnitt Tipps für die tägliche Arbeit.
Andere Datenstrukturen
Andere Datenstrukturen werden nicht von Profil zu Profil übergeben.
Es stehen aber systemweite Datenstrukturen zur Verfügung. Beachten Sie aber bitte, dass nur System-Konstanten in Phase 1 verfügbar sind. Systemweite Nummernkreise und systemweite permanente Werte stehen nur in Phase 3 zur Verfügung. Wollen Sie diese Werte in Phase 1 benutzen, müssen sie den Umweg über Variablen oder System-Konstanten gehen.
Dispatcher-Profile
Wenn man mit Profilketten arbeitet, muss man oft Verzweigungen im Verarbeitungsablauf modellieren. D. h. es muss an einer bestimmten Stelle entschieden werden, ob die weitere Verarbeitung mit Profil A oder Profil B erfolgt.
Hierzu ist es nützlich ein sogenanntes Dispatcher-Profil (Zuteil-Profil) zu erzeugen. Also ein Profil, dass die weitere Verarbeitung an das passende Folgeprofil weiterleitet.
Profil 1 muss lediglich mehrere Antwortwege vom Typ Message haben. In diesem Fall also zwei. Einer davon ruft Profil 2 und der andere Profil 3.
Der Aufruf eines Antwortweges kann über Bedingungen gesteuert werden. Wenn Sie z. B. eine Variable in der Bedingung verwenden, muss diese natürlich in Profil 1 angelegt sein. Diese Variable kann auch von evtl. vorhandenen Vorgängerprofilen belegt werden, muss dann aber wieder entsprechend aufgebaut sein.
Alternativ können Sie den Namen des aufgerufenen Profils über eine Variable (String) angeben in einem einzigen Antwortweg vom Typ Message.