Contact Free trial Login

Connector Configuration Reference

Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.

There are two basic connector structures in Mule:

  • Operation-based connectors and

  • Endpoint-based connectors. This document describes the general configuration needed for both of these types, but does not provide instructions for specific connectors; to obtain reference material for your connector, consult the desired connector’s documentation.

For quick access to reference information for all connectors bundled with Anypoint Studio:

  1. Go to the Anypoint Connectors page.

  2. Go to the Accessing Connectors section.

  3. Check the Reference column in the provided table.g

HTTP connector changes in Mule 3.6 and newer

As of Mule 3.6 and newer, the HTTP and HTTPS endpoint-based connectors and transports have been replaced by a single HTTP operation-based connector which supports HTTPS. The legacy endpoint-based HTTP connectors will be removed in a future version.

For more information on the HTTP operation-based connector, see HTTP Connector.


This document assumes that you are familiar with Mule and the Anypoint Studio interface. To increase your familiarity with Studio, consider completing one or more Anypoint Studio Tutorials. Further, this example assumes that you have a basic understanding of Mule flows, Global Elements, and Anypoint Connectors.

Operation-Based Connector Configuration

Operation-based connectors vary too widely to make generic configuration instructions possible. However, at minimum, all operation-based connectors require the following fields to be configured on the General tab:

Field Description

Connector Configuration

Define global connection parameters. Most operation-based connectors require that the connection credentials be configured at the global level instead of inside the flow where the operation is specified.


Select an operation from the drop-down list to specify the function that the connector should perform against the API or protocol.

Be sure to refer to the connector-specific configuration instructions for guidance on the remaining fields. Information on which connectors are bundled automatically in Anypoint Studio is available at Anypoint Exchange.

To configure an operation-based connector in your flow:

  1. Configure a global connector configuration. Click the Global Element tab below the canvas in Anypoint Studio to create a new global connector configuration, or add a <connectorname>:config to your flow in the XML editor.

  2. Configure connector operation in your flow. Drag and drop a connector from the palette onto your canvas and select the appropriate operation, or add a <connectorname>:<operation> in your flow in the XML editor.

  3. Reference the connector configuration from the connector operation. Click the drop-down next to Connector Configuration in the properties editor to select the global connector that you configured in step 1, or add a config-ref attribute in the XML editor and supply the name of the global connector configuration.

  4. Configure any additional parameters necessary for the operation.

Endpoint-Based Connector Configuration

Endpoints pass messages into and out of a Mule flow, usually to external resources such as databases, Web clients, or email servers, but they can exchange messages with other Mule flows as well.

Inbound Endpoints

An Inbound Endpoint, which resides at the beginning of a flow and acts as a Message Source, triggers a new flow instance each time it receives a message.

Each incoming message must follow the specific protocol supported by the receiving endpoint. For example, email can arrive on a POP3 or IMAP inbound endpoint, but files must use the FTP, File, or SFTP endpoints.

Studio Visual Editor


XML Editor

<http:request-config name="HTTP_Request_Configuration" host="localhost" port="8083" doc:name="HTTP Request Configuration"/>
    <flow name="exampleflow2" >
        <pop3:inbound-endpoint host="localhost" user="${prod.user}" responseTimeout="10000" doc:name="POP3"/>
        <set-payload doc:name="Set Payload" value="foo"/>
        <http:request config-ref="HTTP_Request_Configuration" path="/" method="POST" doc:name="HTTP"/>
        <logger level="INFO" doc:name="Logger" message="bar"/>

Composite Sources

A special scope known as a Composite Source Scope allows you to encapsulate two or more connectors that receive the same type of data (for example, email, files, database maps, or HTML) into a single message processing block. Each embedded connector listens on its specific channel for incoming messages. Whichever connector receives a message first becomes the message source for that particular instance of the flow.

Studio Visual Editor


Drag the Composite Source Scope onto the canvas from the palette, then drag the connectors into the Composite Source Scope processing block. The composite source then allows the each embedded connector to act as a temporary, non-exclusive message source when it receives an incoming message.

XML Editor

<http:request-config name="HTTP_Request_Configuration" host="localhost" port="8083" doc:name="HTTP Request Configuration"/>
    <flow name="exampleflow2" >
        <composite-source doc:name="Composite Source">
            <pop3:inbound-endpoint host="localhost" user="${prod.user}" responseTimeout="10000" doc:name="POP3"/>
            <jetty:inbound-endpoint exchange-pattern="one-way" address="" doc:name="Jetty"/>
        <set-payload doc:name="Set Payload" value="foo"/>
        <http:request config-ref="HTTP_Request_Configuration" path="/" method="POST" doc:name="HTTP"/>
        <logger level="INFO" doc:name="Logger" message="bar"/>

Add a composite-source tag into your flow, then embed multiple connectors inside the scope of the tag. The composite source then allows the each connector to act as a temporary, non-exclusive message source when it receives an incoming message.

Outbound Endpoints

If an endpoint-based connector is not the first building block (i.e., the message source) in a flow, it is designated as an outbound endpoint, since it uses the specific transport channel it supports (such as SMTP, FTP, or JDBC) to dispatch messages to targets outside the flow, which can range from file systems to email servers to Web clients and can also include other Mule flows.

In many cases, an outbound endpoint completes a flow by dispatching a fully processed message to its final, external destination. However, outbound endpoints don’t always complete flow processing, because they can also exist in the middle of a flow, dispatching data to an external source, and also passing that (or some other data) to the next message processor in the flow.

Studio Visual Editor


XML Editor or Standalone

