-
Typically URL-based
-
Typically provides connection for a standard protocol
-
Typically support serializable data
-
Global connector configuration is usually optional
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 |
|
|
Implementation |
|
|
Installation and Updates |
|
|
Global Configuration XML |
For example: |
For example: |
Flow-Level Element XML |
For example: |
For example: |
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 processor.
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
See Also
Not finding what you’re looking for?
-
Refer to the overview of Anypoint Connectors.
-
Access the full library of available connectors.