bpm11g11117 lab faulthandling

Oracle BPM 11g P6 Workshop

of 10 Fault Handling Exercise 9.1

Oracle Confidential. For authorized use only. Do not distribute to third parties.

9 Fault Handling

Table of Contents

9 Fault Handling ..................................................................................................... 1

9.1 Objective ...................................................................................................... 1

9.2 Use Case Description .................................................................................. 1

9.2.1 Overview ............................................................................................. 1

9.3 Exercise Instructions.................................................................................... 1

9.3.1 Fault Handling ..................................................................................... 2

Appendix A: Creating a fault policy from scratch ................................................. 7

Appendix B: Challenge #1 Solution ...................................................................... 8

Appendix C: Challenge #2 Solution ..................................................................... 9

9.1 Objective The objective of this exercise is to learn the different ways fault handling can be implemented in BPMN process. Specifically the lab covers explicit fault handling using boundary events and event sub-processes as well as policy-based fault handling.

9.2 Use Case Description Note: The solution for this exercise can be found in ps6workshop\solutions\BPM11g11117-Solution-fault-handling.zip

9.2.1 Overview

You will be extending the process communication lab to handle various types of exceptions.

Follow the instructions in the next section to complete this exercise.

9.3 Exercise Instructions This exercise requires completing the process communication lab.

If you were not able to complete the process communication lab, use

the solution from ps6workshop\solutions\BPM11g11117-Solution-

ProcessCommunication.zip and deploy it to the server.

Oracle BPM 11g PS6 Workshop

9.3 Fault Handling of 10


9.3.1 Fault Handling

9.3.1.1 Handling Business Faults

1. Initiate a new process instance using the following values:

accountId 9999

cardNumber 9990001

requestedIncrease 10000

requestDate 2012-10-30T00:00:00

requestId R-9999-001

You see that the process fails with an exception.

How would classify this error? Is this a business exception or a system exception?

If you look closely, you will see the exception is caused due to an application error thrown by the PL/SQL procedure. The error also indicates what the root cause is – Invalid credit card number.

Implement the fault handling for this exception so that:

(i) If the error is due to an invalid credit card number, initiate a user task to fix the error and retry the Get Scoring Result activity.

(ii) In all other cases terminate the process with an exception named CreditScoringException.

HINT: Use a boundary event that conditionally transitions to a User task or an Error End Event, based on the fault code

Retest with the above data. Make sure you change the request Id every time a new request is being submitted.

2. In this part of the lab you will use an event sub-process to handle system faults

(i) From the EM console, select LegacyApplicationService composite and shut it down. This simulates a service unavailability condition.

(ii) Instantiate a new process with following values

accountId 2222

cardNumber 22220001


requestDate 2012-10-30T00:00:00


(iii) Examine the exception that was thrown




(iv) Modify the process to use an Event Sub-process to handle all System exceptions. To keep it simple, just have a start and an end without any activities.

(v) Redeploy and test. This time use R-2222-011 as the request ID

As you can see, the event sub process gets control and there is no way to retry or resume the process from the point of exception. This can especially be a problem in case of exceptions that are by nature retriable. The exception you are getting due to the service being down is not a permanent error and can get resolved when the service becomes available.

You will also notice, that once you handle the exception you really can’t resume with your process. All you can do is take care of any housekeeping/cleaning up before the process ends.

If you need to resume the process from the point of exception once the exception is

handled, how would you change the model?

9.3.1.2 Handling System Faults

Policy-based fault handling is the preferred approach for handling all exceptions that need to be handled the same way across different composites and project. It is also useful for exceptions that require intervention from the systems/infrastructure operations people rather than business users. Typically system faults fall in this bucket.

In this part of the lab, you add a fault policy to handle all system faults outside the BPM process using the fault policy framework. You also learn the impact of adding fault policies on your process model, specifically how and when the event sub processes and boundary events are executed.

Start with a simple fault policy that handles all faults and pushes them to the EM Console for manual intervention.

