Hitachi

uCosminexus Service Platform Setup and Operation Guide


7.7.4 Troubleshooting when executing MDB (DB queue)

Organization of this subsection

(1) Method of notifying an error in MDB (DB queue)

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.

Note that, the service component cannot be invoked from asynchronous standard reception (MDB (DB queue) to the (MDB (DB queue) adapter. Therefore, a separate description is provided for the service component end for DB queue and the service requester end for DB queue.

(a) When DB queue exists at the service component end

When error occurs in service component

The error which has occurred at the service component is not notified to the HCSC server and the service requester as error information. Error information is output at the service component machine end. The following figure shows the method of notifying an error when error occurs in service component:

Figure 7‒75:  Method of notifying an error when an error occurs in the service component

[Figure]

(b) When DB queue exists at the service requester end

When an error occurs from the HCSC server

The following figure shows the method of notifying an error when an error occurs from the HCSC server:

Figure 7‒76:  Method of notifying an error when an error occurs from the HCSC server

[Figure]

The errors shown in Figure 7-76 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: Message sending failed

When any of Error 1~Error3 shown in the figure are detected in HCSC server, the error is notified to Reliable messaging on the HCSC server machine.

When Error 4 shown in figure is detected, you can select whether to notify an error to Reliable Messaging on the HCSC server machine or to transform the exception of error into a fault message in the service adapter. For details on how to select an error acquired when an exception occurs, see "7.11 Handling of an exception that occurs in the service adapter".

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

When an error is detected in the HCSC server, perform rollback at HCSC server end and again try fetching a message in the service component (invocation of service component).

When you perform rollback in message fetching on the HCSC server machine and 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, process of invoking the service component is re-executed without any limit. Therefore set the dead message queue name or when the dead message queue without fail.

Further, when the frequency of process re-execution specified in request-jms.rollback-count property of the HCSC server runtime definition file is exceeded, warning message (KDEC00049-W) is output.

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 error is detected in the service requester

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

Figure 7‒77:  Method of notifying an error when an error is detected in the service requester

[Figure]

The error occurs when the service requester performs queuing of messages in DB queue is output at the service requester machine end.

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

The following figure shows the method of notifying an error when synchronous service component is invoked and error of user-defined exception occurs:

Figure 7‒78:  Method of notifying an error when synchronous service component is invoked and error of user-defined exception occurs.

[Figure]

Specify queue for response when the service component is invoked for standard reception of asynchronous (MDB (DB queue), the service component of synchronous SOAP adapter is invoked from standard reception of asynchronous (MDB (DB queue). If user-defined exception occurs at the service component end, message of error information is sent to queue for response (Common queue for sending). If you specify destination of common queue for sending in DB queue at the service requester end, you can acquire contents of error by fetching message from there.

You must create queue for response (Common queue for sending) in advance but, when settings of queue for response are not performed or when number of messages in queue for response is in excess and sending to queue fails, perform rollback for process within the HCSC server and messages are resent from common queue for receiving standard reception. (However, rollback is not performed for process at the service component end (Transaction)).

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, 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.

(2) Method of determining the problem area

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

Figure 7‒79:  Flow of determining problem area (When the service component is invoked using standard reception (MDB (WS-R)) from the service requester)

[Figure]

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

Investigate the cause of failure from failure information which is output to the service component machine end.

Investigate the cause from the following perspective:

  • User message requested from the service requester

  • Status of the service component machine

  • Settings of the service component machine

  • Service component program

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

Investigate the cause of failure by referencing the failure information output by message logs and Reliable Messaging at the HCSC server machine end.

Investigate the cause from the following perspective:

  • Contents of binary data requested from the service requester

  • Format of binary data requested from the service requester

  • Settings and status of the HCSC server

  • Settings of Reliable Messaging of the 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

Investigate the cause of failure from failure information output to the service requester machine end.

Investigate the cause from the following perspective:

  • User message requested from the service requester

  • Status of the service requester machine

  • Settings of the service requester machine

  • The service requester program

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

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

(a) Client correlation ID

The client correlation ID is information set in program at the service requester end which performs the invocation request of service component at the time of request. This ID is used to support request message from the service requester and logs and traces managed in the HCSC server. Therefore, it is recommended to specify different ID for each request sent to the HCSC server. (You must specify the ID when creating the service requester). The following figure shows range inherited by the client correlation ID:

Figure 7‒80:  Range inherited by client correlation ID (When executing MDB (DB queue))

[Figure]

[Figure]

(b) Common message ID

This ID is assigned by HCSC server. This ID is used to identify logs or traces within HCSC server. The following figure shows range inherited by the common message ID:

Figure 7‒81:  Range inherited by the common message ID (When executing MDB (DB queue))

[Figure]

[Figure]

(c) JMSMessageID

JMSMessageID is assigned by Reliable Messaging. This ID is output to logs or traces within HCSC server. The following figure shows range inherited by JMSMessageID:

Figure 7‒82:  Range inherited by JMSMessageID (When executing MDB (DB queue))

[Figure]

[Figure]

# JMSCorrelationID or user specific information of property is not inherited.

(d) Thread ID

Thread ID is an ID assigned to each thread processed using J2EE container. The following figure shows range inherited by thread ID:

Figure 7‒83:  Range inherited by thread ID (When executing MDB (DB queue))

[Figure]

[Figure]

#

You must embed information to link to user message when linking to program at the service component end.