Mule esb presentation 2015

1
Nageshwar Penumarthy
Architect
Virtusa consultancy services
Mule ESB

2
1. What is Mule ESB?
2. Why Mule ESB?
3. Advantages of Mule
4. Application integration with Mule.
5. Mule Architecture
6. Working with Mule Event
7. Flow, sub-flow, private flow, VM etc.. Explained
8. Message sources
9. Message Processors
10. Mule connectors
11. Message transformers (pre-built, custom)
12. Message exchange patterns
13. Mule Endpoints
14. Exception handling & Transaction management
15. Resiliency for unreliable transports
16. Sample Applications
Topics

3
Mule ESB is a lightweight Java-based enterprise service bus (ESB) and integration
platform that allows developers to connect applications together quickly and easily,
enabling them to exchange data. Mule ESB enables easy integration of existing systems,
regardless of the different technologies that the applications use, including JMS, Web
Services, JDBC, HTTP, and more.
The key advantage of an ESB is that it allows different applications to
communicate with each other by acting as a transit system for carrying data between
applications within your enterprise or across the Internet. Mule ESB includes powerful
capabilities that include:
1.Service creation and hosting — expose and host reusable services, using Mule ESB as a
lightweight service container
2.Service mediation — shield services from message formats and protocols, separate
business logic from messaging, and enable location-independent service calls
3.Message routing — route, filter, aggregate, and re-sequence messages based on content
and rules
4.Data transformation — exchange data across varying formats and transport protocols
What is Mule ESB?

5
Mule ESB is lightweight but highly scalable, allowing you to start small and connect more
applications over time. Mule manages all the interactions between applications and
components transparently, regardless of whether they exist in the same virtual machine or
over the Internet, and regardless of the underlying transport protocol used.
Advantages -
1.Mule components can be any type you want. You can easily integrate anything from a
"plain old Java object" (POJO) to a component from another framework.
2.Mule and the ESB model enable significant component reuse. Unlike other frameworks,
Mule allows you to use your existing components without any changes. Components do not
require any Mule-specific code to run in Mule, and there is no programmatic API required.
The business logic is kept completely separate from the messaging logic.
3.Messages can be in any format from SOAP to binary image files. Mule does not force any
design constraints on the architect, such as XML messaging or WSDL service contracts.
4.You can deploy Mule in a variety of topologies, not just ESB. Because it is lightweight and
embeddable, Mule can dramatically decrease time to market and increases productivity for
projects to provide secure, scalable applications that are adaptive to change and can scale
up or down as needed.
Why Mule ESB? Advantages?

6
When a message transits in Mule, it is in fact an event (for example, an instance of
org.mule.api.MuleEvent) that’s moved around.
Exploring Mule Message
Mule Event
Mule Message
Mule Session
Mule context
Payload
Properties
Attachments
Exception payload

7
In Mule, things start moving when they get assembled in a flow
Flow - Flows are the foremost elements of a Mule configuration. They typically start with a
message source followed by message processors, all chained together by the sole virtue of
being encompassed by the flow element. Flows impose virtually no limit to the type of
message processors that can be added in them or in what order they can be added.
<flow name="product-registration">
<http:inbound-endpoint
address="http://api.prancingdonkey.com/products"
method="POST" />
<byte-array-to-string-transformer />
<logger level="INFO" category="products.registration" />
<jms:outbound-endpoint queue="products" />
</flow>
Mule Message Processing

8
Sub Flow - Copy-pasting is the bane of software development. If you reach the point where
you start to have a lot of commonality between your flows, you should quickly feel the
need to extract and reuse common sequences of message processors across your flows.
Enter subflows, a configuration construct that has been created for this very purpose.
A subflow behaves like a standard flow, but without a message source. It receives
messages to process only when explicitly invoked by name via a flow-ref element.
You can think of a subflow as a macro that contains a predefined set of message processors
and which you can invoke on demand. When a flow invokes a subflow, the whole Mule
message (payload, properties, attachments) and its context (session, transactions) are
passed to the subflow. Similarly, the complete context of the result of the subflow is passed
back to the main flow.
<sub-flow name="legacyAdapterSubFlow">
<mulexml:xslt-transformer xsl-file="v1_to_v2.xsl" />
<mulexml:xml-to-object-transformer />
</sub-flow>
Contd..

