How to use subflows in IBM Integration Bus

 View Only
Fri May 15, 2020 10:17 AM

Article written by David Crighton, Philip Jones, and Marisa Lopez de Silanes

You define a subflow in IBM Integration Bus (or WebSphere Message Broker version 8) 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.

For the latest information about using subflows in IBM Integration Bus, see the following pages of the product documentation in IBM Knowledge Center:

  • Subflows. An overview of subflows, their benefits, types, and conditions of use (as originally provided in this article).
  • Scenario: Reusing common application logic in multiple integration solution. This scenario explains how IBM Integration Bus handles subflows created as a .subflow file and as a .msgflow file; provides guidance on how to design a subflow depending on the type; and demonstrates how to convert legacy subflows into IBM Integration Bus subflows.

Benefits of subflows

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).

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.

Note: At runtime, each instance of a subflow creates a copy of all the message flow nodes that define that subflow. This affects resource usage, which can affect your overall message flow performance.
You can create a subflow as a .subflow file or as a .msgflow file. Choose which type of subflow to use based on the following information:
  • 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

You can convert a subflow created as a .msgflow file to a .subflow file.
  • 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 can convert a subflow created as a .subflow file to a .msgflow 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

You can add subflows into a message flow if either of the following statements is true:
  • 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 into a subflow in any of the following cases:
  • 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

You can deploy subflows in any of the following ways:
  • 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.

The following conditions apply when you deploy a subflow as part of an integration solution:
  • 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 including a Passthrough node, you can add a label to your message flow or subflow. By combining this label with keyword replacement from your version control system, you can identify which version of a subflow is included in a deployed message flow. You can use this label for your own purposes. If you have included the correct version keywords in the label, you can see the value of the label in a any of the following ways:
  • 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.
For subflows created as a .subflow file, you must consider the following behaviour when deploying a new version of a subflow:
  • 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.
For subflows created as a .msgflow file, you must consider the following behaviour when deploying a new version of a subflow:
  • You need to update your applications, services, and independent resources that use the subflow to include the new subflow version, and redeploy them.