1. Add a new fault policy definition to the project. The structure and syntax of the fault policy and binding file is described in the SOA Developers Guide at http://docs.oracle.com/cd/E23943_01/dev.1111/e10224/bp_faults.htm#BABIGGIB.

Refer to the appendix Creating a fault policy from scratch for details on creating these XML files.

(i) Add a new fault-policies.xml to your BPM project (should be in the same folder as the composite.xml)

(ii) Define a fault policy with id as CCLimitApprovalFaults

(iii) Keep the <faultName> element empty (indicates the policy is for

handling all faults) and remove any <test> elements.




(iv) Set the <action ref=> to initiateHumanIntervention

(v) Add an <Action> with id set to initiateHumanIntervention

(vi) Add a single action using <humanIntervention>

(vii) Your resulting policy file should look like this:

(viii) Add a new XML file named fault-bindings.xml. This file associates the different policies in the policy file to one or more components, services and references in the composite. It can also be applied at the composite level.

For the purpose of this lab, you apply this at the composite level

by adding <composite faultPolicy="CCLimitApprovalFaults"/>

(ix) Create this file using instructions given in the appendix or copy the code given below

<?xml version="1.0" encoding="UTF-8" ?>

<faultPolicyBindings

xmlns="http://schemas.oracle.com/bpel/faultpolicy">

<composite faultPolicy="CCLimitApprovalFaults"/>

</faultPolicyBindings>

(x) Deploy and initiate a new instance with the following values:

accountId 2222

cardNumber 22220001


requestDate 2012-10-30T00:00:00


(xi) If you have defined your policies correctly you should see that the instance has faulted and is available for recovery.




(xii) Check the Flow Trace for this instance and you see that the event sub-process for handling all system exceptions didn’t get executed.

(xiii) You can click on the Recover icon and take appropriate action.

9.3.1.3 Challenge Exercise #1

As you see from the last lab, the fault policy framework takes precedence over any fault handling inside the BPM process for faults that have matching policies defined. But in the lab, the policy was very simple, basically it defined that all faults should be made available for human intervention. Typically you will have separate policies for different faults with different set of actions to be performed for each policy.

Modify the policy to have separate actions in case of remoteFaults and bindingFaults.

Remote faults are typically caused due to network errors, service unavailability etc and therefore can, in most cases, be retried automatically.

1. Change the current policy to retry the failed operation 3 times with a wait-time between retries of 10 seconds. If after the retries are exhausted, the error still persists, make it available for manual recovery. You need to provide a qualified fault name (namespace + fault name). For remote faults your faultName element should be <faultName

xmlns:bpelx="http://schemas.oracle.com/bpel/extension"

name="bpelx:remoteFault">

2. Add a new policy to initiate manual intervention for all bindingFaults. In this case the name for faultName should be

bpelx:bindingFault.




A Binding Fault typically indicates errors caused during servicing a request, but has passed the initial connection stage of the invocation. Generally, binding faults cannot be automatically retried as it could cause unwanted effects.

Appendix B gives the complete XML definition for this challenge

3. Make sure the LegacyApplicationService is shutdown and redeploy and run the process. You should see that it retries 3 times and then makes it available for recovery. You can increase the wait-time between tries so that it gives you a chance to start the service and watch the retry succeed.

9.3.1.4 Challenge Exercise #2

This challenge requires that you complete Challenge #1.

The changes you made in the Challenge #1 lab, have a side effect that breaks your BPM process from a flow perspective.

To see how the policy impact the process flow, create a new instance with the following data:

accountId 2222

cardNumber 222211111


requestDate 2012-10-30T00:00:00


As you see the credit card number is invalid so the process should initiate a user task so that the request data can be edited from the BPM workspace.

You don’t see a new user task for editing this request. Can you explain why?

Fix the policy so that the process works as expected.

HINT: Recall that the fault policy will get precedence over any fault handling in the process. Instead of checking (or in addition to) for the fault code in the process, check for it as part of the fault policy

Solution to this challenge is in Appendix C


of 10 Fault Handling Exercise 0


Appendix A: Creating a fault policy from scratch Currently, JDeveloper doesn’t provide an automated or easy way to generate a fault policy. Typically you use an existing one and modify it for your project.

