WebSphere Enterprise Service Bus, Version 6.2.0 Betriebssysteme: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Anwendungsfall: Daten aus fehlgeschlagenen Ereignissen wiederherstellen

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.

Abbildung 1. Assemblierungsdiagramm für den Kontoroutingprozess
Eine Anforderung wird zwischen dem Mediationsmodul (AccountRouting) und dem Verarbeitungsmodul (AccountCreation) vom SCA-Import an den SCA-Export übergeben.

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.

Business Flow Manager oder Human Task Manager

Im angeführten Geschäftsfall wird ein BPEL-Prozess für den Prozess AccountCreation eingesetzt.

Im Hinblick auf die Wiederherstellung ist es erforderlich, sich die folgenden Fragen bezüglich der BPEL- und Benutzertaskverwaltung zu stellen:
  1. Welche Art von Prozess wird ausgeführt (Prozess mit kurzer oder langer Laufzeit, Business-Statusmaschine, Benutzertask)?

    Prozesse mit kurzer Laufzeit sind auch unter der Bezeichnung 'Mikroprozesse' bekannt.

  2. Wurde der Prozess korrekt und unter Verwendung der Fehlerbehandlung zur Förderung der Datenintegrität entwickelt?
  3. Auf welche Weise sind die Aufrufmuster und Merkmale von Arbeitseinheiten zur Prognostizierung und Steuerung von Transaktionsgrenzen konfiguriert?

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:

Abbildung 2. Assemblierungsdiagramm für das Kontorouting - Aufrufe 7 und 8
Screenshot des Assemblierungsdiagramms mit den hervorgehobenen Aufrufen 7 und 8

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

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.

Abbildung 3. Verarbeitung durch Failed Event Manager
Mit Nummern versehenes Diagramm der Verarbeitung durch Failed Event Manager, wobei die nummerierten Schritte in einer Auflistung nach dem Diagramm aufgeführt sind
Verarbeitung durch Failed Event Manager
  1. Die Quellenkomponente führt unter Verwendung eines asynchronen Aufrufmusters einen Aufruf durch.
  2. Die SCA-MDB (SCA = Service Component Architecture, MDB = Message-driven Bean) holt die Nachricht vom SCA-Ziel ab.
  3. Die SCA-MDB führt den Ausruf an die korrekte Zielkomponente durch.
  4. Die Zielkomponente löst eine ServiceRuntimeException aus.
  5. Die SCA-MDB-Transaktion führt einen Rollback am SCA-Ziel durch.
  6. Die Ausnahmebedingungsinformationen werden in der Datenbank von Failed Event Manager mit dem Status Nicht bestätigt gespeichert.
  7. Der Aufruf wird vom SIBus n-mal wiederholt.

    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 Busse > SCA.SYSTEM.<CELL>.BUS > Ziele > sca/M navigieren und den Wert im Feld Maximale Anzahl fehlgeschlagener Zustellungen ändern.

  8. Wenn die Anzahl der Wiederholungsversuche den angegebenen Grenzwert erreicht hat, wird die Nachricht zum FEM-Ziel verschoben.
  9. Die Datenbank von Failed Event Manager nimmt die Nachricht auf.
  10. Die Datenbank von Failed Event Manager aktualisiert das fehlgeschlagene Ereignis in der Datenbank und der Status wird in Fehlgeschlagen geändert.

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.

Tabelle 1. Aufrufmuster und Beziehung zu der Erstellung fehlgeschlagener Ereignisse: Service-Business-Ausnahmebedingungen
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.
Tabelle 2. Aufrufmuster und Beziehung zu der Erstellung fehlgeschlagener Ereignisse: Service-Laufzeitausnahmebedingungen
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 enthält das Information Center im Artikel Fehlgeschlagene Ereignisse verwalten.

Zusätzliche Informationen zur Anzeige und erneuten Übergabe fehlgeschlagener Ereignisse enthält der Abschnitt Fehlgeschlagene Ereignisse erneut übergeben.

Service Integration Bus-Ziele

