For a SOAP adapter, if a SOAP fault returned from a service component meets both of the following conditions, the SOAP fault is handled as a fault:

• The SOAP fault is defined in the WSDL of the service component.
• The fault name is specified in faultCode.

Such a fault is called a user-defined exception. Because a user-defined exception is recognized even in a business process, conditional processing can be defined for the process after a fault occurrence.

Depending on the type of service component, a SOAP fault that is not defined in the WSDL, or a SOAP fault with any value specified in faultCode, might be returned. If you want to handle such a SOAP fault as a fault, you can use the SOAP fault operating definition file to handle all the SOAP fault s returned from service components as faults.

In the SOAP fault operation definition file, define the name space (URI of targetNamespace) declared in the WSDL of the service component. For details about the SOAP fault operation definition file, see the SOAP fault Operation definition file in the Service Platform Reference Guide.

For individual service adapters, interfaces of service components are defined in the WSDL. Whether a SOAP fault is handled as a fault is determined based on whether the name space defined in the WSDL matches the contents defined in the SOAP fault operation definition file.

The following figure shows how a SOAP fault is handled when the SOAP fault operation definition file is used.

Figure 4-2 Handling a SOAP fault when the SOAP fault operation definition file is used

1. Define the WSDL of the service component.
2. If the SOAP fault returned from the service component is defined in the WSDL of the service component, it will be handled as a fault.
3. If the returned SOAP fault is not defined in the service component's WSDL or is defined in a name space different from the WSDL definition, the SOAP fault is checked with the SOAP fault operation definition file.
4. If the SOAP fault matches the contents defined in the SOAP fault operation definition file, the SOAP fault is returned (as a fault) to the business process.

If all of the following conditions exist when a SOAP fault returns from a service component, the fault name is set in faultCode and the SOAP fault is handled as a fault:

• The SOAP Communication Infrastructure must be used at the service component side.
• The wsdl:part element that defines the fault message must always reference the element element within the xsd:schema element by using the element attribute.
• The WSDL fault name (name attribute value of the wsdl:fault element) and the element name^# indicating the exception type complexType defined in the schema (within wsdl:types) must be the same, including the name space.

When using a WSDL that does not meet the above conditions, if you want to handle SOAP fault s returned from service components as faults, define the SOAP fault s as user-defined exceptions in the SOAP fault operation definition file.

#

The element name is an element specified by the wsdl:part element (that is referenced by wsdl:fault) by using the element attribute. Specify an element that can be specified by tracing the WSDL in the following order:

1. wsdl:fault
2. wsdl:message (This element might not be traced in some cases.)
3. wsdl:part
4. xsd:element

Note that you can generate a WSDL file with the style attribute of the operation set to rpc by using the Java2WSDL command, which is a Service Platform development command. In this case, the generated WSDL file will be referenced with the type attribute, rather than with the element attribute. Therefore, do not use the generated WSDL file as is, but first modify and regenerate the WSDL file, and then use it. For details about how to modify and regenerate a WSDL file, see 4.3.2 Creating a service component message (for a Web service) in the Service Platform Basic Development Guide.

When using faults with Service Platform, we recommend that you use a document style WSDL.