Problems when deploying message flows or message sets
To debug problems when deploying, you need to check the logs:
The broker domain Event Log.
The local error
log (the Windows Event
log or the syslog).
WebSphere MQ logs.
These logs might be on separate computers, and must be used in conjunction
with the workbench output to ensure that the
deployment was successful.
Use the mqsilist command
to check that the deployment was successful, or look in the Windows Event
or broker domain Event Log.
Use this checklist when you have deployment problems:
Make sure that the remote queue manager is running.
Make sure that channels are running.
Display the channel status to see if the number of system messages
sent increases.
Check the channel from the remote end.
Check the queue manager name.
Determine whether the channel is a cluster channel.
This section outlines some common problems that can arise when
deploying message flows or message sets. It contains advice for dealing with
the following problems:
Migrated message flows are not available to add to a broker archive
file
Scenario: You have migrated your Version 2.1 message
flows and message sets using the mqsimigratemsgflows command and mqsimigratemsgsets commands into
the workbench, but they are not available
to add to a broker archive (bar) file.
Solution: Newly-migrated message flows and
message sets are displayed in the workbench as
a closed project. To make the message flows and message sets available
to add to a bar file:
Open the project by right-clicking on the project and clicking Open Project from the Project menu.
Rebuild the project by right-clicking on the project and clicking Rebuild All. This shows any errors,
and makes the project resources available to add to a bar file.
You get an error when adding a dictionary to a broker archive file
Scenario: You get an error when adding a dictionary to a
broker archive (bar) file, and need information to help diagnose the error.
Explanation: After you create a bar file and add a message
set project into it, two files are created in the bar file: messageset.user.txt and messageset.service.txt. The user.txt file contains user log information, such
as warning BIP0177W, which states that the dictionary that
you have created is not compatible with versions previous to WebSphere Business Integration Message BrokerVersion 5.0. The information in this file should help you to diagnose
the error. The service.txt file contains rudimentary
dictionary information as used by the broker, and can be used by the IBM Support
Center to diagnose problems.
You cannot drag and drop a broker archive file to a broker
Scenario: You cannot drag and drop a broker archive (bar)
file to a broker.
Explanation: Bar files can be deployed only on an execution
group. Using drag and drop you cannot drop the bar file onto a broker in the
Broker Topology editor or in the Domains Navigator.
Solution: Drop the bar file on an execution group in the
Domains navigator, or select an execution group in the deploy dialog.
You cannot deploy a message flow that uses a plug-in message flow
Scenario: You have created a message flow containing an
input node in a user-defined node project. However, you cannot deploy a message
flow that uses this plug-in message flow.
Explanation: Validating, compiling, and deploying cannot
recognize a plug-in message flow as containing an input node.
Solution: To work around the problem, add a dummy Input
node to the flow that you intend to deploy.
The compiled message flow (.cmf) file has not been generated
Scenario: The compiled message flow (.cmf) file has not
been generated. Therefore, it is not added to the broker archive file and
cannot be deployed.
Explanation: When creating mapping files, the overall file
path length must not exceed 256 characters, due to a Windows file system limitation.
If you try to add a message flow to a broker archive file with mapping or
ESQL files with a path length that exceeds 256 characters, the compiled message
flow will not be generated and cannot be deployed.
Solution: Follow these recommendations to overcome this
problem:
Make sure that the install path is as short as possible.
Make sure that project names and broker schema names are as short as possible.
Make sure that ESQL and mapping file names are as short as possible.
The message flow deploys on the test system, but not elsewhere
Scenario: The message flow that you have developed deploys
on the test system, but not elsewhere, and you need information to help diagnose
the error.
Solution: Carry out the following checks:
Make sure that you have verified the installation by creating
and starting a broker and deploying a single execution group. This shows that WebSphere Business Integration Message Broker and the broker database are in place.
Ensure that the broker archive (bar) file's broker.xml file
contains references to the correct resources for the new system.
Ensure that any referenced message sets are deployed.
If database resources or user-defined nodes are
not accessible or authorized from the target system, the deploy fails. On
distributed platforms, ensure that your databases are defined as ODBC sources
so that they can be accessed from WebSphere Business Integration Message Broker.
Also, set the broker's environment to allow access to the databases. (You
might need to run a profile on UNIX platforms.)
Any user-defined extensions that you are using
in your message flow might not load if they cannot be found, or are not linked
correctly. Consult the documentation for your platform for details of tools
that can help you to check your user-defined extension binaries.
Your deploy indicates that the broker does not exist
Scenario: You have initiated a deploy, but get an error
indicating that the broker does not exist.
Explanation: During the first stage of deployment, the Configuration Manager sends a configuration data stream to
the SYSTEM.BROKER.ADMIN.QUEUE of each target broker. When the configuration
data has been sent to all relevant brokers, control is returned to you. If
an error is detected during this first stage of deployment, the deployment
is abandoned; no configuration data is sent to any broker and an error message
is displayed in the log.
Solution: Check that you have specified the correct queue
manager associated with the broker. If it is correct, it is possible that
the deployment message cannot be delivered because the queue to which it is
sent (SYSTEM.BROKER.ADMIN.QUEUE) could not be found on the target queue manager. This returns a WebSphere MQ reason
code of 2085.
If that queue has been accidentally deleted, the broker environment
has been damaged, and you must repair it.
The Configuration Manager is trying to deploy to
a broker that does not exist
Scenario: The Configuration Manager is
trying to deploy to a broker that does not exist.
Explanation: This can happen for a number of reasons:
you deleted a broker component without removing from the toolkit first
you mistyped the name of the broker in the toolkit, creating a reference
to a broker that does not physically exist
you did not follow the correct procedure for deleting a broker
the broker can appear not to exist, due to connectivity problems.
Solution:
Check that the broker does not exist by using the mqsilist (list
resources) command on the computer where the broker should physically exist.
Check your configuration to ensure that the broker does not exist on a
different computer in the domain.
If this still fails to remove the reference, you must delete the broker
manually from the configuration repository.
Note: This method should be used
only by experienced System Administrators.
Copy and paste the following
script into the script window of your DB2 Command
Center and execute. Substitute MYCONFIGMGRDB with the name
of your Configuration Manager database and MYBROKER with
the name of your broker.
connect to MYCONFIGMGRDB
delete from cbrokerceg where cuuid=(select distinct cuuid from cbroker where cname='MYBROKER')
delete from ceg where cbrokercuuid=(select distinct cuuid from cbroker where cname='MYBROKER')
delete from coutstanding where cbrokercuuid=(select distinct cuuid from cbroker where cname='MYBROKER')
delete from cproperties where cbrokercuuid=(select distinct cuuid from cbroker where cname='MYBROKER')
delete from ctopic where cbrokercuuid=(select distinct cuuid from cbroker where cname='MYBROKER')
delete from csubscribe where cbrokercuuid=(select distinct cuuid from cbroker where cname='MYBROKER')
delete from cbroker where cname='MYBROKER'
connect reset
The Configuration Manager reports that it is out
of memory
Scenario: The broker archive file is not deployed because
the Configuration Manager claims to be out of memory, as
indicated by error message BIP1111.
Explanation: The most likely cause of this problem is that
the Java Virtual Machine (JVM), which the Configuration Manager uses
to perform the deployment logic, has run out of temporary storage space.
Solution: Use the maxJVMHeapSize option
on the Configuration Manager to increase the amount of
memory allocated to the Configuration Manager's JVM:
where [newJVMHeapSizeMb] is the size in megabytes
to allocate; the minimum is 64.
Retry the deploy operation.
If the problem still occurs, increase the maxJVMHeapSize parameter
further.
You get a correlation name error when deploying to a Version 2.1 broker
Scenario: When attempting to deploy a broker archive file
to a Version 2.1 broker you get the following
error message:
The correlation name 'CREATE' is not valid.
Those in scope are: Environment, InputLocalEnvironment, OutputLocalEnvironment, InputRoot,
InputBody, InputProperties, OutputRoot, InputExceptionList, OutputExceptionList,
InputDestinationList, OutputDestinationList.
Explanation: This error message indicates that you have
attempted to deploy a message flow that contains a mapping node to a Version 2.1 broker.
Mapping nodes are not supported on Version 2.1 brokers.
It can also arise when you deploy a message flow that is in the same
message flow project as another message flow that contains a mapping node
to a Version 2.1 broker. If this is the case,
move the message flow that contains a mapping node into a different project,
and try the deployment again.
The Run On Server dialog has no indication that a deploy was attempted
Scenario: The Run On Server dialog sometimes has no indication
that a deploy was attempted.
Explanation: The rapid application development (RAD) Run
On Server deploys are incremental. If none of the message flows or message
sets configured for Run On Server are changed, they are skipped without a
message. If there are no changes to deploy, no deploy is attempted.
Your deploy generates BIP error messages
See each explanation below of error messages that might be generated
during a deployment.
Message BIP1106 with WebSphere MQ reason
code 2030
Scenario: You are trying to deploy a large message set and
see error message BIP1106 with the text: ( ConfigMgr
) WebSphere MQ error detected, reason code 2030.
Explanation: The message size exceeds the maximum message
size of the transmit queue to the broker queue manager.
Solution: Increase the maximum message size for the transmit
queue using the WebSphere MQalter
qlocal command, as follows:
alter ql(transmit_queue_name) maxmsgl(104857600)
Message BIP1106 with WebSphere MQ error
AMQ7463
Scenario: You are trying to deploy a large message set to
a broker that shares the queue manager with the Configuration Manager,
and you see error message BIP1106 with the text: (
ConfigMgr ) WebSphere MQ error detected, reason code 2102. You also
get WebSphere MQ error AMQ7463 with the text: The
log for queue manager <queue manager> is full.
Solution:
Stop the Configuration Manager using the mqsistop command as follows:
mqsistop configmgr
Stop the broker using the mqsistop command
as follows:
mqsistop <broker>
Stop the queue manager using the WebSphere MQamqmdain command as follows:
amqmdain end <queue manager>
Start WebSphere MQ Services from
the Start menu by clicking Start > Programs > IBM WebSphere MQ > WebSphere MQ Services.
Right-click the queue manager, and click Properties,
then the Log tab.
Increase the number of primary and secondary files so that the
total size is larger than the deploy message.
Restart the Configuration Manager using the mqsistart command as follows:
mqsistart configmgr
Restart the broker using the mqsistart command
as follows:
mqsistart <broker>
Restart the queue manager using the WebSphere MQamqmdain command as follows:
amqmdain start <queue manager>
Message BIP1538E
Scenario: You are trying to deploy a large message set and
see error message BIP1538E with the text: Unable to
deploy configuration data to broker <broker name> on broker queue manager <broker
queue manager>; WebSphere MQ reason code 2218.
Explanation: The message size exceeds the channel maximum
message size.
Solution: Increase the channel maxmsgl parameter
on both channel pairs, at both ends as follows:
On the Configuration Manager queue manager,
issue the WebSphere MQalter
channel command. For example:
alter chl(CM_to_BRK) chltype(sdr) MAXMSGL(104857600)
alter chl(BRK_to_CM) chltype(rcvr) MAXMSGL(104857600)
On the Broker queue manager, issue the WebSphere MQalter channel command. For
example:
alter chl(BRK_to_CM) chltype(sdr) MAXMSGL(104857600)
alter chl(CM_to_BRK) chltype(rcvr) MAXMSGL(104857600)
Stop and restart each of the channels for these changes to take
effect.
Message BIP1205 and SQL0973N error
Scenario: You see this error when you are using the workbench to deploy complex message flows containing
a large number of nodes:
SQL0973N Not enough storage is available in the APP_CTL_HEAP
heap to process the statement. SQLSTATE = 57011
Explanation: The limit defined by the value of the DB2 database
configuration parameter app_ctl_heap_sz has
been reached.
Solution:
Stop the Configuration Manager using the mqsistop command.
Increase the value of the appl_ctl_heap_sz parameter
for the configuration repository associated with the Configuration Manager.
Restart the Configuration Manager using the mqsistart command.
Message BIP1536
Scenario: You have defined a Configuration Manager to
run with one user ID and you have defined a broker to run on a different computer
with a different user ID. When you try to deploy message flows and
message sets to the broker, deployment is successful but you see the
error message BIP1536.
Explanation: The Configuration Manager is
unable to register for internal subscriptions with the broker because the
broker is running under one ID and the Configuration Manager is
running under another ID. The broker and the Configuration Manager relay
internal messages back and forth via publish/subscribe.
These message are carried through WebSphere MQ,
which requires certain authorizations.
Solution: Do the following:
Ensure that the broker's user ID is a member of the mqm and mqbrkrs groups.
Define the broker's user ID on the computer where the Configuration Manager is
running.
Define the Configuration Manager's user ID on the computer
where the broker is running.
Ensure that all IDs are in lowercase so that they are compatible between
computers.
Message BIP1536 with message BIP7017
Scenario: You see the error messages BIP1536 and BIP7017.
Explanation: The Configuration Manager had
a problem registering its internal subscriptions on topics to do with broker
status change, which it tries to do each time that you deploy a complete configuration.
The cause of the problem is given by the message BIP7017,
which indicates that you are running with a User Name Server configured,
but that the broker to which you are deploying does not have the Configuration Manager service
user ID in its user cache.
This might be because the User Name Server is
not started, or the WebSphere MQ channels between
it and the broker are not started, or because the user ID is not present in
the User Name Server's domain.
Solution: If you correct the problem, the subscriptions
are correctly registered the next time you deploy.
Note: The Configuration Manager service user ID is incorrectly reported
in the BIP7017 message. This is a known problem.
Message BIP1835
Scenario: You see the error message BIP1835.
Explanation: The message set that you are deploying produces
a message set dictionary larger than the internal limit of 4MB. This could
be because you have many large message definitions defined to the same message
set.
Note: The size of an exported message set is not a good
indication of the size of the message set dictionary that is generated at
deploy time, because the exported message set is stored as XML. This can be
very verbose, but the dictionary has a much more compact internal format.
Solution: Split the message definitions into several smaller
message sets.
Message BIP2066
Scenario: You see the error message BIP2066.
Explanation: The deploy request was not acknowledged by
the execution group before the broker timeout ConfigurationTimeout plus
the ConfigurationDelayTimeout (default 60 seconds) expired.
Solution: See Commands for
details of how to set these timeouts using the -g and -k flags of the mqsicreatebroker and mqsichangebroker commands.
Message BIP2242
Scenario: You see error message BIP2242.
Explanation: The deploy (configuration change) request was
not accepted before the broker timeout ConfigurationTimeout (default
300 seconds) expired. The timeout needs to be long enough for the message
flow to complete processing its current message and then accept the deploy
request.
Solution: See Commands for
details of how to set these timeouts using the-g and -k flags of the mqsicreatebroker and mqsichangebroker commands.
Tagged/Delimited String (TDS) Validator error
Scenario: You try to deploy a message set with a TDS wire
format that has an error.
Explanation: The following extract from an error log illustrates
what you might see for a TDS Validator error. In this case, the cause of the
problem is that the element Town does not have a tag defined.
TDS Extractor Trace File
========================
Beginning Extract..
Extracting Identification Info
Extracting Project Info
Extracting Messages
Extracting Elements
Extracting Compound Types
Extracting Type Members
Extracting Type Members
Extracting Type Members
Extracting Type Members
Extracting Type Members
Beginning Indexing..
Creating Member IDs to Tags Index Table.
Beginning Validation..
Validating Project
Validating Types
ERROR: TDSValidator::ValidateTypeMemberSimpleElement:
Simple elements in a type with Data Element Separation attribute = Tagged
Delimited must have the following attribute set:
Element Level - Tag
(Element ID: Town)
(Type ID: AddressType)
Return Code: -80
Validating Messages
Trace Info
===========
EXCEPTION: TDSValidator::Validate:
TDS Validation failed.
1 errors
0 warnings
Return Code: -1
You get an error when deploying using RAD
Scenario: You get the following error when attempting to
deploy using the Rapid Application Development (RAD) tools, such as Run on Server:
Server already started
Explanation: This is a known limitation.
Solution: To get around the problem, stop the execution
group from the Broker
Administration perspective and try again.
You get error messages when deploying on z/OS
Scenario: On z/OS,
you get the following messages in the log when trying to deploy:
+(MQ05BRK) 0 BIP2070E: A problem was detected with WebSphere MQ while issuing
MQPUT for WebSphere MQ queue SYSTEM.BROKER.ADMIN.REPLY, WebSphere MQ queue
manager QM_01. MQCC=2, MQRC=2030.
+(MQ05BRK) 0 BIP2068E: The broker was unable to put an internal configuration
message to message queue SYSTEM.BROKER.ADMIN.REPLY.
Explanation: The transmission queue is not large enough
for the messages issued by WebSphere Business Integration Message Broker.
Scenario: After closing the Broker Topology editor, saving
your changes, and asking for a deploy, you are not notified of the result
from a configuration deploy.
Explanation: When closing the editor, the notification link
with the Configuration Manager is broken, so the workbench is
not notified of the deploy result. This is the same for any eventual
failure notifications.
Solution: To ensure that you receive any notification, save
the editor without closing it and wait for the alert Waiting for answer
from Configuration Manager to disappear. This alert is automatically
removed when the editor receives all expected responses from the Configuration Manager.
You do not receive confirmation that the deployment was successful
Scenario: You have initiated a deploy, but have not received
confirmation that the deployment was successful.
Solution: Assume that communications from the workbench to
the Configuration Manager are working, because the workbench gives an error immediately if this link
fails. Follow these steps to find out if there is a communication problem
that stops the receipt of deployment confirmation:
Stop the broker using the mqsistop command.
On the broker queue manager, check the SYSTEM.BROKER.ADMIN.QUEUE.
If there are messages on this queue, there might be a broker error; look in
the local error
log on the broker's system. If the
queue is empty, continue with the next step.
Redeploy your message flow.
Recheck the SYSTEM.BROKER.ADMIN.QUEUE
on the broker queue manager. If the queue depth has not increased, there is
a problem with the channel between the Configuration Manager and
the broker; check the WebSphere MQ logs. If the
queue depth has increased to one, continue with the next step.
Stop the Configuration Manager, and then
start the broker.
This allows the broker to process the configuration
change and send a response. Wait for the broker to process the message; this
could take some time. (If the message takes more than five minutes to process,
there is a problem with the deployed message and failure messages appear in
the local error
log on the broker's system indicating
the reason for the failure.) Check the SYSTEM.BROKER.ADMIN.REPLY queue on
the Configuration Manager's queue manager. This should
contain a response. If it doesn't, check that the channel from the broker
to the Configuration Manager is running.
Restart the Configuration Manager.
Check that the messages are read from the SYSTEM.BROKER.ADMIN.REPLY
queue on the Configuration Manager's queue manager. If
they are not, check the local error
log on the Configuration Manager's system for errors.
Refresh the Event Log editor in the workbench.
You should now get a reply.
You cannot see any deployed message flows or message
sets
Scenario: After deploying a bar file, you cannot see any
deployed message flows or message sets under the execution
group.
Explanation: After the deploy, you should get an Information
dialog that tells you whether the deploy has been successfully started on
the Configuration Manager. When the deploy has started,
the time it takes to complete depends on your configuration size and work
overload on your computers. However, if after a while no messages
concerning the deploy are present in the Event Log editor, this means that
the broker has not responded to the deploy request.
Solution: Check that the broker is running and that all WebSphere MQ queue managers and channels between
the Configuration Manager and the broker are running. If
the messages are present in the Event Log editor, see if any errors have occurred
that mean that your changes were not activated.
Deleted broker still remains in the Domains navigator
Scenario: After deleting a broker and deploying changes,
the broker still remains in the Domains navigator.
Explanation: If you did not receive any failure response
telling you that the deletion failed, and the Event Log editor has been automatically
refreshed with a set of messages about the deploy result, the deletion succeeded
but the workbench has not been notified of
this deletion.
Solution: For the Broker Topology to reflect the actual Configuration Manager content, refresh the Broker Topology.
If the Broker Topology is open, click Revert to reflect the actual Configuration Manager content.