Category: mulesoft

MuleSoft – Endpoints ”; Previous Next Endpoints basically include those components that trigger or initiate the processing in a working flow of Mule application. They are called Source in Anypoint Studio and Triggers in the Design Center of Mule. One important endpoint in Mule 4 is Scheduler component. Scheduler Endpoint This component works on time-based conditions, which means, it enables us to trigger a flow whenever a time-based condition is met. For example, a scheduler can trigger an event to start a Mule working flow every, say 10 seconds. We can also use flexible Cron expression to trigger a Scheduler Endpoint. Important points about Scheduler While using Scheduler event, we need to take care of some important points as given below − Scheduler Endpoint follows the time-zone of the machine where Mule runtime is running. Suppose if a Mule application is running in CloudHub, the Scheduler will follow the time-zone of the region in which the CloudHub worker is running. At any given time, only one flow triggered by the Scheduler Endpoint can be active. In Mule runtime cluster, the Scheduler Endpoint runs or triggers only on primary node. Ways to configure a Scheduler As discussed above, we can configure a scheduler endpoint to be triggered at a fixed interval or we can also give a Cron expression. Parameters to configure a Scheduler (For Fixed Interval) Following are the parameters to set a scheduler to trigger a flow at regular intervals − Frequency − It basically describes at which frequency the Scheduler Endpoint will trigger the Mule flow. Unit of time for this can be selected from the Time Unit field. In case you do not provide any values for this, it will use the default value which is 1000. On the other side, if you provide 0 or a negative value, then also it uses the default value. Start Delay − It is the amount of time we must wait before triggering the Mule flow for the first time once the application is started. The value of Start delay is expressed in the same unit of time as the frequency. Its default value is 0. Time Unit − It describes the time unit for both Frequency and Start Delay. The possible values of time unit are Milliseconds, Seconds, Minute, Hours, Days. The default value is Milliseconds. Parameters to configure a Scheduler (For Cron Expression) Actually, Cron is a standard used for describing time and date information. In case you use the flexible Cron expression to make Scheduler trigger, the Scheduler Endpoint keeps track of every second and creates a Mule event whenever the Quartz Cron expression matches the time-date setting. With Cron expression, the event can be triggered just once or at regular intervals. Following table gives the date-time expression of six required settings − Attribute Value Seconds 0-59 Minutes 0-59 Hours 0-23 Day of month 1-31 Month 1-12 or JAN-DEC Day of the week 1-7 or SUN-SAT Some examples of Quartz Cron expressions supported by the Scheduler Endpoint are given below − ½ * * * * ? − means that the scheduler runs every 2 seconds of the day, every day. 0 0/5 16 ** ? − means that the scheduler runs every 5 minutes starting at 4 pm and ending at 4:55 pm, every day. 1 1 1 1, 5 * ? − means that the scheduler runs the first day of January and the first day of April, every year. Example The following code logs the message “hi” every second − <flow name = “cronFlow” doc:id = “ae257a5d-6b4f-4006-80c8-e7c76d2f67a0”> <doc:name = “Scheduler” doc:id = “e7b6scheduler8ccb-c6d8-4567-87af-aa7904a50359”> <scheduling-strategy> <cron expression = “* * * * * ?” timeZone = “America/Los_Angeles”/> </scheduling-strategy> </scheduler> <logger level = “INFO” doc:name = “Logger” doc:id = “e2626dbb-54a9-4791-8ffa-b7c9a23e88a1″ message = ””hi””/> </flow> Print Page Previous Next Advertisements ”;

