Application migration

Since FTM version 2, many new strategic concepts were introduced in the development toolkit. The new concepts that were perceived to bring value to FTM customers were adopted for FTM version 3. However, the adoption of these concepts brings a larger application migration from version 2 to version 3 than normal.

The migration can be split into:
  • Mandatory workspace migration.
  • Optional migration to take advantage of new concepts.
The following concepts were adopted in FTM 3:
  • Use of libraries.
  • Use of subflow modules.
  • Use of native XML schema in preference to legacy XML message sets.
  • Use of source deployment in preference to legacy compiled message flow (CMF).

Libraries

A library is a way to encapsulate a set of related runtime components for use by and deployment with a set of application flows. Most of the FTM runtime components are now supplied as libraries, including the FTM Core Flows and Generic Model Actions.

A library can be deployed or updated independently to an execution group, which allows more controlled and fine-grained changes to be made to a deployment. Using the FTM Sample Application as an example, when a generic model action has a defect, you can fix the problem by editing and deploying only the generic model library. All other deployed artifacts and flows are not changed. Libraries can increase the speed and reduce the risk that is associated with a deployment update.

For more information, see Resource management overview - applications and libraries.

Subflows

In WebSphere® Message Broker 7, a subflow was just the reuse of a msgflow file in the context of another parent msgflow. The problem with this approach is that some flows are not designed to be deployed independently (for example, FlowManager.msgflow) but the flow can be deployed in its own right, potentially causing problems.

Now, a new subflow file type is introduced, which specifically indicates that the flow can be deployed only as a subflow. Most FTM flows are now subflows, including all actions, maps, FlowManager, and LogErrorFlow.

Native XML schema

All releases of FTM 2 used XMLNSC message sets to parse and validate XML documents. FTM 3 now uses the strategic option of using native schema for XML. The FTM 3 release still supports XMLNSC message sets, but it no longer includes any of these artifacts. This change includes the ISF and Common Base Event event formats. Instead of message sets, the native schemas are packaged as a library.

Source deployment

In WebSphere Message Broker 7, flows were compiled to CMF files when the BAR files were built. The strategic direction is to deploy the flow source instead of compiling it. In this scenario, the broker runtime provides any needed compilation. Source deployment makes it easier to replace code in the runtime by using libraries, and is also intended to reduce the memory footprint. All BAR files that are provided with FTM 3 are built for source deployment. A CMF deployment of FTM 3 is not supported.

The following concepts were not adopted in FTM 3, but are supported:

Application projects

An application project is an encapsulation container that defines a single deployment unit. A deployment unit is intended to group a set of libraries, message sets, and message flows into a single functional application entity. This concept maps well to the concept of an FTM application. However, the pros and cons for using this concept currently make it unlikely to be a best fit for all customers.

The following list shows the advantages of application projects:
  • Encapsulation - all flows and libraries are isolated from all other deployments to the same integration server (DataFlowEngine).
  • Single deployment unit - deployment of the application project causes deployment of all dependent resources.
The following list shows the disadvantages of application projects:
  • Single deployment unit - message sets, schemas, or libraries can't be updated in the integration server (DataFlowEngine) without redeploying the whole application.
  • An application cannot be deployed across a distributed set of integration servers where some flows are scaled and others aren't, or where some flows aren't deployed to all of the servers. An application project is a single deployment unit and must either be deployed as a whole or not at all.

For more information, see Resource management overview - applications and libraries.

DFDL

DFDL is essentially a replacement for MRM. It allows the definition of a message model by using XML schema syntax that is extended to support non-XML formats. For more information, see Constructing message models.

Graphical data maps

IBM® App Connect Enterprise includes a new graphical mapping editor. For more information, see Using message maps.