Integration Bus/Message Broker Rules summary


IBM has branded the original WebSphere Message Broker technology 3 times.

As WebSphere Message Broker (WMB)

As IBM Integration Bus (IIB)

And as App Connect Enterprise (ACE)

Our product analyzes the underlying source code not what is packaged into a BAR for deployment.
Do our tool is agnostic as to which runtime (ACE, IIB or WMB) that teams are using.

So regardless of what runtime you use, our tool will look at the quality of your files. These include the standard files the the toolkit’s allow you to develop with:

  • “.ESQL” files
  • “.MSGFLOW” files
  • “.SUBFLOW” files
  • “.MSET” files
  • “.PROJECT” files
  • “.DESCRIPTOR” files
  • “.MAP” files

It also supports “.MQSC” files that aren’t created by the toolkit but hold MQ configuration information.

Support of WSDL, XSL and XML can be enabled. It is disabled by default as it will conflict with the standard Sonarqube XML plugin if you have it enabled.

It also optionally supports DataPower (as a separate license):

  • “.XSL” files

It also optionally supports Sterling (as a separate license):

  • “.BPML” files

There are rules that are specific to the different run times. For example there are a number of rules that you can enable that are specific to ACE, but these rules can be enabled regardless of which run time you deploying to. It is more a question of whether they make sense for your particular set of circumstances.
For example these rules are ACE specific:

There are a few differences between run times when working with test coverage that do need to be taken into account when working with ACE (over IIB or WMB).
The BAR file that the instrumentation process changes is more specific for ACE, so there is a specific “ACE” flag that needs to be set to handle any BAR files packaged by/for ACE.

Summary of coding rules and checks

The following lists the violations that can be produced by MQ-Precise while analyzing Message Broker code. They are broken down below into the categories standards, performance, correctness and other.

For a complete list of the rules please follow this link


Validate queue names against a naming standard

Queue names should comply to a set length, should be in uppercase, should not contain underscores, cannot start with SYSTEM. and should not contain blanks. Enforcing a queue names adds to consistency and prevents any issues at run time with MQ names that affect functionality.

Environment tree variables

If the environment is to be used, then the Variables part of the tree should be used.
ie Environment.Variables.Flag
should be used over

ESQL Code complexity

Cyclomatic complexity
The complexity of ESQL code can be measured in much the same way as any other language that provides logical conditions/branches (IF/ELSEIF/ELSE and CASE statements) and loops (FOR/WHILE).
The lower the complexity of a routine the easier it is to test and maintain. A rule of thumb provided by PMD for java is a score of 10 by default.

Function and procedure length
The longer a function or procedure is the more difficult the ESQL is to maintain. A rule of thumb provided by PMD for java is a function length of 100 by default. The higher the cyclomatic complexity the lower this threshold should be. A large function of 200 lines with only one path through the code is very likely to be more maintainable then a function of 100 lines with multiple conditional statements.

Extra long lines

This indicates that the ESQL code on a single line is very long. Long lines can make code more difficult to read.
Any line that is longer then 130 characters will be marked as a violation.

Extra long lines

Missing file header comment

A corporate standard header file can be configured for all ESQL source code. This may include author, history or licensing of the source code (proprietary versus opensource).

Missing comments on functions/Procedures

Functions and Procedures should be documented.

Deprecated functionality used

Certain deprecated functions such as “BITSTREAM” should be avoided


Unused Method/Variable

ESQL code has been found that appears to be “dead” ie a method has been declared that is never called or a variable has been declared that is never referenced. This code may be able to be removed.

Negative IF/ELSE

An IF/ELSE statement has been found that may be restructured to be more readable.

Keywords in UPPERCASE

Keywords should be in UPPERCASE to make the code more readable.

Flows is missing notes

This indicates that a flow has no notes when the “notes are required” setting/property is enabled. Adding a note allows for obvious documentation within flows.
Flow notes

Queue names don’t match the descriptions

The queue being accessed doesn’t match the description that appears in the toolkit.
Mismatched queues



Avoid using “SELECT *” from the code as it could result in needlessly large data sets being loaded and affect performance and scalability.

Node timeout

Long timeouts in MQ, HTTP and SOAP nodes can affect performance and scalability.

Use LocalEnvironment over Environment

Data kept in the Environment lives as long as the instance of the flow that is being processed ie the memory is only released when the flow ends.
Where possible the LocalEnvironment should be used as it is cleaned up (the memory is released) between nodes.

CARDINALITY within a loop

A CARDINALITY check is costly in terms of CPU. Having the check as a loop condition or within a loop should be avoided if possible.
Tree navigation

Atomic references atomic

An atomic block of code could has been found that could be calling another atomic block of code. If two or more broker threads are executing this code at the same time it could result in a deadlock at run-time.

JDBC Column not indexed

A column is being used as a primary key, but the column is not indexed. This could result in a performance issue for queries against larger tables at run-time.


The XMLNSC parser deprecates the XMLNS passer and should be used when possible.

Tree navigation could be a reference

The message tree is being navigated more then it needs to be. A reference will improve performance as it prevents multiple parses of the data in the message.
Tree navigation

Multiple compute nodes in a row

There are two or more compute nodes in a row. Compute nodes are expensive in terms of creation and shouldn’t be created if it can be avoided.


LOOP without a leave statement

Helps protect against infinite loops.

Check filter nodes have valid connections

Check that unknown is wired to filter node if a
Or ‘return null’ is present.

Empty try/catch

Check that try catch node has valid catch connection, otherwise it may lead to losing messages.

Default values for EXTERNAL (UDP)

Externally declared values should have logical default values.

Check filter nodes do not affect messages

Filter nodes are unable to change the message tree, only the environment. Any code that tries to change the message tree will be ignored.

JDBC Table/Column not defined

ESQL code that makes use of an INSERT/SELECT/UPDATE or DELETE has been found but no matching table has been found in the database schema provided. This code may fail at run-time.

MQ Queue name defined but not referenced

An MQ queue has been listed in the MQ setup but not used in the code. The queue may not be required or there is an issue with the code.

MQ Queue name referenced but not defined

An MQ queue has been referred in the code but not listed in the MQ setup. This could cause an issue at run-time if Message Broker attempts to read to or write to a non-existent queue. It could also indicate that the MQ setup file is not complete.


Plain text credentials

This indicates that credentials for authorisation/authentication have been setup in the code in plain text. They ideally should be replaced by a constant defined as an ‘EXTERNAL’ so that they can be replaced at deployment time using a broker override.