9
Private Flows - Private flows are another type of reusable flows, very similar to subflows,
but with a different behavior in terms of threading and exception handling. The primary
reason for using a private flow instead of a subflow is to define in it a different exception
strategy from the calling flow (something that is impossible with a subflow). Another reason
is that subflows aren’t materialized at runtime and, as such, don’t have specific
statistics or debug properties attached to them and can’t be controlled or monitored
independently. Private flows offer all this.
Only difference with main flow is that it doesn’t have any message source.
<flow name="legacyAdapterPrivateFlow" processingStrategy="synchronous">
<mulexml:xslt-transformer xsl-file="v1_to_v2.xsl" />
<catch-exception-strategy>
<jms:outbound-endpoint queue="legacyAdapter.failures" />
</catch-exception-strategy>
</flow>
Contd..

10
Message Sources
In a Mule configuration, message sources usually manifest themselves as inbound
endpoints. Pollers are also commonly used message sources. Cloud connectors can also
provide message sources that can be used in a configuration.
Simple and Composite Message sources -
Only a single message source is allowed in a flow. To allow multiple inbound endpoints to
feed messages in the same flow, a composite message source must be used.
<vm:inbound-endpoint path="payment-processor" />
<composite-source>
<jms:inbound-endpoint queue="payment-processor" />
<http:inbound-endpoint host="localhost“ port="8080"
path="payment-processor" />
</composite-source>
Contd..

11
Message Processors
Message processors are the basic building blocks of a Mule configuration; as you’ve
seen in the previous section, besides message sources, flows are mostly composed of
message processors. Message processors take care of performing all the message handling
operations in Mule and as such manifest themselves in the configuration under
a diversity of elements.
Here’s a list of the main features provided by message processors:
1. As outbound endpoints, they take care of dispatching messages to whatever destination
you want.
2. As transformers, they’re able to modify messages.
3. As routers, they ensure messages are distributed to the right destinations.
4. As components, they perform business operations on the messages.
Contd..

12
Message exchange patterns
Message exchange patterns (MEPs) define the timely coupling that will occur at a particular
inbound or outbound endpoint. By defining if an endpoint interaction is synchronous
or asynchronous, a MEP influences the way both sides of the endpoint
(sender and receiver or, said differently, client and server) interact with each other.
Currently, Mule supports only two MEPs:
1. One-way, where no synchronous response is expected from the interaction
2. Request-response, where a synchronous response is expected
<http:inbound-endpoint host="localhost"
port="8080"
path="payment-processor"
exchange-pattern="request-response" />
<http:outbound-endpoint host="localhost"
port="8081"
path="notifier"
exchange-pattern="one-way" />
Contd..

13
Endpoint URIs
Mule uses Uniform Resource Identifiers (URIs) as the unified representation for all
the resources it exposes or accesses via its endpoints. In other words, inbound and
outbound endpoints are internally configured by a URI
<http:inbound-endpoint host="localhost"
port="8080"
path="products" />
<jms:inbound-endpoint topic="news" />
<tcp:inbound-endpoint host="localhost"
port="51000"
connector-ref="pollingTcpConnector" />
Contd..

14
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
(but not always) 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.
1)HTTP Connector
2)JMS Connector
3)JDBC Connector
4)VM Connector
5)File Connector
6)FTP/SFTP Connector
Examples: -
<http:connector name="httpConnector">
<receiver-threading-profile …….. />
</http:connector>
Mule Connectors

15
<vm:connector name="vmConnector" />
<jdbc:connector name=“XXX" pollingFrequency="1000" dataSource-ref=“xxxxDB"
resultSetHandler-ref="resultSetHandler">
<jdbc:query key="GetJiffyBagGrt40days" value="select * from ……….
</jdbc:connector>
<jms:activemq-connector name="ISLJmsConnector" connectionFactory-ref="amqFactory"
persistentDelivery="true" ……
</jms:activemq-connector>
<file:connector fileAge=“10000" outputAppend="false" name=“fileconnector"
streaming="false" autoDelete="true“ pollingFrequency=“5"
validateConnections="false">
</file:connector>
Mule Connectors Contd..

16
In a Mule flow, a Transformer prepares a message for further processing by enhancing or
altering the contents of the message properties, variables, or payload. Data transformation
is one of the most powerful functionalities of Mule: rather than spending a lot of time
building a customized connection between resources or processors, you can just use a pre-
built transformer to perform a standard data conversion.
For example, if the message source in a flow receives data in XML format, but a
downstream message processor expects a Java object, you can use an XML-to-Object
transformer to convert the format of the message payload.
<object-to-byte-array-transformer />
<object-to-string-transformer />
<mulexml:xslt-transformer name="prancingToBM"
xsl-file="xsl/prancing-to-gondor-bm.xsl" />
<string-to-byte-array-transformer />
<gzip-compress-transformer />
Message Transformers

