3.2 - Building Connectors

Connectors get and send data in and out of Processes. They represent the applications or data sources between which data needs to move, or in other words, the "end points" of the Process. Those applications and data sources can range from traditional on-premise applications like SAP and QuickBooks to Web-based applications like Salesforce.com and NetSuite to data repositories like an FTP directory, a commercial database, or even an email server.

Connectors abstract the technical details of the application interfaces (API) and transportation protocols used to communicate with various applications and data sources, allowing you to focus on the business data and logic of the integration. A Connector is really a combination two Components: a Connection and an Operation. Think of the Connection as the where and the Operation as the how. These two components determine the type of data source, how to physically connect to it, and what type of data records to exchange.

The following table lists some examples to help illustrate the difference between Connections and Operations and what kind of information is configured in each.

For information on how to configure the Connections and Operations for specific Connectors, see the individual Connector documentation under Available Connectors.

Using Connectors in a Process

Every Process begins with a mandatory "Get" Connector called the Start Shape and typically ends with one or more "Send" Connectors. Many Processes will only need to use two Connectors (for the source and destination). However additional Connectors may be needed depending on the specific integration requirements, such as if the data needs to be sent to multiple destinations or email notifications sent under certain conditions, for example.

Connectors are also used in the middle of the Process when the integration requires "reaching out" to a data source for some reason, often to perform a lookup, cross reference, or arbitrary database statements in a Decision, Program Command, or Map Function.

Get vs. Send

There are two generic Actions Connectors can perform: Get and Send. When configuring a Connector Step in a Process, you specify the Action. The Connector Step should reference an Operation component of the same Action type. In addition to filtering the list of Operations to choose from, the Action affects how data is processed.

It is important to understand the basic yet fundamental difference between Get and Send Actions.

• Get - Connector retrieves data from a given source and returns it to the Process for further processing. The Connector call configured in the Start Shape will always perform a "Get" action. This is the only "Get" Connector whose Documents are logged as Inbound Data on the Manage Tab. Documents retrieved by "Get" Connectors used mid-process or within another Process step (as a lookup for example), are not logged.
• Send - Connector sends data to a given destination but does not return any data to the Process for further processing. Documents sent via Connector steps in the Process are logged as Outbound Data on the Manage Tab.

Some Connectors only have support the Get Action. In these cases, every Connector call consists of a request message and a response message. When getting data (usually in the Start Shape), the request message typically contains the selection criteria and the response message contains the resulting data records. When sending data, the request message contains the data records to insert/update and the response message typically contains the resulting transaction status (success/failure) along with any error messages.

Note: The specific API Action is determined by the underlying Operation, discussed below.

Connections

The Connection contains the configuration required to physically connect to the particular application or data source. This usually includes things like user name, password, URL, host name, IP address, port, etc.

Connections are used in Connector Shapes of course, but also in Program Commands, Map Functions, Decisions, and even Operation and Profile wizards.

Atom Specific Connection Settings

Some special integration scenarios require the same processing logic to be used between very similar end points. In these situations, you may be able to build one Process deploy it to multiple Atoms, each with slightly different Connection configuration. You can create a single Connection component with multiple sets of configuration options which are selectively used depending on which Atom the Process is running.

Again, most integration Processes will not need to use this feature. For more information, see Atom Specific Connection Settings.

Tracked Properties

Some Connectors have properties (like Disk file name, FTP directory, or Email subject) that can be referenced or set dynamically elsewhere in the Process. See the individual Connector documentation under Available Connectors for a list of Tracked Properties available for each Connector type.

Note: Tracked Properties are also displayed in the Manage Tab for each Document received or sent.

Operations

The Operation represents a specific action or API call against the application or data source defined by the Connection. For example, the Operation is where you define what Web service call to make (e.g. Get Purchase Orders, Update Account), the FTP directory and file filter to GET, how to batch commit database INSERTS, which email addresses to send to, etc.

The configuration options differ widely between Connectors due to the capabilities of each application's or data source's API. Most application Operations provide a simple wizard interface to configure the Operation and import the request and/or response Profiles to use in the Process to map to/from, etc. When available, always use the wizard to configure the Operation.

Operations for application Connectors are typically configured with filters or other selection criteria to limit the results returned. These filters are usually supplied with a value passed in from the Process step that is calling the Operation, such as a Connector or other step.

Understanding how Operation filters work and how dynamic values are passed into them is one of the most important concepts in Boomi AtomSphere. This topic is discussed further in Understanding Connector Operations#params.

Note: "Send" Operations typically do not implement filters and therefore do not require parameters to be configured.

Archiving

You can choose to automatically archive the documents that pass through an Operation for auditing or troubleshooting purposes. If enabled, documents will be archived to the specified local directory on the machine where the Atom is running. Archived files will be named:

<date time><document index><Operation name>_<unique number>.dat