Using Message Routers
Message routers are used within Using Mule Services to control how messages are sent and received by components in the system. (Within Using Flows for Service Orchestration, the same job is performed by message processors.) See Overview below for a description of the different types of routers. Click a link in the Quick Reference table below for details on a specific router.
Overview
Inbound routers control how a service handles incoming messages, such as selectively consuming only those messages that meet specific criteria or grouping messages together that share a group ID before forwarding them on.
Outbound routers control how a message is dispatched after the service has processed it, such as sending it to a list of recipients or splitting up the message and sending the parts to different endpoints.
Asynchronous reply routers are used in request/response scenarios where message traffic is triggered by a request and the traffic needs to be consolidated before a response is given. The classic example of this is where a request is made and tasks are executed in parallel. Each task must finish executing and the results processed before a response can be sent back.
Catch-all strategies are invoked if no routing path can be found for the current message. An inbound or outbound endpoint can be associated with a catch-all strategy so that any orphaned messages can be caught and routed to a common location.
Filters provide the logic used to invoke a particular router. Filters can be combined using the logic filters AndFilter, OrFilter, and NotFilter. Not all routers need to use filters, but all routers support them. See Using Filters for complete information.
Mule ESB provides flexible message routing support for your components. Routing features are based on the enterprise routing requirements described in EIP. For information on how your Java or Script components can orchestrate messages, see Component Bindings.
Frequently Asked Questions
When do I need an outbound router vs. simply getting a reply?
In simple scenarios, a service receives a request on a synchronous inbound endpoint, processes the request, and then sends it back to the caller as a reply. This is the request-response message style. For example, if a user enters a value in an HTML form, and you want to transform that value and display the results in the same page, you can simply configure a synchronous inbound endpoint on the service that does the transformation. This scenario does not use an outbound router.
If you need to pass the message to a second service for additional processing, you configure an outbound router on the first service to pass the message to the second service. You configure a synchronous inbound endpoint on the second service so that it passes the message back to the first service, which then sends it back to the caller as a reply. This is the synchronous message style.
In the most complex scenario, you can enable request-response messaging and allow the back-end process to be forked to invoke other services and return a result based on the results of multiple service invocations. This is the asynchronous request response message style.
See Service Messaging Styles for more information.
How do I create a nested router that calls a web service with multiple methods without having to hardcode the method name in the outbound endpoint?
The template endpoint router allows endpoints to be altered at runtime based on properties set on the current message or fallback values set on the endpoint properties.