MuleSoft – Core Components & Configuration ”; Previous Next One of the most important abilities of Mule is that it can perform routing, transforming, and processing with the components, because of which the configuration file of Mule application that combines various elements is very large in size. Following are the types of configuration patterns provided by Mule − Simple service pattern Bridge Validator HTTP proxy WS proxy Configuring the component In Anypoint studio, we can follow the below steps to configure a component − Step 1 We need to drag the component we wish to use in our Mule application. For example, here we use HTTP listener component as follows − Step 2 Next, double click on the component to get the configuration window. For HTTP listener, it is shown below − Step 3 We can configure the component as per the requirement of our project. Say for example, we did for HTTP listener component − Core components are one of the important building blocks of work flow in the Mule app. The logic for processing a Mule event is provided by these core components. In Anypoint studio, to access these core components, you can click on the Core from Mule Palette as shown below − Following are various core components and their working in Mule 4 − Custom Business Events This core component is used for the collection of information about flows as well as message processors that handle the business transactions in Mule app. In other words, we can use Custom Business Event component to add the following in our working flow − Metadata Key performance Indicators (KPIs) How to add KPIs? Following are the steps to add KPIs in our flow in Mule app − Step 1 − Follow Mule Palette → Core → Components → Custom Business Event, to add Custom Business Event component to a working flow in your Mule app. Step 2 − Click on the component to open it. Step 3 − Now, we need to provide values for Display Name and Event Name. Step 4 − To capture information from the message payload, add KPIs as follows − Give a name (key) for the KPI (tracking: meta-data element) and a value. The name will be used in search interface of Runtime Manager. Give a value that may be any Mule expression. Example Following table consists of the list of KPIs with Name and Value − Name Expression/Value Student RollNo #[payload[‘RollNo’]] Student Name #[payload[‘Name’]] Dynamic Evaluate This core component is used for dynamically selecting a script in Mule app. We can also use hardcore script through the Transform Message Component but using Dynamic Evaluate component is a better way. This core component works as follows − Firstly, it evaluates an expression that should result in another script. Then it evaluates that script for the final result. In this way, it allows us to dynamically select the script rather than hardcoding it. Example Following is an example of selecting a script from database through an Id query parameter and storing that script in a variable named MyScript. Now, the dynamic-evaluate component will access the variable to invoke the scripts so that it can add a name variable from UName query parameter. The XML configuration of the flow is given below − <flow name = “DynamicE-example-flow”> <http:listener config-ref = “HTTP_Listener_Configuration” path = “/”/> <db:select config-ref = “dbConfig” target = “myScript”> <db:sql>#[“SELECT script FROM SCRIPTS WHERE ID = $(attributes.queryParams.Id)”] </db:sql> </db:select> <ee:dynamic-evaluate expression = “#[vars.myScript]”> <ee:parameters>#[{name: attributes.queryParams.UName}]</ee:parameters> </ee:dynamic-evaluate> </flow> The script can use context variables like message, payload, vars or attributes. However, if you want to add custom context variable, you need to provide a set of key-value pairs. Configuring Dynamic Evaluate Following table provides a way to configure Dynamic Evaluate component − Field Value Description Example Expression DataWeave expression It specifies the expression to be evaluated into the final script. expression=”#[vars.generateOrderScript]” Parameters DataWeave expression It specifies key-value pairs. #[{joiner: ” and ”, id: payload.user.id}] Flow Reference Component If you want to route the Mule event to another flow or sub-flow and back within the same Mule app, then flow reference component is the right option. Characteristics Following are the characteristics of this core component − This core component allows us to treat the whole referenced flow like a single component in the current flow. It breaks the Mule application into discrete and reusable units. For example, a flow is listing files on regular basis. It might reference another flow that processes the output of the list operation. In this way, rather than appending the whole processing steps, we can append Flow References that points to the processing flow. The screenshot below shows that the Flow Reference Core Component is pointing towards a sub-flow named ProcessFiles. Working The working of Flow Ref component can be understood with the help of following diagram − The diagram shows the processing order in Mule application when one flow references another flow in the same application. When the main working flow in Mule application triggered, the Mule event travels all through and executes the flow until the Mule event reaches Flow Reference. After reaching Flow Reference, the Mule event executes the referenced flow from beginning to end. Once Mule event finishes executing the Ref Flow, it returns to the main flow. Example For better understanding, let us use this component in Anypoint Studio. In this example, we are taking HTTP listener to GET a message, as we did in the previous chapter. So, we can drag and drop the component and configure. But for this example, we need to add a Sub-flow component and set Payload component under that, as shown below − Next, we need to configure Set Payload, by double clicking on it. Here we are giving the value, “Sub flow executed” as shown below − Once successfully configuring the sub-flow component, we need the Flow Reference Component to set after Set Payload of main flow, which we can drag and drop from the

