Endpoint 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.

This page discusses the configuration of the flow-level inbound and outbound endpoints, which are the flow-level elements of endpoint-based Anypoint Connectors. Note that none of the information on this page applies for operation-based connectors. Please see Anypoint Connectors for more information about connectors in general.

Endpoints are used to connect flows. An endpoint is a specific channel on which a flow can send messages and from which another flow or external service can receive messages. For example, a purchasing component may receive an order request over HTTP. Once the order has been processed by the component, a JMS message may be sent over a topic to notify an auditing system, and a response can be sent back over HTTP.

This page describes how to configure an endpoint.

Basic Configuration

In its most basic form, an endpoint acts as a flow-level inbound or outbound implementation of a transport and its underlying data source or message channel. For example:

URI-style Endpoints
`<inbound-endpoint address="udp://localhost:65432"/> <jetty:inbound-endpoint address="http://localhost:60211/mycomponent1" exchange-pattern="request-response" /> <outbound-endpoint address="smtp://user:secret@smtp.host"/> <inbound-endpoint address="jms://test.queue"/>`

URI-style Endpoints

<inbound-endpoint address="udp://localhost:65432"/>

<jetty:inbound-endpoint address="http://localhost:60211/mycomponent1" exchange-pattern="request-response" />

<outbound-endpoint address="smtp://user:secret@smtp.host"/>

<inbound-endpoint address="jms://test.queue"/>

Traditionally, endpoints in Mule ESB have been specified as a URI such as the examples above. This form is still supported, and indeed may prove to be more practical depending on your application. However, the recommended way to specify endpoints is via transport-specific namespaces, as shown in the following examples.

Transport-specific Endpoints
<file:inbound-endpoint path="./.mule/in" comparator="org.mule.transport.file.comparator.OlderFirstComparator" reverseOrder="true"/> <ssl:endpoint name="clientEndpoint" host="localhost" port="60198"/> <jetty:endpoint name="serverEndpoint" host="localhost" port="60203" path="services/Foo" /> <imaps:endpoint name="global1s" host="localhost" password="secret" port="123" user="bob"/> <rmi:endpoint name="BadType" host="localhost" port="1099" object="MatchingUMO" method="reverseString"/> <quartz:endpoint name="qEP6" repeatCount="10" repeatInterval="1000" jobName="job"/> <jms:inbound-endpoint queue="test.queue"/>

Transport-specific Endpoints

<file:inbound-endpoint path="./.mule/in"
comparator="org.mule.transport.file.comparator.OlderFirstComparator" reverseOrder="true"/>

<ssl:endpoint name="clientEndpoint" host="localhost" port="60198"/>

<jetty:endpoint name="serverEndpoint" host="localhost" port="60203" path="services/Foo" />

<imaps:endpoint name="global1s" host="localhost" password="secret" port="123" user="bob"/>

<rmi:endpoint name="BadType" host="localhost" port="1099" object="MatchingUMO" method="reverseString"/>

<quartz:endpoint name="qEP6" repeatCount="10" repeatInterval="1000" jobName="job"/>

<jms:inbound-endpoint queue="test.queue"/>

Dynamic Endpoints

An outbound endpoint can also be dynamic. This means that the endpoint’s URI is the value of an expression, which is evaluated just before a message is sent to it. This allows the target of a message to be determined by its contents or the value of any message property. Dynamic endpoints can use either of the endpoint formats shown above.

Dynamic Endpoints
`<outbound-endpoint address="smtp://user:secret@#[message.outboundProperties['host']]"/> <jms:outbound-endpoint host="localhost" queue="#[app.registry['defaultJmsQueue']]"/>`

Dynamic Endpoints

<outbound-endpoint address="smtp://user:secret@#[message.outboundProperties['host']]"/>

<jms:outbound-endpoint host="localhost" queue="#[app.registry['defaultJmsQueue']]"/>

The only part of an endpoint URI that cannot be dynamic is the scheme. Don't do this:

Illegal Dynamic Endpoint
`<outbound-endpoint address="#[message.inboundProperties['endpointType']]//localhost:8080/service"/>`

Illegal Dynamic Endpoint

