See information about the latest product version
Subflows
You define a subflow to provide a common sequence of actions to be used by several message flows, applications, or services. You can include subflows in your message flows in the same way as you include built-in or user-defined nodes. You can also connect subflows to other nodes in the same way.
A subflow provides the following benefits:
- Reusability and reduced development time.
- Consistency and increased maintainability of your message flows (consider a subflow as analogous to a programming macro, or to inline code that is written once but used in many places).
- Flexibility to tailor a subflow to a specific context (for example, by updating the output queue or data source information).
- You can define a subflow that provides a common sequence of actions that applies to several message flows if an error is encountered. For example, you might have a common error routine that writes the message to a database through the Database node, and puts it to a queue for processing by an error recovery routine. The use of this routine in multiple message flows, or in several places within one message flow, provides an efficient and consistent use of resources and avoids reinventing such routines every time an error is encountered.
- You might want to perform a common calculation on messages that pass through several different message flows; for example, you might access currency exchange rates from a database and apply them to calculate prices in several different currencies. You can include the currency calculator subflow in each of the message flows in which it is appropriate.
To learn more about subflows, see the following scenario ../com.ibm.scenarios.doc/UnderstandingSubflows/topics/scnsubflows_01_11_.htm.
Types of subflows
You define a subflow once, and use it in more than one message flow, application, service, and Message Broker project. You define subflow content in the same way as you define message flow content, by adding, configuring, and connecting message flow nodes.
- A subflow that is defined in a .subflow file
can be deployed in any of the following ways:
- Separately from any of the message flows that use this subflow. The subflow and the message flows that include this subflow must be deployed in the same execution group in a broker. The subflow can be deployed directly into an execution group in a broker, or as part of a library. If you update this type of subflow and redeploy it, all message flows that use this subflow, and are not part of an application or service, are automatically updated. You do not need to redeploy these message flows.
- As part of an application or service.
- You cannot use the following nodes in this type of subflow:
- Nodes representing subflows that are defined in .msgflow files
- User-defined nodes created from subflows that are defined in .msgflow files
- MQOptimizedFlow nodes
- If you create a BAR file that contains both ESQL code and a subflow that is defined in a .subflow file, you cannot include the ESQL code directly in compiled message flow files.
- A subflow that is defined in a .msgflow file,
is embedded inside any parent message flows that use it when the message
flow is placed in a bar file. This type of subflow therefore can only
be deployed to a broker with the message flow in which it is used.
- If you update this type of subflow, you must redeploy all message flows that use the subflow for the changes to be used.
- This type of subflow can be packaged as a user-defined node.
Conditions that apply when you convert a subflow between .msgflow and .subflow and viceversa
- If the .msgflow file contains subflows that are defined as .msgflow files, these subflows must also be converted to .subflow files.
- If the .msgflow file is used as a subflow, the parent flow must be updated so that it references the new .subflow file.
- You cannot use the name of a file that already exists in that application, library, or Message Broker project where you create your subflow as a .msgflow file. You must include .msgflow at the end of your subflow file name.
Conditions that apply when you want to add a subflow into a message flow
- The subflow that you want to add in a message flow is defined
in a library, and you have specified the dependency of the current
message flow project on that other project. Applications and services
can reference libraries.Note: A library is a logical grouping of related code, data, or both that typically contains reusable subflows, and other type of resources.
- The subflow that you want to add in a message flow is defined in the same Message Broker project, application project or service project as the message flow.
Conditions that apply when you want to add a subflow into a subflow
- You can add subflows that are defined in .subflow files into subflows that are defined in .subflow files and .msgflow files.
- You can add subflows that are defined in .msgflow files into subflows that are defined only in .msgflow files.
Conditions that apply when you deploy a subflow
- Deploy a subflow as an independent resource defined within a Message Broker project.
- Deploy a subflow as part of an application project.
- Deploy a subflow as part of a service operation.
- Deploy a subflow as part of a library.
You deploy a subflow to an execution group by sending a broker archive (BAR) file to an execution group in a broker, which unpacks and stores the contents ready for when your message flows are started.
- If you deploy a message flow that contains a subflow that is defined in a .subflow file, the subflow is automatically included in the BAR file.
- If you deploy a subflow that is contained in an application, you must deploy the application to an execution group, which results in a complete deployment of the application.
- If you deploy a subflow that is contained in a service, you must deploy the service to an execution group, which results in a complete deployment of the service.
- If you deploy a subflow that is contained in a library, you can deploy the library to an execution group directly, outside of an application or a service. Then the subflow included in the library can be referenced by other message flows and subflows that are deployed directly to the same execution group as the library.
- A subflow that is created as a .msgflow file in a Message Broker project can only be deployed as a separate resource if it contains at least one Input node.
Version control
Use the Passthrough node to enable version control of a subflow at runtime.
- By using the mqsireadbar command to read the properties stored in the broker archive (BAR) file.
- In the WebSphere® Message Broker Toolkit, on the properties of a deployed message flow as last deployed to a particular broker.
- In the runtime environment, if you enable user trace for that message flow.
- If the subflow is deployed separately from any of the message flows that use this subflow and you deploy a new version of the subflow, then all the message flows are updated automatically.
- If the subflow is deployed as part of an application or service, then you need to update your applications and services to include the new subflow version, and redeploy them.
- You need to update your applications, services, and independent resources that use the subflow to include the new subflow version, and redeploy them.
Samples
You can view information about samples only when you use the information center that is integrated with the WebSphere Message Broker Toolkit or the online information center. You can run samples only when you use the information center that is integrated with the WebSphere Message Broker Toolkit.