Fault Handling in SOA Suite 11g

Ronald van LuttikhuizenManaging PartnerVennster, Netherlands

Guido SchmutzTechnology ManagerTrivadis AG, Switzerland

Abstract

It is one thing to design and code the "happy flow" of your automated business processes and services. It is another thing to deal with situations you do not want [or expect] to occur in your processes and services. This session will dive into fault handling in Oracle SOA Suite 11g using a case study based on automated invoice handling. First the session investigates what can go wrong in automated processes and services. Then it categorizes these situations and dives into the mechanisms Oracle SOA Suite 11g offers to handle these different scenarios. These mechanisms include BPEL activities such as Throw and Catch activities, the SOA Suite Enterprise Manager, and SOA Suite's fault handling framework. The session will wrap up by introducing a generic fault handling framework for technical faults used in a real-life project that is realized using a Java fault handler and SOA Suite's fault handling framework.

Agenda

� What is Fault Handling?� Fault Handling in SOA vs. traditional systems� Scenario and Patterns� Implementation of Scenario� Summary and Best Practices

Fault

� What is a “fault”?● Something outside normal operational activity or

“happy flow” happened● Technical error● Programming error● Faulty operation by user● Exceptional business behavior

� Fault isn’t necessarily a bad thing, errors are

Two Types of Faults

� Business faults● Faults that service clients can expect and recover from● Failure to meet a particular business requirement● Often: expected, business value, contractual and recoverable

� Technical faults● Faults that service clients do not expect and cannot (easily)

recover from● Results of unexpected errors during runtime, e.g. null pointer

errors, resources not available, and so on● Often: unexpected, technical, implementation and non-

recoverable

Business Fault

<wsdl:operation name=“orderProduct”>

<wsdl:input message=“order:OrderProductRequestMessage"/>

<wsdl:output message=“order:OrderProductResponseMessage"/>

<wsdl:fault message=“order:ProductNotInStockFaultMessage"

name=“ProductNotInStockFault"/>

<wsdl:fault message=“order:CustomerNotFoundFaultMessage"

name=“CustomerNotFoundFault"/>

</wsdl:operation>

<xsd:element name=“CustomerNotFoundFaultMessage”>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“CustName” type=“xsd:string”/>

<xsd:element name=“City” type=“xsd:string”/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

2. Fault message payload

1. Service contract including fault

Business Fault (II)

<soap:Envelope>

<soap:Header/>

<soap:Body>

<soap:Fault>

<faultcode>CST-1234</faultcode>

<faultstring>Customer not found</faultstring>

<detail>

<CustomerNotFoundFault>

<CustName>John Doe</CustName>

<City>Long Beach</City>

</CustomerNotFoundFault>

</detail>

</soap:Fault>

</soap:Body>

</soap:Envelope>

3. Actual service response

Technical Fault

<wsdl:operation name=“orderProduct”>

<wsdl:input message=“order:OrderProductMessage"/>

<wsdl:output message=“order:OrderProductResponseMessage"/>

<wsdl:fault message=“order:ProductNotInStockFaultMessage"

name=“ProductNotInStockFault"/>

<wsdl:fault message=“order:CustomerNotFoundFaultMessage"

name=“CustomerNotFoundFault"/>

</wsdl:operation>

<soap:Envelope>

<soap:Header/>

<soap:Body>

<soap:Fault>

<faultcode>S:Server</faultcode>

<faultstring>Could not connect to URL 127.0.0.1 on port 8001</faultstring>

</soap:Fault>

</soap:Body>

</soap:Envelope>

1. Service contract including fault

2. Actual service response

Fault Handling, Prevention & Tolerance

� Prevention versus handling● Redundancy● Design and testing● User experience

� Handle it, pass it on, retry/replay, continue

Agenda

� What is Fault Handling?� Fault Handling in SOA vs. traditional systems� Scenario and Patterns� Implementation of Scenario� Summary and Best Practices

Fault Handling SOA vs. traditional

� Multiple service consumers� Services part of larger unit� Heterogeneous & external

components� Long running processes� Asynchronous� Timed events� Often enterprise-wide� Transactions

