![ Type – To define the type of SQL statement we wish to use to submit
queries to a database :
Parametrized – Mule replaces all MEL expressions inside the query with “?”
to create a prepared statement, then evaluates the MEL expressions.
E.g. insert into employees where name = [message.payload.name]
Dynamic – Mule replaces all MEL expressions in the query with the result
of the expression evaluation, then sends the results to the database.
E.g. select * from #[tablename]
From Template- It enables to define a query once globally and then reuse
the query multiple times in the same application.](https://image.slidesharecdn.com/muleesbcomponents1-160625154208/85/Mule-ESB-Components-20-320.jpg)
Ad
More Related Content
What's hot (19)
Similar to Mule ESB Components (20)
Ad
Recently uploaded (20)
![Get & Download Wondershare Filmora Crack Latest [2025]](https://cdn.slidesharecdn.com/ss_thumbnails/revolutionizingresidentialwi-fi-250422112639-60fb726f-250429170801-59e1b240-thumbnail.jpg?width=560&fit=bounds)
Ad
Mule ESB Components
- 2. File Component The File connector allows Mule application to exchange files with a File system. It can be implemented as an inbound or an outbound endpoint.
- 3. File as an Inbound Endpoint If the File component is placed at the beginning of the flow, then it acts as an inbound endpoint, which triggers the flow whenever it receives an incoming file. File endpoint can be configured by providing the values on the fields of the General tab of Properties editor.
- 5. Some of the important fields used for inbound endpoint configuration are :- Display Name – It is the general endpoint name. Path – This is the location of the file which is transferred into the flow. Move to Pattern – This is the pattern to be used when moving the file according to the Move to Directory property Move to Directory – This is used to save a copy of the file on the Host machine when the file is being dispatched to the next element. Polling Frequency – It checks how often the endpoint should check for the incoming messages. File Age – Sets a minimum period a file must wait before it is processed.
- 6. File as an Outbound Endpoint If the File building block is placed at the middle or the end of the flow, then it acts as the outbound endpoint, passing files to the connected file system. File outbound endpoint can also be configured just like inbound endpoint.
- 8. Some of the important fields used for outbound endpoint configuration are :- Path – For an outbound endpoint, this would be the directory on the connected file system to which the file currently in the flow is written. File Name/Pattern – This property specifies a file name or pattern for naming files that are sent from the File endpoint to the connected file system. If not set, it follows the same pattern as the incoming files.
- 9. Advanced Tab fields Apart from the configuration for Inbound and outbound properties in General Tab, there are fields that could b configured in Advanced Tab as well. Some of the main fields are :- Address – To enter the address of the endpoint. Connector Endpoint – To add a new connection configuration or to edit an existing one. Comparator – To sort the incoming files Reverse Order – To reverse the normal comparison order
- 11. Connector Syntax A typical syntax for an inbound endpoint configured for reading files can be given as :- <file:connector name = “input” fileAge = “500” autoDelete = “true” pollingFrequency = “100” moveToDirectory = “/backup” />
- 12. Transformers for File File Component includes several transformers for transforming the content of the file :- File to Byte Array Transformer – This element configures a transformer that reads the content of a java.io.File into a byte array File to String Transformer - This element configures a transformer that reads the content of a java.io.File into a String
- 14. Database Component The Database connector allows to connect with almost any JDBC relational database Using Database connector, we can run diverse SQL operations on our database like Select, Insert, Update, Delete, and even stored procedures. Database connector helps us perform pre defined as well as parametrized queries and even DDL requests.
- 16. Configuration for Database Connector To use Database connector, the basic configuration required is :- A database driver is required to connect with the database Configure a global database element where we can define the database’s location and connection details, and advanced connection parameters like connection pooling. Configure the database element in the mule flow which contains the query and the reference to the Database Global element.
- 18. The Database connector provides out of the box support for 3 databases : MySQL Oracle Derby For those databases, where Out of the box support is not provided, a Generic DB Configuration is provided, and the driver can be added to the prject.
- 19. Configuration Fields Some of the important fields which should be configured are :- Database URL – To define the details of the Database to be connected with Required Dependencies – To add the driver required Enable Datasense(Optional) – It enables Mule to make use of message metadata at run time. Connection Timeout – To define the amount of time the connection should remain active. Config Reference – To identify any Global element if present Operation – To instruct the application for the type of operation to be performed on the database.
- 20. Type – To define the type of SQL statement we wish to use to submit queries to a database : Parametrized – Mule replaces all MEL expressions inside the query with “?” to create a prepared statement, then evaluates the MEL expressions. E.g. insert into employees where name = [message.payload.name] Dynamic – Mule replaces all MEL expressions in the query with the result of the expression evaluation, then sends the results to the database. E.g. select * from #[tablename] From Template- It enables to define a query once globally and then reuse the query multiple times in the same application.
- 21. Other Features Some other important features of Database connector are :- Executing DDL – DDL is a kind of request used for creating, altering or deleting the tables. When using DDL, we can use only Dynamic Queries which may or may not have MEL expressions.
- 23. Bulk Updates – The Database connector can run multiple SQL statements in bulk mode. The individual SQL statements must be separated by semicolons and line breaks. Instead of writing a statement directly, we can also refer a file which contains multiple statements with semicolons and line breaks. We can not perform Select operation as a part of bulk update, only Insert, Update and Delete.
- 25. Using Mule with Web Services Mule ESB allows different integration scenarios using web services :- Consuming existing web services. Building web services and exposing them to other applications. Creating a proxy/gateway to existing web services.
- 26. Web Service consumer While developing our applications, whenever we need to consume some external SOAP services to acquire data, we can use a Web Service consumer. Using the information contained in service’s WSDL, this connector enables us to configure a few details in order to establish the connection. The Web service consumer interfaces only with the SOAP services and not with the REST.
- 27. To use the Web service consumer, we need to carry out the following 3 tasks :- Add the WSDL file of the service we need to consume. Embed a web service consumer in our Mule Flow. Configure the Global web service consumer element in which we reference the service’s WSDL, enable Datasense and apply any security settings that the service provider demands.
- 29. The studio auto populates the values of the fields in the Properties editor of the Web service consumer :- Connector Configuration – With the name of the Global Web service consumer that we just created. Operation – With the name of an operation that the Web service supports for its consumers.
- 30. Building Web Services with CXF Mule provides 3 ways to create web services :- Use the JAX WS front end to build a code first web service. Use the JAX WS front end to build a WSDL first web service. Creating a web service from simple POJOs.
- 31. To begin with writing a code first web service, the steps to be followed are :- We begin with writing the service interface. For example package org.example; import javax.jws.WebService; @WebService public interface HelloWorld { String sayHi(String text); }
- 32. The implementation for the above class may look like package org.example; import javax.jws.WebService; @WebService(endpointInterface = “org.example.HelloWorld”, serviceName = “HelloWorld”) public class HelloWorldImpl implements HelloWorld { public String sayHi(String text){ return “Hello ” + text; } }
- 34. Once the application is deployed, we can generate the WSDL by appending ?wsdl at the end of the end point URL. For e.g. http://localhost:8081/hello?wsdl This displays the WSDL generated by CXF
- 35. REST Component REST relies on HTTP for transport and uses HTTP methods to perform operations on remote services. Mule ESB can be configured as a RESTful service endpoint. It provides a built-in REST component based on the Jersey project. Mule ESB can be used as a publisher as well as consumer of RESTful Web Services.
- 36. Consuming a REST API We can consume a REST API from within a Mule application, by configuring an HTTP Request Connector. A basic Mule application setup to consume a REST API contains :- One or more message processors configured to build the request. An HTTP request connector configured to call the REST API. One or more processors configured to accept and process the response.
- 38. If a RAML file exists that describes the API we want to consume, then we can simply reference it in the HTTP connector and it will expose the structure of the API at design time. If we don’t have a RAML file, then we need to be aware of the structure of the API, including any authentication requirements, the name of the resources we want to access, and the methods supported for each resource. Some of the important information required are :- Authentication Base URL The type of input API expects (JSON, XML, etc) The type of output API produces. Error codes if any
- 39. Configuration The first thing to be configured is the Global Connector element by providing the basic information like Connector name Host Port Base Path API Configuration (if RAML is available)
- 41. Next we configure the Connector’s Properties editor. The basic fields to be configured are :- Name Connector Configuration URL Path Method Parameters (if any) If the API requires additional security requirements, redirects, or a specific content type encoding, the HTTP connector supports additional configuration to manage these details.
- 43. Designing a new API A RAML (RESTful API Modeling Language) editor is a simple and easy way to design APIs. RAML is a simple and practical language for describing APIs. A RAML file includes the following elements :- Root Documentation Resources Methods Pattern based reusable elements
- 44. A RAML file can be written in any text editor, but it is recommended to write it in the API Designer. It consists of a RAML editor with an embedded RAML API console that proactively provides suggestions, error feedback and a built-in live testing environment. It also contains a context aware shelf at the bottom of the Designer which displays a list of the components we can enter.
- 45. The operations to be depicted in the API can be mapped to resources here. Each operation maps to an individual resource. For e.g. For a T-Shirt ordering API, we can have the following resources /products /orders Orders each have a nested {orderId}/status, as a sub resource /products : displayName : Products /orders : displayName : Orders /{orderId}/status : displayName : status
- 46. After adding resources, we can add the methods accordingly. Since we need the customers to see the available products and not modify them, we can add a GET method for this resource. The customers can place orders, so I this case we can add a POST method. Also the customers may want to see the status of their order, so we can add a GET method for /{orderId}/status resource. The responses component on the shelf specifies which response could be expected of these methods :- 200 (OK) 500 (server error) 400 (client error)
- 47. It’s a good practice to provide response examples in the API. Using these examples, developers can build their consuming application accordingly. To ensure that the requests sent to the resources are valid, we can also add schema so that they follow the same structure. Both these things can be added in the body – application/json element. At the same level, we can even add the queryParameters element element with its attributes. Next the API can be tested by turning on the Mocking Service and checking in the API console.
- 49. DataWeave Component DataWeave is a new feature of version 3.7 which replaces the DataMapper in the previous versions. The DataWeave language is a simple, powerful tool to query and transform data inside of mule. It can be used in 2 different ways :- We can graphically map the fields by dragging and dropping them, as in DataMapper, or We can use its powerful JSON like language to make transformations as fast as possible.
- 50. Using the DataWeave Component We can use the DataWeave Component, by placing a Transform Message element in our flow. This generates a .dwl transformation file that stores our code and is packaged within our Mule application. The Properties editor displays two sides for this element :- The left side displays a Graphical editor where we can drag and drop the elements to create mapping between them. The right side displays the DataWeave code editor, where we can use the DataWeave language to make transformations. Both the regions represent the same transformation and any change done to one is reflected on the other.
- 52. Input Structure :- If the elements in the flow expose their metadata, then this information will be readily available in the Transform Message component. If they don’t then we can configure it by editing their Metadata tab. Configuring the CSV Reader :- Some input formats like CSV allow us to define a reader with specific properties like : Header : Boolean that defines if the first line is a header Separator : character that separates fields Quotes : character that defines quoted text Escape : character that escapes quotes
- 53. Examples of DataWeave Transformation We can consider a basic example of conversion from JSON to XML Input :- { “title” : “Java 8 in action”, “author” : “Mario Fusco”, “year” : “2014” }
- 54. Transform :- % dw 1.0 % output application/xml --------- { order : { type : “Book”, title : payload.title details : “By $(payload.author) ($(payload.year))” } }
- 55. Output :- <? Xml version = ‘1.0’ encoding = ‘UTF-8’ ? > <order> <type>Book</type> <title>Java 8 in action</title> <details>By Mario Fusco (2014)</details> </order>