7.7.3 Troubleshooting when executing MDB (WS-R)

(1) Method of notifying an error in MDB (WS-R)

In the service component invocation of MDB (WS-R), the error which occurs between the service requester and the HCSC server, and the HCSC server and the service component is not notified. The types of failure that can be detected, output destination of logs and traces is described here.

When the error of user-defined exception is occurred in a service component

The following figure shows the method of notifying an error in MDB (WS-R) when an error of the user-defined exception occurs in a service component:

Figure 7‒62:  Method of notifying an error in MDB (WS-R) when an error of the user-defined exception occurs in a service component

The exception which occurred in the service component processes error in Reliable Messaging on the service component machine. Reliable Messaging on the service component machine outputs a message indicating the failure of fetching message from the local queue to the log on the service component machine.

Further, for user-defined exception (Application exception), whether to fetch message in the service component by again performing rollback depends on settings of Reliable Messaging at the service component machine end or creation of the service component program.

When you perform rollback in message fetching on the service component machine and frequency of rollback (frequency of message delivery) reaches the maximum value or when the message reaches to its expiry date, that message moves to the dead message queue. However, message is deleted in following cases:

• When settings for the dead message queue are not performed

• When "Unlimited" is set in delivery frequency

• When number of messages in the dead message queue are in excess

• When failure occurs in database

For details on Reliable Messaging, see "Reliable Messaging".

When an error other than the user-defined exception occurs in the service component

The following figure shows the method of notifying an error in MDB (WS-R) when an error other than the user-defined exception occurs in a service component:

Figure 7‒63:  Method of notifying an error in MDB (WS-R) when an error other than the user-defined exception occurs in service component

The exception which occurred in the service component processes the error in Reliable Messaging on the service component machine. Reliable Messaging outputs a message indicating failure in message fetching from local queue in the log on the service component machine.

Furthermore, for system exception, perform rollback at the service component end and again try fetching message in Service component.

When you perform rollback in message fetching on the service component machine and rollback frequency (message delivery frequency) reaches the maximum value or when message reaches to its expiry date, the message moves to the dead message queue. However, the message is deleted in following cases:

• When settings for the dead message queue are not performed.

• When "Unlimited" is set in delivery frequency

• When number of messages in the dead message queue are in excess.

• When a failure occurs in database.

For details on Reliable Messaging, see "Reliable Messaging".

When error occurs in transfer from the HCSC server machine to the service component machine

The following figure shows the method of notifying an error in MDB (WS-R) when error occurs in transfer from HCSC server machine to the service component machine:

Figure 7‒64:  Method of notifying an error in MDB (WS-R) when an error occurs in transfer from HCSC server machine to the service component machine

When message transfer from the HCSC server machine to the service component machine fails, error processing is to be performed in Reliable Messaging at the HCSC server end. Reliable Messaging outputs a message indicating the failure which has occurred in the message transfer to the log on the HCSC server machine.

Furthermore, when you detect an error in message transfer, perform rollback at the HCSC server end, and try to perform transfer again.

When you perform rollback in transfer from the HCSC server and rollback frequency (frequency of message delivery) reaches a maximum value or when "Unlimited" is set in delivery frequency, that message moves to the dead message queue. When the dead message queue name is not set or when the dead message queue is not created, the process of invoking the service component is re-executed without any limit. Therefore, you must set the dead message queue name or the dead message queue without fail.

For details on the setup of Reliable Messaging, see "3.1.2 Setting up the software required for the execution environment". For details on operations performed when the transfer between Reliable message queues fails, see "2.4.7 Operation when failure occurs in transfer between queues" in "Reliable Messaging".

When an error occurs from HCSC server

The following figure shows the method of notifying an error in MDB (WS-R) when an error occurs from HCSC server:

Figure 7‒65:  Method of notifying an error in MDB (WS-R) when an error occurs from HCSC server

The errors shown in Figure 7-65 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: Failure in message sending

When any of Error 1~Error 3 shown in figure are detected in the HCSC server, the error processing is performed in Reliable Messaging on the HCSC server machine. When Error 4 shown in the above Figure is detected, you can select whether to throw an exception of the error to the standard reception as-is or to transform the exception of 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 Handling of an exception that occurs in the service adapter".

Messages of error which have occurred are output to the message log. Reliable Messaging outputs the message indicating the failure in message fetching from the local queue to a log on the HCSC server machine.

Further, when an error is detected in the HCSC server, perform rollback at the HCSC server end and again try to fetch messages in the service component (invoking service component). When you perform rollback in message fetching on the HCSC server machine, and when frequency of rollback (frequency of message delivery) reaches the maximum value, that message moves to the dead message queue.

When the dead message queue name is not set or when the dead message queue is not created, the process of invoking the service component is re-executed without any limit. Therefore, you must set the dead message queue name or the dead message queue.

