> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Finalize Connector

> The Finalize connector completes a deferred source message after the downstream flow succeeds, so the source connector can safely clean up.

The Finalize connector completes a deferred source message. Place it at the end of the success path of a flow to confirm that the flow processed a file successfully, so the connector that received the file can perform its post-processing, such as deleting the source file. The Finalize connector is included with CData Arc and does not require a separate license.

> [!NOTE]
>
> Only the [File connector](https://docs.arc.cdata.com/26.4/self-hosted/en/connectors/file.md) can defer finalization. Other source connectors do not support this feature.

## Key Capabilities

* Deferred cleanup of source files, so a received file is not deleted until the downstream flow succeeds
* Automatic timeout handling that releases pending files for another receive without deleting the source
* No configuration required to link to the source connector, because the message carries the information needed to find it
* Clear error messages when a message cannot be finalized

## Overview

By default, a source connector such as the File connector completes a message as soon as it receives it. Any post-processing, such as deleting the file from the source folder, happens immediately, even if the downstream flow later fails.

When you enable **Defer received-file finalization** on the File connector, the connector holds each received file in a pending state instead. The Finalize connector completes the pending file after the rest of the flow succeeds.

When a message reaches the Finalize connector, the connector:

1. Reads the deferred source information that the message carries.
2. Finds the source connector that received the file.
3. Tells the source connector to finalize the file, which triggers the source connector's configured cleanup (for example, deleting the file when **Delete files (after received)** is enabled).

The Finalize connector has no output. It can only be used as the last connector in a [flow](https://docs.arc.cdata.com/26.4/self-hosted/en/flows/flows.md).

## Connector Configuration

This section contains all of the configurable connector properties.

### Settings Tab

*Settings related to the core configuration of the connector.*

<table><thead><tr><th>Setting</th>
<th>Description</th></tr></thead>
<tbody><tr><td>**Connector Id**</td>
<td>The static, unique identifier for the connector.</td></tr>
<tr><td>**Connector Type**</td>
<td>Displays the connector name and a description of what it does.</td></tr>
<tr><td>**Connector Description**</td>
<td>An optional field to provide a free-form description of the connector and its role in the flow.</td></tr></tbody></table>

### Advanced Tab

#### Other Settings

| Setting | Description |
| - | - |
| **Processing Delay** | The amount of time (in seconds) by which the processing of files placed in the **Transactions** tab is delayed. This is a legacy setting. Best practice is to [use a File connector](https://docs.arc.cdata.com/26.4/self-hosted/en/flows/designing-a-flow.md#interacting-with-the-local-file-system) to manage local file systems instead of this setting. |

#### Logging

*Settings that govern the creation and storage of logs.*

<table><thead><tr><th>Setting</th>
<th>Description</th></tr></thead>
<tbody><tr><td>**Log Level**</td>
<td>The verbosity of logs generated by the connector. When you request support, set this to **Debug**.</td></tr>
<tr><td>**Log Subfolder Scheme**</td>
<td>Instructs the connector to group files in the Logs folder according to the selected interval. The **Weekly** option (which is the default) instructs the connector to create a new subfolder each week and store all logs for the week in that folder. Leaving this setting blank tells the connector to save all logs directly in the Logs folder. For connectors that process many transactions, using subfolders helps keep logs organized and improves performance.</td></tr>
<tr><td>**Log Messages**</td>
<td>Check this to have the log entry for a processed file include a copy of the file itself. If you disable this, you might not be able to download a copy of the file from the **Transactions** tab.</td></tr></tbody></table>

#### Miscellaneous

*Miscellaneous settings are for specific use cases.*

<table><thead><tr><th>Setting</th>
<th>Description</th></tr></thead>
<tbody><tr><td>**Other Settings**</td>
<td>Enables you to configure hidden connector settings in a semicolon-separated list (for example, `setting1=value1;setting2=value2`). Normal connector use cases and functionality should not require the use of these settings.</td></tr></tbody></table>

### Automation Tab

#### Automation Settings

*Settings related to the automatic processing of files by the connector.*

| Setting | Description |
| - | - |
| **Send** | A toggle that instructs the connector to automatically send files when they are ready. |
| **Retry Interval** | The interval the connector waits before retrying a failed send. |
| **Max Attempts** | The number of attempts the connector makes to send the message. Setting this value to *1* instructs the connector to only make the initial send attempt without retrying. The connector waits the duration specified by **Retry Interval** between each attempt. |

#### Performance

*Settings related to the allocation of resources to the connector.*

<table><thead><tr><th>Setting</th>
<th>Description</th></tr></thead>
<tbody><tr><td>**Max Workers**</td>
<td>The maximum number of worker threads consumed from the threadpool to process files on this connector. If set, this overrides the default setting on the [Performance Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/performance-settings.md) portion of the [Advanced Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/advanced-settings.md) page.</td></tr>
<tr><td>**Max Files**</td>
<td>The maximum number of files sent by each thread assigned to the connector. If set, this overrides the default setting on the [Performance Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/performance-settings.md) portion of the [Advanced Settings](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/advanced-settings.md) page.</td></tr></tbody></table>

### Alerts Tab

*Settings related to configuring alerts.*

Before you can execute Service Level Agreements (SLAs), you need to set up email alerts for notifications. By default, Arc uses the global settings on the [Alerts](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/settings/alerts.md) tab. To use other settings for this connector, toggle **Override global setting** on.

By default, error alerts are enabled, which means that emails are sent whenever there is an error. To turn them off, uncheck the **Enable** checkbox.

Enter a **Subject** (mandatory). Check **Allow ArcScript in Subject** to use ArcScript in the **Subject** field. When you select this, the **ArcScript Editor** button appears (![arcscript editor button](https://docs.arc.cdata.com/26.4/images/rest_arcscript_editor.png)).

Optionally, enter a comma-separated list of **Recipient** emails.

### SLAs Tab

*Settings related to configuring Service Level Agreements (SLAs).*

SLAs enable you to configure the volume you expect connectors in your flow to send or receive, and to set the time frame in which you expect that volume to be met. CData Arc sends emails to warn the user when an SLA is not met, and marks the SLA as *At Risk*, which means that if the SLA is not met soon, it will be marked as *Violated*. This gives the user an opportunity to step in and determine the reasons the SLA is not being met, and to take appropriate actions. If the SLA is still not met at the end of the at-risk time period, the SLA is marked as violated, and the user is notified again.

SLA transitions to *At Risk* or *Violated* are also written to the [application log](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/activity.md#application-logs), which means that Application Performance Monitoring (APM) and log-ingestion tools can also alert on them.

To define an SLA, toggle **Expected Volume** on, then click the **Settings** tab.

![SLA Empty](https://docs.arc.cdata.com/26.4/images/sla_empty.png)
<ul><li>If your connector has separate send and receive actions, use the radio buttons to specify which direction the SLA pertains to.</li>
<li>In the **Expect at least** portion of the window:
<ul><li>Set the minimum number of transactions you expect to be processed (the volume)</li>
<li>Use the **Every** fields to specify the time frame</li>
<li>Indicate when the SLA should go into effect. If you choose **Starting on**, complete the date and time fields.</li>
<li>Check the boxes for the days of the week that you want the SLA to be in effect. Use the dropdown to choose **Everyday** if necessary.</li></ul></li>
<li>In the **Set status to 'At Risk'** portion of the window, specify when the SLA should be marked as at risk.
<ul><li>By default, notifications are not sent until an SLA is in violation. To change that, check **Send an 'At Risk' notification**.</li></ul></li></ul>

The following example shows an SLA configured for a connector that expects to receive 1000 files every day Monday-Friday. An at-risk notification is sent 1 hour before the end of the time period if the 1000 files have not been received.

![SLA Configuration Example](https://docs.arc.cdata.com/26.4/images/sla_defined.png)

> [!NOTE]
>
> You can turn off SLA alerts if necessary. This can be useful during maintenance windows. Click **Settings** on the navbar, then navigate to **Alerts > General Alerts**. Click the tablet and pencil icon to edit, and uncheck the **SLA Alerts** setting.

### Transactions Tab

This tab lists all messages associated with the connector. Use the search bar to find specific messages, or click the funnel icon to apply a filter. You can filter by time, message direction, and/or status.

## Using Finalize with the File Connector

To delay deletion of a received file until the flow succeeds:

1. On the File connector that receives the files, enable **Defer received-file finalization** and, if you want the source files removed, **Delete files (after received)**. See [Receive](https://docs.arc.cdata.com/26.4/self-hosted/en/connectors/file.md#receive).
2. Build the rest of the flow that processes the file.
3. Add a Finalize connector and connect it to the **Success Path** of the last connector that processes the file.

For example, a flow that receives files with a File connector, translates them with an X12 connector, upserts the data into SQL Server, and then finalizes them is configured as follows:

![A flow with a File connector, an X12 connector, a SQL Server connector, and a Finalize connector](https://mintcdn.com/cdata-arc/yfA3o6U6SThtnLN0/26.4/images/finalize-flow.png?fit=max\&auto=format\&n=yfA3o6U6SThtnLN0\&q=85\&s=c5714d55ee8a25aa6bae5c676cb5d908)

1. The File connector receives a file from its configured path and holds it as pending.
2. The X12 connector translates the file to XML.
3. The SQL Server connector upserts the XML data into SQL Server.
4. The SQL Server connector's **Success Path** is connected to the Finalize connector, which completes the pending file.

Only the File connector that receives the files at the start of the flow can defer finalization. A File connector later in the flow that sends files to a folder does not defer anything, but the flow can still end with a Finalize connector that completes the original file.

The file remains pending, and is excluded from being received again, until one of the following happens:

* **The file reaches the Finalize connector.** The File connector completes the file and performs the configured cleanup.
* **The pending timeout is reached.** The **Receive Pending Timeout (minutes)** setting on the File connector's [Automation tab](https://docs.arc.cdata.com/26.4/self-hosted/en/connectors/file.md#automation-settings) controls this timeout. The message is marked with a Pending Timeout error, the source file is not deleted, and the file is released so that it can be received again.

> [!NOTE]
>
> Messages that do not come from a connector with deferred finalization enabled cannot be finalized. Sending a regular message to the Finalize connector results in an error.

### Source File Changes

If the source file changes between the time it is received and the time it is finalized, the connector does not delete it. The application log contains the following message, where `{0}` is the name of the file:

`Source file '{0}' changed after it was received. Deferred finalization will not delete it.`

### Pending Timeout

The **Receive Pending Timeout (minutes)** setting on the File connector's **Automation** tab controls how long a received file stays pending. The default is 10 minutes, and setting it to 0 keeps files pending indefinitely. If a pending message is not finalized before the timeout elapses:

* The application log records that the message exceeded the pending timeout while waiting for finalization.
* An error notification is sent with the subject **Send Failure: Pending Timeout**.
* The message is marked with a Pending Timeout error. This appears as **Error** in the **Transactions** tab.
* The source file is not deleted, and the file becomes eligible to be received again.

The pending-message check runs as the **Check Pending** automation action. At the **Debug** [log level](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/activity.md#log-level), the [automation log](https://docs.arc.cdata.com/26.4/self-hosted/en/getting-started/administration/activity.md#automation-logs) records each check and the number of timed-out messages it handled.

### Deferred Message Information

A file that is held for deferred finalization carries extra information in its message headers. To view the headers, open the message on the **Transactions** tab of the File connector and go to the **Details** tab.

| Header | Description |
| - | - |
| **File-Deferred-Source** | The path of the source file that is waiting to be finalized. |
| **Defer-Finalize** | The workspace, connector, and message Id that are part of the finalize chain. The Finalize connector uses this header to find the source connector and the pending message to complete. |
| **Processed** | Lists each connector that processed the message and its status. The File connector with deferred finalization is listed as **Pending** until the message is finalized. |

## Troubleshooting

The Finalize connector reports the following errors when it cannot complete a message.

| Error | Cause and resolution |
| - | - |
| The message has no deferred source lineage. | The message did not come from a connector with deferred finalization enabled. Enable **Defer received-file finalization** on the File connector that starts the flow. To confirm, check that the message has a **Defer-Finalize** header in its details. |
| The deferred source lineage is invalid or has already been completed. | The information that identifies the source message is malformed, or the message was already finalized. Check that the flow does not send the same message to Finalize more than once. |
| The deferred source connector `{workspace}:{connector}` does not exist. | The source connector was deleted or renamed after it received the file. Restore the connector, or process the file again from the source. |
| The deferred source connector `{workspace}:{connector}` is busy. | The source connector is processing other work. Retry the send after the source connector finishes. |
| The pending source message `{id}` does not exist in `{workspace}:{connector}`. | The pending message timed out before it reached the Finalize connector. If this happens regularly, check whether the flow is taking longer than the File connector's **Receive Pending Timeout (minutes)** to complete, and increase the timeout if needed. |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.