Error-Hospital für Oracle SOA Suite

Transkript

1 Error-Hospital für Oracle SOA Suite Markus Lohn esentri AG Ettlingen Schlüsselworte Fusion Middleware, SOA, SOA Suite Einleitung Die Entwicklung von Services mit der SOA Suite erfolgt überwiegend deklarativ und bietet dem Entwickler eine Menge Komfort. Die Entwicklung ist jedoch nur eine Seite der Medaille. Die andere Seite betrifft den Betrieb der Oracle SOA Suite und der implementierten Services. Insbesondere das Thema "Behandlung von Ausnahmesituationen" bei der Abarbeitung der Services stellt den Betrieb vor immense Herausforderungen. Wie kann man das Thema des Betriebes und die Überwachung und ggf. Auflösung von Fehlersituationen mit der SOA Suite konkret lösen. In diesem Vortrag wird genau diese Fragestellung erläutert und mit konkreten Beispielen aus der Praxis dargestellt. Anwendungsfall Die Darstellung und Lösungsmöglichkeiten von Ausnahmesituationen in einer service-basierten Umgebung ist oft sehr schwierig und eher theoretisch. Aus diesem Grund wird in diesem Vortrag ein konkretes Kundenbeispiel als Grundlage herangezogen. In vorliegenden Anwendungsfall werden Daten zwischen mehreren Online-Shops und dem internen Buchhaltungssystem ausgetauscht. Zu den wichtigsten Daten zählen Artikelbestellungen und Zahlungsinformationen. Zusätzlich gibt es noch eine Reihe von weiteren Datenarten, die zwischen den Systemen übermittelt werden müssen. Die Kommunikation erfolgt bi-direktional und asynchron. In Abbildung 1 sind die wesentlichen Systemkomponenten dargestellt. Abbildung 1 beteiligte Komponenten im Anwendungsfall Die Artikelbestellungen werden in verschiedenen Online-Shops erfasst und gespeichert. Die Übermittelung der Daten erfolgt durch Bereitstellung von Nachrichten in Queues. Im Datawarehouse werden Informationen zu Artikelbestellung gespeichert, um entsprechende Auswertungen zu ermöglichen. Das Datawarehouse bietet hierzu eine SOAP-basierte Serviceschnittstelle an. Das Buchhaltungssystem ist eine Eigenentwicklung, die eine SQL-basierte Schnittstelle zur Verfügung stellt. Die Integrationsplattform wird mit der Oracle SOA Suite implementiert und übernimmt die

2 Steuerung und Überwachung der Datenübermittlung zwischen den beteiligten Systemen Shop, Datawarehouse und Buchhaltung. In vorliegenden Anwendungsfall sind nun die klassischen Ausnahmesituationen zu betrachten: System nicht verfügbar Validierungsfehler Ungültiges Nachrichtenformat Folgende Ziele wurden beim Design und Implementieren des Error-Hospitals verfolgt: Generell: Keine Nachrichte darf verloren gehen Aus Sicht der Entwicklung: Einheitliche und zentrale Behandlung von Ausnahmen für alle Services. Aus Sicht des Betriebes: Einheitlicher Prozess zur Nachverfolgung und Auflösung von Ausnahmesituationen. Oracle SOA Suite 11g Die Integrationsplattform wird mit der Oracle SOA Suite 11g implementiert. In Bezug auf die Behandlung von Ausnahmesituationen sind die Möglichkeiten in den einzelnen Service Engines zu betrachten. Service Engines in der Oracle SOA Suite sind BPEL (BPMN), Human Workflow, Business Rules und Mediator. Die aktuelle Implementierung der Integrationsplattform im Anwendungsfall nutzt folgende SOA Suite Komponenten: MQ-Adapter Database-Adapter Mediator BPEL Human Workflow Abbildung 2 Architekturüberblick SOA Suite 11g

