> ## 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.

# Branch Connector

> Routes messages along different flow paths based on configurable conditions, supporting filename, header, XPath, and EDI metadata comparisons.

export const NameDescription = ({extraRows}) => <table>
    <thead>
      <tr>
        <th>Setting</th>
        <th>Description</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td><strong>Connector Id</strong></td>
        <td>The static, unique identifier for the connector.</td>
      </tr>
      <tr>
        <td><strong>Connector Type</strong></td>
        <td>Displays the connector name and a description of what it does.</td>
      </tr>
      <tr>
        <td><strong>Connector Description</strong></td>
        <td>An optional field to provide a free-form description of the connector and its role in the flow.</td>
      </tr>
      {extraRows}
    </tbody>
  </table>;

export const SlasTab = ({siteName = "CData Arc"}) => <>
    <p><em>Settings related to configuring Service Level Agreements (SLAs).</em></p>
    <p>
      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. {siteName} sends emails to warn the user when an SLA is not met, and marks the SLA as <em>At Risk</em>, which means that if the SLA is not met soon, it will be marked as <em>Violated</em>. 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.
    </p>
    <p>
      To define an SLA, toggle <strong>Expected Volume</strong> on, then click the <strong>Settings</strong> tab.
    </p>
    <img src="/public/images/sla_empty.png" alt="SLA Empty" />
    <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 <strong>Expect at least</strong> portion of the window:
        <ul>
          <li>Set the minimum number of transactions you expect to be processed (the volume)</li>
          <li>Use the <strong>Every</strong> fields to specify the time frame</li>
          <li>Indicate when the SLA should go into effect. If you choose <strong>Starting on</strong>, 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 <strong>Everyday</strong> if necessary.</li>
        </ul>
      </li>
      <li>In the <strong>Set status to 'At Risk'</strong> 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 <strong>Send an 'At Risk' notification</strong>.</li>
        </ul>
      </li>
    </ul>
    <p>
      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.
    </p>
    <img src="/public/images/sla_defined.png" alt="SLA Configuration Example" />
    <Note>
      You can turn off SLA alerts if necessary. This can be useful during maintenance windows. Click <strong>Settings</strong> on the navbar, then navigate to <strong>Alerts &gt; General Alerts</strong>. Click the tablet and pencil icon to edit, and uncheck the <strong>SLA Alerts</strong> setting.
    </Note>
  </>;

export const AlertsTab = ({siteNameShort = "Arc"}) => <>
    <p><em>Settings related to configuring alerts.</em></p>
    <p>
      Before you can execute Service Level Agreements (SLAs), you need to set up email alerts for notifications. By default, {siteNameShort} uses the global settings on the <a href="/26.2/self-hosted/en/getting-started/administration/settings/alerts">Alerts</a> tab. To use other settings for this connector, toggle <strong>Override global setting</strong> on.
    </p>
    <p>
      By default, error alerts are enabled, which means that emails are sent whenever there is an error. To turn them off, uncheck the <strong>Enable</strong> checkbox.
    </p>
    <p>
      Enter a <strong>Subject</strong> (mandatory), then optionally enter a comma-separated list of <strong>Recipient</strong> emails.
    </p>
  </>;

export const Message = () => <>
    <p><em>Message settings determine how the connector searches for messages and manages them after processing.</em></p>
    <table>
      <thead>
        <tr><th>Setting</th><th>Description</th></tr>
      </thead>
      <tbody>
        
          <tr>
            <td><strong>Save to Sent Folder</strong></td>
            <td>Check this to copy files processed by the connector to the Sent folder for the connector.</td>
          </tr>
        
        <tr>
          <td><strong>Sent Folder Scheme</strong></td>
          <td>Instructs the connector to group files in the <strong>Sent</strong> folder according to the selected interval. For example, the <strong>Weekly</strong> option instructs the connector to create a new subfolder each week and store all sent files for the week in that folder. The blank setting instructs the connector to save all files directly in the <strong>Sent</strong> folder. For connectors that process many transactions, using subfolders can help keep files organized and improve performance.</td>
        </tr>
      </tbody>
    </table>
  </>;

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

export const Logging = () => <>
    <p><em>Settings that govern the creation and storage of logs.</em></p>
    <table>
      <thead>
        <tr>
          <th>Setting</th>
          <th>Description</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <td><strong>Log Level</strong></td>
          <td>The verbosity of logs generated by the connector. When you request support, set this to <strong>Debug</strong>.</td>
        </tr>
        <tr>
          <td><strong>Log Subfolder Scheme</strong></td>
          <td>Instructs the connector to group files in the Logs folder according to the selected interval. The <strong>Weekly</strong> 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><strong>Log Messages</strong></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 <strong>Transactions</strong> tab.</td>
        </tr>
      </tbody>
    </table>
  </>;