MuleSoft – Mule in Our Machine ”; Previous Next In the previous chapters, we have learnt the basics of Mule ESB. In this chapter, let us learn how to install and configure it. Prerequisites We need to satisfy the following prerequisites before installing Mule on our computer − Java Development Kit (JDK) Before installing MULE, verify that you have supported version of Java on your system. JDK 1.8.0 is recommended to successfully install Mule on your system. Operating System Following operating systems are supported by Mule − MacOS 10.11.x HP-UX 11iV3 AIX 7.2 Windows 2016 Server Windows 2012 R2 Server Windows 10 Windows 8.1 Solaris 11.3 RHEL 7 Ubuntu Server 18.04 Linux Kernel 3.13+ Database An application server or database is not required as the Mule Runtime runs as a standalone server. But if we need to access a data store or want to use an application server, following supported application servers or databases can be used − Oracle 11g Oracle 12c MySQL 5.5+ IBM DB2 10 PostgreSQL 9 Derby 10 Microsoft SQL Server 2014 System Requirements Before installing Mule on your system, it must fulfil the following system requirements − At least 2 GHz CPU or 1 Virtual CPU in virtualized environments Minimum 1 GB RAM Minimum 4 GB storage Download Mule To download Mule 4 binary file, click on the link https://www.mulesoft.com/lp/dl/mule-esb-enterprise and it will lead you to the official web page of MuleSoft as follows − By providing the necessary details, you can get the Mule 4 binary file in Zip format. Install and Run Mule Now after downloading the Mule 4 binary file, unzip it and set an environment variable called MULE_HOME for the Mule directory inside the extracted folder. For example, the environment variable, on Windows and Linux/Unix environments, can be set for version 4.1.5 in the Downloads directory as follows − Windows Environments $ env:MULE_HOME=C:Downloadsmule-enterprise-standalone-4.1.5 Unix/Linux Environments $ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.1.5/ Now, for testing whether Mule is running in your system without any error, use the following commands − Windows Environments $ $MULE_HOMEbinmule.bat Unix/Linux Environments $ $MULE_HOME/bin/mule The above commands will run Mule in the foreground mode. If Mule is running, we cannot issue any other commands on the terminal. Pressing ctrl-c command in the terminal, will stop Mule. Start Mule Services We can start Mule as a Windows Service and as a Linux/Unix Daemon also. Mule as a Windows Service To run Mule as a Windows service, we need to follow the below steps − Step 1 − First, install it with the help of following command − $ $MULE_HOMEbinmule.bat install Step 2 − Once installed, we can run mule as a Windows service with the help of the following command: $ $MULE_HOMEbinmule.bat start Mule as a Linux/Unix Daemon To run Mule as a Linux/Unix Daemon, we need to follow the below steps − Step 1 − Install it with the help of the following command − $ $MULE_HOME/bin/mule install Step 2 − Once installed, we can run mule as a Windows service with the help of following command − $ $MULE_HOME/bin/mule start Example The following example starts Mule as a Unix Daemon − $ $MULE_HOME/bin/mule start MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.1.5 MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.1.5 Starting Mule Enterprise Edition… Waiting for Mule Enterprise Edition…………….. running: PID:87329 Deploy Mule Apps We can deploy our Mule apps with the help of following steps − Step 1 − First, start Mule. Step 2 − Once Mule starts, we can deploy our Mule applications by moving our JAR package files to the apps directory in $MULE_HOME. Stop Mule Services We can use stop command to stop Mule. For example, the following example starts Mule as a Unix Daemon − $ $MULE_HOME/bin/mule stop MULE_HOME is set to /Applications/mule-enterprise-standalone-4.1.5 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.1.5 Stopping Mule Enterprise Edition… Stopped Mule Enterprise Edition. We can also use remove command to remove the Mule Service or Daemon from our system. The following example removes Mule as a Unix Daemon − $ $MULE_HOME/bin/mule remove MULE_HOME is set to /Applications/mule-enterprise-standalone-4.1.5 MULE_BASE is set to /Applications/mule-enterprise-standalone-4.1.5 Detected Mac OSX: Mule Enterprise Edition is not running. Removing Mule Enterprise Edition daemon… Print Page Previous Next Advertisements ”;