For details on setup of Reliable Messaging, see "3.1.2 Setting up the software required for the execution environment".

For details on Reliable Messaging, see "Reliable Messaging".

When an error occurs in the transfer between the service requester machine and the HCSC server machine.

The following figure shows the method of notifying an error in MDB (WS-R) when an error occurs in the transfer between the service requester machine and the HCSC server machine:

Figure 7‒66:  Method of notifying an error in MDB (WS-R) when an error occurs in the transfer between the service requester machine and the HCSC server machine

When message transfer between the service requester machine and the HCSC server machine fails, error processing is performed in Reliable Messaging at the service requester end. Reliable Messaging outputs a message indicating the failure in message transfer to a log on the service requester machine.

Furthermore, when an error is detected in message transfer, perform rollback at the service requester end and try to transfer the message one more time.

When you perform rollback in transfer from the service requester machine and frequency of rollback (frequency of message delivery) reaches the maximum value or when message reaches to its expiry date, that message moves to the dead message queue. However, the message is deleted in following cases:

• When settings for the dead message queue are not performed.

• When "Unlimited" is set in delivery frequency

• When number of messages in the dead message queue are in excess.

• When failure occurs in database.

For details on the operations performed when transfer between Reliable Messaging queues fails, see "2.4.7 Operation when failure occurs in transfer between queues" in "Reliable Messaging".

When an error is detected in the service requester

The following figure shows the method of notifying an error in MDB (WS-R) when an error is detected in the service requester:

Figure 7‒67:  Method of notifying an error in MDB (WS-R) when an error is detected in the service requester

When you cannot send a message from the service requester to the transfer queue, exception (JMSException) is thrown to the service requester. The service requester catches the exception. You can acquire details of the error by using getter of the caught exception object. When message sending from service requester machine fails, message does not move to the dead message queue. For details on Reliable Messaging and JMS, see"Reliable Messaging".

When the synchronous service component is invoked and an error of the user-defined exception occurs

The following figure shows the method of notifying an error in MDB (WS-R) when the synchronous service component is invoked, and an error of the user-defined exception occurs:

Figure 7‒68:  Method of notifying error in MDB (WS-R) when the synchronous service component is invoked and an error of the user-defined exception occurs

Specify a queue for response when the service component is invoked for asynchronous standard reception (MDB (WS-R). The service component of synchronous SOAP adapter is invoked from asynchronous (MDB (WS-R). If a user-defined exception occurs at the service component end, the message of error information is sent to the queue for response (Transfer queue).

If you specify the destination of the transfer queue in the local queue at the service requester end, you can acquire contents of error by fetching the message from the destination of the transfer queue.

You must create a queue (Transfer queue) for response beforehand, but when there are no settings of the queue for sending a response, or when the number of messages in queue for response are in excess and sending to the queue fails, rollback the process within the HCSC server and message is resent from the local queue of standard reception (Rollback is not performed for process (Transaction) at the service component end).

When frequency of rollback (frequency of message delivery) reaches the maximum value that message moves to the dead message queue. When the dead message queue name is not set or when the dead message queue is not created, the process of invoking the service component is re-executed without any limit. Therefore, you must set the dead message queue name or the dead message queue.

To Page Top

(2) Method of determining a problem area

This section describes method of determining the problem area when the service component is invoked using standard reception (MDB (WS-R) from the service requester. The following figure shows the method of determining the problem area:

Figure 7‒69:  Method of determining a problem area (when the service component is invoked)

(i) When an error occurs in the service component machine

Investigate the failure by referencing the failure information output by Reliable Messaging at the service component machine end. Reference the user log of the J2EE server when error information is output to service component program.

Investigate the cause from the following perspective:

• User message requested from the service requester

• Service component machine

• Settings of Reliable Messaging of service component

• Service component program

(ii) When an error occurs in the HCSC server machine

Investigate the fault by referencing the failure information output by Reliable Messaging and message log at the HCSC server machine end.

Investigate the cause from the following perspective:

• Contents of argument requested from the service requester

• Settings and status of HCSC server

• Settings of Realizable Messaging of HCSC server

• Definition contents of service adapter

• Definition contents of business process

• User message requested from the service requester

• Status of network

(iii) When an error occurs in the service requester machine

You can acquire contents of error from exception caught by the service requester. Take action on the basis of the error information of acquired exception. Investigate the fault by referencing the error information output by Reliable Messaging at the service requester machine end.

Investigate the cause from the following perspective:

• Settings and status of J2EE container of the service requester

• Settings of Reliable Messaging of the service requester machine

• Status of network

To Page Top

(3) Method of identifying other causes of failure (tracking execution history of the invocation request of service component)

You can track the progress of the service component invocation process on the basis of information identified from the service requester and information from the HCSC server. The information (ID) necessary to track execution history is described here.

To Page Top