Overview
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:
- R419 – The older style ‘msgmap’ nodes will not work in IIB11/ACE (WMB)
- R415 – MQOptimizedFlow nodes will not work in IIB11/ACE (WMB)
- R185 – Module names should not contain a space, later versions of IIB cannot have a space in a module name (WMB)
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
Standards
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
Environment.Flag
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. |
 |
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. |  |
Queue names don’t match the descriptions
| The queue being accessed doesn’t match the description that appears in the toolkit. |  |
Performance
Broad SELECT
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. |  |
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.
XMLNSC over XMLNS
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. |  |
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.
Correctness
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
‘Return;’
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.
Other
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.