MuleSoft – Discovering Anypoint Studio ”; Previous Next Anypoint Studio editors help us design our applications, APIs, properties and configuration files. Along with designing, it also helps us to edit them. We have the Mule configuration file editor for this purpose. To open this editor, double-click on the application XML file in /src/main/mule. To work with our application, we have the following three tabs under Mule Configuration file editor. The Message Flow tab This tab gives a visual representation of work flow. It basically contains a canvas that helps us check our flows visually. If you want to add Event Processors from the Mule Palette into the canvas, then just drag and drop and it will reflect in the canvas. By clicking on an Event Processor, you can get the Mule Properties View with the attributes for the selected processor. We can also edit them. The Global Elements tab This tab contains the global Mule configuration elements for the modules. Under this tab we can create, edit or delete configuration files. The Configuration XML tab As the name implies, it contains the XML that defines your Mule application. All the changes you do here will reflect in the canvas as well as the properties view of event processor under the Message Flow tab. Views For the active editor, Anypoint studio gives us the graphical representation of our project metadata, properties with the help of views. A user can move, close as well as add views in the Mule project. Following are some default views in Anypoint studio − Package Explorer The main task of Package Explorer view is to display the project folders and files consisted in a Mule project. We can expand or contract the Mule project folder by clicking on the arrow next to it. A folder or file can be opened by double clicking it. Have a look at its screenshot − Mule Palette Mule Palette view shows the event processors like scopes, filters, and flow control routers along with modules and their related operations. The main tasks of Mule Palette view are as follows − This view helps us to manage the modules and connectors in our project. We can also add new elements from Exchange. Have a look at its screenshot − Mule Properties As the name implies, it allows us to edit the properties of the module currently selected in our canvas. Mule Properties view includes the following − DataSense Explorer that supplies real-time information about the data structure of our payload. Inbound and outbound properties, if available or variables. Below is the screenshot − Console Whenever we create or run the Mule application, embedded Mule server displays a list of events and problems, if any, reported by Studio. Console view contains the console of that embedded Mule server. Have a look at its screenshot − Problems View We can encounter many issues while working on our Mule Project. All those issues are displayed in the Problems view. Below is the screenshot Perspectives In Anypoint Studio, it is a collection of views and editors in a specified arrangement. There are two kinds of perspectives in Anypoint Studio − Mule Design Perspective − It is the default perspective we get in Studio. Mule Debug Perspective − Another perspective supplied by Anypoint Studio is Mule Debug Perspective. On the other hand, we can also create our own perspective and can add or remove any of the default views. Print Page Previous Next Advertisements ”;