17
Modifying properties, flow variables, and session variables
Adding, copying between scopes, and modifying or removing properties or variables
is therefore an important aspect of dealing with messages in Mule. This is where the
property transformer, the variable transformer, and the session variable transformer (as
they’re known in Mule Studio) come in handy
Contd..
Operation Property Flow Variable Session Variable
Set Set-property Set-variable Set-session-variable
Remove Remove-
property
Remove-variable Remove-session-
variable
Copy Copy-properties

18
Transforming with expressions
The expression-transformer is able to use these expressions to transform the payload of
the message it processes. This transformer can be configured to evaluate one or several
expressions. Depending on the configuration, the resulting message payload will
be an object (single expression) or an array of objects (multiple expressions).
Single resulting expression transformer -
<expression-transformer expression="message.payload.hostAddress" />
Array returning expression transformer -
<expression-transformer expression=
"{message.payload.hostAddress, message.payload.multicastAddress}"/>
Contd..

19
Enriching messages
When a flow contains a request-response outbound endpoint, the message that
comes back from this endpoint replaces whatever message was under processing in
the flow before calling the endpoint. This isn’t always desirable when you have subsequent
message processors that need some or all of the original message context to
work properly.
<flow name="invoice-processor">
<vm:inbound-endpoint path="invoice-processor"
<enricher source="#[message.payload.currencyCode]"
target="#[flowVars['currencyCode']]">
<vm:outbound-endpoint path="client.service"
</enricher>
<component class="com.prancingdonkey.service.InvoiceProcessor" />
</flow>
Contd.. Enriching messages

20
Automagic transformation
auto-transformer, as its name suggests, this transformer is able to apply the desired
transformation automatically.
<auto-transformer
returnClass="com.prancingdonkey.statistics.ActivityReport" />
XML Transformers –
1)Using a XPath expression to add a property
<set-property propertyName="productId"
value="#[xpath('/products/product[1]/id').text]" />
2) Transforming format with XSL
<mulexml:xslt-transformer
xsl-file="xsl/prancing-to-gondor-bm.xsl" />
3)XML object marshaling
<mulexml:object-to-xml-transformer />
Contd… Automagic transformation & XML Transformers

21
4) JAXB with Mule
<mulexml:jaxb-object-to-xml-transformer
jaxbContext-ref="myJaxbContext" />
<mulexml:jaxb-context name="myJaxbContext"
packageNames="com.prancingdonkey.model.jaxb" />
5) JSON with Mule
<json:json-to-object-transformer
returnClass="com.prancingdonkey.model.json.Provider" />
<json:object-to-json-transformer />
6) Scripting transformer
<scripting:transformer>
<scripting:script file="orderTransformer.groovy" />
</scripting:transformer>
7) Expression transformer
<expression-transformer name="PayloadAsString">
<return-argument expression="message.getPayloadAsString()"
evaluator="groovy"/>
</expression-transformer>
Contd..

22
Custom Transformer
Apart from built-in transformers as stated above, we can have our own transformers so
called customized transformers by extending
org.mule.transformer.AbstractMessageTransformer
public class XXX extends AbstractMessageTransformer{
@Override
public Object transformMessage(MuleMessage message, String outputEncoding)
throws TransformerException {
// Your transformation code.
}
}
<custom-transformer name=“xxx"
class=“com.xx.yy.zz.XXXX"/>
Contd..

23
Filters -
Mule filters evaluate a message to determine whether it can proceed through a flow. The
simplest filters implement basic logic operators (such as and, or, and not), but these simple
elements can be combined in various ways to specify complex logical conditions.
a.Filtering by payload type and header
<payload-type-filter expectedType="com.prancingdonkey.domain.Brew"/>
b.Schema validator filter
<mulexml:schema-validation-filter schemaLocations="orders.xsd"
returnResult="true"/>
c.Filtering with regular expression
<regex-filter pattern="^LEVEL: SEVERE$"/>
d.Wildcard filter
<wildcard-filter pattern="*SEVERE*"/>
d.Expression filter
<expression-filter expression="xpath('/order/priority').text == 'HIGH'"/>
e. Logical filter
<and-filter> exp1 exp2 exp3 </and-filter>
<or-filter>exp1 exp2 exp3</or-filter>
Mule Filters, Scopes, and Routers

24
Routers
You often need to send a message to more than one endpoint
a.Dispatching messages with the all router
The all routing message processor sends a message to a group of endpoints. The all router
makes a copy of the MuleMessage for each recipient.
<all>
<flow-ref name=“XX" />
<flow-ref name=“YY" />
<flow-ref name=“ZZ" />
</all>
b. Going async with the async processor
The all router is appropriate when you want to synchronously dispatch or aggregate
requests to endpoints. What’s your option, however, when you want a series of message
processors to be processed asynchronously in a different thread? In such a case,
the async messaging scope is necessary.
<async>
<flow-ref name=“XX" />
<flow-ref name=“YY" />
<flow-ref name=“ZZ" />
</async>