<outbound-endpoint address="#[message.inboundProperties['endpointType']]//localhost:8080/service"/>

Global Connection Configuration

In many cases, the global connection configuration associated with an endpoint can simply be assumed based on the transport and created implicitly. However, if more than one global connector configuration of the same transport exists, or if non-default settings are used, you must refer to the connector configuration from the endpoint using the connector-ref attribute.

Specifying a connector
`<inbound-endpoint address="tcp://localhost:65432" connector-ref="tcpConnector1"/> <tcp:inbound-endpoint host="localhost" port="65433" connector-ref="tcpConnector2"/>`

Specifying a connector

<inbound-endpoint address="tcp://localhost:65432" connector-ref="tcpConnector1"/>
<tcp:inbound-endpoint host="localhost" port="65433" connector-ref="tcpConnector2"/>

Properties

Properties on endpoints can be used to customize behavior. Any properties set on the endpoint can be used to override default properties on the associated transport’s connector. For example, an SMTP outbound endpoint might set the fromAddress property to workflow1 to override a default connector value of sysadmin. Any standard properties for an endpoint will be available as attributes in the XML schema if transport-specific endpoints are used. It is also possible to specify a non-standard property. For example:

Setting properties
`<!-- Standard properties --> <quartz:endpoint name="qEP6" repeatCount="10" repeatInterval="1000" jobName="job"/> <!-- Non-standard properties --> <quartz:endpoint name="qEP7" jobName="job2"> <property key="actionOnTimeout" value="self-destruct"/> <property key="precision" value="2.5"/> </quartz:endpoint>`

Setting properties

<!-- Standard properties -->
<quartz:endpoint name="qEP6" repeatCount="10" repeatInterval="1000" jobName="job"/>

<!-- Non-standard properties -->
<quartz:endpoint name="qEP7" jobName="job2">
    <property key="actionOnTimeout" value="self-destruct"/>
    <property key="precision" value="2.5"/>
</quartz:endpoint>

Transactions

A transaction can begin or commit when an event is received or sent via an endpoint. The endpoint must be synchronous, and transaction support depends largely on the particular transport being used. For more information see Transaction Management.

Transaction example
`<jms:inbound-endpoint queue="in"> <jms:transaction action="BEGIN_OR_JOIN"/> </jms:inbound-endpoint>`

Transaction example

<jms:inbound-endpoint queue="in">
    <jms:transaction action="BEGIN_OR_JOIN"/>
</jms:inbound-endpoint>

Encoding

This is the encoding an endpoint used to convert message content. For inbound endpoints, it is used to convert the bytes received to characters. For outbound endpoints, it is used to convert characters about to be sent to bytes. If no encoding is set on the endpoint, the default encoding for the Mule configuration is used. This is turn defaults to UTF-8.

Encoding example
`<inbound-endpoint address="tcp://localhost:65432" encoding="iso-8859-1"/>`

Encoding example

<inbound-endpoint address="tcp://localhost:65432" encoding="iso-8859-1"/>

MimeType

This is the mime type associated with an endpoint’s messages. When set on an inbound endpoint, it indicates the type of message expected for incoming messages. Receiving a message with a different mime type will result in an exception. When set on an outbound endpoint, the result is to set that mime type on all outgoing messages.

MimeType example
`<inbound-endpoint address="tcp://localhost:65432" mimeType="text/xml"/>`

MimeType example

<inbound-endpoint address="tcp://localhost:65432" mimeType="text/xml"/>

Redelivery Policy

A redelivery policy can be defined on an inbound endpoint. It is similar to the maximum redelivery counts that can be set on JMS brokers, and solves a similar problem: if an exception causes the read of a message to be rolled back over and over, how to avoid an infinite loop? Here’s an example:

MimeType example
`<flow name ="syncFlow" processing-strategy="synchronous"> <file:inbound-endpoint path="/tmp/file2ftp/ftp-home/dirk"> <idempotent-redelivery-policy maxRedeliveryCount="3"> <dead-letter-queue> <vm:outbound-endpoint path="error-queue" /> </dead-letter-queue> </idempotent-redelivery-policy> </file:inbound-endpoint> ...`

MimeType example