MuleSoft – DataWeave Language ”; Previous Next DataWeave is basically a MuleSoft expression language. It is mainly used for accessing and transforming the data received through a Mule application. Mule runtime is responsible for running the script and expressions in our Mule application, DataWeave is strongly integrated with Mule runtime. Features of DataWeave Language Following are some important features of DataWeave language − Data can be transformed from one format to another very easily. For example, we can transform application/json to application/xml. The input payload is as follows − { “title”: “MuleSoft”, “author”: ” tutorialspoint.com “, “year”: 2019 } Following is the code in DataWeave for transform − %dw 2.0 output application/xml — { order: { ”type”: ”Tutorial”, ”title”: payload.title, ”author”: upper(payload.author), ”year”: payload.year } } Next, the output payload is as follows − <?xml version = ”1.0” encoding = ”UTF-8”?> <order> <type>Tutorial</type> <title>MuleSoft</title> <author>tutorialspoint.com</author> <year>2019</year> </order> The transform component can be used for creating scripts that performs both simple as well as complex data transformations. We can access and use core DataWeave functions on parts of the Mule event that we need as most of the Mule message processors support DataWeave expressions. Prerequisites We need to satisfy the following prerequisites before using DataWeave scripts on our computer − Anypoint Studio 7 is required to use Dataweave scripts. After installing Anypoint Studio, we need to set up a project with a Transform Message component in order to use DataWeave scripts. Steps for Using DataWeave Script with Example In order to use DataWeave scrip, we need to follow the steps below − Step 1 First, we need to set up a new project, as we did in the previous chapter, by using File → New → Mule Project. Step 2 Next, we need to provide the name of the project. For this example, we are giving the name, Mule_test_script. Step 3 Now, we need to drag the Transform Message component from Mule Palette tab into canvas. It is shown as below − Step 4 Next, in the Transform Message component tab, click on Preview to open Preview pane. We can expand the source code area by clicking the empty rectangle next to Preview. Step 5 Now, we can start scripting with DataWeave language. Example Following is the simple example of concatenating two strings into one − The above DataWeave script is having a key-value pair ({ myString: (“hello” ++ “World”) }) which will concatenate two strings into one. Print Page Previous Next Advertisements ”;

MuleSoft – Flow Control and Transformers ”; Previous Next Flow Control (Routers) The main task of Flow Control component is to take the input Mule event and route it to one or more separate sequences of components. It is basically routing the input Mule event to other sequence(s) of components. Therefore, it is also called as Routers. Choice and Scatter-Gather routers are the most used routers under Flow Control component. Choice Router As the name suggests, this router applies DataWeave logic to choose one of two or more routes. As discussed earlier, each route is a separate sequence of Mule event processors. We can define choice routers as the router that dynamically routes message through a flow according to a set of DataWeave expressions used to evaluate message content. Schematic diagram of Choice Router The effect of using Choice router is just like adding conditional processing to a flow or an if/then/else code block in most of the programming languages. Following is the schematic diagram of a Choice Router, having three options. Among those, one is the default router. Scatter-Gather Router Another most used routing event processor is Scatter-Gather component. As its name implies, it works on the fundamentals of scatters (copy) and Gather (Consolidates). We can understand its working with the help of following two points − First, this router copies (Scatter) a Mule event to two or more parallel routes. The condition is that each route must be a sequence of one or more event processors which is like a sub-flow. Each route in this case will create a Mule event by using a separate thread. Every Mule event will have its own payload, attributes as well as variables. Next, this router gathers the created Mule events from each route and then consolidates them together into a new Mule event. After this, it passes this consolidated Mule event to the next event processor. Here the condition is that the S-G router will pass a consolidated Mule event to the next event processor only when every route is completed successfully. Schematic Diagram of Scatter-Gather Router Following is the schematic diagram of a Scatter-Gather Router having four event processors. It executes every route in parallel and not sequentially. Error Handling by Scatter-Gather Router First, we must have knowledge on the kind of error that can be generated within Scatter-Gather component. Any error might be generated within event processors leading the Scatter-Gather component to throw an error of type Mule: COMPOSITE_ERROR. This error will be thrown by the S-G component only after every route either fails or completes. To handle this error type, a try scope can be used in each route of Scatter-Gather component. If the error is successfully handled by try scope, then the route will be able to generate a Mule event, for sure. Transformers Suppose if we want to set or remove a part of any Mule event, Transformer component is the best choice. Transformer components are of the following types − Remove variable transformer As the name implies, this component takes a variable name and removes that variable from the Mule event. Configuring removing variable transformer The table below shows the name of fields and their description to be considered while configuring removing variable transformer − Sr.No Field & Explanation 1 Display Name (doc:name) We can customize this to display a unique name for this component in our Mule working flow. 2 Name (variableName) It represents the name of the variable to remove. Set payload transformer With the help of set-payload component, we can update the payload, which can be a literal string or DataWeave expression, of the message. It is not recommended to use this component for complex expressions or transformations. It can be used for simple ones like selections. The table below shows the name of fields and their description to be considered while configuring set payload transformer − Field Usage Explanation Value (value) Mandatory The value filed is required for setting a payload. It will accept a literal string or DataWeave expression defining how to set the payload. The examples are like “some string” Mime Type (mimeType) Optional It’s optional but represents the mime type of the value assigned to the payload of message. The examples are like text/plain. Encoding (encoding) Optional It’s also optional but represents the encoding of the value that is assigned to the payload of message. The examples are like UTF-8. We can set a payload through XML configuration code − With Static Content − Following XML configuration code will set the payload by using static content − <set-payload value = “{ ”name” : ”Gaurav”, ”Id” : ”2510” }” mimeType = “application/json” encoding = “UTF-8″/> With Expression Content − Following XML configuration code will set the payload by using Expression content − <set-payload value = “#[”Hi” ++ ” Today is ” ++ now()]”/> The above example will append today’s date with the message payload “Hi”. Set Variable Transformer With the help of set variable component, we can create or update a variable to store values which can be simple literal values like strings, message payloads or attribute objects, for use within the flow of Mule application. It is not recommended to use this component for complex expressions or transformations. It can be used for simple ones like selections. Configuring set variable transformer The table below shows the name of fields and their description to be considered while configuring set payload transformer − Field Usage Explanation Variable Name (variableName) Mandatory It is required filed and it represents the name of the variable. While giving the name, follow the naming convention like it must contain number, characters and underscores. Value (value) Mandatory The value filed is required for setting a variable. It will accept a literal string or DataWeave expression. Mime Type (mimeType) Optional It’s optional but represents the mime type of the variable. The examples are like text/plain. Encoding (encoding) Optional It’s also optional but represents the encoding of the variable. The examples are like ISO