25
Routing collections
Mule also provides facilities to iterate over the contents of an individual message, typically
its payload, and process each piece individually. This functionality is achieved using
the foreach message processor
<foreach collection="xpath('//lineItem')“ counterVariableName="lineItem">
<choice>
<when expression="xpath('priority/text()').textContent == 'HIGH'">
<object-to-string-transformer/>
<flow-ref ref=“xxxx” />
</when>
<otherwise>
<object-to-string-transformer/>
<flow-ref ref=“yyy” />
</otherwise>
</choice>
</foreach>

26
The first-successful and until-successful routers allow you to define how Mule deals
with a failure when sending a message to an endpoint. The first-successful router,
illustrated next, will attempt to send a message to each endpoint until one succeeds:
<first-successful>
<http:outbound-endpoint ref=“xxx” />
<http:outbound-endpoint ref=“yyy” />
<http:outbound-endpoint ref=“zzz” />
</first-successful>
The until-successful router, contrasted with the first-successful router, will continue to
retry delivery to an endpoint until it succeeds.
<until-successful objectStore-ref="documentRequestObjectStore“ maxRetries="12"
deadLetterQueue-ref="vm://DLQ“ secondsBetweenRetries="300">
<outbound-endpoint address="http://localhost:9091/documents"/>
</until-successful>
Resiliency for unreliable transports

27
Any exception thrown by invoking the outbound endpoint would trigger the resiliency
behavior. In the case of the first-successful router, it would cause delivery to be attempted
to the next message in the chain. For the until-successful router, it would trigger a retry
attempt. By setting the failureExpression attribute on either router, you can control what
Mule perceives as an error.
<until-successful objectStore-ref="documentRequestObjectStore“ maxRetries="12"
deadLetterQueue-ref="vm://DLQ“ failureExpression=
"exception-type:java.net.SocketTimeoutException“ secondsBetweenRetries="300">
<outbound-endpoint address="http://localhost:9091/documents"/>
</until-successful>
Failure expressions and the until-successful router

28
Exception strategies can be configured on a per-flow basis.
This is done by defining an exception strategy at the end of each flow definition. You
can additionally define exception strategies globally; in this case, to establish the
exception strategy in a flow, you’ll have to use a reference.
<catch-exception-strategy>
<set-payload value="Error: #[exception.summaryMessage]"/>
</catch-exception-strategy>
a. Default exception strategy—Implicitly present by default in every flow; will log the
exception and roll back the transaction.
b. Catch exception strategy—Customize the reaction for any exception; will commit
the transaction and so will consume the message.
c. Rollback exception strategy—Customize the reaction for any exception; will roll
back the transaction, hence won’t consume the message.
d. Choice exception strategy—Using a Mule expression will route to one exception
strategy within a set; if no exception strategy is suitable in the set, the exception
will be routed to the default exception strategy.
e. Reference exception strategy—Delegate the responsibility to handle exceptions to a
global exception handler.
Exception handling and transaction management with Mule

29
<flow name="HelloWorldFlow1" doc:name="HelloWorldFlow1">
<http:inbound-endpoint exchange-pattern="request-response" host="localhost"
port="8081" doc:name="HTTP" doc:description="This endpoint receives an HTTP
message."/>
<set-payload value="Hello World" doc:name="Set Payload" doc:description="This
processor sets the payload of the message to the string 'Hello World'."/>
</flow>
Sample Application 1

30
<flow name=“xxx">
<inbound-endpoint ref=“xxx" transformer-refs=“xxTransformer">
<cxf:jaxws-service serviceClass=“xx.yy.zz.Service">
<cxf:inInterceptors>
<spring:bean class=“xx.yy.LoggingInInterceptor" />
</cxf:inInterceptors>
<cxf:outInterceptors>
<spring:bean class=“xx.yy..LoggingOutInterceptor" />
</cxf:outInterceptors>
</cxf:jaxws-service>
</inbound-endpoint>
<transformer ref=“yyTransformer" />
<all>
<flow-ref name=“flow1" />
</all>
<response>
<transformer ref=“zzTransformer"/>
</response>
</flow>
Sample Application 2

Mule esb presentation 2015

More Related Content

What's hot (19)

Similar to Mule esb presentation 2015 (20)

Recently uploaded (20)

Mule esb presentation 2015