Workspace migration

The following guidelines are for how to manually migrate an existing FTM version 2 application workspace to FTM version 3. Customers are recommended to check with product support for the most recent advice about migration before they embark on a migration effort.

  1. Your existing FTM workspace is made up of projects that were supplied with FTM and custom projects that were developed to produce the rest of the application. Ensure you understand and identify which are which.
    Typically, the following FTM projects might be in use:
    • FTM Core CBE1
    • FTM Core Flows
    • FTM Core Flows Ext
    • FTM Core ISF for Payments V21
    • FTM Core ISF for Payments V31
    • FTM Core WTX
    • FTM EndMapper1
    • FTM Generic Model Actions
    • FTM SWIFT MT Flows
    • FTM SWIFT MT Flows Current
    • FTM SWIFT MT Flows fin20112
    • FTM SWIFT MT Flows fin20122
    • FTM SWIFT MT Flows fin2013
    1 Supplied as a native XML schema library in FTM 3.

    2 Not supplied with FTM 3.

  2. Export all of your custom projects from a WebSphere® Message Broker 7 workspace into a project interchange (PI) file.
  3. Create an IBM® App Connect Enterprise workspace and import your custom projects.
  4. Unpack the FTM .zip files to obtain the project interchange .zip files that contain the product projects. Depending on which FTM projects you identified in your workspace, the areas you need to consider are shown in the following list.
    • FXH_Core_Projects_WMB.zip
      • FXH_Core_Projects_WMB_PI.zip
      • FXH_WTX_Integration_Flows_WMB_PI.zip
    • FXH_GenericModel.zip
      • FXH_GenericModel_WMB_PI.zip
  5. If your workspace includes FTM sample application resources, also unpack those projects:
    • FXH_Sample.zip
      • FXH_Sample_PI.zip
  6. From the product PI files, import the FTM projects that you were using in your application.
  7. After all of the projects are loaded, the IBM App Connect Toolkit finds problems in your workspace. The problems are because many key FTM flows were converted from msgflows to subflows and your flows are still referring to them by the old names.
    Typically, the following msgflows have a direct impact on an application:
    • EventProcessingFlow.v108.BeginAction
    • EventProcessingFlow.EndAction
    • EventProcessingFlow.BeginPublish
    • EventProcessingFlow.EndPublish
    • EventProcessingFlow.BeginOutboundMapper
    • EventProcessingFlow.EndOutboundMapper
    • EventProcessingFlow.EventProcessingFlow
    • EventProcessingFlow.WTXOutMap
    • PhysicalTransmissionFlow.BeginMapper
    • PhysicalTransmissionFlow.EndMapper
    • Common.FlowManager
    • Common.LogErrorFlow
    • Common.GenericErrorHandler
    • Mappers.ISFToISFMapper
    • Mappers.ISFToISFOutMapper
    • PhysicalTransmissionFlow.PhysicalTransmissionFlow
    • PhysicalTransmissionFlow.ComIbmFxhStandardsProcessing
    • PhysicalTransmissionFlow.WTXMap
    • InboundMappers.WTXGenericInMapper
    • OutboundMappers.WTXGenericOutMapper
    • Actions.Generic_FSM_Actions3
    3 All actions were migrated to subflows, but applications typically include all actions from this container.
  8. Typically, customer workspaces contain a single top-level application project. It is recommended that you split this project into two projects so that you can separate all your application actions and maps into a separate Library project.
To remove the errors from your application, you must correct all the broken references. This correction can be done in one of the following ways:
    1. Locate all msgflow references on your flows that cannot be resolved.
    2. Right-click and select Locate subflow.
    3. Browse to locate the subflow.
    4. When all are resolved, rebuild the workspace.
    1. Locate all the subflows that cannot be located. Right-click and select Convert to Message Flow.
    2. Reconvert the msgflow back to a subflow. Right-click and select Convert to Sub Flow. When it is converting back to a subflow, the toolkit can automatically update all references to the subflow.

Since the toolkit is modifying the product flows during this round-trip conversion, it is recommended that you reimport the product flows after the workspace errors are resolved. Reimporting the product flows ensures that they are restored to the exact same state as the product distribution.

Typically, the first option is the best for flows like EventProcessingFlow that are referenced once or twice by custom flows. The second option can significantly reduce the effort for migration of actions since they all reference BeginAction and EndAction.

Message set and native XML schema migration

If your workspace was using XMLNSC message sets but one or more of them was migrated to native XML schema libraries, you might need to change the application model for the affected FORMAT entries. Before the migration, the format configuration would specify a DOMAIN value of XMLNSC and a message set value. When native XML schema libraries are used, the message set value is no longer relevant, and must be cleared to an empty string or NULL. Failing to make this change means that the FTM runtime attempts to locate a message set by the name specified.

The clearing of the message set name requires a further change around parser settings. FTM uses the presence of the message set name when it starts the XMLNSC parsers to control the way the internal message tree is constructed by the XMLNSC.BuildTreeUsingSchemaTypes parser property. If a native schema is used, you can take explicit control of the XMLNSC.BuildTreeUsingSchemaTypes property by adding it to the new parser options property for the format entry. The parser options property is a comma-separated list of string values that must be understood by the parser to which they apply. Therefore, the parser options can be used to request any XMLNSC compatible setting not explicitly requested by FTM. For FTM 3.0.0, Fix Pack 3 and later, the available parser options are listed in the FTM Generic model under the classification scheme named PARSER_OPTIONS.