![Mule Expression Language
Mule Expression Language (MEL) is the primary language used for formulating
expressions in Mule, allows us to access, manipulate, and use information from
the message and its environment.
• MEL is a lightweight and Mule-specific expression language that you can use to access and
evaluate the data in the payload, properties and variables of a Mule message.
• Accessible and usable from within virtually every message processor in Mule.
• MEL enables you to quickly and elegantly filter, route, or otherwise act upon the different
parts of the Mule message object.
#[message.inboundProperties.propertyName]](https://image.slidesharecdn.com/mule-170609054718/85/Mule-13-320.jpg)
Mule
- 1. Mule ESB
- 2. What is Mule ESB? • Mule 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 and 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. • It enables easy integration of existing systems, regardless of the different technologies that the applications use. Example: JMS, Web Services, JDBC, HTTP, and more
- 3. Capabilities of Mule • Service creation and hosting — expose and host reusable services, using the ESB as a lightweight service container • Service mediation — shield services from message formats and protocols, separate business logic from messaging, and enable location-independent service calls • Message routing — route, filter, aggregate, and re-sequence messages based on content and rules • Data transformation — exchange data across varying formats and transport protocols
- 4. Do I need an ESB and when to select an ESB? It is form the article written by MuleSoft founder and VP of Product Strategy Ross Mason: To ESB or not to ESB. 1. Are you integrating 3 or more applications/services? 2. Will you need to plug in more applications in the future? 3. Do you need to use more than one type of communication protocol? 4. Do you need message routing capabilities such as forking and aggregating message flows, or content-based routing? 5. Do you need to publish services for consumption by other applications?
- 5. Advantages of Mule provides over other competitors • Mule's stage event-driven architecture (SEDA) makes it highly scalable. • 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. • 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.
- 6. Mule Enterprise • There are two editions of Mule. Community and Enterprise. • Enterprise is the enterprise-class version of the ESB, with additional features and capabilities that are ideal for production deployments of Mule that have requirements for performance, HA, resiliency, or technical support. https://www.mulesoft.com/platform/soa/mule-esb-enterprise
- 7. Installation
- 8. Anypoint Studio • Canvas /Message Flow • Global Elements • Configuration XML • Palette ( where mule building blocks/elements are available ) 1. Connector 4. Transformers 2. Scope 5. Filters 3. Components 6. Flow Control elements (or "Routers")
- 9. Message Sources • Mule processes messages, also known as events. • which may be transmitted from resources external to Mule. Example: A message can be initiated by an event • Such as a consumer request from a mobile device. • A change to data in a database. • The creation of a new customer ID in a Software as a service(Saas) application. • The first building block of most flows is a receiver which receives new messages and places them in the queue for processing. This message source – receives messages from one or more external sources, thus triggering the execution of a flow. • Message sources in Mule are usually Anypoint Connectors, elements which provide connectivity to a specific external source, either via a standard protocol (such as HTTP, FTP, SMTP) or a third-party API (such as Salesforce.com, Twitter, or MongoDB.)
- 10. Message Processors • In Mule, message processors are grouped together by category. • Mule transformers are the key to exchanging data between nodes. • Mule to convert message payload data to a format that another application can understand. • Mule uses Staged Event-Driven Architecture (SEDA) for core asynchronous message processing in flows. • Importantly, components don’t have to have any Mule-specific code. • It can be simply be POJOs, Spring beans, Java beans, Groovy scripts, Python, JavaScript, Ruby, and PHP or web services containing the business logic for processing data.
- 11. Mule Flow • A flow is the most versatile and powerful integration mechanism available in Mule. • A flow is the construct within which you link together several individual elements to handle the receipt, processing, and eventual routing of a message. • You can connect many flows together to build a complete application and each names should be unique. Private Flows, Sub Flows, Flow-Ref
- 12. Mule Message Structure The Mule message is the data that passes through an application via one or more flows. It consists of two main parts: • The message header, which contains metadata about the message. • The message payload, which contains your business-specific data. • A Mule message is, itself, embedded within a Mule message object. • Some Mule message objects may contain variables, attachments, and exception payloads
- 13. Mule Expression Language Mule Expression Language (MEL) is the primary language used for formulating expressions in Mule, allows us to access, manipulate, and use information from the message and its environment. • MEL is a lightweight and Mule-specific expression language that you can use to access and evaluate the data in the payload, properties and variables of a Mule message. • Accessible and usable from within virtually every message processor in Mule. • MEL enables you to quickly and elegantly filter, route, or otherwise act upon the different parts of the Mule message object. #[message.inboundProperties.propertyName]
- 14. Properties & Variables • The metadata contained in the message header consists of properties which provide useful information about the message. • Properties and Variables share a common format: each individual property or variable has a name and a value. • A message’s properties and variables have specific scopes that define and organize how they apply across that message’s lifecycle.
- 15. • Properties have two main scopes: inbound and outbound. • Inbound properties are immutable, are automatically generated by the message source and cannot be set or manipulated by the user. • Outbound properties are mutable; they are set during the course of a flow and can become inbound properties when the message passes from the outbound endpoint of one flow to the inbound endpoint of a different flow via a transport.
- 16. • Variables are user-defined metadata about a message. Variables have three scopes: • Flow variables apply only to the flow in which they exist. • Session variables apply across all flows within the same application. • Record variables apply to only to records processed as part of a batch.
- 17. Anypoint Studio • Palette (Message Processors) 1. Connector 2. Scope 3. Components 4. Transformers 5. Filters 6. Flow Control elements (or "Routers") 7. Error Handling 8. Security
- 18. Anypoint Connectors • Anypoint Connectors receive or send messages between Mule and one or more external sources. • Connectors can act as message sources by working as inbound endpoints. • Connectors can act as a message processor that performs an operation in the middle of a flow. • Connectors can be at the end of a flow and act as the recipient of the final payload data.
- 19. Connectors in Mule are either endpoint-based or operation-based Endpoint-Based Connectors • Endpoint-based connectors follow either a one-way or request-response exchange pattern. • 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. • Connectors often (but not always) named and based around a standard data communication protocol such as FTP and SMTP. Operation-Based Connectors • 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. • When you add an operation-based connector to your flow, you immediately define a specific operation for that connector to perform. Global Connector Configurations
- 20. Components • Components are the message processors which is embedded with business logic and it is executes on message. • Components fall into three categories 1. General Components 2. Script Components 3. Web service Components.
- 21. • General Components • General components execute whenever a message is received. • The logic embedded into General components cannot be modified. • Components such as the Logger and Flow Reference fall into this category. • Script Components Script components do not contain pre-packaged logic. Instead it allows the developer to specify the logic (in the form of a custom script or a Java class) to add into the component. • Script components also allow you to: • Configure interceptors • Add Spring beans • Change the value or reference of a specific property within the associated class • The Java Component allows you to reference a Java class. • The other Script components support the Groovy, JavaScript, Python and Ruby scripting engines.
- 22. • Web Service Components Web Service components provide or facilitate the developer in exposing, consuming, and proxying web services with the framework to reference classes and API’s needed by RESTful and SOAP Web services. These components let you add interceptors, bundled logic which executes before the service is published, that run tasks such as scheduling or logging a specific event. • The CXF component leverages the CXF framework, mule uses to support SOAP web services. • The REST component work with Jersey to support REST Web services.
- 23. Scopes • Scopes are also known as wrappers. mule scopes work to encapsulate other message processors so that they function as a single unit.
- 24. Scopes Avaiable in any point studio
- 25. Scopes explanation: • Async scope:Creates a block of message processors that execute asynchronously while the rest of the flow continues to execute in parallel. For instance, you can populate an Async scope with a sequence of building blocks that perform logging so that logging does not slow down the rest of the application flow. • Cache scope:Caches data produced by part of a flow. Wrap a cache scope around message processors in your flow so that it caches the response events produced within the scope
- 26. Scopes explanation Composite Source:To accept incoming messages from multiple input channels, place two or more message sources (also known as receivers) into a Composite Source. A message entering the Composite Source on any supported channel triggers the processing flow. Foreach:Splits any type of message collection apart into individual messages for processing, and then aggregate them again at the end of the scope.
- 27. Scopes explanation Message Enricher:Appends information to a message, often using an expression to determine what part of the payload to evaluate so as to return an appropriate value to append to that payload. For example,the expression can evaluate a ZIP code and then append the associated City and State to the payload. The message processor is executed and the enricher scope uses the result of that execution to enrich the message coming into the scope. Until Successful:Attempts, at a specified interval, to route a message to an embedded message processor until one of the following occurs:
- 28. Scopes explanation • The message processor succeeds • The maximum number of retries is reached • An exception is thrown Thus, Until Successful can prove useful in sending messages to resources, such as shared printers, which might not always be immediately available.
- 29. Scopes explanation Request-Reply Scope:The Request-Reply scope enables you to embed a "pocket" of asynchronous processing within a Mule flow. This functionality enables you to receive a response from an asynchronous flow without hardcoding the destination of the response. For example, you can use request- reply to convert a one-way VM or JMS flow to a request-response flow without having to change it’s configuration. In other words, the request-reply converts part of a synchronous process into an asynchronous one.
- 30. Scopes explanation Request-reply consists of two parts: •The request portion wraps the connector or outbound connector which submits an asynchronous request to another flow or an external resource •The response portion wraps the connector or inbound connector which receives an asynchronous response from another flow or an external resource
- 31. Scopes explanation • Poll scope:By default, Poll Scopes in Mule are set to poll a resource every 1000 milliseconds for new data. At times, you may wish to adjust the default polling interval, or configure the polling schedule to follow a more complex logic. • The below details are on how to configure a polling schedule via two methods made available in Anypoint Studio: • Fixed Frequency Scheduler • Cron Scheduler
- 32. Scopes explanation Message Enricher:One common scenario involves the need to enrich an incoming message with information that isn’t provided by the source system. You can use a content enricher if the target system needs more information than the source system can provide. • Consider a message from a source system contains a zip code but the target system needs the two letter state. A message enricher can be used to lookup the state using the zip code from an enrichment resource. The enricher calls out to the enrichment resource with the current message (containing the zip code) then enriches the current message with the result.