<flow name ="syncFlow" processing-strategy="synchronous">
    <file:inbound-endpoint path="/tmp/file2ftp/ftp-home/dirk">
        <idempotent-redelivery-policy maxRedeliveryCount="3">
            <dead-letter-queue>
                <vm:outbound-endpoint path="error-queue" />
            </dead-letter-queue>
        </idempotent-redelivery-policy>
    </file:inbound-endpoint>
    ...

If something later in the flow throws an exception, the file won’t be consumed, and will be reprocessed. The idempotent-redelivery-policy ensures that it won’t be reprocessed more then 3 times; after that, it will be send to vm:error-queue, where it can be handled as an error case.

Embedding Message Processors Inside an Endpoint

The following message processors can be nested inside an endpoint:

Transformers
Filters
Security Filters
Aggregators
Splitters
Custom Message Processors

You can put any number of these message processors as child elements on an endpoint (inbound or outbound), and they will get applied in the order in which they are listed to any message passing through that endpoint.

In the case of a synchronous outbound endpoint, there is a response message involved, and so any number of message processors can also be put inside a response wrapper and will get applied to the response message in the order in which they are listed.

Note that any of these elements could be declared locally (i.e., in-line in the endpoint) or globally (and referenced via a ref="foo" attribute).

Transformers

Transformers can be configured on an endpoint encapsulating transformation logic in an endpoint that can then be reused as required.

Transformers are configured on endpoints using child elements. When configured on an inbound endpoint they are used to transform the message received by the endpoint, and when configured on an outbound endpoint they are used to transform the message before it is sent.

Response transformers can be configured inside the nested <response> element. When configured on an inbound endpoint these transformer will be applied to the message just before it is sent back over the transport, and when configured on an outbound endpoint they are applied on the message received from the invocation of the outbound endpoint if there is one.

As will all message processors configured on endpoints, the order in which they are configured is the order in which they are executed.

<inbound-endpoint address="file://./test-data/in">
  <xml-to-object-transformer/>
  <expression-filter expression=""/>
  <transformer ref="ExceptionBeanToErrorMessage"/>
  <response>
    <custom-transformer class=""/>
  </response>
</inbound-endpoint>

In the above example you can see two request transformers configured, one of which will be executed before the expression filter and the other one after. The custom transformer configured in the <response> element will be applied to the response message.

Although globally defined transformers can be referenced from endpoints using the <transformer ref=""/> element, as seen in the above example, endpoints also support a shortcut notification.

The transformer-refs and responseTransformer-refs attributes can be used to quickly and easily reference global endpoints.

<inbound-endpoint address="file://./test-data/in" transformer-refs="globalTransformer1 globalTransformer2" responseTransformer-refs="globalTransformer2"/>

Any transformers referenced in this way will be added to the end of the list of message processors configured a child elements and will therefore be executed last. If you need them to be executed before something else like a filter or need to use global endpoints in conjunction with locally defined endpoints in a specific order then you’ll need to use <transformer> elements instead.

Filters

An endpoint can contain a filter to selectively ignore certain messages. The filter can be transport-specific such as a JMS selector or file filter or can be a general-purpose filter such as JXPath. Filtering is not supported by all transports, and setting a filter on an endpoint using some transports results in an UnsupportedOperationException. For more information, see Using Filters.

Filter example
`<jms:endpoint queue="in.queue"> <jms:selector expression="JMSPriority > 5"/> </jms:endpoint> <vm:endpoint name="fruitBowlEndpoint" path="fruitBowlPublishQ"> <message-property-filter pattern="foo=bar"/> </vm:endpoint>`

Filter example

<jms:endpoint queue="in.queue">
    <jms:selector expression="JMSPriority > 5"/>
</jms:endpoint>

<vm:endpoint name="fruitBowlEndpoint" path="fruitBowlPublishQ">
    <message-property-filter pattern="foo=bar"/>
</vm:endpoint>

Global Endpoints

Global endpoints, while not required, are a recommended best practice for having a nicely organized configuration file. A global endpoint can be thought of as a template for shared endpoint configuration. Global endpoints can be used as they are defined globally, or they can be extended by adding more configuration attributes or elements.

