Flow identifiers

What is a flow identifier

A flow identifier, or IDF, is a unique identifier that is defined at each step in a flow when files are transferred using the PeSIT protocol. In the following diagram, for example, a Partner is an external partner, ST represents an instance of SecureTransport, and CFT represents an instance of Transfer CFT.

Picture of a flow with different identifiers in each stage of the flow.

When deploying to Transfer CFT in PeSIT, flow identifiers (idf parameters), are used in the send template and receive template (CFTSEND/CFTRECV) for each sender-receiver pair.

It is recommended that you use a unique flow identifier for each flow, but in certain use cases you can define multiple flows using the same flow identifier. Additionally, you can use the same flow identifier multiple times in the same flow. However, in store-and-forward cases the identifier must be the same throughout the store-and-forward path.

Flows with different identifiers

The following illustrates how different identifiers can be set in flows.

Picture of three flows with identifiers set between sender and receiver pairs.

Flows with the same identifier

PeSIT protocol only

This section illustrates reusing an IDF in multiple Central Governance flows.

This section describes use cases for creating multiple flows in Central Governance that share the same PeSIT identifier (IDF) between the same Transfer CFT and other entities, or between the same SecureTransport and some partners. After creating these flows, options are:

  • Deploy - Central Governance checks if there is another flow that uses the same PeSIT identifier as the current flow between the same Transfer CFT and other entities, including legacy flows, or between the same SecureTransport and some partners. If a conflict exists, the deployment status displays the reason why the deployment could not be done. The deployment status also provides a link to the Core Services logs, which gives details about the potential impact of this deployment.
  • Force deploy - The deployment proceeds without a notification about a conflict with other flows or legacy flows. However, you can find information about detected conflicts in the Core Services logs.

See Flow status and deployment for details. And for legacy flow details, see the Receive template fields and Send template fields sections.

Flows with the same PeSIT identifier between a specific Transfer CFT and other entities

This section describes deploying multiple flows when the same IDF is used between a specific Transfer CFT and other flow entities in more than one flow.

At flow deployment, Transfer CFT creates both a CFTSEND and CFTRECV that have as ID, the IDF of the flow. If an IDF is used in more than one flow, for a given Transfer CFT the same CFTSEND or CFTRECV object may already be deployed. In this case, the source or target properties defined in the flow currently being deployed overwrite the settings in the CFTSEND or CFTRECV object on the Transfer CFT.

If, during  deployment, a flow deployment attempts to overwrite a CFTSEND or CFTRECV object, this leads to a Transfer CFT IDF conflict. See the Transfer CFT Use case 1 and 2 below.

The send template's (CFTSEND) uniqueness is derived from its ID combined with the IMPL setting. See the Transfer CFT use case 4 below. For each flow that has a Transfer CFT IDF conflict with another Central Governance flow, if you select Deploy, the deployment status indicates why the deployment could not be done and there is a warning entry in Core Services logs about the potential impact.

Note If multiple flows use the same Transfer CFT and the same IDF, the last deployed flow overwrites the FLOWNAME field from the CFTSEND/CFTRECV object. This FLOWNAME value is used by Sentinel when executing commands.
Note When several flows share the same IDF between a Transfer CFT and other products, if you remove a flow from Central Governance it may happen to be the most recently deployed flow. As a result, the configuration on the Transfer CFTs is the last deployed one, and may differ from the Transfer CFT configuration in the remaining flows in Central Governance. The configuration on the Transfer CFT does not change because of this flow removal. To synchronize Central Governance with the Transfer CFTs, in Central Governance make a small change in one of the remaining flows with the same IDF and deploy it.

Use cases that generate an IDF conflict

Transfer CFT use case 1: The same Transfer CFTs are using the same IDF in different flows

Different flows connecting the same Transfer CFTs via the same IDF, while the Transfer CFTs are part of different applications in each flow.

Transfer CFT use case 2: There is an IDF conflict between a flow with relay and one without relay

In this use case, there is a Transfer CFT CFTSEND object that is already deployed in a flow. A second flow, that happens to have a relay, uses the same target Transfer CFT and IDF, and tries to overwrite the first (deployed) CFTSEND.

Flow use cases that do not generate an IDF conflict

Transfer CFT use case 3: The current flow uses the same IDF as another flow that has not yet been deployed

When there are two flows that share the same IDF on the same Transfer CFT, and a deployment is initiated on one of the flows, the IDF conflict is not triggered as long as the other flow is not yet deployed.

Transfer CFT use case 4: Two CFTSEND objects with the same ID and different IMPL values are deployed on a Transfer CFT

The CFTSEND objects have the same ID, but do not conflict with one another because the defined direction (push/pull) is not the same.

In the following example, deployment of both flows creates CFTSEND objects with the same ID. However, there is no conflict because:

  • The first flow direction is set to Sender pushes file, meaning IMPL= No is deployed on the source Transfer CFT.
  • The second flow direction is set to Receiver pulls file, meaning IMPL=Yes is deployed on the source Transfer CFT.

Flows using the same PeSIT identifier between SecureTransport and partners

The following use cases are based on creating multiple flows in Central Governance, which share the same PeSIT identifier (IDF) between partners and a SecureTransport.

SecureTransport use case 1: SecureTransport sends and receives files using the same IDF

SecureTransport receives files from a partner having a PeSIT identifier, and sends files back to that same partner using the same PeSIT identifier.

 

SecureTransport use case 2: SecureTransport pushes files to a partner and the partner pulls files from SecureTransport using the same IDF

SecureTransport pushes files to a partner using a PeSIT IDF, and that same partner, or another partner, pulls files from the SecureTransport using the same IDF.

SecureTransport use case 3: Multiple partners communicate with the SecureTransport using the same IDF

SecureTransport uses the same IDF for all partners, but different IDFs for each Transfer CFT when pushing files.

 

Or, SecureTransport receives files from different Transfer CFTs, via different IDFs, and pushes files to different partners via the same IDF.

Note When multiple flows use the same IDF, the last deployed flow can overwrite properties in the SecureTransport account's transfer profile, subscription, or route.

SecureTransport use case 4: Partner pushes and SecureTransport pulls files using the same IDF

Not supported

The partner pushes files to a SecureTransport using a PeSIT IDF, and the SecureTransport pulls files from the same partner using the same IDF.

 

Central Governance | Document Directory

Related Links