Nachrichten, die auf die Verarbeitung warten, können sich an einigen wenigen SIBus-Zielen (SIBus = Service Integration Bus) ansammeln. In den meisten Fällen sind diese Ziele 'Systemziele'. Bei den Nachrichten innerhalb dieser Ziele handelt es sich in der Regel um eine Mischung der folgenden Nachrichtentypen:
  • Asynchrone Anforderungen für die Verarbeitung
  • Asynchrone Antworten auf Anforderungen
  • Asynchrone Nachrichten, bei denen die Entserialisierung oder die Funktionsselektorauflösung fehlgeschlagen ist
    Anmerkung: Asynchrone Antworten können gültige Business-Objekte oder Fehler sein, die als Ergebnis auf eine Anforderung zurückgegeben wurden.

SCA-Modulziel

Beziehen Sie sich wieder auf den angeführten Geschäftsfall.

Die Lösung würde zwei 'SCA-Modul'-Ziele enthalten:
  • sca/AccountRouting
  • sca/AccountCreation

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)

Wie bereits zuvor ausgeführt besitzt Failed Event Manager (FEM) einen integrierten Wiederholungsmechanismus bei der SCA-MDB. Dieses Wiederholungsverhalten lässt sich durch entsprechende Änderung des Attributs 'Maximale Anzahl fehlgeschlagener Zustellungen' für das Modulziel steuern.
Anmerkung: Normalerweise gibt es keinen Grund, diese Wiederholungsfunktion anzupassen. Die an dieser Stelle bereitgestellten Informationen dienen der Vollständigkeit.

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.

Diagramm mit einer Darstellung der Verarbeitung von Systemausnahmen
Ein externer JMS-Client stellt eine Nachricht in eine eingehende Warteschlange, die per JMS-Export offen gelegt wurde. Die Message-driven Bean (MDB) der JMS-Exportbindung holt die Nachricht zur Verarbeitung ab. Ab hier erfolgt eine der beiden folgenden Aktionen:
  1. Der JMS-Export wertet die Nachricht erfolgreich aus und sendet, sobald ermittelt worden ist, welche Operation auf der Schnittstelle aufgerufen werden muss, die Nachricht zur Verarbeitung an die SCA-Laufzeit.
  2. Der JMS-Export kann den Nachrichtenkörper nicht als gültiges Business-Objekt erkennen oder die JMS-Exportbindung entserialisiert den Nachrichtenkörper, kann aber nicht ermitteln, welche Operation auf der Schnittstelle korrekterweise aufgerufen werden muss. Zu diesem Zeitpunkt wird die Nachricht in das Systemausnahmenziel für den Bus gestellt.

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

Bei WebSphere ESB ist als Ziel für Ausnahmebedingungen die Zielwarteschlange für WebSphere ESB festgelegt. Für diese Warteschlange gilt die folgende Namenskonvention:
Knotenname: WESBNode
Servername: server1
Ziel für Wiederherstellungsausnahmen: WBI.FailedEvent.WESBNode.server1
Im 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.

Zusammenfassung

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.

Tabelle 3. Verwaltungsfunktionen zur Unterstützung bei der Verwaltung von Fehlern
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.

Anmerkung: Welche Anzahl von Ereignissen oder Datensätzen diese Tools gleichzeitig verwalten können ist jeweils abhängig von externen Faktoren wie Speicherzuordnung, Ergebnismengen und Datenbankoptimierung sowie Verbindungszeitlimits. Führen Sie Tests aus und legen Sie geeignete Schwellenwerte fest, um Ausnahmebedingungen (OOM, TransactionTimeOut) zu vermeiden.

concept Konzeptabschnitt

Nutzungsbedingungen | Feedback


Zeitmarkensymbol Letzte Aktualisierung: 05 Juli 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/crec_use_case_recovery.html
Copyright IBM Corporation 2005, 2010. Alle Rechte vorbehalten.
Dieses Information Center basiert auf Eclipse-Technologie (http://www.eclipse.org).