To reference a global endpoint, use the usual <inbound-endpoint> and <outbound-endpoint> elements, and specify the global endpoint name using the ref attribute.

Global endpoint example
`<file:endpoint name="fileReader" reverseOrder="true" comparator="org.mule.transport.file.comparator.OlderFirstComparator"/> ...cut... <flow name="Priority1"> <file:inbound-endpoint ref="fileReader" path="/var/prio1"/> ...cut... </flow> <flow name="Priority2"> <file:inbound-endpoint ref="fileReader" path="/var/prio2"/> ...cut... </flow>`

Global endpoint example

<file:endpoint name="fileReader" reverseOrder="true" comparator="org.mule.transport.file.comparator.OlderFirstComparator"/>
...cut...

  <flow name="Priority1">
        <file:inbound-endpoint ref="fileReader" path="/var/prio1"/>
        ...cut...
  </flow>

  <flow name="Priority2">
        <file:inbound-endpoint ref="fileReader" path="/var/prio2"/>
        ...cut...
  </flow>

In the above example, the "fileReader" endpoint is used as a template for the inbound endpoints. The properties reverseOrder and comparator only need to be declared once, and the property path changes for each inbound endpoint.

Custom Message Sources

You can replace any inbound endpoint in a flow with a custom message source. This allows you to use any class as a message source to the flow, including connectors. You configure the custom message source using the <custom-source> element. In the element you identify the class for the custom source. You can further configure the custom message source using Spring bean properties.

The following code example configures a custom message source for a flow:

<flow name="useMyCustomSource">
   <custom-source class="org.my.customClass">
      <spring:property name="threads" value="500"/>
   </custom-source>
   <vm:outbound-endpoint path="output" exchange-pattern="one-way"/>
</flow>

Generic Endpoint Reference

The following reference tables list the attributes that can be configured for the generic endpoint in Mule.

Inbound endpoint

An inbound endpoint receives messages via the associated transport. As with global endpoints, each transport implements its own inbound endpoint element.

Table 1. Attributes of <inbound-endpoint…>
Name	Type	Required	Description
name	name (no spaces)	no	Identifies the endpoint in the registry. There is no need to set the 'name' attribute on inbound or outbound endpoints, only on global endpoints.
ref	string	no	A reference to a global endpoint, which is used as a template to construct this endpoint. A template fixes the address (protocol, path, host, etc.), and may specify initial values for various properties, but further properties can be defined locally (as long as they do not change the address in any way).
address	string	no	The generic address for this endpoint. If this attribute is used, the protocol must be specified as part of the URI. Alternatively, most transports provide their own attributes for specifying the address (path, host, etc.). Note that the address attribute cannot be combined with 'ref' or with the transport-provided alternative attributes.
responseTimeout	integer	no	The timeout for a response if making a synchronous endpoint call
encoding	string	no	String encoding used for messages.
connector-ref	string	no	The name of the connector associated with this endpoint. This must be specified if more than one connector is defined for this transport.
transformer-refs	list of names	no	A list of the transformers that will be applied (in order) to the message before it is delivered to the component.
responseTransformer-refs	list of names	no	A list of the transformers that will be applied (in order) to the synchronous response before it is returned via the transport.
disableTransportTransformer	boolean	no	Don’t use the default inbound/outbound/response transformer which corresponds to this endpoint’s transport, if any.
mimeType	string	no	The mime type, e.g. text/plain or application/json
exchange-pattern	enumeration	no

