- Have you made any changes to the message flow since it last
ran successfully?
If so, it is likely that the error exists
somewhere in the new or modified part of the flow. Examine the changes and
see if you can find an obvious reason for the problem.
- Have you used all the functions of the message flow before?
Did the problem occur when you used part of the message flow that
had never been invoked before? If so, it is likely that the error exists
in that part. Try to find out what the message flow was doing when it failed
by using user tracing, trace nodes, and the workbench's debugger function.
If you have run
a message flow successfully on many previous occasions, check the current
queue status and the files that were being processed when the error occurred.
It is possible that they contain some unusual data value that invokes a rarely-used
path in the message flow.
- Does the message flow check all return codes?
Has
your system been changed, perhaps in a minor way, but your message flow does
not check the return codes it receives as a result of the change? For example:
- Does your message flow assume that the queues that it accesses can be
shared? If a queue has been redefined as exclusive, can your message flow
deal with return codes indicating that it can no longer access that queue?
- Have any security profiles been changed? A message flow could fail because
of a security violation.
- Does the message flow expect particular message formats?
If a message with an unexpected message format has been put onto
a queue (for example, a message from a queue manager on a different operating
system) it might require data conversion or a different form of processing.
Also, check whether you have changed any of the message formats that are used.
- Does the message flow run on other WebSphere Message Broker systems?
Is there something different about the way that your system is set
up that is causing the problem? For example, have the queues been defined
with the same maximum message length or priority? Are there differences in
the databases used, or their setup?
- Are you using any user-defined extensions?
There might be translation or compilation problems with loadable
implementation library (LIL) files. Before you look at the code, examine the
output from the translator, the compiler or assembler, and the linkage editor,
to see if any errors have been reported. Fix any errors to make the user-defined
extension work.
If the documentation shows that each of these steps
was completed without error, consider the coding logic of the message flow,
message set, or user-defined extension. Do the symptoms of the problem indicate
which function is failing and, therefore, which piece of code is in error?
See User-defined extensions for more information.
- Can you see errors from WebSphere Message Broker or
external resources, such as databases?
Your message flow
might be losing errors because of incorrect use of the failure terminals on
built-in nodes. If you use the failure terminals, make sure that you handle
errors adequately. See Handling errors in message flows for
more information about failure terminals.