This section describes the method of notifying an error which occurs when you invoke the service component using the standard reception from the service requester. Note that the method of notifying an error differs according to the error or existence of a business process.

When an error of 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 SessionBean communication, when an error of the user-defined exception is returned from the service component and a business process is not used:

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

The exception which occurred in the service component is notified as-is to the HCSC server. The HCSC server that has caught the exception throws CSCMsgServerException to the service requester. You can acquire the name or contents of the exception (details of error) by using getter of the caught exception object. For details on CSCMsgServerException, see "8.4.7 Acquiring Error Information" in "Service Platform Basic Development Guide".

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

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

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

When an unexpected exception occurs in the service component, it is notified as-is to the HCSC server as RuntimeException (System exception).

You can also transform the system exception which occurred when the service component is invoked from the service adapter to a fault message in the service adapter. For details on how to transform the system exception to a fault message, see "7.11 Selecting the errors to be acquired when an exception occurs".

The HCSC server that has caught the exception throws CSCMsgServerException to the service requester. You can acquire contents of the exception (Details of error) by using getter of the caught exception object. For details on CSCMsgServerException, see "8.4.7 Acquiring Error Information " in "Service Platform Basic Development Guide".

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 SessionBean communication, when an error is returned from the HCSC server and a business process is not used:

Figure 7-46 Figure Method of notifying an error in SessionBean communication, when an error is returned from the HCSC server (when you do not use a business process)

The errors shown in figure 7-46 are as follows:

• Error 1:Invalid request parameter
• Error 2: Address (Location) not found, service adapter has stopped
• Error 3:Data transformation failed
• Error 4:Invalid address, service component has stopped, Communication failure

When any of Error 1~ Error 3 shown in the figure are detected in the HCSC server, the error information is thrown to the service requester as CSCMsgServerException. When Error 4 shown in the figure is detected, you can select whether to throw the exception of the error to the service requester as-is or to transform the error exception into a fault message in the service adapter. For details on how to select the error acquired when an exception occurs, see "7.11 Selecting the errors to be acquired when an exception occurs".

For the service requester, you can acquire the name or contents of the occurred exception (details of error) by using getter of the caught exception object For details on CSCMsgServerException, see "8.4.7Acquiring Error Information" in "Service Platform Basic Development Guide"

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

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

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

If a user-defined exception occurs in the service component, the business process will process the error in following order:

1. Error is caught in business process.
2. In the business process, the error is converted into an exception indicating the failure of the service component, and an exception is notified.
3. Business process throws CSCMsgServerException to the service requester.

You can acquire the contents of the exception (details of error) by using getter of the caught exception object. For details on CSCMsgServerException, see "8.4.7Acquiring 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 SessionBean communication, when an error other than the user-defined exception is returned from the service component and a business process is used:

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

When an unexpected exception occurs in service component, you can select whether to return the exception as-is to the service requester or to transform the exception which occurred in the service adapter into a fault message. For details on how to transform an exception into a fault message, see "7.11 Selecting the errors to be acquired when an exception occurs".

When the exception is not to be converted into a fault message, the business process processes the error in the following order:

1. Error is caught in business process.
2. In the business process, the error is converted into an exception indicating the failure of the service component, and an exception is notified.
   When the exception is converted into a fault message, it can be caught in business process as a fault.
   
3. Business process throws CSCMsgServerException to the service requester.

You can acquire the contents of the exception (details of error) by using getter of the caught exception object. For details on CSCMsgServerException, see "8.4.7Acquiring Error Information" in "Service Platform Basic Development 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 SessionBean communication, when an error of the user-defined exception is returned from the HCSC server, and a business process is used:

Figure 7-49 Figure Method of notifying an error in SessionBean communication when an error is returned from the HCSC server (when you use a business process)

The errors shown in figure are as follows:

• Error 1:Invalid request parameter
• Error 2: Address (Location) not found, service adapter has stopped
• Error 3:Data transformation failed
• Error 4:Invalid address, service component has stopped, Communication failure
• Error 5:Exception error in processing the business process

When any of Error 1~Error 3, and Error 5shown in figure are detected in the HCSC server, the error information is thrown to the service requester as CSCMsgServerException.

When Error 4 shown in the figure is detected, you can select whether to throw the exception of the error to the service requester as-is or to transform the exception of the error into a fault message in the service adapter.

For details on how to select the error acquired when an exception occurs , see,"7.11 Selecting the errors to be acquired when an exception occurs".

For the service requester, you can acquire the contents of the exception (details of error) by using getter of the caught exception object. For details on CSCMsgServerException, see"8.4.7Acquiring Error Information" in "Service Platform Basic Development Guide"

