Troubleshoot flow deployment

Flow deployment may fail for one of multiple reasons before deploying on individual products. In case of a failure, the flow status is Deployed in error or Saved, not deployed, the status Details provide a reason for the failure, and the Core Services logs provide additional information.

This section provides some examples of why a deployment might fail, and corrective actions when applicable.

Flow deployment fails due to the custom attributes values

The custom attributes values used in a flow cannot be validated in GUI when the flow is saved. The flow deployment fails if either:

  • The custom attribute value is out of the range for a flow field.
  • The custom attribute defined in the Transfere CFT Partner template configuration file is not set correctly for an application used in the flow. See Transfer CFT partner template.

Flow deployment fails when trying to overwrite objects from other flows

Example 1: NSPART conflict

A previous flow deployment created a CFTPART object on the same Transfer CFT, which the current flow is trying to overwrite. However, the value of the NSPART field in this CFTPART object is different from the one the current flow is trying to deploy. To prevent overwriting the NSPART value deployed by the first flow, Central Governance does not allow the second flow deployment.

Example 2: Flow conflicts with a flow that has a relay

Example 2.a: Using a physical CFTPART identifier

A flow with Transfer CFTs as source and target, which does not have a relay, is already deployed.

A second flow with the same source and target as the first flow, also has a relay. When deploying the second flow, the flow deployment has an error before starting the deployment on products. Thus there is no information about the second flow in the Deployments list page.

Example 2.b: Using a logical CFTPART identifier

A flow with Transfer CFTs as source and target that uses application name as CFTPART identifier is deployed successfully.

A second flow has the same source as the first flow. The relay from the second flow is the same as the target from the first flow. The protocol between source and relay is set to use the physical name as the CFTPART identifier. When deploying the second flow, the flow deployment has an error before starting the deployment on products. Therefore, no information about the second flow displays in the Deployments list page.

Example 3: Flows with a logical identifier and the receiver pulls updated files from the REST API

A flow with Transfer CFTs as source and target has the protocol direction set as Receiver pulls. From the Rest API set the application name to use as CFTPART identifier. The flow deployment fails before the deployment on products is started because the application name as CFTPART identifier is an option available only when the direction of the protocol is Sender pushes files.

Note You cannot create this flow type from the user interface.

 

Central Governance | Document Directory

Related Links