MuleSoft – The Mule Project ”; Previous Next The motivations behind the Mule project were − to make things simpler for the programmers, the need of lightweight and modular solution that could scale from an application-level messaging framework to an enterprise-wide highly distributable framework. Mule ESB is designed as an event-driven as well as programmatic framework. It is event-driven because it is combined with unified representation of messages and can be expandable with pluggable modules. It is programmatic because programmers can easily implant some additional behaviors such as specific message processing or custom data transformation. History The historical perspective of Mule project is as follows − SourceForge project The Mule project was started as the SourceForge project in April 2003, and after 2 years its first version was released and moved to CodeHaus. Universal Message Object (UMO) API was at the core of its architecture. The idea behind UMO API was to unify the logic while keeping them isolated from the underlying transports. Version 1.0 It was released in April 2005 containing numerous transports. The key focus of many other versions followed by it, was on debugging and adding new features. Version 2.0 (Adoption of Spring 2) Spring 2 as configuration and wiring framework was adopted in Mule 2 but it proved to be a major over-haul because of the lack of expressiveness of the required XML configuration. This issue was resolved when XML Schema-based configuration has been introduced in Spring 2. Building with Maven The biggest improvement that simplified Mule usage, both at development and deployment times, was the use of Maven. From version 1.3, it started to be constructed with Maven. MuleSource In 2006, MuleSource got incorporated “to help support and enable the rapidly growing community using Mule in mission-critical enterprise applications”. It proved to be the key milestone for Mule Project. Competitors of Mule ESB Following are some of the major competitors of Mule ESB − WSO2 ESB Oracle Service Bus WebSphere Message Broker Aurea CX Platform Fiorano ESB WebSphere DataPower Gateway Workday Business Process Framework Talend Enterprise Service Bus JBoss Enterprise Service Bus iWay Service Manager Mule’s Core Concept As discussed, Mule ESB is a lightweight and highly scalable Java-based enterprise service bus (ESB) and integration platform. Regardless of various technologies used by applications, Mule ESB enables easy integration of applications, enabling them to exchange data. In this section, we will discuss about Mule’s core concept coming into play to make such integration happen. For this, we need to understand its architecture as well as building blocks. Architecture The architecture of Mule ESB has three layers namely, Transport layer, Integration layer and Application layer as shown in the following diagram − Generally, there are following three types of tasks that can be performed to configure and customize Mule deployment − Service Component Development This task involves development or re-using the existing POJOs, or Spring Beans. POJOs is a class with attributes that generates the get and set methods, cloud connectors. On the other hand, Spring Beans contains the business logic to enrich messages. Service Orchestration This task basically provides the service mediation that involves configuring the message processor, routers, transformers and filters. Integration The most important task of Mule ESB is the integration of various applications regardless of the protocols they are using. For this purpose, Mule provides transport methods that allow receiving and dispatching the messages on various protocol connectors. Mule supports many existing transport methods, or we may also use a custom transport method. Building Blocks Mule configuration has the following building blocks − Spring beans The main use of Spring beans is to construct service component. After constructing spring service component, we can define it through a configuration file or manually, in case you do not have configuration file. Agents It is basically a service created in Anypoint Studio before Mule Studio. An agent is created once you start a server and will be destroyed once you stop the server. Connector It is a software component configured with the parameters that are specific to protocols. It is mainly used for controlling the usage of a protocol. For example, a JMS connector is configured with a Connection and this connector will be shared among various entities in charge of actual communication. Global Configuration As the name implies, this building block is used to set the global properties and settings. Global Endpoints It can be used in Global Elements tab which can be used as many times in a flow − Global Message Processor As the name implies, it observes or modifies a message or message flow. Transformers and filters are the examples of Global Message Processor. Transformers − The main job of a transformer is to convert data from one format to another. It can be defined globally and can be used in multiple flows. Filters − It is the filter that will decide which Mule message should be processed. Filter basically specifies the conditions that must be met for a message to be processed and routed to a service. Models In contrast to Agents, it is a logical grouping of services which are created in studio. We have the liberty to start and stop all the services inside a specific model. Services − Services are the one that wrap our business logic or components. It also configures Routers, Endpoints, transformers and filters specifically for that service. Endpoints − It may be defined as an object on which services will inbound (receive) and outbound (send) messages. Services are connected through endpoints. Flow Message processor use flows to define a message flow between a source and a target. Mule Message Structure A Mule message, totally wrapped under Mule Message Object, is the data that passes through applications via Mule flows. The structure Mule’s message is shown in the following diagram − As seen in the above diagram, Mule Message consists of two main parts − Header It is nothing but the metadata of the message which is further represented by the