When an error is detected in the service requester

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

Figure 7-50 Figure Method of notifying an error in SessionBean communication when an error is detected in the service requester

When the HCSC server could not be invoked from the service requester or, when invocation of a the service component is complete but there is no response from the HCSC server to the service requester due to some reason, the stub (J2EE container) at the service requester end (client end) returns an error.

The service requester can catch an exception in RuntimeException. You can acquire the information of fault (details of error) by using getter of the caught exception object.

The method of determining an area where a problem has occurred when the service component is invoked from the service requester using standard reception (SessionBean) is described here. The following figure shows how to determine an area where the problem has occurred:

Figure 7-51 Figure Method of determining problem area (when the service component is invoked from the service requester using the standard reception (SessionBean)

When the cause of failure exists in the service component (for user-defined exception defined in the service component)

There is a possibility that the cause of failure exists in the service component. You can acquire contents of the exception returned by the service component by using the following method:

• getErrorMessage: Acquire contents of the exception from service component.
• getErrorCode: Acquire the error code corresponding to contents of the exception from service component.

Investigate the cause from the following perspective:

• User message requested from the service requester.
• Service component machine
• Service component program

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 failure exists in business process (for a fault defined in the business process)

There is a possibility that the cause of failure exists in the activity processing executed in the business process (for service invocation activity, there is a possibility that the cause of failure exists in the invoked service component). You can acquire the contents of the fault returned by the business process using the following method:

• getErrorMessage: Acquire contents of the exception from the business process.
• getErrorCode: Acquire the error code corresponding to the contents of the exception from the business process.
• getCscmsgFaultCode: Acquire FaultCode information.
• getCscmsgFaultString: Acquire FaultString information.
• getCscmsgFaultActor: Acquire FaultActor information.
• getCscmsgFaultDetail: Acquire FaultDetail information.

Investigate the cause from the following perspective:

• User message requested from the service requester
• Service component machine
• Service component program
• Definition contents of 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.

Furthermore, it is necessary to design a system which determines whether to resend (re-execution of business process) according to the design contents of the business process.

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

You can acquire the contents of the error by using the following method. Take action as per counter measures of the acquired error code and error message.

• getErrorMessage: Acquire message of the error detected within the HCSC server.
• getErrorCode: Acquire error code of the error detected within the HCSC server.

Investigate by referencing the message log output by Service platform.

Investigate the cause from the following perspective:

• Contents of the argument requested from the service requester.
• Settings or status of the HCSC server
• Definitional contents of service adapter.
• Definition contents of business process
• User message requested from the service requester
• Resending of the service component invocation differs according to the contents of the error.
• Service component machine
• Service component program
• Status of network

If resending fails temporarily, you can rectify it by trying the resend operation. However, in case of the following errors resending fails even if you try the resend operation and an error occurs:

• When there is error in the contents of the argument requested from the service requester.
• When there is an error in the settings of the HCSC server
• When there is an error in the definition of service adapter or business process
• When there is an error in the user message requested by the service requester

(iv) When error is detected in the communication board (for Runtime Exception)

You can acquire the contents of error from RuntimeException. Take action on the basis of the error information of the acquired exception.

Investigate the cause from the following perspective:

• Stub being used in the service requester
• Settings and status of J2EE container of the service requester machine
• Settings and status of the HCSC server
• Status of network

Whether to resend the invocation of the service component differs according to the contents of the error. If resending fails temporarily, you can rectify it by trying the resend operation. However, in the case of the following errors resending fails even if you try the resend operation, and an error occurs:

• When there is an error in stub being used in the service requester
• When there is an error in settings of J2EE server of the service requester machine
• When there is an error in settings of the HCSC server

This section describes the type of information to be set in a particular factor for SOAP Fault (SOAP message) returned from the HCSC server. The following table describes contents of an exception returned from the HCSC server.The error case number corresponds to the number shown in "7.7.2(2) Method of determining a problem area".

Table 7-57 Table Contents of the exception returned from the HCSC server

Fault name of CSCMsgServerException returned fromHCSC server	Error case
	For (ii)	For (i), (iii)
errorMessage	This is the content of the following errors: Error detected in the HCSC server Error from service component, business process, and service adapter#
errorCode	This is the error code corresponding to the contents of exception: Error detected in HCSC server Error from service component, business process, and service adapter#
processInstanceID	This is the information of Instance ID of business process. Value is set when an error occurs in business process.
cscmsgFaultCode	This is the FaultCode information from a service component (Web service), business process, or service adapter#	Value is not present.
cscmsgFaultString	This is the FaultString information from a service component (Web service), business process, or service adapter#	Value is not present.
cscmsgFaultActor	This is the FaultActor information from a service component (Web service), business process, or service adapter#	Value is not present.
cscmsgFaultDetail	This is the Detail information from a service component (Web service), business process, or service adapter#	Value is not present.
faultName	This is the Fault name (Exception name) information from a service component (Web service or SessionBean) or business process. Value will be set in following cases: For SOAP Fault of the user-defined exception from a service component (Web service or SessionBean) For fault from a business process	Value is not present.

#1

For (iv), throw RuntimeException from the stub of the service requester end (J2EE server).

#2

When the service component of the SOAP adapter is invoked from the standard reception (SessionBean), Fault information is set same as in (ii).

Note#

The following service adapters are out of scope:

SOAP adapter

SessionBean adapter

MDB (WS-R) adapter

MDB (DB queue) adapter

Other than the method of determining the problem area from the exception and error message returned from the service requester, this section describes how to identify the problem area based on the client correlation ID or correlation set of the business process at the service requester end. The following figure shows how to track the execution history of the invocation request of the service component:

Figure 7-52 Figure Tracking the execution history of the service component (for SessionBean)

The method of identifying or the procedure when the business process is used is same as the procedure in Web service (SOAP communication).For details, see "7.7.1 Troubleshooting when executing Web service (SOAP communication)".

The procedure applicable for SessionBean is described here:

(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.
2. Acquire the common message ID.
3. Acquire the process ID of the business process.
4. Acquire the status of activity.
5. Check user message.

For details, see "7.7.1 Troubleshooting when Web service (SOAP communication) is executed"".

You can specify the problem area in more detail by investigating again using the performance analysis trace. You can check compatibility with the log of the sevice component machine by following the thread ID of the performance analysis trace.

1. Search for the row which has a character string matching with the common message ID
   Since the common message ID is output in the "ASCII" row at the entry of the request reception of HCSC server, first it is searched there.
   
2. Check the thread ID of the row which has matched in search, follow that thread ID, and check the problem area.
   Thread ID is changed by invoking RMI-IIOP but you can understand the connection with "Root AP CommonNo" column.
   
3. The error location is a location where a value other than 0 is specified in "Rc (Return code)" column. When the error location is identified, check the processing contents before and after that location and investigate the cause of error.

When you want to investigate again, use the log of the failure information output by the J2EE server and follow the thread ID of the location where error has occurred.

The following figure shows an example of performance analysis trace:

Figure 7-53 Figure Example of performance analysis trace

The numbers in "Figure 7-53 Example of performance analysis trace" indicate the following contents:

(1)This is a row which contains character strings matching with the common message ID. You can understand the connection since common IDs are assigned.

(2)Number changes since multiple threads are covered through RMI invocation.

(3)This is thread number that has matched in the search.

(4) This is thread ID of the thread number (Number 3).

(5) This is entry of standard reception (SessionBean).

(6) This is point of invocation of the business process.

(7) This is invocation of the execution request of the business process from the messaging board.

(8) This is invocation of the data transformation request.

(9) This is a response from the data transformation request.

(10) This is invocation of the service from the business process to the messaging board.

(11) This is the entry of the business process reception.

(12) This is invocation of the service component of SessionBean adapter.

(13) This is invocation of Service component machine from the HCSC server machine.

(14) This is immediately after an EJB container request.

(15) This is just before receiving an EJB container response.

(16) Error has occurred.

In this example, in point (13) shown in "Figure 7-50 Example of performance analysis trace", you can understand that RMI of the service component is invoked and the error has occurred immediately after the EJB container has received a request (there are two extraction levels of performance analysis trace such as "Normal" and "Details", but "Figure 7-50 Example of performance analysis trace"shows trace collected at "Normal")

When Service component machine is using Application Server, you can investigate again by comparing the thread ID of the location where the error has occurred and the failure information at Service component machine end.

Note that, the thread ID of performance analysis trace has a decimal value but, since the failure information is output in hexadecimal value by the J2EE server, you must individually modify the thread ID to a hexadecimal value.

Regarding the invocation of the service component from the service adapter, thread ID is changed by invoking SessionBean, but you can understand the connection through Root AP CommonNo column. For details on how to use the performance analysis trace file, see "7.7.1 Overview of the analysis of process functionality" in "Application Server Maintenance and Migration 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 user message is as follows:

1. Check the correlation set.
2. Acquire the process ID of business process.
3. Acquire status of activity.

For details, see "7.7.1 Troubleshooting when executing Web service (SOAP communication)".