uCosminexus Service Platform, Basic Development Guide
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.
To define fault handling:
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
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
This point describes the message format used for defining the fault processing in a business process.
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:
<?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:
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
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.
All Rights Reserved. Copyright (C) 2015, Hitachi, Ltd.