Nav

Connector User Guide

The pages in this section describe how to install, configure, and manage connectors in Anypoint Studio.

User Guide Pages

Connector Types

All connectors can function as endpoints by sending and receiving messages between flows or between a flow and some other data source outside of Mule. Some connectors are endpoint-based, meaning that you configure them either as inbound or outbound endpoints in your flow, then specify other operation logic within the configuration of that endpoint. Some connectors are operation-based, meaning that they allow you to invoke specific actions against an API, Web service, or database.

While there are exceptions, this table summarizes the major differences between endpoint-based and operation-based connectors in Mule. 

Endpoint-Based Connectors Operation-Based Connectors

Usage

  • Typically URL-based

  • Typically provides connection for a standard protocol

  • Typically support serializable data

  • Global connector configuration is usually optional

  • Typically operation-based

  • Typically provides connection to one or more APIs

  • Support serializable or structured data

  • Global connector configuration always required

Implementation

  • Built around a transport

  • Not built around a transport, may be a provided connector such as HTTP, and may be implemented using DevKit

Installation and Updates

  • Automatically included with Anypoint Studio

  • Specify them as required transports when building with Maven

  • Updates occur with Mule releases only (with the exception of SAP and HL7, which are available on update sites)

  • Some are automatically included with Anypoint Studio

  • Add them as dependencies when building with Maven

  • Updates available on Anypoint Studio update sites (with the exception of Database and web service consumer, which are updated with Mule releases)

Global Configuration XML

<connectorname>:connector

For example: ftp:connector

<connectorname>:config

For example: sfdc:config

Flow-Level Element XML

<connectorname>:inbound-endpoint

<connectorname>:outbound-endpoint

For example: ftp:inbound-endpoint

<connectorname>:<operation>

For example: sfdc:create

See the Connector Configuration Reference for instructions for configuring connectors for endpoint functions or for operations.

See the HTTP Connector for information on this operation-based connector.

Terminology

In previous versions of Mule, endpoint-based connectors were sometimes referred to as transports. Also the term connectors was used for both the global connection configuration for an endpoint and for Mule-specific extensions (also called Cloud Connectors) for third-party APIs.

As of Mule 3.5, we clarify the terminology as follows:

Transport: Transports provide connectivity to a data source or message channel by implementing one of a variety of standard connection protocols that are bundled with Mule. Endpoint-based connectors are often constructed around a transport.

Connector: A connector is a Mule-specific connection to an external resource of any kind, whether it is a generic protocol such as HTTP, FTP, or a Java-based database, or a specific third-party API, such as Salesforce or Workday. Connectors may be operation-based or endpoint-based, but this distinction refers to a difference in configuration details, not in functionality.

Endpoint: An endpoint is a flow-level element that is configured to receive and/or send messages from and/or to external resources. Any connector (whether endpoint-based or operation-based) can function as an endpoint, but some connectors can only act as inbound endpoints, others can only act as outbound endpoints.

Endpoint-Based Connector Communication

Depending on its location in a flow, an endpoint-based connector may function as an inbound endpoint or outbound endpoint.

Note: An endpoint is a functional concept in Mule, not a rigid category. Endpoint-based connectors are always configured as either an inbound endpoint or an outbound endpoint, but operation-based connectors may also function as endpoints.

Inbound Endpoints

When a connector is configured as an inbound endpoint, it is acting as a message source. A message source receives new messages from a channel or resource, thus triggering the execution of a flow. A connector configured as an inbound endpoint reads the data it receives, packages the content as a message, then passes it to the first message processor in a Mule flow. A message source can receive data by: 

  • Using a server socket

  • Polling a remote socket or resource

  • Registering a listener

Inbound endpoints use one of two message exchange patterns (MEPs) in a Mule flow. 

  • An inbound endpoint with a one-way exchange pattern simply accepts information from an external source for processing by Mule. For example, an JMS endpoint would use a one-way exchange pattern to accept messages from an external queue and process them in Mule (the queue doesn’t expect a post-processing response). 

  • An inbound endpoint with a request-response exchange pattern not only accepts information from an external source, it also returns a response to the external source that "called" the Mule flow. For example, a Jetty endpoint might use a request-response exchange pattern to accept a request from a caller, then return a response after Mule has processed the message.

Outbound Endpoints

Outbound endpoints send messages from Mule to an external system or application. Outbound endpoints can exist either in the middle of a flow or at the end of a Mule flow, sending a message out to an external system after Mule has processed the message to transform it, enrich it, or otherwise act upon it. 

Outbound endpoints may also use one of two message exchange patterns:

  • An outbound endpoint with a one-way exchange pattern simply receives the message payload and routing instructions from the message processor which precedes it in a flow, then sends the message to its destination. For example, an SMTP connector, which can only be configured as a one-way, outbound endpoint, sends the message it receives from the Mule flow as an email using the SMTP protocol to a destination and does not expect a response. 

  • An outbound endpoint with a request-response exchange pattern not only sends information to an external resource, it also returns the external resource’s response to the Mule flow. For example, a VM connector might use a request-response exchange pattern to send a message to another flow via a VM queue, then that second flow would process the message and return it back to the first flow after its processing is complete. 

Endpoint-based connectors in Anypoint Studio visually indicate their message exchange pattern with small arrow icons on the building block.

Endpoints with a request-response exchange pattern are represented with a two-way arrow graphic in the bottom of the connector icon.

In addition, a Message source using a endpoint-based connector with a request-response exchange pattern is represented by two vertically stacked blocks, one at the start of the inbound flow, and another at the end of the outbound response flow.

jetty request response

Endpoints configured with a one-way exchange pattern are represented as a single block, and have just one arrow in the graphic in the bottom of the connector icon:

jetty no response

Operation-based connectors do not have these indicators, as their message exchange pattern varies according to the specific operation that you select for the connector.

Operation-Based Connector Communication

Many connectors are operation-based, which means that when you add the connector to your flow, you immediately define a specific operation for that connector to perform. For example, when you add a Salesforce connector to your flow, the first configuration you need to define is the operation. The XML element of the operation-based connector differs according to the operation that you select, taking the form <connectorname>:<operation>. For example, sfdc:query or sfdc:upsert-bulk. The remaining configuration attributes or child elements are determined by the operation that you select.

Operation-based connectors require a global connector configuration (usually optional for endpoint-based connectors) to specify the connection parameters such as username, passwords, and security token. Additional global parameters may also be configured. For details, see the individual references for each connector. General instructions are available on the Connector Configuration Reference.

Note that endpoint-based connectors also perform operations on resources, but in most cases the protocol itself defines what that operation is. For example, the SMTP connector always sends an email, so the "send" operation is built into the protocol itself. In cases where a protocol supports multiple operations, the configuration of the operation is done via attributes or child elements of the connector, rather than in the connector element itself.

Connector Compatibility

Operations-Based

All operations-based connectors are forward-compatible with all new releases of Mule. This group of connectors, which are referred to as Studio-compatible, can be configured either through the Properties pane in Anypoint Studio’s visual interface or through an XML editor.

Endpoint-Based

Endpoint-based connectors are constructed around transports that are bundled with the Mule distribution, and are tied directly to a Mule version. 

See Also

Not finding what you’re looking for?