MuleSoft Tutorial PDF Version Quick Guide Resources Job Search Discussion Mule ESB is a lightweight and highly scalable Java-based enterprise service bus (ESB) and integration platform provided by MuleSoft. Mule ESB allows developer to connect applications easily and quickly. Regardless of various technologies used by applications, Mule ESB enables easy integration of applications, enabling them to exchange data. Audience This tutorial will be useful for developers who are working on Mule ESB, and for migrators who are migrating Mule with other technologies. Besides, graduates, post graduates, and research students, who either have an interest in this technology or have this as a part of their curriculum, will also be benefited from this tutorial. The reader can be a beginner or an advanced learner. Prerequisites The reader must have basic knowledge about Java and Eclipse. He/she should also be aware of basic terminologies used in database and scripting languages like Python, Ruby and JavaScript. Print Page Previous Next Advertisements ”;

MuleSoft – Introduction to Mule ESB ”; Previous Next ESB stands for Enterprise Service Bus which is basically a middleware tool for integrating various applications together over a bus-like infrastructure. Fundamentally, it is an architecture designed to provide a uniform means of moving work among integrated applications. In this way, with the help of ESB architecture we can connect different applications through a communication bus and enable them to communicate without depending on one another. Implementing ESB The main focus of ESB architecture is to decouple the systems from each other and allow them to communicate in a steady and controllable way. ESB’s implementation can be done with the help of ‘Bus’ and ‘Adapter’ in the following way − The concept of “bus”, which is achieved through a messaging server like JMS or AMQP, is used to decouple different applications from one another. The concept of “adapter”, responsible for communicating with backend application and transforming data from application format to bus format, is used between applications and bus. The data or message passing from one application to another through the bus is in a canonical format which means there would be one consistent message format. The adapter can also perform other activities like security, monitoring, error handling and message routing management. ESB’s Guiding Principles We can call these principles as core integration principles. They are as follows − Orchestration − Integration of two or more services to achieve synchronization between data and process. Transformation − Transforming data from canonical format to application specific format. Transportation − Handling protocol negotiation between formats like FTP, HTTP, JMS, etc. Mediation − Providing multiple interfaces to support multiple versions of a service. Non-functional consistency − Providing mechanism for managing transactions and security also. Need of ESB ESB architecture enables us to integrate different applications where each application can communicate through it. Following are some guidelines on when to use ESB − Integrating two or more applications − Use of ESB architecture is beneficial when there is a need to integrate two or more services or applications. Integration of more applications in future − Suppose if we want to add more services or applications in future, then it can be easily done with the help of ESB architecture. Using multiple protocols − In case if we need to use multiple protocols like HTTP, FTP, JMS etc., ESB is the right option. Message routing − We can use ESB in case if we require message routing based on message content and other similar parameters. Composition and consumption − ESB can be used if we need to publish services for composition and consumption. P2P integration vs. ESB integration With the increase in number of applications, a big question in front of developers was how to connect different applications? The situation was handled by hand-coding a connection between various application. This is called point-to-point integration. Rigidity is the most obvious drawback of point-to-point integration. The complexity increases with the increased number of connections and interfaces. The disadvantages of P-2-P integration leads us to ESB integration. ESB is a more flexible approach to application integration. It encapsulates and exposes each application functionality as a set of discrete reusable capabilities. No application directly integrates with other, instead they integrate through an ESB as shown below − For managing the integration, ESB has the following two components − Service Registry − Mule ESB has Service Registry/Repository where all the services exposed into the ESB are published and registered. It acts as a point of discovery from where one can consume the services and capabilities of other applications. Centralized Administration − As the name implies, it provides a view of transactional flows of performance of interactions occurring inside the ESB. ESB Functionality − VETRO abbreviation is generally used to summarize the functionality of ESB. It is as follows − V(Validate) − As the name implies, it validates the schema validation. It requires a validating parser and up-to-date schema. One example is an XML document confirming to an up-to-date schema. E(Enrich) − It adds additional data to a message. The purpose is to make message more meaningful and useful to a target service. T(Transform) − It converts the data structure to a canonical format or from a canonical format. Examples are conversion of date/time, currency, etc. R(Routing) − It will route the message and act as a gatekeeper of the endpoint of a service. O(Operate) − The main job of this function is to invoke the target service or interacts with the target app. They run at the backend. VETRO pattern provides overall flexibility to the integration and ensures that only consistent and validated data will be routed throughout the ESB. What is Mule ESB? Mule ESB is a lightweight and highly scalable Java-based enterprise service bus (ESB) and integration platform provided by MuleSoft. Mule ESB allows the developer to connect applications easily and quickly. Regardless of various technologies used by applications, Mule ESB enables easy integration of applications, enabling them to exchange data. Mule ESB has the following two editions − Community Edition Enterprise Edition An advantage of Mule ESB is that we can easily upgrade from Mule ESB community to Mule ESB enterprise because both the editions are built on a common code base. Features & Capabilities of Mule ESB Following features are possessed by Mule ESB − It has simple drag-and-drop graphical design. Mule ESB is capable of visual data mapping and transformation. User can get the facility of 100s of pre-built certified connectors. Centralized monitoring and administration. It provides robust enterprise security enforcement capabilities. It provides the facility of API management. There is secure Data Gateway for cloud/on-premise connectivity. It provides the service registry where all the services exposed into the ESB are published and registered. Users can have control through a web-based management console. Rapid debugging can be performed using service flow analyzer. Print Page Previous Next Advertisements