7.7.1 Troubleshooting when executing Web service (SOAP communication)

(a) For standard reception

The method of notifying an error differs according to error types and existence of the business process.

When an error other than the user-defined exception is returned from a service component (when you do not use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error of the user-defined exception is returned from a service component and a business process is not used:

Figure 7‒38:  Method of notifying an error in SOAP communication (when you do not use a business process) when an error of the user-defined exception is returned from a service component

When you are using SOAP Communication Infrastructure or JAX-WS engine provided by Service Platform in the communication infrastructure of a service component, at the time of writing a code to throw an exception in the service component, a user-defined exception is defined using SOAP fault in WSDL of the service component. If a user-defined exception occurs in the service component, the contents of SOAP fault are returned from the standard reception to the service requester.

WSDL used by the service requester is provided by Service Platform. CSCMsgServerFaultException^# is defined as SOAP fault in this WSDL. The service requester can catch SOAP fault returned by the HCSC server using the CSCMsgServerFaultException^# object. You can acquire the name of the exception that occurs in a service component and the fault information (error details) by using getter of the exception object, which is caught. For details on CSCMsgServerFaultException^#, see "8.3.8 Acquiring error information" in "Service Platform Basic Development Guide".

Note#

For SOAP1.2, the exception name will be CSCMsgServerFault12Exception.

When an error other than the user-defined exception is returned from a service component (when you do not use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error of the user-defined exception is returned from a service component and a business process is not used:

Figure 7‒39:  Method of notifying an error in SOAP communication (when you do not use a business process) when an error other than the user-defined exception is returned from a service component

When you are using SOAP Communication Infrastructure or JAX-WS engine provided by Service Platform in the communication infrastructure of a service component, if an unexpected exception which is not defined in WSDL of the service component (system exception) occurs, the SOAP message is to be notified as RuntimeException. Moreover, this condition is to be handled as an exception in the HCSC server even if SOAP fault is defined in WSDL, when JAX-WS engine is used in the communication infrastructure of a service component and SOAP Communication Infrastructure provided by Service Platform is not used.

The system exception, which occurs when a service component is invoked from the service adapter can be transformed to a fault message using the service adapter. For details on how to transform a system exception into a fault message, see "7.11 Handling of an exception that occurs in the service adapter".

WSDL used by the service requester is provided by Service Platform. CSCMsgServerFaultException^# is defined as SOAP fault in this WSDL. The service requester can catch the SOAP fault returned by the HCSC server using the CSCMsgServerFaultException^# object. You can acquire information of the fault, which occurred (error details) using getter of the exception object, which is caught. For details on CSCMsgServerFaultException^#, see "8.3.8 Acquiring error information" in "Service Platform Basic Development Guide".

When you want to notify the SOAP fault returned by a service component as is instead of an exception in the HCSC server, define it in SOAP Fault operation definition file. For details on SOAP Fault operation definition file, see "6.6.1 SOAP fault operation definition file" in "Service Platform Reference Guide".

Note#

For SOAP1.2, the exception will be CSCMsgServerFault12Exception.

When an error is returned from the HCSC server (when you do not use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error is returned from the HCSC server and a business process is not used:

Figure 7‒40:  Method of notifying an error in SOAP communication when an error is returned from the HCSC server (when you do not use a business process)

The following cases correspond to each of the errors shown in the figure:

• Error 1: Invalid request parameter, invalid specified character code, various invalid formats.

• Error 2: Address (location) is not found, the service adapter is stopped

• Error 3: A failure occurs in data transformation

• Error 4: Invalid address, stopping of a service component, communication failure

When any one of the errors from error 1 to error 3 shown in the figure is detected in the HCSC server, the exception of the error, which occurred is returned to the service requester.

If error 4 shown in the figure is detected, you can select whether to return the exception of error occurred as is to the service requester or whether to transform the exception of error into fault message in service adapter. For details on how to select the error to be acquired when an exception occurs, see "7.11 Handling of an exception that occurs in the service adapter".

The service requester can catch the SOAP fault returned by the HCSC server using the CSCMsgServerFaultException^# object. You can acquire information of the fault, which occurred (error details) using getter of the exception object, which is caught. For details on CSCMsgServerFaultException^#, see "8.3.8 Acquiring error information" in "Service Platform Basic Development Guide".

Note#

For SOAP1.2, the exception will be CSCMsgServerFault12Exception.

When an error other than user-defined exception is returned from a service component (when you use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error other than the user-defined exception is returned from the service component and a business process is used:

Figure 7‒41:  Method of notifying an error in SOAP communication (when you use a business process) when an error of the user-defined exception is returned from a service component

When you are using SOAP Communication Infrastructure or JAX-WS engine provided by Service Platform in the communication infrastructure of a service component, at the time of writing a code to throw an exception in the service component, a user-defined exception is defined using SOAP fault in WSDL of the service component. If a user-defined exception occurs in the service component, that error can be caught once in the business process.

The service requester can catch the SOAP fault returned by the HCSC server using the CSCMsgServerFaultException^# object. You can acquire name of the exception or information of the fault (error details), which occurred using getter of the exception object, which is caught. It becomes easier to determine the exception, which occurs in the service requester by defining the fault name in the business process. For details on CSCMsgServerFaultException^#, see "8.3.8 Acquiring error information" in "Service Platform Basic Development Guide".

Note#

For SOAP1.2, the exception will be CSCMsgServerFault12Exception.

When an error other than the user-defined exception is returned from a service component (when you use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error other than the user-defined exception is returned from the service component and a business process is used:

Figure 7‒42:  Method of notifying an error in SOAP communication (when you use a business process) when an error of user-defined exception is returned from a service component

When you are using SOAP Communication Infrastructure or JAX-WS engine provided by Service Platform in the communication infrastructure of a service component, if an unexpected exception (system exception), which is not defined in WSDL occurs in the service component, , the SOAP message is notified as RuntimeException. Moreover, if you use JAX-WS engine in the communication infrastructure of the service component or if you do not use SOAP communication infrastructure provided by Service Platform, even if you define SOAP fault in WSDL, it is handled as an exception in the HCSC server.

The system exception, which occurs when a service component is invoked from the service adapter, can be transformed into a fault message in the service adapter.

When you do not transform an exception into a fault message, process it as an exception in the business process and throw this exception into a standard reception. When you transform an exception into a fault message, it can be caught as a fault in the business process. For details on how to transform a system exception into a fault message, "7.11 Handling of an exception that occurs in the service adapter".

The service requester can catch the SOAP fault returned by the HCSC server using the CSCMsgServerFaultException^# object. You can acquire information of the fault, which occurred (error details) using getter of the exception object, which is caught. For details on CSCMsgServerFaultException^#, see "8.3.8 Acquiring error information" in "Service Platform Basic Development Guide".

When you want to notify the SOAP fault returned by a service component as is instead of an exception in the HCSC server, define it in SOAP Fault operation definition file. For details on SOAP Fault operation definition file, see "6.6.1 SOAP fault operation definition file" in "Service Platform Reference Guide".

Note#

For SOAP1.2, the exception will be CSCMsgServerFault12Exception.

When an error is returned from the HCSC server (when you use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error is returned from the HCSC server and a business process is used:

Figure 7‒43:  Method of notifying an error in SOAP communication (when you do not use a business process) when an error is returned from the HCSC server

The following cases correspond to each of the errors shown in the figure:

• Error 1: Invalid request parameter, invalid specified character code, various invalid formats

• Error 2: Address (location) is not found, the service adapter is stopped

• Error 3: A failure occurs in data transformation

• Error 4: Invalid address, stopping of a service component, communication failure

• Error 5: An exception error during processing of the business process

When any one of the errors from error 1 to error 3 and error 5 is detected in the HCSC server, the exception of the error, which occurred, is returned to the service requester. If error 4 shown in the figure is detected, you can select whether to return the exception of error occurred as is to the service requester or whether to transform the exception of error into fault message in service adapter. For details on how to select the error to be acquired when an exception occurs, see "7.11 Handling of an exception that occurs in the service adapter".

The service requester can catch the SOAP fault returned by the HCSC server using the CSCMsgServerFaultException^# object. You can acquire information of the fault, which occurred (error details) using getter of the exception object, which is caught. For details on CSCMsgServerFaultException^#, see "8.3.8 Acquiring error information" in "Service Platform Basic Development Guide".

Note#

For SOAP1.2, the exception will be CSCMsgServerFault12Exception.

When an error is detected in the service requester

The following figure shows the method of notifying an error in SOAP communication, when an error is detected in the service requester:

Figure 7‒44:  Method of notifying an error in SOAP communication when an error is detected in the service requester (for standard reception)

SOAP Communication Infrastructure or JAX-WS engine of the service requester (client side) returns an error in cases such as when the HCSC server is not invoked from the service requester or though invocation of the service component is completed, due to some reason, response was not returned from the HCSC server to the service requester.

When you are using SOAP Communication Infrastructure provided by Service Platform in the communication infrastructure of the service requester, the exception can be caught using the C4Fault object. Information of the fault, which occurred (error details) can be acquired using getter of the exception object, which is caught. For details on C4Fault, see "13.2 C4Fault class (Retaining SOAP Fault information) " in "Application Server SOAP Application Development Guide".

When you use JAX-WS engine in the communication infrastructure of the service requester, an exception can be caught in the SOAPFaultException object. Moreover, when you do not use SOAP Communication Infrastructure provided by Service Platform, catching of an exception depends on implementation of respective communication infrastructure.

(b) For user-defined reception

The method of notifying an error differs according to error types and existence of the business process.

When an error of the user-defined exception is returned from a service component (when you use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error of the user-defined exception is returned from a service component and a business process is used:

Figure 7‒45:  Method of notifying an error in SOAP communication when an error of the user-defined exception is returned from a service component (when you use a business process)

When you are using SOAP Communication Infrastructure or JAX-WS engine provided by Service Platform in the communication infrastructure of a service component and you are writing a code for throwing an exception in a service component, a user-defined exception is defined in WSDL of a service component. If a user-defined exception occurs in the service component, that error can be caught once in the business process.

The service requester uses WSDL defined in the user-defined reception. However, the fault returned from a business process can be caught as the SOAP fault of user-defined exception even in the service requester by defining this fault in WSDL. With this, the fault can be caught with name and format same as the SOAP fault returned by a service component even in the service requester.

You must create the information required for analyzing the exception object which is caught using the program of a service component. Note that it becomes easier to determine the exception, which occurs in the service requester by defining the fault name in the business process.

For details on how to acquire the error information using the service requester that sends a request to SOAP reception, "8.7.6 Acquiring error information" in "Service Platform Basic Development Guide".

When an error other than the user-defined exception is returned from a service component (when you use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error other than user-defined exception is returned from a service component and a business process is used:

Figure 7‒46:  Method of notifying an error in SOAP communication when an error other than user-defined exception is returned from a service component (when you use a business process)

When you are using SOAP Communication Infrastructure provided by Service Platform in the communication infrastructure of a service component, if an unexpected exception (system exception), which is not defined in WSDL, occurs in the service component, the SOAP message is notified as RuntimeException. Moreover, if you use JAX-WS engine in the communication infrastructure of the service component or if you do not use SOAP Communication Infrastructure provided by Service Platform, even if you define SOAP fault in WSDL, it is handled as an exception in the HCSC server.

The system exception, which occurs when a service component is invoked from the service adapter, can be transformed into a fault message in the service adapter.

When you do not transform an exception into a fault message, process it as an exception in the business process and throw this exception into the user-defined reception. When you transform an exception into a fault message, it can be caught as a fault in the business process. For details on how to transform a system exception into a fault message, see "7.11 Handling of an exception that occurs in the service adapter".

The HCSC server returns SOAP fault of CSCMsgServerFaultException to the service requester. However, WSDL used by the service requester is defined in the user-defined reception. CSCMsgServerFaultException is not defined in this WSDL. Therefore, when you are using SOAP Communication Infrastructure provided by Service Platform in the communication infrastructure of the service requester, an exception can be caught using the C4Fault object. Information of the fault, which occurred (error details) can be acquired using getter of the exception object, which is caught. For details on C4Fault, see, "13.2 C4Fault class (Retaining SOAP Fault information) " in "Application Server SOAP Application Development Guide".

When you use JAX-WS engine in the communication infrastructure of the service requester, an exception can be caught using the SOAPFaultException object. Moreover, when you do not use SOAP Communication Infrastructure provided by Service Platform, catching of an exception depends on the implementation of respective communication infrastructure.

When you want to notify the SOAP fault returned by a service component as is instead of an exception in the HCSC server and catch a fault in the business process, define it in SOAP Fault operation definition file. For details on SOAP Fault operation definition file, see "6.6.1 SOAP fault operation definition file" in "Service Platform Reference Guide".

When an error is returned from the HCSC server (when you use a business process)

The following figure shows the method of notifying an error in SOAP communication, when an error is returned from the HCSC server and a business process is used:

Figure 7‒47:  Method of notifying an error in SOAP communication (when you do not use a business process) when an error is returned from the HCSC server

The following cases correspond to each of the errors shown in the figure:

• Error 1: Invalid specified character code, various invalid formats

• Error 2: Address (location) is not found, the service adapter is stopped

• Error 3: A failure occurs in data transformation

• Error 4: Invalid address, stopping of a service component, communication failure

• Error 5: An exception error during processing of the business process

When any one of the errors from error 1 to error 3 and error 5 is detected in the HCSC server, the exception of the error, which occurred, is returned to the service requester. If error 4 shown in the figure is detected, you can select whether to return the exception of the error occurred as is to the service requester or whether to transform the exception of the error into a fault message in the service adapter. For details on how to select the error to be acquired when an exception occurs, see "7.11 Handling of an exception that occurs in the service adapter".

The HCSC server returns SOAP fault of CSCMsgServerFaultException to the service requester. However, WSDL used by the service requester is defined in the user-defined reception. CSCMsgServerFaultException is not defined in this WSDL. Therefore, when you are using SOAP Communication Infrastructure provided by Service Platform in the communication infrastructure of the service requester, an exception is to be caught using the C4Fault object. Information of the fault, which occurred (error details) can be acquired using getter of the exception object, which is caught. For details on C4Fault, see "13.2 C4Fault class (Retaining SOAP Fault information) " in "Application Server SOAP Application Development Guide".

When you use JAX-WS engine in the communication infrastructure of the service requester, an exception can be caught using the SOAPFaultException object. Moreover, when you do not use SOAP Communication Infrastructure provided by Service Platform, catching of an exception depends on the implementation of respective communication infrastructure.

When an error is detected in the service requester

The following figure shows the method of notifying an error in SOAP communication, when an error is detected in the service requester:

Figure 7‒48: Method of notifying an error in SOAP communication when an error is detected in the service requester (for user-defined reception)

SOAP Communication Infrastructure or JAX-WS engine of the service requester (client side) returns an error in cases such as when the HCSC server cannot be invoked from the service requester due to reasons such as invalid address, stopping of the HCSC server, and communication failure or though invocation of the service component is completed, due to some reason, response is not returned from the HCSC server to the service requester.

When you are using SOAP Communication Infrastructure provided by Service Platform in the communication infrastructure of the service requester, the exception can be caught using the C4Fault object. Information of the fault, which occurred (error details) can be acquired using getter of the exception object, which is caught. For details on C4Fault, see "13.2 C4Fault class (Retaining SOAP Fault information) " in "Application Server SOAP Application Development Guide".

When you use JAX-WS engine in the communication infrastructure of the service requester, an exception can be caught in the SOAPFaultException object. Moreover, when you do not use SOAP Communication Infrastructure provided by Service Platform, catching of an exception depends on implementation of respective communication infrastructure.

(a) For standard reception

The following figure shows the method of determining problem areas when a service component invoked from the service requester using standard reception (Web service):

(i)When the cause of error is present in a service component (for user-defined exceptions defined in a service component)

The cause of error might be present in a service component. You can acquire the contents of SOAP Fault returned by a service component using the following methods:

<For SOAP1.1>

• getCscmsgFaultCode: Acquires FaultCode information.

• getCscmsgFaultString: Acquires FaultString information.

• getCscmsgFaultActor: Acquires FaultActor information.

• getCscmsgFaultDetail: Acquires FaultDetail information.

<For SOAP1.2>

• getCscmsgFaultCode: Acquires Code information.

• getCscmsgFaultReason: Acquires Reason information.

• getCscmsgFaultRole: Acquires Role information.

• getCscmsgFaultNode: Acquires Node information.

• getCscmsgFaultDetail: Acquires Detail information.

Check the causes using the following view-points:

• User message requested by the service requester

• Service component machine

• Program of a service component

Decision regarding whether to resend invocation of the service component depends on the agreement between the service requester and the service component (end-to-end) through the HCSC server.

(ii)When the cause of error is present in a business process (for faults defined in a business process)

The cause of error might be present in the processing of the activity executed by a business process (In case of invoke service activity, the cause of error might be present in the service component, which is invoked).

You can acquire the contents of SOAP Fault returned by the business process or the service component using the following methods:

<For SOAP1.1>

• getCscmsgFaultCode: Acquires FaultCode information.

• getCscmsgFaultString: Acquires FaultString information.

• getCscmsgFaultActor: Acquires FaultActor information.

• getCscmsgFaultDetail: Acquires FaultDetail information.

<For SOAP1.2>

• getCscmsgFaultCode: Acquires Code information.

• getCscmsgFaultReason: Acquires Reason information.

• getCscmsgFaultRole: Acquires Role information.

• getCscmsgFaultNode: Acquires Node information.

• getCscmsgFaultDetail: Acquires Detail information.

Check the causes using the following view-points:

• User message requested by the service requester

• Service component machine

• Program of a service component

• Definition contents of a business process

Decision regarding whether to resend invocation of the service component depends on the agreement between the service requester and the service component (end-to-end) through the HCSC server.

Moreover, depending on the type of the process in which the business process is designed, you must design the system containing a service requester that determines whether to resend (re-execution of a business process).

(iii)When an error is detected in the HCSC server (When the exception name is not set)

You can acquire the error contents using the following methods. Take action according to the countermeasures for the acquired error code and error message. Refer the message log output by Service Platform as well and check it.

• getErrorMessage: Acquires the error message of the error detected in the HCSC server.

• getErrorCode: Acquires the error code of the error detected in the HCSC server.

Check the cause based on the following viewpoints:

• Contents of the argument requested from the service requester

• Settings or status of the HCSC server

• Definition contents of the service adapter

• Definition contents of the business process

• User message requested from the service requester

• Service component machine

• Program of a service component

• Network status

Moreover, the problem areas can be narrowed down by verifying whether the following processes are always executed:

1. The SOAP message is correctly output from the service adapter (client).

2. The SOAP message has reached SOAP Communication Infrastructure or JAX-WS engine of the service component machine (server).

3. The message can be processed in the service component of the service component machine (server).

4. The SOAP message used as a reply from the service component of the service component machine (server) is correctly output.

5. The SOAP message used as a reply from the service component of the service component machine (server) has reached SOAP Communication Infrastructure or JAX-WS engine of the service adapter (client).

Refer the failure information output by SOAP Communication Infrastructure or JAX-WS engine at the time of verification. For details on how to acquire the failure information, see "7.3.3(3) How to acquire the failure information output by SOAP Communication Infrastructure or JAX-WS engine".

For the format of the failure information output by SOAP Communication Infrastructure, see "14. Troubleshooting" in "Application Server SOAP Application Development Guide". For the format of the failure information output by JAX-WS engine, see "39. Troubleshooting" in "Application Server Web Service Development Guide".

You can verify the message data sent and received between the service adapter and the service component by acquiring the application log output by SOAP Communication Infrastructure or JAX-WS engine.

Decision regarding whether to resend invocation of the service component differs as per the error contents. In case of temporary failure, you might succeed by trying to resend. However, in case of the following errors, even if you try to resend, an error occurs:

• If the contents of the argument requested from the service requester are incorrect

• If the settings of the HCSC server are incorrect

• If the definition of a service adapter and a business process is incorrect

• If the user message requested from the service requester is incorrect

(iv)When an error is detected in the communication infrastructure(for C4Fault)

You can acquire the error contents from C4Fault provided by SOAP Communication Infrastructure. Take action according the countermeasures for the acquired error codes and error messages.

For details on C4Fault, see "13.2 C4Fault class (Retaining SOAP Fault information) " in "Application Server SOAP Application Development Guide".

Check the cause based on the following viewpoints:

• WSDL used in the service requester

• Settings or status of SOAP Communication Infrastructure of the service requester machine

• Settings or status of the HCSC server

• Network status

Moreover, the problem areas can be narrowed down by verifying whether the following processes are always executed:

1. The SOAP message is correctly output from the service adapter (client).

2. The SOAP message has reached SOAP Communication Infrastructure of the HCSC server machine (server).

3. The SOAP message used as a reply from the service component of the HCSC server machine (server) is correctly output.

4. The SOAP message used as a reply from the service component of the HCSC server machine (server) has reached SOAP Communication Infrastructure of the service adapter (client).

Refer the failure information output by SOAP Communication Infrastructure at the time of verification. For details on how to acquire the failure information, see "7.3.3(3) How to acquire the failure information output by SOAP Communication Infrastructure or JAX-WS engine".

For the format of the failure information output by SOAP Communication Infrastructure, see "14. Troubleshooting" in "Application Server SOAP Application Development Guide"

You can verify the message data sent and received between the service requester and the HCSC server by acquiring the application log output by SOAP Communication Infrastructure.

Decision regarding whether to resend invocation of the service component differs as per the error contents. In case of temporary failure, you might succeed by trying to resend. However, in case of the following errors, even if you try to resend, an error occurs:

• If WSDL used in the service requester is incorrect.

• Settings of SOAP Communication Infrastructure of the service requester machine are incorrect

• Settings of the HCSC server are incorrect

(b) For user-defined reception

The following figure shows the method of determining problem areas when a service component invoked from the service requester using SOAP reception:

(i) When the cause of error is present in a service component (for exceptions other than user-defined exceptions defined in a service component)

The cause of error might be present in a service component. The error information consists of the contents defined in the service component. (You must create the information required for analyzing the exception object, which is caught in the program of the service component).

Check the cause based on the following viewpoints:

• User message requested from the service requester

• Service component machine

• Program of the service component

Decision regarding whether to resend invocation of the service component depends on the agreement between the service requester and the service component (end-to-end) through the HCSC server.

(ii) When the cause of error is present in a business process (for faults defined in a business process)

The cause of error might be present in the processing of the activity executed by a business process (In case of invoke service activity, the cause of error might be present in the service component, which is invoked).

The error information will consists of contents of the fault defined in the business process (You must set the information required for analyzing the exception object, which is caught at the time of defining the business process).

Check the cause based on the following viewpoints:

• User message requested from the service requester

• Service component machine

• Program of the service component

• Definition contents of the business process

Decision regarding whether to resend invocation of the service component depends on the agreement between the service requester and the service component (end-to-end) through the HCSC server.

Moreover, you must design the system that determines whether to resend (re-execution of a business process) depending on the design contents of the business process.

(iii)When an error is detected in the HCSC server (for CSCMsgServerFaultException)

You can acquire the error contents from C4Fault provided by SOAP Communication Infrastructure. Take action according to the countermeasures for the acquired error code and error message. For the implementation method to be used when acquiring the error information from C4Fault in the service requester, see "8.7.6 Acquring Error Information" in "Service Platform Basic Development Guide". For details on C4Fault, see "13.2 C4Fault class (Retaining SOAP Fault information) " in "Application Server SOAP Application Development Guide". Refer the message log output by Service Platform as well and check it.

Check the cause based on the following viewpoints:

• Contents of the argument requested by the service requester

• Settings or status of the HCSC server

• Definition contents of the service adapter

• Definition contents of the business process

• User message requested from the service requester

• Service component machine

• Program of the service component

• Network status

Moreover, the problem areas can be narrowed down by verifying whether the following processes are always executed:

1. The SOAP message is correctly output from the service adapter (client).

2. The SOAP message has reached SOAP Communication Infrastructure of the service component machine (server).

3. The message can be processed in the service component of the service component machine (server).

4. The SOAP message used as a reply from the service component of the service component machine (server) is correctly output.

5. The SOAP message used as a reply from the service component of the service component machine (server) has reached SOAP Communication Infrastructure of the service adapter (client).

Refer the failure information output by SOAP Communication Infrastructure at the time of verification. For details on how to acquire the failure information, see "7.3.3(3) How to acquire the failure information output by SOAP Communication Infrastructure or JAX-WS engine".

For the format of the failure information output by SOAP Communication Infrastructure, see "14. Troubleshooting" in "Application Server SOAP Application Development Guide".

You can verify the message data sent and received between the service adapter and the service component by acquiring the application log output by SOAP Communication Infrastructure. Decision regarding whether to resend invocation of the service component differs as per the error contents. In case of temporary failure, you might succeed by trying to resend. However, in case of the following errors, even if you try to resend, an error occurs:

• If the contents of the argument requested from the service requester are incorrect

• If the settings of the HCSC server are incorrect

• If the definition of a service adapter and a business process is incorrect

• If the user message requested from the service requester is incorrect

(iv)When an error is detected in the communication infrastructure (in cases other than (i) to (iii))

You can acquire the error contents from C4Fault provided by SOAP Communication Infrastructure. Take action according to the countermeasures for the acquired error code and error message.

For the implementation method to be used when acquiring the error information from C4Fault in the service requester, see "8.7.6 Acquiring Error Information" in "Service Platform Basic Development Guide". For details on C4Fault, see "13.2 C4Fault class (Retaining SOAP Fault information) " in "Application Server SOAP Application Development Guide". Refer the message log output by Service Platform as well and check it.

Check the cause based on the following viewpoints:

• WSDL used in the service requester

• Settings or status of SOAP Communication Infrastructure of the service requester machine

• Settings or status of the HCSC server

• Network status

Moreover, the problem areas can be narrowed down by verifying whether the following processes are always executed:

1. The SOAP message is correctly output from the service requester (client).

2. The SOAP message has reached SOAP Communication Infrastructure of the HCSC server machine (server).

3. The SOAP message used as a reply from the service component of the HCSC server machine (server) is correctly output.

4. The SOAP message used as a reply from the service component of the HCSC server machine (server) has reached SOAP Communication Infrastructure of the service requester (client).

Refer the failure information output by SOAP Communication Infrastructure at the time of verification. For details on how to acquire the failure information, see "7.3.3(3) How to acquire the failure information output by SOAP Communication Infrastructure or JAX-WS engine".

For the format of the failure information output by SOAP Communication Infrastructure, see "14. Troubleshooting" in "Application Server SOAP Application Development Guide".

You can verify the message data sent and received between the service requester and the HCSC server by acquiring the application log output by SOAP Communication Infrastructure. Decision regarding whether to resend invocation of the service component differs as per the error contents. In case of temporary failure, you might succeed by trying to resend. However, in case of the following errors, even if you try to resend, an error occurs:

• If WSDL used in the service requester is incorrect

• If settings of SOAP Communication Infrastructure of the service requester machine are incorrect

• If the settings of the HCSC server are incorrect

(a) For SOAP1.1

The following table describes the correspondence between the elements of SOAP fault and information set up at the time of error, when SOAP1.1 is in use:

The error case numbers are same as the numbers indicated in "7.7.1(2) Method of determining problem areas".

(b) For SOAP1.2

The following table describes the correspondence between the elements of SOAP Fault and information set up at the time of error, when SOAP1.2 is in use:

The error case numbers are same as the numbers indicated in "7.7.1(2) Method of determining problem areas".

(a) Method of following the client correlation ID specified from the service requester

The procedure followed from the client correlation ID specified from the service requester is as follows:

1. Check the client correlation ID.

   The client correlation ID is the information set at the time of request (at the time of invocation) in the program of the service requester, which requests for invocation of the service component. Use this ID to map request messages from the service requester with log and trace managed in the HCSC server. Therefore, it is recommended that you specify a different ID for each request sent to the HCSC server (You must specify it when creating a service requester).

   In case of tracking the execution history of the invocation request of the service component, when a request for failure investigation is made to the system administrator from the requester at service requester side, the client correlation ID is to be notified. Based on that information, the system administrator tracks the execution history.

   An example of coding that specifies the client correlation ID in the service requester is described here. The client correlation ID ("ClientID0001") is set in the argument when invoking the standard reception (Web service).

   

2. Check the request trace based on the client correlation ID and acquire the message common ID used when an error occurred. You can identify the instance of the business process in which a failure occurred according to the message common ID.

   The client correlation ID might be duplicated. Therefore, identify the corresponding locations by acquiring appropriate execution time and name of the business process (service name).

   An example of request trace is as follows. The client correlation ID and the business process name (service name) are present in the "message" raw of the request trace. The message common ID is output at first.

   

3. Based on the acquired message common ID, acquire the process ID of the business process by referring execution history of the process instance. Use search command of the process instance (cscpiselect) to acquire the process ID.

   In the cscpiselect command, search for the execution history of the process instance using start time and business process name (service name) in the condition.

   Moreover, specify "relation" in the -table option, specify SQL condition in the search condition (where clause), and display the corresponding message related information.

   

   For details on how to use the cscpiselect command, see "6.1.2 Searching the execution log of a process instance". For the syntax of the command, see "cscpiselect (Finding process instances)" in "Service Platform Reference Guide".

4. Based on the acquired process ID, acquire the activity of the business process and its status by referring execution history of the process instance. Use search command of the process instance (cscpiselect) to acquire the information of an activity.

   In the cscpiselect command, search for the execution history of the process instance using start time and business process name (service name) in the condition.

   Moreover, specify "activity" in the -table option, specify SQL condition in the search condition (where clause), and display the corresponding activity information.

   The location whose status is "Executing" is an activity which is currently being executed. You can understand which activity has stopped by checking the status.

   

   For details on how to use the cscpiselect command, see "6.1.2 Searching the execution log of a process instance". For the syntax of the command, see "cscpiselect (Finding process instances)" in "Service Platform Reference Guide".

5. When the option to extract the user message trace is set, you can check the contents of the user message.

   In the user message trace, search for the user message based on the message common ID (You can search even from the client correlation ID or time). For the output destination and output contents of the user message trace, see "7.4.4 User message trace".

   Specify settings regarding extraction of the user message trace in the HCSC server runtime definition file. For details, see "6.5.6 HCSC server runtime definition file" in "Service Platform Reference Guide".

(b) Method of following from the business process correlation set specified in the user message

The procedure for following from the business process correlation set specified in the user message is as follows:

1. Check the correlation set.

   The correlation set is the information to be set in the user message at the time of request in the program of the service requester, which requests for invocation of the service component. It is a string used for uniquely identifying a request message to be sent to a service component from the service requester through the HCSC server.

   As a response from the HCSC server, a response message containing the correlation set is to be sent to the service requester. As a result, the service requester can uniquely identify the mapping between the request messages and the received response messages.

   To use a correlation set, you must define it at the time of defining a business process in the development environment. For details, see "5.5.2 Defining Correlation Sets" in "Service Platform Basic Development Guide".

   In case of tracking the execution history of the invocation request of the service component, when a request for failure investigation is made to the system administrator from the requester at service requester side, the correlation set and name of the requested business process (service name) is to be notified. Based on that information, the system administrator tracks the execution history.

   Important note

   If the user of the service requester does not capture the value of the correlation set, the repository imported in the HCSC server must be referred in the development environment and the correlation set of the corresponding business process must be checked. Method of checking the correlation set is as follows:

   1. Double-click the [Variables and correlation sets] icon of the business process definition screen.

      A dialog containing list of variables and correlation sets is displayed.

   2. Click the "View" button of the dialog containing list of variables and correlation sets.

      View variables dialog is displayed.

   3. Check the user message against XML schema of View variables dialog and acquire the path to the correlation set.

   4. Acquire variable names and part names from the path name using List of variables and correlation sets dialog. Search for correlation set having same variable name and part name from the List of variables and correlation sets dialog and acquire name of the correlation set.

2. Based on the acquired correlation set, refer the execution history of the process instance and acquire the process ID of the business process. To acquire the process ID, use search command (cscpiselect) of the process instance.

   In the cscpiselect command, consider the correlation set as a condition and search for the execution history of the process instance.

   Moreover, specify "process_set" in the -table option. Specify SQL condition in the search condition (where clause) and display overview of the corresponding process.

   

   For details on how to use the cscpiselect command, see "6.1.2 Searching the execution log of a process instance". For the syntax of the command, see "cscpiselect (Finding process instances)" in "Service Platform Reference Guide".

3. Based on the acquired process ID, acquire the activity of the business process and its status by referring execution history of the process instance. Use search command of the process instance (cscpiselect) to acquire the information of an activity.

   In the cscpiselect command, search for the execution history of the process instance using start time and business process name (service name) in the condition.

   Moreover, specify "activity" in the -table option and display the corresponding activity information in the search condition.

   The location whose status is "Executing" is an activity which is currently being executed. You can understand which activity has stopped by checking the status.

   

   For details on how to use the cscpiselect command, see "6.1.2 Searching the execution log of a process instance". For the syntax of the command, see "cscpiselect (Finding process instances)" in "Service Platform Reference Guide".