Ein Anwendungsfall liefert den Kontext für ein Wiederherstellungsszenario. In dem Anwendungsfall verfügt ein Unternehmen über eine Anwendung, bei der die Anforderung zur Erstellung eines neuen Kontos eingeht.
Die Lösung besteht aus mehreren Modulen wie auch empfohlen durch die bewährten Verfahren für Module.
Das erste Modul ist für die Mediation der Anforderung zuständig und delegiert Arbeit an einen Prozess zur Kontoerstellung. In dem Beispiel unten wurde die Lösung in Form mehrerer Module implementiert, wobei die Anforderung zwischen dem Mediationsmodul (AccountRouting) und dem Verarbeitungsmodul (AccountCreation) per SCA-Import/-Export übergeben wird. Der folgende Screenshot veranschaulicht die beiden Module.
Von dem durch Abbildung 1 dargestellten Assemblierungsdiagramm können Sie ableiten, an welchen Stellen in Ablauf Fehler oder Störungen auftreten könnten. Alle Aufrufpunkte im Assemblierungsdiagramm können eine Transaktion weitergeben oder einbeziehen. In einigen Bereichen des Ablaufs werden sich Daten als Folge von Anwendungs- oder Systemfehlern ansammeln.
Im Allgemeinen werden Transaktionsgrenzen durch die synchrone oder asynchrone Interaktion zwischen Komponenten und Import-/Exportbindungen sowie den ihnen zugeordneten Qualifikationsmerkmalen erstellt und verwaltet. Geschäftsdaten häufen sich meist aufgrund von Transaktionsfehlern, Deadlocks oder Rollbacks an bestimmten Wiederherstellungspositionen an.
Transaktionsfunktionen innerhalb WebSphere Application Server helfen WebSphere ESB bei der Anmeldung von Transaktionen bei Service-Providern. Es ist wichtig, diese angemeldeten Interaktionen zu verstehen, und zwar insbesondere in Bezug auf Import- und Exportbindungen. Genaue Kenntnisse der Verwendungsweise von Import- und Exportvorgängen in Ihren ganz speziellen Geschäftsfällen maßgeblich für die Fähigkeit, ermitteln zu können, wo sich wiederherstellungsbedürftige Ereignisse anhäufen.
Eine Fehlerbehandlungsstrategie sollte die Interaktionsmuster, die verwendeten Transaktionen und die Verwendung von Importen und Exporten vor der Anwendungsentwicklung klar definieren. Die Lösungsarchitekten sollten die zu verwendenden Vorgaben und Richtlinien definieren, die bei der Erstellung der Anwendung dann verwendet werden. Der Architekt muss beispielsweise wissen, wann synchrone Aufrufe im Gegensatz zu asynchronen Aufrufen verwendet werden müssen, wann die BPEL-Fehlerbehandlung zum Einsatz kommt usw. Der Architekt muss auch wissen, ob alle bzw. welche Services an Transaktionen teilnehmen können, und er muss hinsichtlich der Services, die nicht teilnehmen können, die Kompensierungsmaßnahmen kennen, falls Probleme auftreten sollen.
Zusätzlich nutzt die im Assemblierungsdiagramm in Abbildung 1 dargestellte Anwendung bewährte Verfahren für die Modulentwicklung und Konnektivitätsgruppen. Durch den Einsatz dieses Musters ist es jetzt möglich, den eingehenden Fluss neuer Ereignisse durch Anhalten des Moduls AccountRouting zu stoppen.
Die folgenden Abschnitte behandeln die Speicherposition von Geschäftsdaten im Fehler- und Wiederherstellungsfall.
Im angeführten Geschäftsfall wird ein BPEL-Prozess für den Prozess AccountCreation eingesetzt.
Prozesse mit kurzer Laufzeit sind auch unter der Bezeichnung 'Mikroprozesse' bekannt.
Wenn Sie die Antworten auf diese Fragen kennen, wird dies Auswirkungen auf die Wiederherstellungsstrategie für die Aufrufe 7 und 8 im Assemblierungsdiagramm wie durch folgenden Screenshot veranschaulicht haben:
Komponenten mit Zustandsüberwachung (z. B. BPEL-Prozesse mit langer Laufzeit und Business-Statusmaschinen) beziehen zahlreiche Datenbanktransaktionen ein, bei denen Prozessaktivitätsübergänge und Statusänderungen in der Datenbank festgeschrieben werden. Die Arbeit schreitet voran, indem die Datenbank aktualisiert wird und eine Nachricht in eine interne Warteschlange eingefügt wird, die beschreibt, was als Nächstes zu erfolgen hat.
Bei Problemen oder Fehlern mit der Verarbeitung von internen Nachrichten von Business Flow Manager werden diese Nachrichten in eine Sicherungswarteschlange verschoben. Das System versucht, die Verarbeitung von Nachrichten fortzusetzen. Wenn eine darauffolgende Nachricht erfolgreich verarbeitet wird, werden die Nachrichten in der Sicherungswarteschlange erneut zur Verarbeitung übergeben. Wenn ein und dieselbe Nachricht fünfmal in die Sicherungswarteschlange gestellt wird, so wird sie anschließend in die Haltewarteschlange eingereiht.
Zusätzliche Informationen zum Anzeigen der Anzahl von Nachrichten und zur Wiedergabe von Nachrichten enthalten die Abschnitte zur Wiedergabe von Nachrichten von der Sicherungs-/Haltewarteschlange.
Failed Event Manager (FEM) dient der Wiedergabe von Ereignissen oder Serviceaufrufanforderungen, die zwischen den meisten Komponententypen asynchron erfolgen.
Fehlgeschlagene Ereignisse werden erstellt, wenn die Komponente AccountRouting einen asynchronen Aufruf an die SCA-Importbindung AccountCreationSCAImport durchführt und eine Ausnahmebedingung ServiceRuntimeException zurückgegeben wird.
Beachten Sie unbedingt, dass meist keine fehlgeschlagenen Ereignisse generiert werden, wenn BPEL als Client in der Serviceinteraktion fungiert. Dies bedeutet, dass die Aufrufe für 7 und 8 (wie in Abbildung 2) im Regelfall kein fehlgeschlagenes Ereignis zur Folge haben. BPEL bietet Fehlerhandler sowie andere Maßnahmen, die für Fehler modelliert werden können. Wenn ein ServiceRuntimeException-Fehler (SRE-Fehler) beim Aufrufen von 'JDBCOutboundInterface' auftritt, wird aus diesem Grund die Service-Laufzeitausnahmebedingung (SRE) zur Verarbeitung an die BPEL (BPEL = Business Process Execution Language) zurückgegeben. Die Fehlerbehandlungsstrategie für das Projekt sollte definieren, wie die konsequente Handhabung von Laufzeitausnahmebedingungen in BPEL aussehen soll.
Sie sollten hierbei jedoch unbedingt zur Kenntnis nehmen, dass für den BPEL-Client fehlgeschlagene Ereignisse für asynchrone Antwortnachrichten erstellt werden, wenn diese Nachrichten wegen eines Infrastrukturfehlers nicht der Prozessinstanz zugestellt werden können.
Das folgende Diagramm veranschaulicht die Funktionsweise der Komponente 'Failed Event Manager'. Dem Diagramm folgen Beschreibungen der Verarbeitung, die jeweils den mit Nummern versehenen Schritten zugeordnet ist.
Der Standardwert für das Wiederholungslimit ist 5 (Erstaufruf und vier Wiederholungsversuche). Der Standardwert kann in der Administrationskonsole geändert werden. Wenn Sie zum Beispiel annehmen, dass ein SCA-Modul namens 'M' vorhanden ist, könnten Sie zu
navigieren und den Wert im Feld Maximale Anzahl fehlgeschlagener Zustellungen ändern.Wann werden 'fehlgeschlagene Ereignisse' erstellt?
Wie angegeben werden fehlgeschlagene Ereignisse weder für synchrone Aufrufe noch in der Regel für bidirektionale Business-Prozess-Interaktionen erstellt.
Fehlgeschlagene Ereignisse werden im Allgemeinen erstellt, wenn Clients ein asynchrones Aufrufmuster verwenden und der der Service-Provider eine Service-Laufzeitausnahmebedingung (ServiceRuntimeException) auslöst.
Wenn die gesamte Verarbeitung synchron und in derselben Transaktion erfolgt, werden nirgendwo die Daten erfasst. Stattdessen werden sie alle an den Client zurückgegeben, von dem der Aufruf ausging. Überall dort, wo eine Festschreibung erfolgt, werden Daten erfasst. Wenn alle Aufrufe synchron sind, aber mehrere Festschreibungen vorliegen, werden diese Festschreibungen zu einem Problem.
Ganz allgemein sollten Sie asynchrone Verarbeitungsaufrufe oder die BPEL mit langer Laufzeit verwenden, wenn mehrere Transaktionen benötigt werden. Jeder ASYNC-Aufruf ist als Möglichkeit zum Erfassen von Daten zu verstehen. BPEL-Prozesse mit langer Laufzeit dienen als Sammelpunkt.
Aufrufmuster | Erstellung eines fehlgeschlagenen Ereignisses (Ja/Nein) | Anmerkungen |
---|---|---|
Synchron | Nein | Für Service-Business-Ausnahmebedingungen und bei Verwendung eines asynchronen Musters werden keine fehlgeschlagenen Ereignisse erstellt. |
Asynchron - unidirektional | Nein | Definitionsgemäß können unidirektionale Aufrufe keine Fehler deklarieren, d. h. es kann keine 'ServiceBusinessException' ausgelöst werden. |
Asynchron - verzögerte Antwort | Nein | Für Service-Business-Ausnahmebedingungen werden keine fehlgeschlagenen Ereignisse erstellt. |
Asynchron - Callback | Nein | Für Service-Business-Ausnahmebedingungen werden keine fehlgeschlagenen Ereignisse erstellt. |
Aufrufmuster | Erstellung eines fehlgeschlagenen Ereignisses (Ja/Nein) | Anmerkungen |
---|---|---|
Synchron | Nein | Für Service-Laufzeitausnahmebedingungen und bei Verwendung eines synchronen Musters werden keine fehlgeschlagenen Ereignisse erstellt. |
Asynchron - unidirektional | Ja | |
Asynchron - verzögerte Antwort | Ja | |
Asynchron - Callback | Ja | |
BPEL - bidirektional | Nein | Es werden keine fehlgeschlagenen Ereignisse erstellt, wenn die Quellenkomponente ein Business-Prozess ist.
Anmerkung: Wenn bei einem asynchronen Aufruf die Antwort nicht an BPEL zurückgegeben werden kann, wird ein fehlgeschlagenes Ereignis erstellt.
|
BPEL - unidirektional | Ja |
Zusätzliche Informationen zur Anzeige und erneuten Übergabe fehlgeschlagener Ereignisse enthält der Abschnitt Fehlgeschlagene Ereignisse erneut übergeben.
SCA-Modulziel
Beziehen Sie sich wieder auf den angeführten Geschäftsfall.
Diese Ziele werden erstellt, wenn das Modul auf einem Anwendungsserver oder in einem Cluster implementiert wird.
An diesen Zielen häufen sich nur in seltenen Fällen Nachrichten an. Die Anhäufung von Nachrichten an diesen Positionen ist ein deutliches Anzeichen dafür, dass unter Umständen ein Leistungsproblem oder ein Anwendungsdefekt vorliegt. Untersuchen Sie die Situation unverzüglich. Es ist wichtig, die Modulziele in der Tiefe (mit der von Ihnen gewählten IT-Überwachungslösung) zu überwachen, denn eine Stauung von Nachrichten könnte einen Systemausfall oder Verlängerung der Wiederanlaufzeit bewirken.
Diese Ziele werden als 'SCA-Modul'-Ziele bezeichnet, da der generierte Name mit Ausnahme der vorangestellten Zeichenfolge 'sca/' mit dem Modulnamen identisch ist. Diese Ziele sind ausschlaggebend für die Funktion von asynchronen SCA-Aufrufen (Vermittlung von Anforderungen und Antworten). Es wird eine unterschiedliche Anzahl von zusätzlichen Zielen während der Anwendungsinstallation auf dem SCA.SYSTEM-Bus generiert, doch zum Zweck der vorliegenden Erörterung soll hier auf die Bedeutung des 'SCA-Modul'-Ziels eingegangen werden.
Wiederholungsversuche des System Integration Bus (SI-Bus)
In Bezug auf den angeführten Geschäftsfall werden SCA eine Reihe von SI-Buszielen zur Unterstützung der asynchronen Kommunikation erstellt.
Wie bereits zuvor erläutert wurde, heißt eines dieser Ziele 'sca/AccountRouting'. Sie können die Anzahl von Wiederholungsversuchen, die im Falle einer Service-Laufzeitausnahmebedingung (ServiceRuntimeException) eines asynchronen Serviceaufrufs erfolgen, durch Änderung des Werts für das Merkmal 'Maximale Anzahl fehlgeschlagener Zustellungen' in der Administrationskonsole anpassen. Für Module mit einem BPEL-Prozess können jedoch keine Werte von unter 2 angegeben werden. Die zweite Zustellung ist für die Rückgabe von 'ServiceRuntimeExceptions' zur Verarbeitung an die BPEL erforderlich.
Systemausnahmenziele
Failed Event Manager ist einer von mehreren Orten, an denen die Verwaltung von Fehlern erfolgen kann. Wenn es sich um JMS- oder EIS-basierte Importe und Exporte handelt, muss ein anderer wichtiger Ort berücksichtigt werden.
Ziele auf dem 'SCA.Application'-Bus sind für das Routing von fehlgeschlagenen Nachrichten zum SIB-Systemausnahmenziel konfiguriert. Wenn also ein JMS-Export eine Nachricht vom SCA-Anwendungsbus abholt und in eine Rollbacksituation gerät, wird die fehlgeschlagene Nachricht an das SIB-Systemausnahmenziel umgeleitet und nicht an das WBI-Ziel für Wiederherstellungsausnahmen. Dieses Szenario weicht insofern von der Erörterung fehlgeschlagener Ereignisse ab, als dass das Nichterfolgen der Entserialisierung einer Nachricht auf dem 'SCA.Application'-Bus kein fehlgeschlagenes Ereignis zur Folge hat. Auf jedem Bus innerhalb der Lösung gibt es ein Systemausnahmenziel. Diese Ziele müssen ganz ähnlich wie die in MQ-Infrastrukturen übliche Warteschlange für 'nicht zustellbare Post' überwacht und verwaltet werden.
Überdenken Sie folgendes Szenario.
Diese Art von Fehler kann auftreten, wenn versucht wird, Anforderungen von AccountRoutingJMSExport (1) zu empfangen. Bei diesem Export handelt es sich um einen JMS-Export und es besteht die Möglichkeit, dass sich Ereignisse im Systemausnahmenziel auf 'SCA.Application.Bus' ansammeln. Verwenden Sie die ausgewählte IT-Überwachungslösung, um dieses Ziel in seiner gesamten Tiefe zu beobachten.
Failed Event Manager- und SIB-Ziele
Knotenname: WESBNode Servername: server1 Ziel für Wiederherstellungsausnahmen: WBI.FailedEvent.WESBNode.server1Im Allgemeinen sind alle auf dem 'SCA.System'-Bus erstellten Ziele so konfiguriert, dass fehlgeschlagene Nachrichten an das Ziel für Wiederherstellungsausnahmen weitergeleitet werden.
Wenn ein Systemfehler auftritt, wird nicht nur die fehlgeschlagene Nachricht an diesem Ausnahmebedingungsziel erfasst, sondern die Wiederherstellungsfunktion von WebSphere ESB generiert außerdem ein fehlgeschlagenes Ereignis, das den Systemfehler darstellt, und speichert dieses wie im Abschnitt zu Failed Event Manager dieses Dokuments beschrieben in der Wiederherstellungsdatenbank.
Kurz zusammengefasst stellt WebSphere ESB ein funktionelles Leistungsspektrum für die Verwaltung bereit, das weit über die Fähigkeiten der zugrunde liegenden WebSphere Application Server-Plattform hinausgeht. Es sollten entsprechende Maßnahmen ergriffen werden, um sich mit der Gesamtheit dieser Funktionalität vertraut zu machen und sie zu nutzen. Außerdem sollten Sie sich an den Empfehlungen unter Fehlerprävention und Wiederherstellung planen im Abschnitt für Verfahren zur Prävention orientieren.
Verwaltungsfunktionalität | Im WebSphere ESB-Paket enthalten? (Ja/Nein) | Zusammenfassung |
---|---|---|
Failed Event Manager | Ja | Lese-, Bearbeitungs- und Löschzugriff. Dies ist der zentrale Bereich für die Verwaltung von Service-Laufzeitausnahmebedingungen und anderen Arten von Infrastrukturfehlern bzw. -störungen. |
Service Integration Bus-Browser |
Ja |
Lese- und Löschzugriff. Verwenden Sie den Service Integration Bus-Browser der Administrationskonsole, um tägliche Betriebstasks für Service Integration Bus-Instanzen zu durchsuchen und auszuführen. |