![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/muleslidesnaveen-170615084338/85/Mule-slides-13-320.jpg)
More Related Content
What's hot (11)
Similar to Mule slides (20)
Recently uploaded (20)
Mule slides
- 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. Batch Batch is a new Mule construct that provides the ability to process messages in batches. Within an application, you can initiate a batch job which is a block of code that splits messages into individual records, performs actions upon each record, then reports on the results and potentially pushes the processed output to other systems or queues. This functionality is particularly useful when working with streaming input or when engineering “near real-time” data integration between SaaS applications.
- 24. Batch
- 25. Phases
- 27. Record Variable