官术网_书友最值得收藏!

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.

  1. We add the <catch> activity to the scope, where we invoke the web service. We model the <catch> activity with the following parameters:
  2. 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:

  3. Now, if we run the BPEL process that finishes successfully, we get the following response:
  4. 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).

主站蜘蛛池模板: 佛坪县| 罗定市| 泰安市| 惠水县| 安陆市| 江阴市| 通州市| 宜州市| 淮北市| 南汇区| 治多县| 原阳县| 平度市| 石屏县| 谢通门县| 青岛市| 万载县| 湘乡市| 河间市| 平邑县| 德化县| 鹤山市| 泸溪县| 惠东县| 红安县| 措勤县| 保德县| 北京市| 楚雄市| 武城县| 淮南市| 定南县| 白河县| 措勤县| 宜州市| 上思县| 贵德县| 三门县| 天峻县| 耿马| 阆中市|