3 In den jeweiligen Technologie-Adaptern (z. B. Database Adapter) können Konfigurationseinstellungen für Ausnahmesituationen durchgeführt werden. Zusätzlich kann das Fault Management Framework für die Behandlung von Rejected Messages konfiguriert werden. In der Service Engine BPEL kann die Behandlung von Faults direkt im BPEL-Prozess oder im Fault Management Framework durchgeführt werden. Jedoch ist zu beachten, dass die im BPEL Standard definierten Fault Typen (z. B. InvalidVariable) nicht direkt über das Fault Management Framework abgefangen werden können. Das Fault Management Framework berücksichtigt lediglich Faults von Oracle, z. B. remotefault. Im Vortrag wird jedoch eine Lösungsmöglichkeit skizziert. Im Falle der Komponente Mediator erfolgt die Faultvearbeitung direkt über das Fault Management Framework. Bei der Analyse eines Faults im Mediator erfolgt die Unterscheidung in die Hauptkategorien TYPE_DATA, TYPE_METADATA, TYPE_FATAL, TYPE_TRANSIENT. Jede dieser Hauptkategorien kann wiederum feiner unterteilt werden. Bei der Implementierung der Services für die Integrationsplattform wurde darauf geachtet, keine Faults direkt im Composite zu verarbeiten. Alle Faults werden ausnahmslos über das Fault Management Framework abgewickelt. Ferner wurde insbesondere beim Design der Services darauf geachtet (Transaktionsgrenzen), wie mögliche Faults später im Betrieb zu behandeln sind. Fehlerkategorien Es wurde grundsätzliche eine Unterscheidung in zwei Fehlerkategorien vorgenommen: Non-Recoverable Faults Betrifft alle Faults, die nur durch ein manuelles Eingreifen behoben werden können. In diesem Fall wird die Composite Instance auf jeden Fall beendet. Ein Neustart eines Composites mit korrigierter Nachricht ist dann erforderlich. Beispiele sind ungültige Nachrichtenversion, Konvertierungs- und Validierungsfehler. Recoverable Faults Betrifft alle Faults, die nach dem Beenden der Ausnahmesituation fortgesetzt werden können. Die Composite Instance wird angehalten und später fortgesetzt. Beispiel ist die Nichtverfügbarkeit eines Services beim Aufruf durch eine Composite Instance. Prozessablauf Ausnahmebehandlung im Anwendungsfall Alle möglichen Ausnahmesituationen im Anwendungsfall werden über das Fault Management Framework der SOA Suite abgefangen und entsprechend verarbeitet. Es besteht keine Notwendigkeit für den Entwickler Ausnahmesituationen direkt im Composite zu behandeln. Es wurde ein Custom Java Fault Handler entwickelt, der die Verarbeitung der Ausnahmesituation durchführt. Der Prozessablauf ist in Abbildung 3 kurz skizziert.

4 Abbildung 3 Überblick Prozess Ausnahmebehandlung Es erfolgt eine Fallunterscheidung im Java Fault Handler, so dass der in Abbildung 3 dargestellte Prozess teilweise unterschiedlich abgearbeitet wird. Es existieren jeweils spezialisierte Java Fault Handler für die verschiedenen Kommunikationsrichtungen. Zusätzlich verarbeitet ein eigener Java Fault Handler Faults beim Auslesen aus Queues. In diesem Fall wird keine Composite-Instanz gestartet. Im Sprachgebrauch der SOA Suite handelt es sich um eine Rejected Message. Abbildung 4 Objekthierarchie Java Fault Handler Der Java Fault Handler analysiert den abgefangenen Fault. Dabei muss berücksichtigt werden, aus welcher SOA Suite Komponente (z. B. BPEL oder Mediator) der Fault verursacht wurde. Dann wird die Nachricht (Payload) zur Composite Instance ermittelt (direkt aus der Datenbank) und in eine sog. DeadLetter Queue geschrieben. Es handelt sich hierbei um eine spezielle Queue, die für jeden Service konfiguriert und nur im Fehlerfall beschrieben wird. Existiert keine DeadLetter Queue für den jeweiligen Service oder kann diese aus technischen Gründen nicht angesprochen werden, dann wird die Nachricht in ein spezielles Logfile geschrieben. Im folgenden Bearbeitungsschritt erfolgt die Erzeugung einer speziellen Fault Task. Alle gesammelten Informationen über den abgefangenen Fault werden in der Fault Task bereitgestellt. Bei Erzeugung einer Fault Task wird automatisch ein definierter Personenkreis via benachrichtigt. Mit der BPM Worklist können alle Informationen zum Fault analysiert und weitere Schritte eingeleitet werden. Ferner besteht die Möglichkeit, den aktuellen Bearbeitungsstand direkt in der Fault Task zu dokumentieren. Abschließend wird überprüft, ob die Composite Instance direkt beendet oder für das manuelle Recovery im Enterprise Manager markiert wird. Die Entscheidung wird anhand der definierten Fehlerkategorie vorgenommen. Fault Tasks werden automatisch durch den Java Fault Handler geschlossen, wenn die verknüpften Composite Instances im Enterprise Manager manuell recovered wurden.

5 Fazit: Mit dem hier vorgestellten Error-Hospital wurde der Betrieb in die Lage versetzt, Ausnahmesituationen über einen einheitlichen Prozess zu erkennen und aufzulösen. Dabei ist ein tiefgreifendes technisches Wissen über die eingesetzte Infrastruktur (SOA Suite) nicht erforderlich. Keine Nachricht geht in Ausnahmesituationen verloren. Insbesondere in HA-Tests wurde das erfolgreich verifiziert. In der nahen Zukunft wird der Prozess noch um die Komponente Business Activity Monitoring (BAM) erweitert. Zusätzlich besteht die Möglichkeit, weitere Ticket-Systeme zu integrieren. Kontaktadresse: Markus Lohn esentri AG Pforzheimer Straße 132 D Ettlingen Telefon: +49 (0) Fax: +49 (0) Internet: