Physical Transmission Wrapper template

The Physical Transmission Wrapper template is made up of the following files:
  • PhysicalTransmissionWrapper.msgflow (see PhysicalTransmissionWrapper.msgflow)
  • MappersAndActions.subflow (see MappersAndActions.subflow)
  • IdentifyChannelByName.esql
  • IdentifyChannelByQueueName.esql
  • InChannelRouteToFailed.esql
Figure 1. PhysicalTransmissionWrapper.msgflow
PhysicalTransmissionWrapper.msgflow
Figure 2. MappersAndActions.subflow
MappersAndActions.subflow
A physical-transmission wrapper links the Physical Transmission message flow to input/output nodes. It includes the mappers and actions that the Physical Transmission message flow calls. The template includes the following input nodes:
MQ.IN.Input
This is provided as a single example input queue.
MQ.IN.Command
This is provided as the standard FTM Command queue.
You will almost certainly need to extend this template to add additional inputs such as IBM® MQ, HTTP, or file. The template routes normal and failure paths of the inputs into the subflow InChannel.msgflow before routing the input messages to the Physical Transmission message flow.
InChannel.msgflow, shown in InChannel.subflow, attempts to identify the inbound channel. Messages that arrive at the InputFailure terminal are routed to the failure Queue path of the main wrapper flow. The failure path will try to write the message to the channel specific failure queue or, if that fails, to the generic failure queue. If the inbound channel cannot be identified, the message is routed to the failure queue via the Unknown Channel trace node. This subflow allows you to specify the ESQL code that will run to identify the inbound channel.
Figure 3. InChannel.subflow
InChannel.subflow
The default action carried out by the template workspace is to identify the channel by name and load the channel definition details from the FTM database for use later in the process flows. The ESQL code that does this is contained in the IdentifyChannelByName.esql module, which contains the following code fragments:
  • Ensure that the Physical Transmission Flow is initialized.
    IF PTF_CONST_INIT = FALSE THEN
       CALL INIT_PTF_CONST(rEnv);
    END IF;
  • Declare and create space for the channel information to be looked up.
    
    CREATE LASTCHILD OF Environment.PMP.Variables NAME 'Channel';
    DECLARE rPMPVars                REFERENCE TO Environment.PMP.Variables;
    DECLARE refChannel              REFERENCE TO rPMPVars.Channel;
  • Lookup channel for the input.
    CALL Cache.GetChannelByName(Cache.GetFlowInstanceCacheId(rEnv), GetChannelName(), refChannel);
  • Propagate to either the good or the bad terminal.
    DECLARE bPropagate BOOLEAN EXISTS(refChannel.MAPPER_NAME[]);
    IF NOT bPropagate THEN
       -- Propagate to the Unknown channel terminal
       PROPAGATE TO TERMINAL 'out1';
    ELSE
       --------------------------------------------------------------------
       -- As of FTM 2.1.1 the FTM Core flows will set the entry label for 
       -- the ISF Mapper sub-flow if the wrapper does not set it.
       -- It is no longer recommended to handle this in the wrapper.
       --------------------------------------------------------------------
       --SET OutputLocalEnvironment.Destination.RouterList.DestinationData[1].labelname = <wrapper computed label>;
    END IF;
    
    RETURN bPropagate;
The template workspace also includes IdentifyChannelByQueueName.esql, which provides the ESQL to identify a channel by queue name. A brief description of the main code fragments follows:
  • Ensure that the Physical Transmission flow is initialized.
    IF PTF_CONST_INIT = FALSE THEN
       CALL INIT_PTF_CONST(rEnv);
    END IF;
  • Declare and create space for the channel information to be looked up.
    CREATE LASTCHILD OF Environment.PMP.Variables NAME 'Channel';
    DECLARE refChannel REFERENCE TO Environment.PMP.Variables.Channel;
  • Lookup all of the channels for the input and put it into a temporary variable space.
    DECLARE refChannels ROW;
    CALL Cache.GetChannelsForQueue(Cache.GetFlowInstanceCacheId(rEnv),
         InputRoot.MQMD.SourceQueue, refChannels);
  • Depending on the number of channels found, you might need to apply different logic. An example is provided in the template. Edit or rewrite it as required.
    DECLARE channelCount INTEGER CARDINALITY(refChannels.Channel[]);
    
    CASE channelCount
       WHEN 0 THEN PROPAGATE TO TERMINAL 'failure';
       WHEN 1 THEN SET refChannel = refChannels.Channel[1];
       ELSE
          -- Start Custom Channel selection
          -- < customize this code to suit project requirements >
          DECLARE chanField CHAR '';    -- TODO 
          DECLARE chanFieldVal CHAR ''; -- TODO
          SET refChannel = THE(SELECT * FROM refChannels.Channel[]
             AS C WHERE C.{chanField}=chanFieldVal);
    
          -- End Custom Channel selection
    END CASE;
  • Set the destination mapper name in the OutputLocalEnvironment.
    
    SET OutputLocalEnvironment.Destination.RouterList.DestinationData[1].labelname 
                            = refChannel.MAPPER_NAME;
MappersAndActions.msgflow includes the action and mapper containers used by the Physical Transmission message flow. In the template, the following containers are have been included as an example:
  • Inbound mappers template (see InboundMapperContainer.subflow)
  • Actions template (see ActionContainer_Template.msgflow)
  • Outbound mappers template (see OutboundMapperContainer.subflow)
The physical-transmission wrapper message flow requires the inbound mappers but might not need actions or outbound mappers. Requirements depend on the EVENT_TYPE.RENDER_AS_MSG settings.
Figure 4. InboundMapperContainer.subflow
nboundMapperContainer.msgflow
Figure 5. ActionContainer_Template.msgflow
ActionContainer_Template.msgflow
Figure 6. OutboundMapperContainer.subflow
OutboundMapperContainer.subflow