Mule connectors

1. Mule Connectors

2. • Anypoint™ Connectors receive or send messages
between Mule and one or more external sources,
such as files, databases, or Web services.
• Connectors can act as message sources by
working as inbound endpoints, they can act as a
message processor that performs an operation in
middle of a flow, or they can fall at the end of a
flow and act as the recipient of the final payload
data.

3. • Connectors in Mule are either endpoint-based or
operation-based. Endpoint-based connectors
follow either a one-way or request-response
exchange pattern and are often named and based
around a standard data communication protocol,
such as FTP, JMS, and SMTP.
• Operation-based connectors follow an
information exchange pattern based on the
operation that you select and are often (but not
always) named and based around one or more
specific third-party APIs.

4. Endpoint-Based Connectors
• Endpoint based connectors are configured as
either inbound or outbound endpoints in a
flow. Inbound endpoints serve as a message
source for a flow. Outbound endpoints can
occur mid-flow or at the end of flows, and
send information to external systems.

5. Operation-Based Connectors
• When you add an operation-based connector to
your flow, you immediately define a specific
operation for that connector to perform.
• The XML element of the 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

6. Global Connector Configuration
• Some connectors require that connection
information such as username, password, and
security tokens be configured in a global element
rather than at the level of the message processor
within the flow. Many connectors of the same
type in one application can reference the
connector configuration at the global level. For
operation-based connectors, the global
connector configuration is mandatory, but for
most endpoint-based connectors it is optional.

7. Examples
HTTP Connector
• This example shows how an HTTP connector,
which can be configured both as a listener (for
receiving inbound requests) or as a request
connector (for making outbound requests).
The HTTP connector always requires a global
connector configuration that specifies its
connection attributes.

8. • <http:listener-config
name="HTTP_Listener_Configuration"
host="localhost" port="8081" doc:name="HTTP
Listener Configuration"/>
• <http:request-config
name="HTTP_Request_Configuration"
host="localhost" port="8082" doc:name="HTTP
Request Configuration"/>

9. JMS Connector
• This example shows a JMS connector, which is
endpoint-based, configured as an inbound
endpoint in a flow. The JMS endpoint includes
a mandatory reference to a global connector
configuration which contains the connection
parameters.

10. Example
• <jms:activemq-connector name="Active_MQ"
username="test" password="test"
brokerURL="tcp://localhost:61616"
validateConnections="true" doc:name="Active MQ"/>
•
• <flow name="myNewProjectFlow1"
doc:name="myNewProjectFlow1">
• <jms:inbound-endpoint queue="test" connector-
ref="Active_MQ" doc:name="JMS Endpoint"/>
• ...
• </flow>