There is a better way to do this by utilizing JDeveloper’s built-in XML editing features. Follow these steps to create a new fault policy:

Register the fault-policies.xsd and fault-binding.xsd with JDeveloper’s schema registry. These files are in (as of 11.1.1.7 release) JDeveloperHome/jdeveloper/soa/modules/oracle.soa.fabric_11.1.1

/soa-infra-tools.jar

1. To register these files, open JDeveloper preferences and select XML Schemas (Tools��Preferences��XML Schemas)

2. Click on the Add button to select the fault-policies.xsd and then

fault-bindings.xsd from soa-infra-tools.jar. You should see something like the screen shot below:

3. Create a new fault-policy.xml in your BPM project by right-clicking on SOA Content folder and selecting New��XML��XML Document From XML Schema

4. Name the XML file fault-policies.xml. Make sure there are no typing errors in the name as the SOA compiler looks for this specific name.

5. Select Use Registered Schemas

6. In the Options screen, you should select

http://schemas.oracle.com/bpel/faultpolicy as the Target Namespace and faultPolicies as the Root Element


0 Fault Handling of 10


7. Increase the depth to the maximum (should be 8) and click on Finish to complete.

8. You should now have the XML generated for you. Remove/comment-out parts you don’t need. Since you have these schemas registered, you can also use the auto-complete feature of the editor. Just start with a < and the editor will prompt you for the possible valid completions.

9. Once have defined your policies you can right-click and run the schema validator. You can also monitor the errors in the structure panel, as your typing.

For creating the fault-bindings.xml, you wont be able to use the auto-generate option. For some reason (most likely because both schemas have the same namespace), JDeveloper only shows the fault-policies schema in the create New XML file dialog.

Create fault-bindings.xml as a regular XML file in the BPM project (New ��XML �� XML Document). Add the following to the new file:

<?xml version="1.0" encoding="UTF-8" ?>

<faultPolicyBindings


</faultPolicyBindings>

You should now be able to add the binding definitions using the auto-complete feature as shown in the screen shot below

Appendix B: Challenge #1 Solution <?xml version="1.0" encoding="UTF-8" ?>

<faultPolicies


<faultPolicy id="CCLimitApprovalFaults">

<Conditions>

<faultName



<condition>

<action ref="retryWithManualIntervention"/>


of 10 Fault Handling Exercise 0


</condition>

</faultName>

<faultName


name="bpelx:bindingFault">

<condition>

<action ref="initiateHumanIntervention"/>

</condition>

</faultName>

</Conditions>

<Actions>

<Action id="retryWithManualIntervention">

<retry>

<retryCount>3</retryCount>

<retryInterval>10</retryInterval>

<retryFailureAction

ref="initiateHumanIntervention"/>

</retry>

</Action>

<Action id="initiateHumanIntervention">

<humanIntervention></humanIntervention>

</Action>

</Actions>

</faultPolicy>

</faultPolicies>

Appendix C: Challenge #2 Solution <?xml version="1.0" encoding="UTF-8" ?>

<faultPolicies


<faultPolicy id="CCLimitApprovalFaults">

<Conditions>

<faultName



<condition>

<action ref="retryWithManualIntervention"/>


0 Fault Handling of 10


</condition>

</faultName>

<faultName


name="bpelx:bindingFault">

<condition>

<test>$fault.code="20001"</test>

<action ref="letBPMHandleIt"/>

</condition>

<condition>

<action ref="initiateHumanIntervention"/>

</condition>

</faultName>

</Conditions>

<Actions>

<Action id="retryWithManualIntervention">

<retry>

<retryCount>3</retryCount>

<retryInterval>10</retryInterval>

<retryFailureAction

ref="initiateHumanIntervention"/>

</retry>

</Action>

<Action id="initiateHumanIntervention">

<humanIntervention></humanIntervention>

</Action>

<Action id="letBPMHandleIt">

<rethrowFault/>

</Action>

</Actions>

</faultPolicy>

</faultPolicies>

bpm11g11117 lab faulthandling

Documents