Table 2. Child Elements of <inbound-endpoint…>
Name	Cardinality	Description
abstract-reconnection-strategy	0..1	A placeholder for a reconnection strategy element. Reconnection strategies define how Mule should attempt to handle a connection failure.
abstract-multi-transaction	0..1	A placeholder for multi-transaction elements. Multi-transactions allow a series of operations to be grouped together spanning different transports, e.g. JMS and JDBC, but without the overhead of XA. The trade-off is that XA reliability guarantees aren’t available, and services must be ready to handle duplicates. This is very similar to a 1.5 PC concept. EE-only feature.
response	0..1
abstract-redelivery-policy	0..1	A placeholder for a redelivery policy. Redelivery policies determine what action to take when the same message is redelivered repeatedly.
abstract-transaction	0..1	A placeholder for transaction elements. Transactions allow a series of operations to be grouped together.
abstract-transformer	0..1	A placeholder for transformer elements. Transformers convert message payloads.
abstract-filter	0..1	A placeholder for filter elements, which control which messages are handled.
abstract-security-filter	0..1	A placeholder for security filter elements, which control access to the system.
abstract-intercepting-message-processor	0..1	A placeholder for intercepting router elements.
abstract-observer-message-processor	0..1	A placeholder for message processors that observe the message but do not mutate it used for exmaple for logging.
processor	0..1	A reference to a message processor defined elsewhere.
custom-processor	0..1
abstract-mixed-content-message-processor	0..1	A placeholder for message processor elements.
property	0..*	Sets a Mule property. This is a name/value pair that can be set on components, services, etc., and which provide a generic way of configuring the system. Typically, you shouldn’t need to use a generic property like this, since almost all functionality is exposed via dedicated elements. However, it can be useful in configuring obscure or overlooked options and in configuring transports from the generic endpoint elements.
properties	0..1	A map of Mule properties.

Outbound endpoint

An outbound endpoint sends messages via the associated transport. As with global endpoints, each transport implements its own outbound endpoint element.

Table 3. Attributes of <outbound-endpoint…>
Name	Type	Required	Description
name	name (no spaces)	no	Identifies the endpoint in the registry. There is not need to set the 'name' attribute on inbound or outbound endpoints, only on global endpoints.
ref	string	no	A reference to a global endpoint, which is used as a template to construct this endpoint. A template fixes the address (protocol, path, host, etc.), and may specify initial values for various properties, but further properties can be defined locally (as long as they do not change the address in any way).
address	string	no	The generic address for this endpoint. If this attribute is used, the protocol must be specified as part of the URI. Alternatively, most transports provide their own attributes for specifying the address (path, host, etc.). Note that the address attribute cannot be combined with 'ref' or with the transport-provided alternative attributes.
responseTimeout	integer	no	The timeout for a response if making a synchronous endpoint call
encoding	string	no	String encoding used for messages.
connector-ref	string	no	The name of the connector associated with this endpoint. This must be specified if more than one connector is defined for this transport.
transformer-refs	list of names	no	A list of the transformers that will be applied (in order) to the message before it is delivered to the component.
responseTransformer-refs	list of names	no	A list of the transformers that will be applied (in order) to the synchronous response before it is returned via the transport.
disableTransportTransformer	boolean	no	Don’t use the default inbound/outbound/response transformer which corresponds to this endpoint’s transport, if any.
mimeType	string	no	The mime type, e.g. text/plain or application/json
exchange-pattern	enumeration	no

Table 4. Child Elements of <outbound-endpoint…>
Name	Cardinality	Description
abstract-reconnection-strategy	0..1	A placeholder for a reconnection strategy element. Reconnection strategies define how Mule should attempt to handle a connection failure.
abstract-multi-transaction	0..1	A placeholder for multi-transaction elements. Multi-transactions allow a series of operations to be grouped together spanning different transports, e.g. JMS and JDBC, but without the overhead of XA. The trade-off is that XA reliability guarantees aren’t available, and services must be ready to handle duplicates. This is very similar to a 1.5 PC concept. EE-only feature.
response	0..1
abstract-redelivery-policy	0..1	A placeholder for a redelivery policy. Redelivery policies determine what action to take when the same message is redelivered repeatedly.
abstract-transaction	0..1	A placeholder for transaction elements. Transactions allow a series of operations to be grouped together.
abstract-transformer	0..1	A placeholder for transformer elements. Transformers convert message payloads.
abstract-filter	0..1	A placeholder for filter elements, which control which messages are handled.
abstract-security-filter	0..1	A placeholder for security filter elements, which control access to the system.
abstract-intercepting-message-processor	0..1	A placeholder for intercepting router elements.
abstract-observer-message-processor	0..1	A placeholder for message processors that observe the message but do not mutate it used for exmaple for logging.
processor	0..1	A reference to a message processor defined elsewhere.
custom-processor	0..1
abstract-mixed-content-message-processor	0..1	A placeholder for message processor elements.
property	0..*	Sets a Mule property. This is a name/value pair that can be set on components, services, etc., and which provide a generic way of configuring the system. Typically, you shouldn’t need to use a generic property like this, since almost all functionality is exposed via dedicated elements. However, it can be useful in configuring obscure or overlooked options and in configuring transports from the generic endpoint elements.
properties	0..1	A map of Mule properties.

