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

Werbung
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
Herunterladen