- BPEL and Java Cookbook
- Jurij Laznik
- 449字
- 2021-08-06 16:58:20
Handling the faults thrown from a web service
The faults are one of the most important aspects of the BPEL process. In this recipe, we will explore how to handle the faults that are thrown from the web service.
Getting ready
This recipe explains how to handle the faults thrown from the synchronous web service.
How to do it…
We will modify the BPEL process we created in the Invoking web services in parallel recipe and name it BPELProcessFault
. If we now run the BPEL process, it will complete with the faults. Now, we have to adapt the BPEL process in order to catch the faults thrown from the web service.
- We add the
<catch>
activity to the scope, where we invoke the web service. We model the<catch>
activity with the following parameters: - Inside the
<catch>
activity we add the<assign>
activity, where we report that something went wrong to the client calling our process as follows:<faultHandlers> <catch faultName = "ns1:BookCarServiceInvalidDatesException" faultVariable = "FaultVar"> <assign name = "AssignFault"> <copy> <from expression = "string('Problem with the BPEL process !!!!!')"/> <to variable = "outputVariable" part = "payload" query = "/client:processResponse/client:result"/> </copy> </assign> </catch> </faultHandlers>
The final outlook of the BPEL process for handling faults is as follows:
- Now, if we run the BPEL process that finishes successfully, we get the following response:
- In case of the fault, we receive the following response from the BPEL process:
How it works…
The faults are specified in the port type when we invoke the synchronous web service. The web service itself creates the fault and fills it with information about the fault. This fault message is received by the BPEL process that invokes faulted web service. Based on the criteria about the fault message, the BPEL process catches the fault with the information within. Based on the fault type and information inside the fault, we can decide how to proceed with the BPEL process execution. The fault handler can affect only the scope that encloses it. When the fault occurs in the scope, the BPEL process execution continues after the scope definition. If the fault handler is attached to the outer most scope, then the BPEL process finishes after the fault is handled.
There's more…
There are cases where the fault message is not known. If we cannot define the message or we fail to catch every fault that comes from the web service invocation, we utilize the <catchAll>
activity. The <catchAll>
activity does not have any conditions and simply consumes any fault coming into the BPEL process.
Note
We can have multiple <catch>
activities per scope in the BPEL process; however, there must exist only one <catchAll>
activity per scope. The same functionality can be found in the Java programming language. We can see the BPEL <catch>
activity as the Java catch statement with the named exception. Similarly, we can see that the BPEL <catchAll>
activity is similar to the Java statement catch(Exception e)
.
- Linux操作系統基礎
- Implementing Cisco UCS Solutions
- Linux系統文件安全實戰全攻略
- 高性能Linux服務器構建實戰:運維監控、性能調優與集群應用
- 計算機系統開發與優化實戰
- Python基礎教程(第3版)
- AWS Development Essentials
- 突破平面3ds Max動畫設計與制作
- Ceph分布式存儲實戰
- INSTANT Migration from Windows Server 2008 and 2008 R2 to 2012 How-to
- 計算機應用基礎(Windows 7+Office 2016)
- 寫給架構師的Linux實踐:設計并實現基于Linux的IT解決方案
- Drupal 7 Cookbook
- 電腦辦公(Windows 10 + Office 2016)入門與提高(超值版)
- Android應用性能優化最佳實踐