export const Performance = () => <>
    <p><em>Settings related to the allocation of resources to the connector.</em></p>
    <table>
      <thead>
        <tr>
          <th>Setting</th>
          <th>Description</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <td><strong>Max Workers</strong></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 <a href="/26.2/self-hosted/en/getting-started/administration/settings/performance-settings">Performance Settings</a> portion of the <a href="/26.2/self-hosted/en/getting-started/administration/settings/advanced-settings">Advanced Settings</a> page.</td>
        </tr>
        <tr>
          <td><strong>Max Files</strong></td>
          <td>The maximum number of files sent by each thread assigned to the connector. If set, this overrides the default setting on the <a href="/26.2/self-hosted/en/getting-started/administration/settings/performance-settings">Performance Settings</a> portion of the <a href="/26.2/self-hosted/en/getting-started/administration/settings/advanced-settings">Advanced Settings</a> page.</td>
        </tr>
      </tbody>
    </table>
  </>;

export const siteNameShort = "Arc";

export const siteName = "CData Arc";

A Branch connector functions as a fork in the flow. Files are sent along different paths in the flow depending on whether a condition specified in the connector is true.

## Key Capabilities

* Intelligent flow routing based on configurable conditions (filename, headers, XPath, and EDI metadata)
* Support for multiple data types (such as string, number, DateTime) with flexible comparison operators
* Advanced XPath evaluation for XML document routing
* EDI-specific metadata branching for document type routing

## Overview

Branch conditions can check for these different types of values:

* the filename
* a header on the message
* all matching XPaths
* the first matching XPath
* one or more matching XPaths
* [EDI](./edi-connectors) metadata

**Notes**:

* To use the XPath options, the file being evaluated must be an XML file.
* EDI metadata branching can only be used on EDI documents.

The Branch connector configuration determines which value to look for, and the *target* values to compare against. If an incoming value matches a target value, the message is passed along a dotted blue flow path. You can have multiple target values, each of which sends the message along a different flow path. If the values do not match any of the conditions, the message is passed along the dotted gray path.

<img src="https://mintcdn.com/cdata-arc/Lo_2D5t4szDfleFN/public/images/branch_flow.png?fit=max&auto=format&n=Lo_2D5t4szDfleFN&q=85&s=234204706c83402deae65d8831b6b3fd" width="800" data-path="public/images/branch_flow.png" />

