Entwicklung eines Error- Hospital für Oracle SOA Suite

Transkript

1 Entwicklung eines Error- Hospital für Oracle SOA Suite 1

2 Agenda Anwendungsfall SOA Suite 11g Fault Management Error Hospital Demo 2

3 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 Blog: Twitter: 3

4 esentri AG Gründung: 2009, AG seit 04/2012 Standort: Ettlingen bei Karlsruhe Mitarbeiter: 20 esentri AG Pforzheimer Straße Ettlingen Tel +49 (0) 7243 / Fax +49 (0) 7243 / info@esentri.com 4

5 Anwendungsfall 5

6 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

7 Komponenten Integrationsplattform IBM Oracle SOA Suite Eigenentwicklung Eigenentwicklung 7

8 Architektur E-Commerce Shop Inbound Outbound SOAP-basierte XML-Nachrichten Integrationsplattform Oracle SOA Suite MQ Adapter Datawarehouse DWH Shop2Buch Services Buch2Shop Services DWH Service Database Adapter Zeilenorientiert mit festen Spaltenlängen Buchhaltung Buchhaltung UC4: Java Data-Exchange DB 8

9 Ausnahmesituationen E-Commerce Shop Inbound Outbound SOAP-basierte XML-Nachrichten Integrationsplattform Rejected Message Datawarehouse Oracle SOA-Suite MQ Adapter Validierung 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

10 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

11 Oracle SOA Suite 11g Fault Management 11

12 Oracle SOA Suite 11g Rich End User Interaction Web based customization BPMN 2.0 / SOA Composite Editor BPEL (Business & IT views) BPM Workspace Process Portal (WebCenter) MS Office Process Composer BPEL Process Core BPMN Human Workflow Business Rules Mediator B2B Service Infrastruktur MDS BAM Process Analytics Proc Cubes Optimized binding Common JCA-based connectivity infrastructure WebLogic Server Policy Manager EM console +BPMN Screens 12

13 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

14 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

15 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

16 Mediator (2): Fault Groups Fault Group TYPE_ALL Description all mediator faults TYPE_DATA Data related faults Assignment, Filtering, Transformation & Validation TYPE_METADATA TYPE_FATAL TYPE_TRANSIENT Mediator metadata related faults Filtering conditions, transformation metadata, mediator metadata validation fatal errors DB related, Cache related, error handling, SOA Infrastructure related, messaging, transaction etc. Errors that can be recovered Infrastructure related, messaging related 16

17 BPEL BPEL 1.0 BPEL 2.0 Oracle Namespace: /03/business-process/ Namespace: ss/ executable Namespace: 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

18 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

19 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

20 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

21 Error Hospital 21

22 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

23 Fault Management: Fachlich FaultTask wird automatisch geschlossen 23

24 Fault Management: Technik Überblick Composite 2 Composite 3 Composite 1 Sensor Fault Policy & Binding Sensor Fault Policy & Binding Sensor Fault Policy & Binding Custom Java Fault Handler Java FaultAction Payload ermitteln Message To DeadLetter Queue Composite EAIFaultHandler Fault Info und Sensor Data auswerten Human Task erstellen Sensor Composite 4 Fault Policy & Binding Terminate Recovery 24

25 Fault Management: Technik Detail 25

26 Objekthierarchie Java Fault Handler 26

27 Demo 27

28 Q & A 28

29 Entwicklung eines Error- Hospital für Oracle SOA Suite 29