uCosminexus Service Platform, Basic Development Guide

[Contents][Glossary][Index][Back][Next]

5.4.3 Defining Fault Handling

To enable process execution when a fault occurs in activities, deploy an activity for fault handling and execute fault handling.

You define fault handling by linking the activity in which a fault occurs with the activity that executes fault handling. Use fault connection for the link.

Organization of this subsection
(1) Procedure for defining fault handling
(2) Defining fault handling when executed in a batch
(3) Message format used for defining fault handling in a business process

(1) Procedure for defining fault handling

To define fault handling:

  1. Deploy the activity in which a fault occurs and the activity that executes fault handling on the canvas, and define their details.
    You can define multiple activities that execute fault handling.
    For details about how to deploy activities, see 5.4.1 Deploying Activities. For details about how to define individual activities, see 5.6 Defining Activities.
  2. Use fault connection to link the activity in which a fault occurs with the activity that executes fault handling.
    For details about how to link activities, see 5.4.2(2) Link setting method. For details about activities that can use fault connection, see 5.4.2(5) Conditions for linking activities.
  3. Double-click a link line.
    The Fault Handler dialog box opens.
    For details about the input and display contents of the Fault Handler dialog box, see the manual Cosminexus Service Platform Reference. Note that only the message type variables are allocated for fault handling.
  4. Define fault handling conditions.
    In the Allocated variable drop-down list, specify the variable that is subject to a fault. In the Transition destination drop-down list, specify the link-destination activity that executes processing when a fault occurs.
    To specify fault handling to be executed when an undefined fault occurs, click catch-all in the Allocated variable drop-down list. If the activity in which a fault occurs is a Java-invoking activity, only catch-all fault handling can be specified.
    For converting an exception for error occurred when invoking service component (Web Services) from service adapter to a fault message in service adapter, choose the definition file to be set in the variable definition from the Allocated variable dropdown list. For details about how to set the definition file, see 5.5.1(6)(a) Defining new variables.
  5. Click OK.
 

As shown in the following figure, when a fault occurs, the process moves to the next activity from the one in which the fault occurred after the fault handling is executed:

Figure 5-2 Processing after fault handling is executed

[Figure]

(2) Defining fault handling when executed in a batch

When a process contains multiple activities that might return a fault, you can execute fault handling for processes, in a batch instead of defining fault handling for each activity. In such a case, compile processes within the processing into one, and then define fault handling.

Figure 5-3 Fault handling defined by using the scope activity

[Figure]

(3) Message format used for defining fault handling in a business process

This point describes the message format used for defining the fault processing in a business process.

(a) Message format corresponding to multiple fault names

From a Java program that throws multiple user-defined exceptions, use the SOAP application development support functionality (Java2WSDL command) and create a WSDL of the Document style. If you define an adapter using this WSDL as the input, the message format corresponding to the multiple fault names displayed in Fault messages of the Adapter Definition screen will become the same. In such a case, the message format includes multiple root elements as shown in the following example:

Example of a message format (root schema) corresponding to multiple fault names
 
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://service"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://service"
  xmlns:tns2="http://data.service"
  xmlns:tns3="http://fault.service">
  <xsd:import namespace="http://data.service"
              schemaLocation="cscformat2.xsd"/>
  <xsd:import namespace="http://fault.service" 
              schemaLocation="cscformat3.xsd"/>
  <xsd:element name="order">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="in0" type="tns2:OrderData"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="orderResponse">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="orderReturn" type="tns2:OrderResult"/>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
  <xsd:element name="StockShortageFault"
               type="tns3:StockShortageFault"/>
  <xsd:element name="InvalidCustomerFault"
               type="tns:InvalidCustomerFault"/>
  <xsd:complexType name="InvalidCustomerFault">
    <xsd:sequence>
      <xsd:element name="CustomerName" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>
 

In the above example, fault messages corresponding to the two faults StockShortageFault and InvalidCustomerFault are handled by a single message format cscformat1.xsd.

The same format is applicable even when an adapter is defined based on the WSDL corrected according to the procedure described in Notes of 4.3.2 Creating a Service Component Message (for Web Services), so as to handle the faults after creating an rpc style WSDL using the SOAP application development support functionality (Java2WSDL command).

When this message format is defined as a separate variable for each fault, and catch is defined twice as the allocated variable in the Fault Handler dialog box to separate the processing according to the generated faults, the format of the two variables allocated as catch will become the same. Therefore, no matter which fault occurs, the catch allocated variable defined first will be applicable, and the corresponding fault handling will not be invoked for the cause.

When the fault message has such a format, make sure to take action by defining the business process according to the following method:

(b) Definition method

Instead of defining variables for each fault, define a single variable that will be common for faults having the same message format. Also specify a single transition destination for fault handling, and allocate a common variable in the Fault Handler dialog box. However, for unexpected fault handling, you can additionally set up the transition destination for catchAll.

Arrange a switch activity in the transition destination of fault processing, and describe the switch conditions for separating the faults that occur based on the element names of the root.

The following figure shows the schematic diagram when a common variable is allocated:

Figure 5-4 Schematic diagram when a common variable is allocated

[Figure]

An example of describing the switch condition for acquiring the root element name and then judging the match (Root element judgment in the figure) is as follows:

csc:getVariableData('Fault variable 1','local-name(/*)')="StockShortageFault"

In Fault variable 1, specify the variable name of the fault common variable, and in StockShortageFault, specify the root element name.