Entwicklung eines „ErrorHospital“ für Oracle SOA Suite 1 Agenda • • • • Anwendungsfall SOA Suite 11g – Fault Management Error Hospital Demo 2 Markus Lohn – esentri AG Head of Technology Consulting • Consultant, Trainer und Experte für SOA und JEE-Technologien (Oracle 8i – FMW 12c) • seit 01. Februar 2013 bei esentri AG angestellt • zuvor 13 Jahre als Consultant in den Bereichen Content Management und SOA bei Oracle tätig • Umfangreiche Erfahrung bei der Umsetzung von komplexen Projekten mit Oracle-Technologien seit 1999 in den Branchen: • Öffentliche Verwaltung • Banken und Versicherungen • Automotive • Industrie • Baubranche Email: [email protected] Blog: http://esentri.com/blog/ Twitter: https://twitter.com/MarkusLohn 3 esentri AG • Gründung: 2009, AG seit 04/2012 • Standort: Ettlingen bei Karlsruhe • Mitarbeiter: 20 esentri AG Pforzheimer Straße 132 76275 Ettlingen Tel +49 (0) 7243 / 354 90 0 Fax +49 (0) 7243 / 354 90 99 [email protected] www.esentri.com 4 Anwendungsfall 5 Zielsetzung E-Commerce • bi-direktionaler Datenaustausch Buchhaltung primär „relevante“ Daten zwischen E-Commerce und Buchhaltung synchronisieren – Buchhaltung nach ECS • Personendaten • Artikelstatus • Artikelverfügbarkeit – ECS nach Buchhaltung • Bestellung • Zahlungsinformationen • • Relevante Daten = Daten, die für eine Weiterverarbeitung im jeweiligen System benötigt werden Es erfolgt keine vollständige Synchronisation aller verfügbaren Daten! 6 Komponenten Integrationsplattform IBM Suite A O S Oracle twick n e n e g Ei lung k c i w t n igene E lung 7 Architektur E-Commerce Inbound Shop Outbound SOAP-basierte XML-Nachrichten Integrationsplattform Oracle SOA Suite Shop2Buch Services Datawarehouse DWH MQ Adapter Buch2Shop Services DWH Service Database Adapter Zeilenorientiert mit festen Spaltenlängen Buchhaltung Buchhaltung UC4: Java Data-Exchange DB 8 Ausnahmesituationen E-Commerce Inbound Shop Outbound SOAP-basierte XML-Nachrichten Rejected Message Integrationsplattform Oracle SOA-Suite Validierung MQ Adapter Datawarehouse DWH Version ungültig Shop2Buch Services Buch2Shop Services DWH Service Database Adapter Zeilenorientiert mit festen Spaltenlängen Buchhaltung Buchhaltung UC4: Java Data-Exchange DB 9 Anforderungen • • • Generell: Keine Nachricht 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. 10 Oracle SOA Suite 11g Fault Management 11 Oracle SOA Suite 11g Web based customization Rich End User Interaction BPM Workspace BPMN 2.0 / SOA Composite EditorBPEL (Business & IT views) MS Office Process Composer BPEL BPMN Process Core B2B Process Portal (WebCenter) Human Workflow Business Rules Mediator Service Infrastruktur Process Analytics BAM Proc Cubes Common JCA-based connectivity infrastructure Optimized binding MDS Policy Manager WebLogic Server EM console +BPMN Screens 12 Human Workflow • • • • Human Workflow ist ein asynchroner Service Aufruf erfolgt über synchrone Servicefunktionen (initiateTask) Ø Ausnahmesituationen müssen beim Aufruf durch den Client berücksichtigt werden! Typische Ausnahmesituation: • Task kann keinem Benutzer oder Gruppe zugewiesen werden, da nicht im IDM-System auffindbar Lösungsmöglichkeiten • Definition eines “Owners” und “Error-Assignee” für jede Task • ggf. eigene Zuweisungsregel implementieren (RoutingSlip) 13 Business Rules • • RULES ENGINE Rules ist ein synchroner Service Aufruf erfolgt über synchrone Servicefunktionen Ø Ausnahmesituationen müssen beim Aufruf durch den Client berücksichtigt werden! 14 Mediator (1) • Sequential Execution – Mediator verarbeitet den Request synchron Ø Ausnahmesituationen müssen beim Aufruf durch den Client berücksichtigt werden! • Parallel Execution – Mediator verarbeitet den Request asychron Ø Ausnahmesituationen können durch das Fault Management Framework bearbeitet werden 15 Mediator (2): Fault Groups Fault Group Description TYPE_ALL all mediator faults TYPE_DATA Data related faults Assignment, Filtering, Transformation & Validation TYPE_METADATA Mediator metadata related faults Filtering conditions, transformation metadata, mediator metadata validation TYPE_FATAL fatal errors DB related, Cache related, error handling, SOA Infrastructure related, messaging, transaction etc. TYPE_TRANSIENT Errors that can be recovered Infrastructure related, messaging related 16 BPEL BPEL 1.0 BPEL 2.0 Oracle Namespace: http://schemas.xmlsoap.org/ws/ 2003/03/business-process/ Namespace: http://docs.oasis-open.org/wsbpel/2.0/proce ss/ executable Namespace: http://schemas.oracle.com/ bpel/extension • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • selectionFailure conflictingReceive conflictingRequest mismatchedAssignmentFailure joinFailure forcedTermination correlationViolation uninitializedVariable repeatedCompensation invalidReply ambiguousReceive completionConditionFailure conflictingReceive conflictingRequest correlationViolation invalidBranchCondition invalidExpressionValue invalidVariables joinFailure mismatchedAssignmentFailure missingReply missingRequest scopeInitializationFailure selectionFailure subLanguageExecutionFault uninitializedPartnerRole uninitializedVariable unsupportedReference xsltInvalidSource xsltStylesheetNotFound bindingFault remoteFault replayFault 17 Fault Management Framework Policy Driven Fault Handling • Externalize your error handling • Policy-driven • Intended for technical faults (but handles business faults as well) • Engine level – No impact on BPEL process design – No impact on process in runtime (fault is isolated from process) • XML-based fault policies – Conditions for faults (fault name, XPath on fault content) – Set of actions (retry, human intervention, replay scope, rethrow fault, abort, custom Java action) – Centrally managed • Manual resubmission supported through Enterprise Manager console 18 Fault Handling Policy • Maps faults to actions • Specify fault by QName – e.g., bpelx:remoteFault, medns:mediatorFault • Specify criterea with XPath – Query fault code, details, etc • Specify action to be performed • Specify policies at different levels: – Composite – Component • Overrides any fault handling in the BPEL process • Defined in fault-policies.xml in the same directory as composite.xml – Can also be stored in the MDS and referenced in composite.xml – useful if standard policies across SOA applications 19 Java Action • Implements IFaultRecoveryJavaClass interface public interface IFaultRecoveryJavaClass { public void handleRetrySuccess(IFaultRecoveryContext ctx ); public String handleFault(IFaultRecoveryContext ctx ); } • • • • handleRetrySuccess is invoked upon a successful retry attempt. The retry policy chains to a Java action on retrySuccessAction handleFault is invoked to execute a policy of type javaAction Typically handles ‘side tasks’: notifications, fault logging and extended decisions about recovery action Executed in EJB context – within composite’s transaction 20 Error Hospital 21 Fehlerkategorien • 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. In diesem Fall wird die Composite Instance im Enterprise Manager als recoverable gekennzeichnet. 22 Fault Management: Fachlich FaultTask wird automatisch geschlossen 23 Fault Management: Technik Überblick Payload Sensor Composite 1 ermitteln Fault Policy & Binding Message To DeadLetter Queue Composite EAIFaultHandler Sensor Custom Java Fault Handler Composite 2 Fault Policy & Binding Fault Info und Sensor Data auswerten Java FaultAction Sensor Composite 3 Human Task erstellen Fault Policy & Binding Sensor Composite 4 Fault Policy & Binding Terminate Recovery 24 Fault Management: Technik Detail 25 Objekthierarchie Java Fault Handler 26 Demo 27 Q& A 28 Entwicklung eines „ErrorHospital“ für Oracle SOA Suite 29