<flow name="exampleflow2" >
   <pop3:inbound-endpoint host="localhost" user="${prod.user}" responseTimeout="10000" doc:name="POP3"/>
   <set-payload doc:name="Set Payload" value="foo"/>
   <pop3:outbound-endpoint host="localhost" user="${prod.user}" responseTimeout="10000" doc:name="POP3"/>
   <logger level="INFO" doc:name="Logger" message="bar"/>

Configuration Reference

While unique properties exist for various endpoint-based connectors, most of these building blocks share common properties.

The General tab often provides these fields.

Field Description

Display Name

Defaults to the connector name. Change the display name, which must be alpha-numeric, to reflect the endpoint’s specific role, for example, Order Entry Endpoint


Defines the interaction between the client and server. The available patterns are one-way and request-response. A one-way exchange-pattern assumes that no response from the server is necessary, while a request-response exchange-pattern waits for the server to respond before it allows message processing to continue.


The default name is localhost. Enter the Fully Qualified Domain Name (FQDN) or IP address of the server.


The port number used to connect to the server. (For example, 80)


Allows specification of a path. for example, /enter/the/path

Connector Configuration

Define global connection parameters.

Depending on the protocol and type (inbound or outbound); these additional parameters may appear on the General tab:

Field Description

Polling Frequency

Time is milliseconds (ms) to check for incoming messages. Default value is 1000 ms.

Output Pattern

Choose the pattern from a drop down list. Used when writing parsed filenames to disk.

Query Key

Enter the key of the query to use.


Lets you select the element to use for a transaction. Click the plus + button to add Mule transactions.

Cron Information

Enter a cron expression to schedule events by date and time.


The operation performed on message data. Available options are: OPTION, GET, HEAD, POST, PUT, TRACE, CONNECT, and DELETE.

The Advanced tab often includes these fields.

Field Description


Enter the URL address. If using this attribute, include it as part of the URI. Mutually exclusive with host, port, and path.

Response Timeout

How long the endpoint waits for a response (in ms).


Select the character set the transport uses. For example, UTF-8

Disable Transport Transformer

Check this box if you do not want to use the endpointโ€™s default response transport.


Select a format from the drop-down list that this endpoint supports.

Connector Endpoint

Define a global version of the connector configuration details.

Business Events

Check the box to enable default event tracking.

The Transformers tab often includes these fields.

Field Description

Global Transformers (Request)

Enter the list of transformers to apply to a message before delivery. The transformers are applied in the order they are listed.

Global Transformers (Response)

Enter a list of synchronous transformers to apply to the response before it is returned from the transport.

Configuring Global Elements for Connectors

When developers create a Mule application utilizing connectors, they manage details and connection policy inside a "global element" that is accessible for as many connections as the developer cares to support. That means the connection information for API/service instances is saved inside a global element, accessible easily through the Studio UI or manually using the connector technical reference, available on each connector page or via Exchange - whether you like to drag and drop or code the Mule application XML code manually, the goal of the user guide is to make configuration easy, because swift and flexible development, testing and deployment is essential for.

Basically, a global element for a connector typically includes references to a username, password, and security tokens that are stored in a Properties File. There references can be stored securely within the global element. The references are typically in Ant syntax - ${my.ConnectionProperty} and are only a placeholder for the connection credentials and URIs.

If you already understand how to set connection attributes then the other consideration would be to ensure you are securely encapsulating your connection attributes as you require, inside the .properties or similar file, rather than within a global element itself. The .properties file usually lives within a resources folder .res within your application; rather than at the level of the connector instance in the flow.

This global connector configuration maintains the configuration and state, and many connectors of the same type in one application can reference the connector configuration at the global level. For example, a Mule application with four different HTTP connectors may all reference the same globally configured HTTP connector which defines specifics such as security, protocol, and proxy settings. Because they all reference the same global connector configuration, all four HTTP endpoints behave consistently within the application.

Selected global connector configurations can also be defined as Shared Resources for a domain and referenced by all applications for that same domain. For more information, see Shared Resources.

Note that the global element that you configure in Anypoint Studio is called a Connector Configuration and is nearly always referenced at the connector level. The connector consistently utilizes the connector configuration you carefully prepare, provided your connection credentials and settings are valid. Studio alerts you to problems in design time if you choose to use the UI’s Test Connection button or similar in the Global Element Properties Window. That is your hub for connector global element configuration within Studio.

Access the screen from the dropdown in the bottom window after selecting/clicking the connector in your flow. Note: make sure you configure the connector to authenticate and connect to the exact service instance you are permitted to access. When you design an application, make sure you initially use an account for your integration development purposes, rather than any account for production. The corresponding connector XML tags follow a standard format most of the time:

<connectorName>:config for operation-based connectors,

and for endpoint-based connectors: <connectorName>:connector

In Studio, if using the UI, you can quickly and simply set up an application that:

  • uses connectors to hook into APIs or web services, listens to information administered by servers, maintains persistent connections to interact with databases and navigate external service architectures, send messages, pass them to other applications via Mule flow etc.

You can do all this using the fundamental integration development practices you have read above. Having understood Mule application development and connection management means you can start to develop and hone an integration pattern on top of Mule runtime. Even if you don’t understand how Mule works internally, you can take advantage of its flexbile, durable engine. By reading Mule application code, following development procedures that others have set up for you in Anypoint Exchange, or by following step-by-step MuleSoft tutorials, especially those from Mule 3.x and Studio 5.x versions and earlier, you can understand Mule’s traditional implementations inside Mule Applications built in Studio. Use the version dropdown at the top to navigate to earlier material.

See Also

Was this article helpful?

๐Ÿ’™ Thanks for your feedback!

Edit on GitHub