Branch Connector

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

Setting	Description
Sample File	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.
If	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 Sample File image above.
Data Type	Whether the target value is a string, number, or DateTime. If your data type is String, use the Trim string and Ignore case checkboxes to further refine the comparison. If your data type is DateTime, use the field to the right to specify how your DateTime values are structured.
Trim String	Whether the string comparison should ignore whitespace.
Ignore Case	Whether the string comparison should be case-sensitive. 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 Add Case to add conditions. Each condition is made up of three components: the operator (for example, is equal to, contains, starts with, or matches regex) the value to compare with the value found in the file the Then output to component As you create your flow, connect a different connector to each case statement in the Branch connector to establish the Then output to connectors. Finally, connect a different connector to the Else case to tell what to do if none of the other conditions are satisfied.
Ignore Missing Values	Whether to treat missing headers or XPaths as an empty string (not applicable when your If selection is Filename). 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.

​

Settings Tab

Settings related to the core operation of the connector.

​

Advanced Tab

​

Logging

​

Other Settings

​

Miscellaneous

​

Automation Tab

​

Automation Settings

​

Performance

​

Alerts Tab

​

SLAs Tab

​

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. 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 before the Branch connector in the flow appends X12-TransactionCode to each message header. The Branch connector uses the transaction code in the message header to tell 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 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 for further processing. 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 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 connector to receive incoming documents (required because the Workspace Send connector was used in the Branch flow), an X12 connector with identifiers that enable translation of the raw X12 data into XML, an XML Map connector to handle mapping the XML to the destination, and finally a destination connector (PostgreSQL in the following image).