Variable in Mule 4
In this Variable in Mule 4 tutorial we will look how we can create and use mule variable in Mule 4, and how it is different from Mule 3 and Mule 4. In Mule 3 we had Flow variables, Session variables and record variable to store the data inside mule flow. But now in Mule 4 this has been changed; session variable and record variable has been removed and there is only Flow Variable. As in Mule 3, Flow Variable in Mule 4 value is lost even when the flow crosses the transport barrier. In Mule 4, flow variables have been enhanced to work efficiently during batch processing, just like the record variables. Flow variables created in batch steps are now automatically tied to the processing record and stays with it throughout the processing phase. No longer record variables are needed. |
Category Archives: Mulesoft Basics
Retry Mechanism – Until Success Vs Flow Reference
Retry Mechanism – Until Success Vs Flow Reference
In mule 3 we have roll back exception strategy which enable’s the ability to retry the execution in case of error and define a separate flow to be executed once the retry count has exceeded.
In mule 4 you do have re-connection strategy which we can define on the connectors but that only retries in case of failure in connection. In Mule 4 we do not have roll back exception strategy, so in this tutorial we will be looking on how we can implement the same functionality in Mule 4.
To achieve this retry mechanism, we can use Until Successful, but the issue we will face are:
- We would not be able to specify any specific condition on which retry should happen . For Example: We will not be able to define retry only when HTTP status code is 202.
- We also cannot implement error flow, once an error has occurred. For Example: Every time an error is generated we need to send the error message on to a queue before retrying.
Scenario 1: We want to implement retry mechanism on Web service call, in case of error if HTTP status code is 502 then, API should retry its Web Service Call only 3 times.
To complete the above scenario, we will be using Flow Reference.
Flow Reference in Mule 3 was not able to call its own flow in which it was defined. But in Mule 4 you can call any flow even its own flow.
Flow Diagram:
All we need is to use is flow reference to call its own flow when an error is generated. We have moved HTTP Request to another flow “HTTPFlow” and is referred by flow reference in main flow “get:\users:test-config”.
Inside HTTPFlow we have HTTP Request call on which we have implement retry mechanism. In Error handling part, “On Error Continue” is checking for the retry count if it has reached to its max or not. Inside error flow of “On Error Continue” retry count value is getting incremented and after some seconds of sleep; flow reference will again call HTTPFlow. Once the retry count has reached to its max “On Error Continue” will no longer catch the error and the final error is throw back to its parent flow.
<flow name="get:\users:test-config"> <ee:transform xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd" doc:id="86de922d-7d4d-4d0a-b010-e1cf9e23a79d"> <ee:message> <ee:set-payload><![CDATA[%dw 2.0 output application/json --- { userID: [ "1", "2" ], userName: "Varun", subject: [ "Maths", "Mule", "TIbco" ], class: { name: "Class 10" } }]]></ee:set-payload> </ee:message> </ee:transform> <logger level="INFO" doc:name="Logger" doc:id="897eb15a-c379-4051-ae78-21ebbbf33cd1" /> <set-variable value="1" doc:name="SetRetryCount" doc:id="ae08693c-0c8e-4397-b5e2-235b8b288821" variableName="retryCount" /> <flow-ref doc:name="HTTPFlow" doc:id="84ab16f4-0fa5-4ac4-a73e-80dd7ab20ea0" name="HTTPFlow"/> <logger level="INFO" doc:name="Logger" doc:id="92727a36-d8ed-4ea1-8616-3c0537598400" /> </flow> <flow name="HTTPFlow" doc:id="610bee6d-59f2-4f77-a29e-d60b88aaea01" > <logger level="INFO" doc:name="Logger" doc:id="38537854-3f21-48a7-a6a6-31907d8bca90" message="Calling HTTP request count - #[(vars.retryCount default 0)]" /> <http:request method="GET" doc:name="HTTPCall" doc:id="c766093c-c7ac-444f-914d-cd4d1b70676d" config-ref="HTTP_Request_configuration" path="/abc"> <reconnect /> </http:request> <error-handler > <on-error-continue enableNotifications="true" logException="true" doc:name="On Error Continue" doc:id="8d23329f-b006-4a56-b6a7-6e33eb748957" when="#[(vars.retryCount as Number default 0) < 3 and error.muleMessage.attributes.StatusCode == 503]"> <logger level="INFO" doc:name="Logger" doc:id="1be75ffe-a4bf-4fe1-9802-ae1309d76341" message="#[error.description]"/> <set-variable value="#[(vars.retryCount default 0) +1]" doc:name="Increment retryCount" doc:id="a9877e1d-d1f5-4786-93e9-58126d08f3f4" variableName="retryCount"/> <scripting:execute doc:name="Sleep" doc:id="531bc61a-937d-4a0c-81ce-1ea0685ce64f" engine="groovy"> <scripting:code >def duration = Long.valueOf('3000'); sleep(duration); return message.payload;</scripting:code> </scripting:execute> <flow-ref doc:name="HTTPFlow" doc:id="3f37c302-ec9a-4751-ab4e-dcdefb2607f5" name="HTTPFlow"/> </on-error-continue> </error-handler> </flow>
Scenario 2: Here we want to implement retry mechanism on Web service call when a specific value is received. Example if a web service call returns a value 5 then retry should happen maximum 3 times else not.
Implementation:
We have moved HTTP Request to sub flow “testSub_Flow” and is referred by flow reference in its parent flow “post:\users:application\json:test-config”.
Inside testSub_Flow we are using flow reference to call itself. Once we have received the response from web service call “Request“, Choice router we are routeing flow processing based on response received and number of retires number.
Calling Custom Java Function in Mule 4
Calling Custom Java Function in Mule 4
In this tutorial we will learn how we can invoke custom java functions in mule 4. The ways by which Java functions can be called are: |
Parallel For Each in Mule 4
The Parallel For-Each scope enables you to process a collection of messages by splitting the collection into parts that are simultaneously processed in separate routes. After all messages are processed, the results are aggregated following the same order they were in before the split, and then the flow continues.
In the below tutorial we will see who we can use parallel for each in you project.
Download Parallel For Each Example
Syntax:
<parallel-foreach doc:name="parallel For Each" collection="payload"> <!-- Code to be Processed parallel --> </parallel-foreach>
Parallel For Each
In this example we will send a JSON message as an array, which will be split by parallel for each and executed in parallel.
Inside parallel for each we are transforming the message received with a delay of 5 sec, so that we can clearly see in logs in our API has processed messages in parallel or not.
<sub-flow name="addUsersParallelForEach" doc:id="5820e110-740b-48aa-baf2-b4f0fa68716a" > <logger level="INFO" doc:name="Log Request" doc:id="53992e7f-84cf-4c29-bb74-2be27a2ececf" message="'request received - ' #[payload]"/> <parallel-foreach doc:name="parallel For Each" doc:id="81acc47f-7b50-4806-95ea-6e7f24cd6683" collection="payload"> <ee:transform doc:name="Transform Message" doc:id="751032f3-11f6-4ce3-b136-73e534bd6224" > <ee:message > <ee:set-payload ><![CDATA[%dw 2.0 import * from dw::Runtime output application/json --- msg : payload.username ++ ' processed' wait 5000]]></ee:set-payload> </ee:message> <ee:variables > </ee:variables> </ee:transform> <logger level="INFO" doc:name="for-each output" doc:id="bfe598c4-6b02-4d36-8fa9-00d9cb2a8cce" message="for-each output: #[payload]"/> </parallel-foreach> <set-payload value="#[%dw 2.0 output application/json --- payload]" doc:name="Set Payload" doc:id="989fedef-40e2-4e74-87e6-577bebca3b4c" /> <logger level="INFO" doc:name="Logger" doc:id="fa4eb2fb-a70c-4489-aaff-81eafa03213f" message="#[payload]"/> </sub-flow>
Request:
Output:
Logs: In the logs we can see that the messages are processed in parallel.
Parallel Processing in Batches
In this example we will execute parallel processing but in batches. If we are connecting to an external system (suppose salesforce), and need to send the request in batches of 200 and all the batches should be executed in parallel.
How can we achieve this? is simple, by using divideBy function.
<parallel-foreach doc:name="parallel For Each" doc:id="3641e6b1-e499-4528-b6f6-d9ad7545368e" collection="#[import * from dw::core::Arrays output application/json --- payload divideBy 2]">
Here for example, if we receive 10 records. 10 records will be spit/divided into sets of 2 and 5 jobs will be created that will executed in parallel and processed.
In the below code we are dividing the payload received into set of 2, then transforming the message received with a delay of 5 sec so that we can clearly see in API logs if messages processed in parallel or not.
<sub-flow name="addUsersBatchParallelForEach" doc:id="aedbbefb-d38f-4ee1-a7e3-dc537645da5e" > <logger level="INFO" doc:name="Log Request" doc:id="1e9de3c9-cce7-4744-9010-c3b9b2a100ab" message="'request received - ' #[payload]"/> <parallel-foreach doc:name="parallel For Each" doc:id="3641e6b1-e499-4528-b6f6-d9ad7545368e" collection="#[import * from dw::core::Arrays output application/json --- payload divideBy 2]"> <flow-ref doc:name="Flow Reference" doc:id="2bf73bb0-1916-47fd-967d-4cdde18428f3" name="addUsersSub_Flow_BatchParallelForEach"/> </parallel-foreach> <set-payload value="#[%dw 2.0 output application/json --- flatten (payload.payload)]" doc:name="Set Payload" doc:id="bbee3431-7975-4528-93cf-3955ee4011cc" /> <logger level="INFO" doc:name="Logger" doc:id="fffae7bf-573d-4b27-9a69-26ecedde5d78" message="#[payload]"/> </sub-flow> <sub-flow name="addUsersSub_Flow_BatchParallelForEach" doc:id="eb15de26-5035-47ab-8183-4e6efbe49b80"> <ee:transform doc:name="Transform Message" doc:id="eaaebb0c-539a-4269-8295-2701b5c6397a" > <ee:message > <ee:set-payload ><![CDATA[%dw 2.0 import * from dw::Runtime output application/json --- (payload map { msg : $.username ++ ' processed' }) wait 5000 ]]></ee:set-payload> </ee:message> <ee:variables > </ee:variables> </ee:transform> <logger level="INFO" doc:name="for-each output" doc:id="198b6135-10e6-4882-bd1d-1686dd3f49fd" message="for-each output: #[payload]"/> </sub-flow>
Output:
To get only the message payload received after processing we are using flatten (payload.payload)
Logs:
Executing Dataweave Dynamically
In case we want our Dataweave expression outside mule project, load and process it at runtime then you would need Dynamic Evaluate component.
Download Dynamic Evaluate Project Example
In a scenario wherein dataweave mapping conditions are expected to change frequently based on client’s requirements and you don’t want to redeploy running APIs again and again, in such scenario we can store our dataweave expression in a DB or S3 or other location and access and process it dynamically in our Mule API. Any changes made to this external datawave will be picked up by Mule while reading it from external source and processed.
In the below example we are using variable dynamic_dw to store the datawave expression as a String. In a real world this datawave expression should be coming from an external source like DB or SFTP or others and getting stored in a variable.
Request:
Response:
Code:
<sub-flow name="dynamic-evaluateSub_Flow" doc:id="2145c3c0-5196-418f-9dd3-adf06966cc4a" > <set-variable value="#[%dw 2.0 output application/json --- payload]" doc:name="Store payload" doc:id="18b55a69-28fd-48ae-9344-f80e9be3ffc6" variableName="reqReceived"/> <set-variable value="#['%dw 2.0 output application/json --- vars.reqReceived.username']" doc:name="datawave received from external source" doc:id="29aebfba-73e4-41b3-9f3f-e508f98da413" variableName="dynamic_dw"/> <logger level="INFO" doc:name="datawave received" doc:id="672895f7-42e8-4c25-8dca-b11bd61634b3" message="#['script - ' ++ vars.dynamic_dw]"/> <ee:dynamic-evaluate doc:name="Dynamic Evaluate" doc:id="59d877bb-36ba-4193-bf72-df5083a06d22" expression="#[vars.dynamic_dw]"/> <logger level="INFO" doc:name="output" doc:id="fea7a7e5-b8d3-4726-80b8-a846c3794a71" message="#[payload]"/> </sub-flow>
Creating Mule 4 Project with RAML
Creating Mule 4 Project with RAMLIn this Mule tutorial we will learn how to Create Mule 4 project with RAML and a detailed walk-through on how the Mule flow works in case of a success or error scenario: |
Mule ESB – What is RAML and why it’s usedRAML stands for RESTful API Modeling Language and is similar to WSDL. A RAML provides a structure to the API which is useful for developers to start there development process and also helps client who is invoking the API to know before hand what the API does. A RAML contains:
|
Inbound Outbound Properties
In this “Inbound Outbound Properties” tutorial of Mule 4 we will look on how we can set and modify Mule Inbound and Outbound Properties.
In Mule Inbound properties referees to the additional information that comes to an Mule API along with the message body/payload itself. It may consist of inbound Headers, Query Params, URI Params, HTTP method etc.
In Mule Inbound properties are preset by the sender of the message thus cannot be added or modified.
Mule Outbound Properties are headers and properties that Mule API set before ending its request to other external systems.
Inbound Properties
In Mule 3 we used to access inbound properties by #[message.inboundProperties]
Whereas in Mule 4 we access these properties by #[attributes]
Example
We have create a simple project using RAML.
The GET method of the RAML has URI Param – user_id, which can assess by #[attributes.uriParams['user_id']]
Similarly to access Query Param we do it by #[attributes.queryParams['code']]
To view all the Inbound Properties that are received by a Mule API:
#[attributes]
Output :
Outbound Properties
As in Mule 3 we used to set outbound properties via using Set Property Component.
In Mule 4, outbound properties no longer exist. Instead, the headers or properties (e.g. HTTP headers or JMS properties) that you wish to send as part of a request or message (e.g. HTTP request or JMS message) respectively are now configured explicitly as part of the connector operation configuration.
Example:
To Set the outbound HTTP headers and HTTP status code for a Mule API we need to modify the HTTP Listener Configuration.
SoapUI Output –
Mule 4: JSON Schema Validation
JSON Schema is a specification for JSON based format for defining the structure of JSON data. It validates input data at runtime and verifies that they match a referenced schema or not. We can match against defined schemas that exist in local file or in an external URI.
If the payload is incorrect with given JSON schema, then compiler throws below Exception:
org.mule.module.json.validation.JsonSchemaValidationException: Json content is not compliant with schema
Use Case:
Validating the input JSON payload against with JSON Schema.
JSON Payload:
{ "firstName": "Murali", "lastName": "Krishna", "age" : 26 }
JSON – Schema :
{ "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "firstName": { "type": "string" }, "lastName": { "type": "string" }, "age": { "type": "integer" } }, "required": [ "firstName", "lastName", "age" ] }
Mule Flow:
Step -1 :
Configure the HTTP Listener with by giving hostname, port number and path along with this specify allowed methods (Optional) at an Advanced tab of HTTP connector.
Step-2:
Drag and Drop the JSON Validate Schema from Mule Palette to validate the input payload. And provide the schema path. In my case it is like below:
schemas/Sample-Schema.json
From above line,
schemas –> It is directory
Sample-Schema.json —> It is JSON-Schema structure for validation.
Syntax of JSON Validator as below:
<json:validate-schema doc:name="Validate schema" doc:id="5a8b10e1-59e8-4f68-9aaa-303c9cb5c9d6" schema="schemas/Sample-Schema.json">
Step-3:
Drag & Drop the Logger component to log the resultant payload after validation.
Final Config.xml:
<?xml version="1.0" encoding="UTF-8"?> <mule xmlns:json="http://www.mulesoft.org/schema/mule/json" xmlns:validation="http://www.mulesoft.org/schema/mule/validation" xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd http://www.mulesoft.org/schema/mule/validation http://www.mulesoft.org/schema/mule/validation/current/mule-validation.xsd http://www.mulesoft.org/schema/mule/json http://www.mulesoft.org/schema/mule/json/current/mule-json.xsd"> <http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config" doc:id="8a601d72-5913-4ed7-99d3-707601301ec9" > <http:listener-connection host="0.0.0.0" port="8080" /> </http:listener-config> <flow name="abcFlow" doc:id="30917fd1-0429-4ec7-9d7d-aa8d4d19413e" > <http:listener doc:name="Listener" doc:id="2b89fed0-69ce-47eb-93bf-3bd0628fe188" config-ref="HTTP_Listener_config" path="abc" allowedMethods="POST"> <ee:repeatable-file-store-stream /> </http:listener> <json:validate-schema doc:name="Validate schema" doc:id="5a8b10e1-59e8-4f68-9aaa-303c9cb5c9d6" schema="schemas/Sample-Schema.json"> </json:validate-schema> <logger level="INFO" doc:name="Logger" doc:id="26b62866-2f25-4374-9d95-9fe14c052366" message="Payload is Validated ----> #[message.payload]" /> </flow> </mule>
Success Scenario:
Failed Scenario:
Thank you!
Please feel free to share your thoughts in the comments section.
Mule – 4 DataWeave Functions – Part – 1
In DataWeave 2.0 functions are categorized into different modules.
- Core (dw::Core)
- Arrays (dw::core::Arrays)
- Binaries (dw::core::Binaries)
- Encryption (dw::Crypto)
- Diff (dw::util::Diff)
- Objects (dw::core::Objects)
- Runtime (dw::Runtime)
- Strings (dw::core::Strings)
- System (dw::System)
- URL (dw::core::URL)
Functions defined in Core (dw::Core) module are imported automatically into your DataWeave scripts. To use other modules, we need to import them by adding the import directive to the head of DataWeave script, for example:
import dw::core::Strings
import dasherize, underscore from dw::core::Strings
import * from dw::core::Strings
Sample Payload: |
{ "firstName" : "Murali", "lastName" : "Krishna", "age" : "26", “age” : ”26” }
1. Core (dw::Core)
Below are the DataWeave 2 core functions:
++ , –, abs, avg, ceil, contains, daysBetween, distinctBy, endsWith, filter, IsBlank, joinBy, min, max etc….
result : [0, 1, 2] ++ [“a”, “b”, “c”] will gives us “result” : “[0, 1, 2, “a”, “b”, “c”]”
result : [0, 1, 1, 2] — [1,2] will gives us “result” : “[0]”
result : abs(-20) will gives us “result” : 20
average : avg([1, 1000]) will gives us “average” : 500.5
value : ceil(1.5) will gives us “value” : 2
result : payload contains “Krish” will gives us “result” : true
days: daysBetween(“2016-10-01T23:57:59-03:00”, “2017-10-01T23:57:59-03:00”) will gives us “days”: 365
age : payload distinctBy $ will gives us :
{
“firstName” : “Murali”,
“lastName” : “Krishna”,
“age” : ”26”
}
a: “Murali” endsWith “li” will gives us “a” : true
a: [1, 2, 3, 4, 5] filter($ > 2) will gives us “a” : [3,4,5]
empty: isBlank(“”) will gives us “empty” : true
aa: [“a”,”b”,”c”] joinBy “-” will gives us “a” : “a-b-c”
a: min([1, 1000]) will gives us “a” : 1
a: max([1, 1000]) will gives us “a” : 1000
2.Arrays (dw::core::Arrays)
Arrays related functions in DataWeave are :
countBy, divideBy, every, some, sumBy
[1, 2, 3] countBy (($ mod 2) == 0) will gives us 1
[1,2,3,4,5] dw::core::Arrays::divideBy 2 will gives us :
[
[
1,
2
],
[
3,
4
],
[
5
]
]
[1,2,3,4] dw::core::Arrays::every ($ == 1) will gives us “false”
[1,2,3,4] dw::core::Arrays::some ($ == 1) will gives us “true”
[ { a: 1 }, { a: 2 }, { a: 3 } ] sumBy $.a will gives us “6”
3.Binaries (dw::core::Binaries)
Binary functions in DataWeave-2 are:
fromBase64, fromHex, toBase64, toHex
toBase64(fromBase64(12463730)) will gives us “12463730”
{ “binary”: fromHex(‘4D756C65’)} will gives us “binary” : “Mule”
{ “hex” : toHex(‘Mule’) } will gives us “hex” : “4D756C65”
4.Encryption (dw::Crypto)
Encryption functions in Dataweave – 2 are:
HMACBinary, HMACWith, MD5, SHA1, hashWith
{ “HMAC”: Crypto::HMACBinary((“aa” as Binary), (“aa” as Binary)) } will gives us :
“HMAC”: “\u0007£š±]\u00adÛ\u0006‰\u0006Ôsv:ý\u000b\u0016çÜð”
Crypto::MD5(“asd” as Binary) will gives us “7815696ecbf1c96e6894b779456d330e”
Crypto::SHA1(“dsasd” as Binary) will gives us “2fa183839c954e6366c206367c9be5864e4f4a65”
5.Diff (dw::util::Diff)
It calculates difference between two values and returns list of differences.
DataWeave Script:
%dw 2.0
import * from dw::util::Diff
output application/json
var a = { age: “Test” }
var b = { age: “Test2” }
—
a diff b
Output:
{
“matches”: false,
“diffs”: [
{
“expected”: “\”Test\””,
“actual”: “\”Test2\””,
“path”: “(root).age”
}
]
}
Note:
Rest of the things will proceed in Mule – 4 DataWeave Functions Part – 2 article
DataWeave 1.0 to DataWeave 2.0 Migration – Part -1
DataWeave is a new feature of Mule-3 that allows us to convert data to any kind of format, such as XML, CSV, JSON and POJO’s etc. In Mule 3, we use both MEL and Dataweave for writing the mule messages. Among these, MEL is default expression language in Mule 3 But this approach had some data inconsistencies and scattered approaches. To avoid the stress of converting data objects to Java objects in Mule 3 every time by the usage of expressions Mule 4 was launched. In Mule 4 DataWeave is the default expression language over Mule 3’s default MEL.
In Mule-4 DataWeave version has changed from 1.0 to 2.0.
Apart from syntax changes, there are many new features in DataWeave 2.0
Externalizing Common Mule Flows
Externalizing Common Mule Flows
In this tutorial we will be externalizing some common mule flows so they can be used by multiple Mule Applications Externalizing common mule flows can be achieved by exporting the flows to be externalized into a JAR file and then importing the JAR in other applications. Tells look on the details of how we can do this with just few steps. |
1. Understanding the Flow
In the flow below we want to externalize sub flow – “externalizeMuleAPISub_Flow” which is been called by Flow reference in Get and Post Flows and exception handling – “externalizeMuleAPI-apiKitGlobalExceptionMapping”. |
2. Creating new Mule project We need to create a new mule project and dump the mule common flows that we want to externalize into it. And remove copied code from our previous project. Here we have deleted and added the 2 flows from our old project into our new project.
|
3. Exporting the new project as JAR file.
Here are the steps to be followed to export the project as JAR. Right Click on the Project in Package Explorer >> Click Export In the Popup Window Select Java>Jar File and Click Next. Select The project to be exported “externalflows” and add the path where the JAR is to be saved and Click Finish.
Now, we have create the project with common flows as Jar and export it to the specified location. |
4. Importing the JAR file
Now after exporting JAR, we need to import it to our main project. To Import the Jar -> go to Project Properties and Click “Add External Jars” and select the JAR File. |
5. Adding the Common Flows
Now we need to add the mule XML file name that we have imported as JAR into our main project. |
6. Running the Code
You might see few error been reported by Mule even after adding the mule XML filename. But do not worry on building the application all the error will go off. |
Validation Framework – Handling Business Errors MuleSoft
MuleSoft Validation Framework – Handling Business Errors
In this tutorial of mulesoft validation we will create an exception handling framework that will generate business/logical error and do custom validations to request/response message while mapping mulesoft code and learn how to handle those error. The validations are: The above example, can be resolved in couple of ways and we will see one of the most simplest and easy way by creating validation framework. |
Scatter-Gather In Depth – MuleSoft Tutorial
MuleSoft Scatter-Gather Scope
In this tutorial we will look at various configuration properties of Scatter-Gather with examples in detail and also see how to handle exception in Scatter-Gather. Why use Scatter-Gather in Mulesoft: Please read Validation Framework to understand how error is generated in the example. |
Caching or Cache Scope – Mulesoft / Mule ESB Tutorial
Caching In Mule ESB or Cache ScopeIn this Mule ESB tutorial we will look into what is caching and why to use it, how can we implement caching in mulesoft project and configuration properties in Mule Cache Scope/Activity. Also a step by step configuration of mule cache scope/activity and how to cache information retrieved from database. Please refer to Mule Tutorial: Connecting with Database mule tutorial to know how to connect to database in Mule ESB. |
What is caching and why to use it?
Caching is a concept with is used to store frequently used data in the memory, file system or database which saves processing time and load if it would have to be access from original source location every time. For example: We have to create an API to retrieve user information, that has connect to an external database which is on different server and fetch the records. (Assumption: external DB is not changing frequently) |
Understanding Various Mule Flows – Mulesoft Tutorial
Mulesoft / Mule EBS – Mule Flows Tutorial |
Mule Flows
In this mule ESB tutorial we will understand various mule flows in detail with downloadable examples. |
Various types of flows in mule
There are 4 types of flows in mule. While creating these flows the flow name should be unique in whole mule project despite beaning in different mule application XML file. |
SubFlow
Use – It can be used to split common logic and be reused by other flows. |
Creating Mule Project with RAML – Mulesoft / Mule ESB Tutorial
Creating Mule Project with RAMLIn this Mule tutorial we will learn how to create Mule project with RAML and a detailed walk-through on how the Mule flow works in case of a success or error scenario: |
Mule ESB – What is RAML and why it’s used
RAML stands for RESTful API Modeling Language and is similar to WSDL. A RAML provides a structure to an API and also help the client who is invoking the API to know before hand what the API does. A RAML contains:
|
Connecting with Database MySql – Mulesoft / Mule ESB Tutorial
Connecting with Database MySQLIn this Mulesoft / Mule ESB tutorial of Connecting with Database Using MySql, we will use mulesoft Database Connector and connect it with MySQL DB: |
MuleSoft Database Connector using MySQL
The Database connector allows you to connect with database with almost any Java Database Connectivity (JDBC) relational database using a single interface for every case. The Database connector allows you to run SQL operations on database including Select, Insert, Update, Delete, and even Stored Procedures. As of Anypoint Studio May 2014 with 3.5.0 Runtime, the JDBC connector is deprecated, and the Database connector takes on JDBC connection capabilities. |