Generate .msgflow from running message flow pattern
This simple pattern causes a deployed message flow to be extracted from
a running broker and converted into a corresponding source message
flow file.
Solution
This pattern uses the Message Broker's CMP API interface to connect to a
local or remote broker and discover a specific message flow and its properties.
It uses this information to construct a new message flow that contains the
same nodes, properties and connections of the source message flow.
When to use this pattern
There are several scenarios in which you might want to use this pattern.
You might want to use this pattern to understand the high-level behaviour of
message flows in situations where the source is not available, or if you want
to ensure that the broker is running the message flow that was intended.
Alternatively, you might want to use this pattern to kick-start the recreation
of existing message flows where the source has been lost.
Restrictions
The pattern uses only public, published external interfaces to reconstitute
message flows. However, this means that there are a number of restrictions on
what this pattern can produce, based on limitations in the information that is
available from the V7 or V8 broker through these interfaces. The most significant
limitations include:
- ESQL: This pattern does not reconstitute any ESQL, and you will need to
right-click on any ESQL-based nodes, select 'Open ESQL' and manually re-enter any
ESQL in your message flow.
This is because, in order to improve performance, the broker does not return ESQL
logic to CMP applications and so the ability to view existing ESQL is not available
through the public interface. However, you are able to use the mqsireportproperties
command to view ESQL; see the product documentation for more information.
- V7 Mapping nodes: In WebSphere Message Broker V7 (but not V8), Mapping nodes
are converted to Compute nodes when they are deployed to the broker. This means that
when a message flow containing a Mapping node is reconstituted using this pattern, the
Mapping nodes are converted to Compute. In WebSphere Message Broker V8, the Mapping
nodes can be reconstituted successfully using this pattern, but the referenced MSL files
are only accessible through the broker's filesystem - see "other deployed object types"
below.
- Subflows: In WebSphere Message Broker V7, subflows are expanded
when the message flow is deployed, which means that the broker sees one long message
flow rather than a main message flow with calls out to separately defined subflows.
This means that when a message flow is reconstituted using this pattern, subflows
will be shown in-line within the same file rather than being in separate files.
In WebSphere Message Broker V8, subflows can be deployed and managed separately from
main message flows; these .subflow source files are accessible directly from the local
filesystem - see "other deployed object types" below.
- Node positioning: In order to minimize the size of the deployed message flow,
rendering information related to the message flow (such as the position of the icons
on the message flow canvas) is removed before it is sent to the broker. This means that
when a message flow is reconstituted using this pattern, you might need to rearrange
the icons of the generated msgflow in order to view the message flow as it was
originally designed.
- Other deployed object types (e.g. JAR, XSL, MSL, DFDL): In
WebSphere Message Broker V7 and V8, the CMP cannot report the exact contents of any other
objects deployed to an execution group, and so it is not possible to reconstitute
files of these types using this pattern.
However, it is often possible to access these files by directly looking on the broker
machine's filesystem; most types can be found unchanged in the directories underneath
the root directory referred to by the $MQSI_WORKPATH environment variable.
Files of type .dictionary are not accessible through any published interface.
Support
This pattern is supplied "as-is" and has no formal support statement;
use it at your own risk! Complete source for this pattern is included
on the official download site for this pattern at MQSeries.net,
so feel free to take a look there to find out how the pattern works (and improve it!).
You can contact me with any questions or comments using the private message facility
on the same site; my user name is mqmatt.