ESB

Implemen-tation

Implemen-tation

Implemen-tation

BPM User Interface

Scenario (Areas of Problems/Faults)

Old System with limited scalability

Only reachable by queuing

No 7*24 avail. for single instance

of visa

Short Network interruptions

Response sometimes get

lost

Not always available

Fault if product is no longer avail

gus3

Slide 12

gus3 Explain scenario and areas of problems / faults (could also be right at the beginning of presentation to set the context of our talk)Guido Schmutz; 22.05.2011

Fault Recovery Strategies

� Inaction – ignore the request� Balk – admit failure� Guarded suspension – suspend execution

until conditions for correct execution are established

� Provisional action – pretend to perform the request, but do not commit until success is granted

� Recovery – perform an acceptable alternative

Fault Recovery Strategies

� Rollback – try to proceed, but on failure, undo the effects of a failed action

� Retry – repeatedly attempt a failed action after recovering from failed attempts

� Appeal to higher authority – ask someone to apply judgment and steer the software to an acceptable resolution

� Resign – Minimize damage, write log information, then signal definite and safe failure

Patterns for Fault Tolerant Software

� Compensation� Exception shielding� (Limit) Retry� Share the load� Alternative� Exception handler� Heartbeat� Throttling

Anti-patterns

Agenda

� What is Fault Handling?� Fault Handling in SOA vs. traditional systems� Scenario and Patterns� Implementation of Scenario� Summary and Best Practices

Implementation of Scenario

gus5

Slide 18

gus5 might be skipped during the presenation, because the use case has been explained beforeGuido Schmutz; 22.05.2011

Product Management

� Problem● Not to overload the old, non-scalable product system with

the new demand

� Solution● Use Result Caching to cache the product information

(read-only operation)● Use Service Throttling to limit the number of concurrent

requests

Result Cache

gus6

Slide 19

gus6 all the comming slides have the same idea, zoom into the scenario and explain a certain problem and the possible solution.

- One slide with the Problem / Solution- Followed by One or More slide with the implementation in OSB / BPEL and a possible demoGuido Schmutz; 22.05.2011

Result Caching

� Results are returned from cache rather than invoking always the external service● Product data is rather static, so ideal candidate for caching

Product DB

OSB

Proxy Service

Business Service

1

2 3

ResultCache

Service Throttling

� restricts the number of messages on the message flow to a business service

● Set from Operational Settings on the OSB console

OSB

Proxy Service

Business Service

ProductDB

Message Buffer

Credit Card Booking

� Problem● Unstable network between us and the external services

� Solution● Use Retry mechanism of OSB to try many times● No Fault Management necessary for service consumer if

network interruption is only for a short time

Retry

Retry in OSB

� Configured on the business service in OSB

Visa Service

OSB

Proxy Service

Business Service

1

2after 2s

5x

Credit Card Booking (II)

� Problem● Visa Service does not guarantee 7*24 availability for one

single instance

� Solution● Use the multiple instances (endpoints) visa provides and

use service pooling feature of OSB● No Fault Management for the service consumer if at least

one endpoint is available

Service Pooling

Service Pooling

Visa Service 2

Visa Service 1

Visa Service 3OSB

Proxy Service

Business Service

Order Management

� Problem● Guarantee that the message will be delivered to the order

management system

� Solution● Make sure that queues are available, even if the Handle

Order system is not● Make sure that queuing run’s in the same transaction as the

service consumer

Transaction of OSBService Consumer

Transaction of OSBService Consumer

Transactions in OSB

� Explanation and Demo of Transactions in OSB

Order Management (II)

� Problem● Need to return a Product No Longer Available Business

Fault over an Asynchronous MEP

� Solution● Design a separate Fault Message and Operation on the

Callback contract (WSDL) and use that

Fault Message on Callback Contract

� “Business Fault” modeled as another operation on the Callback WSDL

Fault in Async MEP

Order History

� Problem● Order History System not available should have no impact

on Business Process

� Solution● Use Mediator with Fault Policy Management Framework to

configure retry independent of availability of Order History Web Service

