If the problem appears to involve one particular message flow,
consider whether it has run successfully before.
Before you answer
Yes to this question, consider the following:
- Have you made any changes to the message flow since it last
ran successfully?
If so, it is likely that the error lies
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 fully exercised 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 lies in that part. Try to find out what the message flow was doing
when it failed; use user tracing (see User trace).
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?
Could
it be that your system has 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 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 platform)
it might require data conversion or a different form of processing. Also,
check whether you have changed any of the message formats used?
- Does the message flow run on other WebSphere
Business Integration Event Broker systems?
Is 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?
If your answer is No to the question "Has the
message flow run successfully before?", examine your message flow carefully
to see if you can find any of the following error:
- Do you see the errors from WebSphere
Business Integration Event Broker or
external resources, such as databases?
Your message flow
might be losing errors by incorrect use of the failure terminals on primitive
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.