See [Branching on Message Headers](#branching-on-message-headers) for a detailed explanation of the image above.

## Connector Configuration

This section contains all of the configurable connector properties.

### Branch Config Tab

*Settings related to configuring the branch conditions.*

The branch settings allow you to specify multiple conditions for a single source value to define your branches.

<table>
  <thead>
    <tr>
      <th>Setting</th>
      <th>Description</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><strong>Sample File</strong></td>
      <td>If you upload a sample XML file, the connector shows the document structure when you use an XPath for comparison. An example is shown below.</td>
    </tr>

    <tr>
      <td><strong>If</strong></td>
      <td>Use the dropdown to specify what attribute to compare when messages are received. Options are: the message header, the filename, all matching XPaths, the first matching XPath, one or more matching XPaths, or EDI metadata. Once you make your selection, use the fields to the right to further define the condition, as shown in the <strong>Sample File</strong> image above.</td>
    </tr>

    <tr>
      <td><strong>Data Type</strong></td>
      <td>Whether the target value is a string, number, or DateTime. If your data type is <strong>String</strong>, use the <strong>Trim string</strong> and <strong>Ignore case</strong> checkboxes to further refine the comparison. If your data type is <strong>DateTime</strong>, use the field to the right to specify how your DateTime values are structured.</td>
    </tr>

    <tr>
      <td><strong>Trim String</strong></td>
      <td>Whether the string comparison should ignore whitespace.</td>
    </tr>

    <tr>
      <td><strong>Ignore Case</strong></td>

      <td>
        <p>Whether the string comparison should be case-sensitive.</p>

        <img src="https://mintcdn.com/cdata-arc/-adMVRA2NGLWRgFp/public/images/branch_sample_file.png?fit=max&auto=format&n=-adMVRA2NGLWRgFp&q=85&s=0442c1d62004950dc9be91a1fcc8ba26" width="400" data-path="public/images/branch_sample_file.png" />

        <p>The center portion of the branch settings section (shown in the image below) allows you to set as many conditions as you need. Hover above or below the white pane and select <strong>Add Case</strong> to add conditions.</p>

        <img src="https://mintcdn.com/cdata-arc/Lo_2D5t4szDfleFN/public/images/branch_conditions.png?fit=max&auto=format&n=Lo_2D5t4szDfleFN&q=85&s=cda0584f06735a5789bd83b69357a5ee" width="500" data-path="public/images/branch_conditions.png" />

        <p>Each condition is made up of three components:</p>

        <ul>
          <li>the operator (for example, <em>is equal to, contains, starts with,</em> or <em>matches regex</em>)</li>
          <li>the value to compare with the value found in the file</li>
          <li>the <em>Then output to</em> component</li>
        </ul>

        <p>As you create your flow, connect a different connector to each case statement in the Branch connector to establish the <em>Then output to</em> connectors. Finally, connect a different connector to the <strong>Else</strong> case to tell {siteNameShort} what to do if none of the other conditions are satisfied.</p>
      </td>
    </tr>

    <tr>
      <td><strong>Ignore Missing Values</strong></td>
      <td>Whether to treat missing headers or XPaths as an empty string (not applicable when your <strong>If</strong> selection is <em>Filename</em>). This avoids errors being thrown when an expected header or XPath is missing, and instead passes the message along the 'does not match' Flow path.</td>
    </tr>
  </tbody>
</table>

### Settings Tab

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

<NameDescription />

### Advanced Tab

#### Message

<Message />

#### Logging

<Logging />

#### 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](../flows/designing-a-flow#interacting-with-the-local-file-system) to manage local file systems instead of this setting. |

#### Miscellaneous

<MiscConnector />

### Automation Tab

#### Automation Settings

| Setting  | Description                                                             |
| -------- | ----------------------------------------------------------------------- |
| **Send** | Whether messages arriving at the connector are automatically processed. |

#### Performance

<Performance />

### Alerts Tab

<AlertsTab />

### SLAs Tab

<SlasTab />

## Examples Using the Branch Connector

The following examples describe common Branch connector use cases.

### Branching on Message Headers

In this example, your business receives multiple types of EDI documents from a trading partner, and you need the different types to be processed differently.

<img src="https://mintcdn.com/cdata-arc/Lo_2D5t4szDfleFN/public/images/branch_flow_input.png?fit=max&auto=format&n=Lo_2D5t4szDfleFN&q=85&s=9d8c1f3a8ed327b0b19a0cb18eaed132" width="800" data-path="public/images/branch_flow_input.png" />

The image above illustrates a situation where you send a trading partner purchase orders. They then send you two different types of EDI documents: one is an 855 purchase order acknowledgement and one is an 810 invoice. The [X12 connector](./x12) before the Branch connector in the flow appends **X12-TransactionCode** to each message header.

<img src="https://mintcdn.com/cdata-arc/Lo_2D5t4szDfleFN/public/images/branch_flow.png?fit=max&auto=format&n=Lo_2D5t4szDfleFN&q=85&s=234204706c83402deae65d8831b6b3fd" width="800" data-path="public/images/branch_flow.png" />

The Branch connector uses the transaction code in the message header to tell {siteNameShort} what to do when it receives an 810 or an 855 EDI document, and what to do if it receives a document that does not have either of those transaction codes.

* When an 810 document is received, the next step in the flow sends it to the invoices table of the back-end system (PostgreSQL in this example.)
* When an 855 document is received, the next step in the flow sends it to a PO acknowledgement table in the back-end system.
* When any other type of document is received, the **Else** condition uses a [Notify connector](./notify) to send an email to an administrator for manual processing.

### Branching on EDI Metadata

In this example, your business receives X12 documents from multiple companies, and you need the documents from two companies to be sent to specific [Workspaces](../flows/workspaces) for further processing.

<img src="https://mintcdn.com/cdata-arc/Lo_2D5t4szDfleFN/public/images/branch_edimetadata.png?fit=max&auto=format&n=Lo_2D5t4szDfleFN&q=85&s=3964ab5d4fb2dacb057da4c7d8ddb177" width="800" data-path="public/images/branch_edimetadata.png" />

The image above illustrates a situation where two companies send you X12 documents. The Branch connector uses the X12 Metadata **InterchangeSenderId** to specify where the documents should be delivered.

* When a document is received from CompanyA, the next step in the flow sends it to the CompanyA workspace.
* When a document is received from CompanyB, the next step in the flow sends it to the CompanyB workspace.
* When any other type of document is received, the **Else** condition uses a [Notify connector](./notify) to send an email to an administrator alerting them that an inbound X12 document did not match one of the two expected companies.

The company-specific workspaces might then contain a [Workspace Receive](./workspace-receive) connector to receive incoming documents (required because the [Workspace Send](./workspace-send) connector was used in the Branch flow), an [X12 connector](./x12) with identifiers that enable translation of the raw X12 data into XML, an [XML Map](./xml-map/xml-map) connector to handle mapping the XML to the destination, and finally a destination connector ([PostgreSQL](./postgresql/postgresql) in the following image).

<img src="https://mintcdn.com/cdata-arc/Lo_2D5t4szDfleFN/public/images/branch_edimetadata_output.png?fit=max&auto=format&n=Lo_2D5t4szDfleFN&q=85&s=646b24c49ee37cc9bddc83d6b79c35ae" width="800" data-path="public/images/branch_edimetadata_output.png" />