Use Fault Policy ManagementIn Mediator to configure retry

Fault Policy Management

� Explanation and demo of Fault Policy Management on Mediator

Order Handling Process

� Problem● Both Product Management and Credit Card

Booking can return Business Faults

� Solution● Handle errors and map them to errors returned

to the service consumer (i.e. the caller of the process)

Fault Handling

Fault Handling

Signal Fault

Handling and Throwing Faults

� Explanation and demo of Handling and Returning Business Faults in BPEL

Order Handling Process (II)

� Problem● Order Processing Response Message can get

lost in the Order Processing system, i.e. the callback message will never arrive in BPEL

� Solution● Timeout on the Wait For Answer with a BPEL

pick activity with a timeout● Undo the process by doing compensation● Use the BPEL compensate activity together with

compensation handler to undo the Booking of the Credit Card

Pick with timeout

Compensate

Handle missing callback message

� Demo of Pick Activity with Timeout and Compensation

Order Handling Process (III)

� Problem● Order Processing Callback Message can be a

Product No Longer Available Business Fault

� Solution● Undo the process by doing compensation● Use the BPEL compensate activity together with

compensation handler to undo the Booking of the Credit Card

Handle BusinessFault and Compensate

CompensationHandler

Compensation Handling

� Explanation and demo of Compensation Handling

Order Handling Process (IV)

� Problem● Credit Card Booking is a non-idempotent

operation

� Solution● To avoid BPEL calling the Book Card again (not

really the case here) we have to make sure to set the Idempotent Property to FALSE for the Book Card operation

Idempotent

Non-Idempotent

Non-Idempotent operations

� Explanation and demo of Compensation Handling

Order Handling Process (V)

� Problem● Unexpected (technical) fault● Multiple processes deal with unexpected faults

in their own way

� Solution● Use fault handler mechanism to enqueue on

error queue without adding process logic● Create one process to listen to error queue and

handle faults● Retrieve process information by using

(composite) sensors

Unexpected (technical) error

Generic fault handler

� Explanation and demo of generic fault handler

Agenda

� What is Fault Handling?� Fault Handling in SOA vs. traditional software

development� Scenario and Patterns� Implementation of Scenario� Summary and Best Practices

Summary

Issue Solution ProductOverloading product management system ThrottlingResult cache OSBVisa Service does not guarantee 7*24 uptime due to e.g. network problems

Muliple endpointsService pooling

OSB

Guarantee message delivery to order management system

Availability of queuesEnqueue and dequeue in service consumer transaction

OSB (and SOA Suite for XA propagation to OSB)

Returning business fault over async MEP from order management system

Separate operation and fault message

OSB and SOA Suite (callback contract between the two)

Order history service not available Retry in Mediator using fault policy framework

SOA Suite

Business fault handling from service to process to consumer

Catch faults in process and reply fault to consumer

OSB and SOA Suite (correct contracts)

Detect missing response message Timeout in pick activity SOA SuiteHandle product no longer available Compensation SOA SuiteAvoid calling credit card booking twice Set non-idempotent property SOA SuiteProcesses needing to deal with unexpected technical faults. All processes solving it in their own way using process logic.

Fault policy frameworks, error queue, generic error handler & (composite sensors.

SOA Suite

Summary & Best Practices

� Differentiate between business and technical faults� Design service contracts with faults in mind: formally describe

business faults in service contracts� Don‘t use exceptions as goto’s� Design with criticality, likeliness to fail, and cost in mind� Differentiate fault patterns in OSB and BPM/BPEL:

● OSB: Retry, Throttling, transactions● BPM/BPEL: Compensation, business fault handling, generic

fault handler, timeout� Handle unexpected errors generically� Make services autonomous� Fault-handling on scope of services and in wider perspective

Fault Handling with SOA Suite 11gPlease Fill Out Your Evaluations

Ronald van LuttikhuizenManaging PartnerVennster, Netherlands

Guido SchmutzTechnology ManagerTrivadis AG, Switzerland

Security Façade for a Component

� Is the theory behind the Fault Policy Management Framework