声明:该博文来自热爱JAVA,热爱生活。原文地址http://maping930883.blogspot.com/
Oracle SOA Suite 提供了复杂而精致的异常处理机制,你可以定义异常处理器来处理不同层次的异常,包括系统异常和应用异常。
BPEL的规范中提供了如何捕捉和处理异常,详细说明请参考《BPEL 如何处理异常?》。
但SOA应用中不光是BPEL组件,还有其它组件,比如Mediator。而Mediator并没有提供有关异常的规范,那么该如何处理Mediator中的异常呢?
为此,Oracle SOA Suite 提供了一个基于策略的异常处理机制,这些策略可以绑定到整个SOA 应用或者应用中的一个组件,比如Mediator。
在这个实验中,我们将首先处理基于策略的异常,然后再处理BPEL的异常。
1. 基于策略的异常
为了模拟remote fault,在EM中,我们把getStatusByCC服务Shutdown,输入大订单测试。
(1)remote fault异常
[img]http://dl.iteye.com/upload/attachment/0071/7315/bd81edc5-09a4-328e-8824-5ac396664771.png[/img]
(2)增加策略文件:fault-policies.xml。与POProcessing中的composite.xml文件在同一目录。
<!-- Step #1: Add your fault handler for remote fault here: -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:remoteFault">
<condition>
<action ref="ora-human-intervention"/>
</condition>
</faultName>
(3)增加策略文件:fault-bindings.xml。与POProcessing中的composite.xml文件在同一目录。
<?xml version="1.0" encoding="UTF-8" ?>
<faultPolicyBindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="POProcessingFaults"/>
</faultPolicyBindings>
(4)重新发布POProcessing,重新测试大订单。发现该异常是可以恢复重试的。
[img]http://dl.iteye.com/upload/attachment/0071/7319/7090510c-2ddc-3f16-af1a-bd97ded62cbe.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7321/9c616740-c270-31b6-8cb3-1d4ebda638b9.png[/img]
(5)重启getStatusByCC服务,点击Recover重试。
[img]http://dl.iteye.com/upload/attachment/0071/7323/be3c1780-e713-3fb9-9028-0ebf00959272.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7325/5b6be7c4-6895-37ed-b04c-52f0bda8484a.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7327/20950188-e804-321e-9392-0529a5871c47.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7329/49ec5572-5dec-3731-b103-6ef9c7da7c49.png[/img]
2. 处理BPEL异常
BPEL的规范中提供了如何捕捉和处理异常,因此发生在BPEL中的异常最好使用规范中的处理办法。
目前,validateForCC的实现:如果传入一个不存在的信用卡号,validateForCC只是简单的返回一个空响应。这个空响应不太直观,因为返回空响应可能还有其它原因。
现在,修改validateForCC的实现如下:如果传入一个不存在的信用卡号,将会抛出一个UnkonwCC的异常。在BPEL中可以捕捉到这个异常,然后进行处理。这样的修改在设计上更加合理。
2.1 实验准备:创建VALIDATECC存储过程
该存储过程用来验证信用卡是否存在,如果不存在抛出应用异常:-20001, 'UNKNOWN CREDIT CARD'。
sqlplus soademo/soademo @create_validate_cc.sql
create or replace FUNCTION VALIDATECC(cc_number IN VARCHAR2)
RETURN VARCHAR2 AS
l_status CREDITCARDINFO.STATUS%TYPE;
BEGIN
select status
into l_status
from creditcardinfo
where ccnumber = cc_number;
RETURN l_status;
EXCEPTION
WHEN NO_DATA_FOUND THEN
raise_application_error(-20001, 'UNKNOWN CREDIT CARD');
END VALIDATECC;
/
2.2 修改ValidateForCC,增加validateCC Reference。
Meditor过滤条件如下:以2开头的信用卡号调用validateCC,返回'code=20001'的异常;
不以2开头的信用卡号调用getCreditValidation。
拖放Database Adapter,并设置如下:
[img]http://dl.iteye.com/upload/attachment/0071/7331/80058e74-ad61-333c-9e80-820e3df65d39.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7333/7f9394be-dde9-3556-bd8b-bfc2a07eb281.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7335/31f64762-82b0-3868-a6c0-99e85b5bd4ed.png[/img]
2.3 修改ApproveLargeOrder BPEL。
把invokeCCStatusService放入一个Scope中,并为这个Scope添加一个Catch分支,捕捉bindingFault异常。
这里有一个BUG:默认生成的.bpel文件中定义的变量是<variable messageType="bpelx:bindingFault" name="FaultVar"/>
但实际上,没有地方定义类型bpelx:bindingFault,应该改成如下的样子:
<variable messageType="bpelx:RuntimeFaultMessage" name="FaultVar"/>
否则,编译时会报错:WSDL messageType "{http://schemas.oracle.com/bpel/extension}bindingFault" of variable "" is not defined in any of the WSDL files。
2.4 修改fault-policies.xml。
由于上一个实验中设置了基于策略的异常处理,而基于策略的异常处理优先于BPEL的异常处理,所以以下的设置是让基于策略的异常处理啥都不做,直接抛出异常,由BPEL异常处理来接管。
<!-- Step #2: Add your fault handler for binding fault here: -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<!-- Let the component handle this specific binding fault -->
<test>$fault.code="20001"</test>
<action ref="ora-rethrow-fault"/>
</condition>
</faultName>
2.5 测试大订单,订单号以2开头。
你会发现ApproveLargeOrder中,异常被异常策略框架抛出,然后由BPEL异常框架捕捉到并处理。
[img]http://dl.iteye.com/upload/attachment/0071/7337/accc3c82-50c8-33d0-b4b4-f19a908adf79.png[/img]
3. 使用Java Fault Handler捕捉和处理异常。
3.1 MyFaultHandler.java
package soatraining.faulthandling;
import java.io.File;
import java.io.PrintStream;
import java.util.*;
import oracle.integration.platform.faultpolicy.IFaultRecoveryContext;
import oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass;
public class MyFaultHandler
implements IFaultRecoveryJavaClass
{
public MyFaultHandler()
{
}
public void handleRetrySuccess(IFaultRecoveryContext ifc)
{
print("RertySuccess");
}
public String handleFault(IFaultRecoveryContext ifc)
{
print("Handle Fault");
print("Properties");
print("=================================================================");
Map props = ifc.getProperties();
java.util.Map.Entry entry;
for(Iterator iterator = props.entrySet().iterator(); iterator.hasNext(); print((new StringBuilder()).append((String)entry.getKey()).append(" = ").append(((ArrayList)entry.getValue()).get(0)).toString()))
entry = (java.util.Map.Entry)iterator.next();
String logFileName = (String)((ArrayList)props.get("logFileName")).get(0);
String logFileDir = (String)((ArrayList)props.get("logFileDir")).get(0);
PrintStream ps = null;
try
{
ps = new PrintStream((new StringBuilder()).append(logFileDir).append(File.separator).append(logFileName).toString());
}
catch(Exception e)
{
print(e.getMessage());
}
log(ps, "Fault Details");
log(ps, "===============================================================");
log(ps, (new StringBuilder()).append("Fault Type ................ ").append(ifc.getType()).toString());
log(ps, (new StringBuilder()).append("Poilcy ID ................. ").append(ifc.getPolicyId()).toString());
log(ps, (new StringBuilder()).append("Faulted Partner Link ...... ").append(ifc.getReferenceName()).toString());
log(ps, (new StringBuilder()).append("Port Type ................. ").append(ifc.getPortType()).toString());
return "OK";
}
private void log(PrintStream ps, String s)
{
try
{
ps.println(s);
}
catch(Exception e)
{
print(e.getMessage());
}
}
private void print(String s)
{
System.out.println((new StringBuilder()).append("MyFaultHanlder: ").append(s).toString());
}
}
3.2 修改fault-policies.xml。
<!-- Step #2: Add your fault handler for binding fault here: -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<!-- Let the component handle this specific binding fault -->
<test>$fault.code="20001"</test>
<action ref="my-java-handler"/>
</condition>
</faultName>
3.3 测试。
查看my-java-handler的定义,会发现它只是记录一些Log,然后重新抛出异常。
因此,BPEL的异常处理机制最终来接管该异常
[img]http://dl.iteye.com/upload/attachment/0071/7337/accc3c82-50c8-33d0-b4b4-f19a908adf79.png[/img]
4. 使用Java Fault Handler捕捉和处理Mediator异常。
Mediator异常处理只能使用基于策略的方式。
Mediator异常可能来自Adapter异常,可能来自Transformation异常。
我们将使用Java Fault Handler捕捉和处理Mediator的所有异常。
为了模拟Adapter异常,我们将把temp目录改成只读,这样对其进行写操作时将抛出异常。
注意,在Windows平台上,改成只读方式不起作用。即使把该目录换名也不行,File Adapter会自动创建该目录。
4.1 修改fault-policies.xml。
<!-- Step #3: Add your fault handler for mediator faults here: -->
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault">
<condition>
<action ref="my-mediator-fault-handler"/>
</condition>
</faultName>
<!-- Step #4: Add the Action definition for handling mediator fauls using custom java here:-->
<Action id="my-mediator-fault-handler">
<javaAction className="soatraining.faulthandling.MyFaultHandler"
defaultAction="ora-terminate" propertySet="myMediatorProps">
<returnValue value="OK" ref="ora-human-intervention"/>
</javaAction>
</Action>
<!-- Step #5: Add new property set for MyFaultHandler for logging Mediator faults here:-->
<propertySet name="myMediatorProps">
<property name="logFileName">mediator-faults.log</property>
<property name="logFileDir">c:\po\log</property>
</propertySet>
4.2 修改routePO mediator。
之所以要把“quantity < 1000”的路由从Sequential改成Parallel。
是因为Sequential表明Mediator的调用者和Mediator使用的是同一个Thread和Transaction Context,如果出现Mediator异常,异常将直接返回给调用者,而无法被Java Fault Handler捕捉到。
使用Parallel表明进入Mediator后,将启动一个新Thread和Transaction Context,如果出现Mediator异常,可以被Java Fault Handler捕捉到。
[img]http://dl.iteye.com/upload/attachment/0071/7339/597421e9-af21-3062-b896-152a8baed970.png[/img]
4.3 测试。
EM 中应该提示等待人工恢复,因为策略上设置的是“ora-human-intervention”。
因为我是Win7平台,所以没有测试,以后在Linux上再验证吧。
Oracle SOA Suite 提供了复杂而精致的异常处理机制,你可以定义异常处理器来处理不同层次的异常,包括系统异常和应用异常。
BPEL的规范中提供了如何捕捉和处理异常,详细说明请参考《BPEL 如何处理异常?》。
但SOA应用中不光是BPEL组件,还有其它组件,比如Mediator。而Mediator并没有提供有关异常的规范,那么该如何处理Mediator中的异常呢?
为此,Oracle SOA Suite 提供了一个基于策略的异常处理机制,这些策略可以绑定到整个SOA 应用或者应用中的一个组件,比如Mediator。
在这个实验中,我们将首先处理基于策略的异常,然后再处理BPEL的异常。
1. 基于策略的异常
为了模拟remote fault,在EM中,我们把getStatusByCC服务Shutdown,输入大订单测试。
(1)remote fault异常
[img]http://dl.iteye.com/upload/attachment/0071/7315/bd81edc5-09a4-328e-8824-5ac396664771.png[/img]
(2)增加策略文件:fault-policies.xml。与POProcessing中的composite.xml文件在同一目录。
<!-- Step #1: Add your fault handler for remote fault here: -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
name="bpelx:remoteFault">
<condition>
<action ref="ora-human-intervention"/>
</condition>
</faultName>
(3)增加策略文件:fault-bindings.xml。与POProcessing中的composite.xml文件在同一目录。
<?xml version="1.0" encoding="UTF-8" ?>
<faultPolicyBindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="POProcessingFaults"/>
</faultPolicyBindings>
(4)重新发布POProcessing,重新测试大订单。发现该异常是可以恢复重试的。
[img]http://dl.iteye.com/upload/attachment/0071/7319/7090510c-2ddc-3f16-af1a-bd97ded62cbe.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7321/9c616740-c270-31b6-8cb3-1d4ebda638b9.png[/img]
(5)重启getStatusByCC服务,点击Recover重试。
[img]http://dl.iteye.com/upload/attachment/0071/7323/be3c1780-e713-3fb9-9028-0ebf00959272.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7325/5b6be7c4-6895-37ed-b04c-52f0bda8484a.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7327/20950188-e804-321e-9392-0529a5871c47.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7329/49ec5572-5dec-3731-b103-6ef9c7da7c49.png[/img]
2. 处理BPEL异常
BPEL的规范中提供了如何捕捉和处理异常,因此发生在BPEL中的异常最好使用规范中的处理办法。
目前,validateForCC的实现:如果传入一个不存在的信用卡号,validateForCC只是简单的返回一个空响应。这个空响应不太直观,因为返回空响应可能还有其它原因。
现在,修改validateForCC的实现如下:如果传入一个不存在的信用卡号,将会抛出一个UnkonwCC的异常。在BPEL中可以捕捉到这个异常,然后进行处理。这样的修改在设计上更加合理。
2.1 实验准备:创建VALIDATECC存储过程
该存储过程用来验证信用卡是否存在,如果不存在抛出应用异常:-20001, 'UNKNOWN CREDIT CARD'。
sqlplus soademo/soademo @create_validate_cc.sql
create or replace FUNCTION VALIDATECC(cc_number IN VARCHAR2)
RETURN VARCHAR2 AS
l_status CREDITCARDINFO.STATUS%TYPE;
BEGIN
select status
into l_status
from creditcardinfo
where ccnumber = cc_number;
RETURN l_status;
EXCEPTION
WHEN NO_DATA_FOUND THEN
raise_application_error(-20001, 'UNKNOWN CREDIT CARD');
END VALIDATECC;
/
2.2 修改ValidateForCC,增加validateCC Reference。
Meditor过滤条件如下:以2开头的信用卡号调用validateCC,返回'code=20001'的异常;
不以2开头的信用卡号调用getCreditValidation。
拖放Database Adapter,并设置如下:
[img]http://dl.iteye.com/upload/attachment/0071/7331/80058e74-ad61-333c-9e80-820e3df65d39.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7333/7f9394be-dde9-3556-bd8b-bfc2a07eb281.png[/img]
[img]http://dl.iteye.com/upload/attachment/0071/7335/31f64762-82b0-3868-a6c0-99e85b5bd4ed.png[/img]
2.3 修改ApproveLargeOrder BPEL。
把invokeCCStatusService放入一个Scope中,并为这个Scope添加一个Catch分支,捕捉bindingFault异常。
这里有一个BUG:默认生成的.bpel文件中定义的变量是<variable messageType="bpelx:bindingFault" name="FaultVar"/>
但实际上,没有地方定义类型bpelx:bindingFault,应该改成如下的样子:
<variable messageType="bpelx:RuntimeFaultMessage" name="FaultVar"/>
否则,编译时会报错:WSDL messageType "{http://schemas.oracle.com/bpel/extension}bindingFault" of variable "" is not defined in any of the WSDL files。
2.4 修改fault-policies.xml。
由于上一个实验中设置了基于策略的异常处理,而基于策略的异常处理优先于BPEL的异常处理,所以以下的设置是让基于策略的异常处理啥都不做,直接抛出异常,由BPEL异常处理来接管。
<!-- Step #2: Add your fault handler for binding fault here: -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<!-- Let the component handle this specific binding fault -->
<test>$fault.code="20001"</test>
<action ref="ora-rethrow-fault"/>
</condition>
</faultName>
2.5 测试大订单,订单号以2开头。
你会发现ApproveLargeOrder中,异常被异常策略框架抛出,然后由BPEL异常框架捕捉到并处理。
[img]http://dl.iteye.com/upload/attachment/0071/7337/accc3c82-50c8-33d0-b4b4-f19a908adf79.png[/img]
3. 使用Java Fault Handler捕捉和处理异常。
3.1 MyFaultHandler.java
package soatraining.faulthandling;
import java.io.File;
import java.io.PrintStream;
import java.util.*;
import oracle.integration.platform.faultpolicy.IFaultRecoveryContext;
import oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass;
public class MyFaultHandler
implements IFaultRecoveryJavaClass
{
public MyFaultHandler()
{
}
public void handleRetrySuccess(IFaultRecoveryContext ifc)
{
print("RertySuccess");
}
public String handleFault(IFaultRecoveryContext ifc)
{
print("Handle Fault");
print("Properties");
print("=================================================================");
Map props = ifc.getProperties();
java.util.Map.Entry entry;
for(Iterator iterator = props.entrySet().iterator(); iterator.hasNext(); print((new StringBuilder()).append((String)entry.getKey()).append(" = ").append(((ArrayList)entry.getValue()).get(0)).toString()))
entry = (java.util.Map.Entry)iterator.next();
String logFileName = (String)((ArrayList)props.get("logFileName")).get(0);
String logFileDir = (String)((ArrayList)props.get("logFileDir")).get(0);
PrintStream ps = null;
try
{
ps = new PrintStream((new StringBuilder()).append(logFileDir).append(File.separator).append(logFileName).toString());
}
catch(Exception e)
{
print(e.getMessage());
}
log(ps, "Fault Details");
log(ps, "===============================================================");
log(ps, (new StringBuilder()).append("Fault Type ................ ").append(ifc.getType()).toString());
log(ps, (new StringBuilder()).append("Poilcy ID ................. ").append(ifc.getPolicyId()).toString());
log(ps, (new StringBuilder()).append("Faulted Partner Link ...... ").append(ifc.getReferenceName()).toString());
log(ps, (new StringBuilder()).append("Port Type ................. ").append(ifc.getPortType()).toString());
return "OK";
}
private void log(PrintStream ps, String s)
{
try
{
ps.println(s);
}
catch(Exception e)
{
print(e.getMessage());
}
}
private void print(String s)
{
System.out.println((new StringBuilder()).append("MyFaultHanlder: ").append(s).toString());
}
}
3.2 修改fault-policies.xml。
<!-- Step #2: Add your fault handler for binding fault here: -->
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<!-- Let the component handle this specific binding fault -->
<test>$fault.code="20001"</test>
<action ref="my-java-handler"/>
</condition>
</faultName>
3.3 测试。
查看my-java-handler的定义,会发现它只是记录一些Log,然后重新抛出异常。
因此,BPEL的异常处理机制最终来接管该异常
[img]http://dl.iteye.com/upload/attachment/0071/7337/accc3c82-50c8-33d0-b4b4-f19a908adf79.png[/img]
4. 使用Java Fault Handler捕捉和处理Mediator异常。
Mediator异常处理只能使用基于策略的方式。
Mediator异常可能来自Adapter异常,可能来自Transformation异常。
我们将使用Java Fault Handler捕捉和处理Mediator的所有异常。
为了模拟Adapter异常,我们将把temp目录改成只读,这样对其进行写操作时将抛出异常。
注意,在Windows平台上,改成只读方式不起作用。即使把该目录换名也不行,File Adapter会自动创建该目录。
4.1 修改fault-policies.xml。
<!-- Step #3: Add your fault handler for mediator faults here: -->
<faultName xmlns:medns="http://schemas.oracle.com/mediator/faults" name="medns:mediatorFault">
<condition>
<action ref="my-mediator-fault-handler"/>
</condition>
</faultName>
<!-- Step #4: Add the Action definition for handling mediator fauls using custom java here:-->
<Action id="my-mediator-fault-handler">
<javaAction className="soatraining.faulthandling.MyFaultHandler"
defaultAction="ora-terminate" propertySet="myMediatorProps">
<returnValue value="OK" ref="ora-human-intervention"/>
</javaAction>
</Action>
<!-- Step #5: Add new property set for MyFaultHandler for logging Mediator faults here:-->
<propertySet name="myMediatorProps">
<property name="logFileName">mediator-faults.log</property>
<property name="logFileDir">c:\po\log</property>
</propertySet>
4.2 修改routePO mediator。
之所以要把“quantity < 1000”的路由从Sequential改成Parallel。
是因为Sequential表明Mediator的调用者和Mediator使用的是同一个Thread和Transaction Context,如果出现Mediator异常,异常将直接返回给调用者,而无法被Java Fault Handler捕捉到。
使用Parallel表明进入Mediator后,将启动一个新Thread和Transaction Context,如果出现Mediator异常,可以被Java Fault Handler捕捉到。
[img]http://dl.iteye.com/upload/attachment/0071/7339/597421e9-af21-3062-b896-152a8baed970.png[/img]
4.3 测试。
EM 中应该提示等待人工恢复,因为策略上设置的是“ora-human-intervention”。
因为我是Win7平台,所以没有测试,以后在Linux上再验证吧。