This section describes method of notifying an error when business process is invoked using Message Queue reception from JMS provider (WebSphere MQ).

The following figure shows the method of notifying an error when custom reception framework returns an error:

Reference note

When fault is to returned from the service component or service adapter, communication model cannot return fault from business process for asynchronous reception. Therefore, it returns an exception. The following figure shows the method of notifying an error:

Figure 7-79 Figure Method of notifying an error when custom reception framework returns an error (for reception of Message Queue)

The errors shown in figure are as follows:

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

When any of Error 1- Error 5 occurs, custom reception framework in which exceptions are caught throws CSCMsgServerException for reception process of Message Queue reception. For details on CSCMsgServerException see "Appendix A.3 APIs of the custom reception framework" in "Service Platform Reception and Adapter Definition Guide".

In reception process of Message Queue reception, exception log is output on the basis of caught exceptions, respond normally to MQ resourse adapter after executing EJBContext#setRollbackOnly.

In MQ resourse adapter, normal response is returned as is for queue manager of JMS provider (WebSphere MQ).

The queue manager of JMS provider (WebSphere MQ) rolls back the transaction and resets the message at the beginning of the queue.

Note

When frequency of rollback increases due to settings of rollback frequency limit value, message is moved to dead letter queue. The maximum number of times rollback can be performed is described in detail in the manual uCosminexus BPM/ESB Service Platform Overview. See the description of the setting for the number of times a message can be rolled back in 2.10.1 Invoking service components using Message Queue reception in that manual.

When operation fails, the required troubleshooting information is output to log file as log, and to the trace file as trace.

This section describes how to acquire message log and each type of trace.

(a) Message log (Message Queue reception)

In the activity log of the J2EE server of message log, each type of information occurred in Message Queue reception is output as message.

For details on output contents or output destination of message log, see "7.4.1 Message log".

(b) Request trace (Message Queue reception)

Reuquest trace is used to analyze cause of failure occurred in request.

Output of request trace is not from Message Queue reception but from custom reception framework

(c) Performance analysis trace (Message Queue reception)

This section describes performance analysis trace (PRF trace) in Message Queue reception.

?Output format of performance analysis trace

The format to be output to performance analysis trace is same as format of performance analysis trace of J2EE server. For details on, see "7. Performance analysis wherein performance analysis trace is used" in "Application Server Maintenance and Migration Guide".

?Output contents

The following table describes contents to be output to performance analysis trace file:

Table 7-66 Table Contents to be output to performance analysis trace file (for Message Queue reception)

Item	Contents
Event ID	Event ID of collection point is output. For details on collection point, Item "Performance analysis trace collection point"
Return code	Collection point type is output. 0: Normal end 1: Abnormal end
Interface name	Class name is output.
Operation name	Method name is output
Operation information	Following operation information is to be output: JMS message ID Reception name Reception ID Service name Service operation name Exception name (Only when failure occurs)

? Performance analysis trace collection point

The following figure shows the performance analysis trace collection point:

Figure 7-80 Figure Performance analysis trace collection point (for Message Queue reception)

The following table lists and describes the relationship between the event ID, trace collection point, and performance analysis trace collection level. The numbers in the Number in figure column of the table correspond to the numbers in the above figure.

Table 7-67 Table Performance analysis trace collection point (for Message Queue reception)

Event ID	Number in figure	Trace collection point	Level
0x98A0	1	Opening of Message Queue reception	A
0x98A1	2	Exit of Message Queue reception	A
0x98A2	3	Invocation of custom reception framework	B
0x98A3	4	Response reception of custom reception framework	B
0x9860	5	Entry to custom reception framework	A
0x9861	6	Exit to custom reception framework	A
0x9864	7	Invocation of HCSC message delivery control	A
0x9865	8	Response reception of HCSC message delivery control	A

Legend:

A: Indicates the "Standard" level.

B: Indicates the "Detailed" level.

? Collection method and output destination of performance analysis trace

Settings are important to acquire performance analysis trace. For details on settings, see "7. Performance analysis wherein performance analysis trace is used " in "Application Server Maintenance and Migration Guide".

(d) User message trace (Message Queue reception)

You can use the user message trace to check status of message.

User message trace is output from custom reception framework and not from Message Queue reception.

For details on user message trace, see explanation for request trace (custom reception) in "Appendix A.8 Acquiring the failure information (Custom reception) "in "Service Platform Reception and Adapter Definition Guide".

When J2EE server is down during Message Queue reception process, realtime rollback is not performed for message in WebSphere MQ specification. Restart the WebSphere MQ server.