Mule esb componenets and its descrption

1. Mule ESB Components
karthik

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>