Endpoint

A global endpoint, which acts as a template that can be used to construct an inbound or outbound endpoint elsewhere in the configuration by referencing the global endpoint name. Each transport implements its own endpoint element, with a more friendly syntax, but this generic element can be used with any transport by supplying the correct address URI. For example, "vm://foo" describes a VM transport endpoint.

Table 5. Attributes of <endpoint…>
Name	Type	Required	Description
name	name (no spaces)	yes	Identifies the endpoint so that other elements can reference it. This name can also be referenced in the MuleClient.
ref	string	no	A reference to a global endpoint, which is used as a template to construct this endpoint. A template fixes the address (protocol, path, host, etc.), and may specify initial values for various properties, but further properties can be defined locally (as long as they do not change the address in any way).
address	string	no	The generic address for this endpoint. If this attribute is used, the protocol must be specified as part of the URI. Alternatively, most transports provide their own attributes for specifying the address (path, host, etc.). Note that the address attribute cannot be combined with 'ref' or with the transport-provided alternative attributes.
responseTimeout	integer	no	The timeout for a response if making a synchronous endpoint call
encoding	string	no	String encoding used for messages.
connector-ref	string	no	The name of the connector associated with this endpoint. This must be specified if more than one connector is defined for this transport.
transformer-refs	list of names	no	A list of the transformers that will be applied (in order) to the message before it is delivered to the component.
responseTransformer-refs	list of names	no	A list of the transformers that will be applied (in order) to the synchronous response before it is returned via the transport.
disableTransportTransformer	boolean	no	Don’t use the default inbound/outbound/response transformer which corresponds to this endpoint’s transport, if any.
mimeType	string	no	The mime type, e.g. text/plain or application/json
exchange-pattern	enumeration	no

Table 6. Child Elements of <endpoint…>
Name	Cardinality	Description
abstract-reconnection-strategy	0..1	A placeholder for a reconnection strategy element. Reconnection strategies define how Mule should attempt to handle a connection failure.
abstract-multi-transaction	0..1	A placeholder for multi-transaction elements. Multi-transactions allow a series of operations to be grouped together spanning different transports, e.g. JMS and JDBC, but without the overhead of XA. The trade-off is that XA reliability guarantees aren’t available, and services must be ready to handle duplicates. This is very similar to a 1.5 PC concept. EE-only feature.
response	0..1
abstract-redelivery-policy	0..1	A placeholder for a redelivery policy. Redelivery policies determine what action to take when the same message is redelivered repeatedly.
abstract-transaction	0..1	A placeholder for transaction elements. Transactions allow a series of operations to be grouped together.
abstract-transformer	0..1	A placeholder for transformer elements. Transformers convert message payloads.
abstract-filter	0..1	A placeholder for filter elements, which control which messages are handled.
abstract-security-filter	0..1	A placeholder for security filter elements, which control access to the system.
abstract-intercepting-message-processor	0..1	A placeholder for intercepting router elements.
abstract-observer-message-processor	0..1	A placeholder for message processors that observe the message but do not mutate it used for exmaple for logging.
processor	0..1	A reference to a message processor defined elsewhere.
custom-processor	0..1
abstract-mixed-content-message-processor	0..1	A placeholder for message processor elements.
property	0..*	Sets a Mule property. This is a name/value pair that can be set on components, services, etc., and which provide a generic way of configuring the system. Typically, you shouldn’t need to use a generic property like this, since almost all functionality is exposed via dedicated elements. However, it can be useful in configuring obscure or overlooked options and in configuring transports from the generic endpoint elements.
properties	0..1	A map of Mule properties.

Gartner names MuleSoft a Leader

Unleash the power of Salesforce Customer 360 through integration

Anypoint Platform Fundamentals

The world of AI is a world of APIs