Chinna’s MuleSoft course

MuleSoft learning path

DEVELOPER ARCHITECT

LEVEL 1 LEVEL 2 INTEGRATION ASSOCIATE INTGRATION ARCHITECT PLATFORM ARCHITECT

• Anypoint platform • Integration architectural concepts

• Access management to deal with platform administration area’s
• Design API’s using RAML or OAS • Platform architectural concepts
• Dealing artifacts over exchange.
• Cloud runtime to deploy mule applications.
• API management. deploy mule apps.
• Analytics management on deployed applications.

• Mule ESB integrations development using anypoint studio

• Dataweave language for transformations & enrichments

• MUnit to develop test cases driven development

• DevOps with mule

• Hands on real time project

Mule API life cycle
Setting up your computer

• Java installation & environment variables

• Maven installation & environment variables

• Setup Anypoint studio

• Postman installation
Web services

• Web service : A web service is a program which runs in server and whose results are sharable over network/integration to make data transfer
between applications.

• The types of web services are of two types SOAP and REST.

• SOAP services are legacy approach, and the development of SOAP services is very less comparing to REST.

• REST services are latest and called as REST API’s.

• The percentage of development of REST is 95% and SOAP is 5%

How rest service can be accessed

• Before implementation of REST services, we should understand about a URL that we usually interact every day because we interact with
REST API using URL.

• http-protocol://host:port/base-path/sub-path

• Example: http://localhost:8081/customer-sapi/customers

• Example: http://mule-dev-customer-sapi.cloudhub.io/customer-sapi/customers

• Example: https://mule-dev-customer-sapi.cloudhub.io/customer-sapi/customers

• HTTP Method : GET, POST, PUT, DELETE etc.

• Example: GET https://mule-dev-customer-sapi.cloudhub.io/customer-sapi/customers

• Example: POST https://mule-dev-customer-sapi.cloudhub.io/customer-sapi/customers

• Example: PUT https://mule-dev-customer-sapi.cloudhub.io/customer-sapi/customers

• Example: DELETE https://mule-dev-customer-sapi.cloudhub.io/customer-sapi/customers

How request & response data passed over REST request
request headers
• Headers
• URI params
• Query params
• Etc.

request body
• JSON payload
• XML payload

Example: 200, OK. 400, Bad Request. 500 Server Error. etc.

response headers
Process request
• http response status code, status message
and sends back
response body response

• JSON payload
• XML payload
Use case development of session : hello-mule-api

Rest configuration Example

HTTP method GET
Protocol HTTP
Host localhost
Port 8081
Base path hello-mule-api
Sub path hello-mule
URL http://localhost:8081/hello-mule-api/hello-mule
Mule events
request headers
• Headers
• URI params
• Query params
• Etc.

request body
• JSON payload
• XML payload
Mule event message

Mule event source Mule event processors

Mule event
Mule message structure

request headers
• Headers
• URI params
• Query params
• Etc.

request body
attributes.headers.’Content-Type’
• JSON payload
• XML payload
attributes.uriParams.fieldName

attributes.queryParams.fieldName

payload.fieldName

vars.variablename
create-employee rest service
⬥ URL: http://localhost:8091/emp-sapi/create-employee (POST)

HTTP request body:

{
"employeeID": 100,
"employeeName": "Chinna",
"employeeStatus": "A"
}

HTTP response header: 200, success

HTTP response body:

{
"status": 200,
"message": “Success”
}
update-employee rest service
⬥ URL: http://localhost:8091/emp-sapi/update-employee (PUT)

HTTP request body:

<?xml version="1.0" encoding="UTF-8"?>

<employee>
<employeeID>333</employeeID>
<employeeStatus>A</employeeStatus>
</employee>

HTTP response body: HTTP response header: 200, OK

<?xml version="1.0" encoding="UTF-8"?>

<response>
<status>200</status>
<message>success</message>
</response>
get-employee rest service
⬥ URL: http://localhost:8091/emp-sapi/get-employee?employeeID=100 (GET)

HTTP response header: 200, OK

HTTP response body:

{
“employeeID”: 100,
“employeeName”: “Chinna”,
“employeeStatus”: “A”
}
get-employees rest service
⬥ URL: http://localhost:8091/emp-sapi/get-employees (GET)

HTTP response header: 200, OK

HTTP response body:
[
{
“employeeID”: 100,
“employeeName”: “Chinna”,
“employeeStatus”: “A”
},
{
“employeeID”: 101,
“employeeName”: “John”,
“employeeStatus”: “A”
}
]
delete-employee rest service
⬥ URL: http://localhost:8091/emp-sapi/delete-employee/101/John (DELETE)

HTTP response header: 200, OK

HTTP response body:
{
“status”: 200,
“message”: “Success”
}
Types of mule flows

Mule flows

Main flow Sub flow Private flow

Event source

Error handling
Error handling

• Error handling: The process of handling errors in flow and responding back user friendly messages instead of
system error messages is known as error handling.

response headers
500, Server error
response body
Could not obtain connection from data source

response headers
503, Service unavailable
response body
{
"code":503,
"message":"Service unavailable",
"description":"The service is temporarily not available",
"dateTime":"2024-05-31T06:18:02Z",
"transactionId":"48n32920-69ne-47b4-907d-
fa15869f3c4d"
}
Error handling

NAMESPACE:IDENTIFIER
On error propagate vs on error continue
Error handling b/w parent flow & sub flow

1. No error handling sub flow

2 1

3 3
Error handling b/w parent flow & sub flow

2. Error handling in sub flow with on-error-propagate

3 1

4
2
Error handling b/w parent flow & sub flow

2. Error handling in sub flow with on-error-propagate

3 1

4
2
Error handling b/w parent flow & sub flow

3. Error handling in sub flow with on-error-continue

3 4 1

2
Mule API life cycle

DESIGN

DEVELOPMENT

MANUAL UNIT TESTING

MUNIT TESTING

MANUAL DEPLOYMENT

CICD DEPLOYMENT

API MANAGEMENT
Designing API’s
Designing API’s
Rest API

Base URI Resource

• REST API URL : http://localhost:8081/covid/v1/cases

• HTTP Method : GET, POST, PUT, DELETE etc.

• Input: headers, body

• Content type: application/json, application/xml etc.

• Response headers: 200, OK. 400, Bad Request. 500 Server Error. Etc

• Response body: application/json, application/xml etc.

 1
2
3
4
5

9 8
10

11 12
Fragments in RAML

Fragments : API fragments are reusable component of RAML to make the design and build
of a reusable API even quicker and easier.

API FRAGMENTS

LOCAL GLOBAL

uhub-sapi
uhub-sapi aws-sapi
who-sapi
Mule project naming standards and structure

Project name: kebab case (ex: uhub-sapi)

Flow and subflow names: kebab case (ex: register-covid-case)

Property file names: kebab case (ex: uhub-sapi-dev.yaml)

JSON/XML fields: Any on of below

• capital camel case: StreetAdress
• kebab case: street-address
• snake case: sreet_address
• camel case: streetAddress

Variable names: camel case (ex: covidCasePayload)

Connector names: Firstletter capital word with space b/w words (ex:
Transform Message)
Mule error types

ERRORS

ANY CRITICAL

TRANSFORMATION ROUTING CONNECTIVITY EXPRESSION SECURITY UNKNOWN FATAL OVERLOAD

RETRY_EXAUSTED CLIENT_SECURITY SEVERE_SECURITY

Mule properties management

Properties management : Externalizing properties from mule configuration help us in better code
management and need not touch applications on configurations property changes.

Mule properties management

properties file yaml file

1. Create property file or yaml file in src/main/resources.

2. Create “configuration properties” global element.

3. Use ${key} expression extract the property from property file or yaml file.

4. Use Mule::p(‘key’) dataweave script to extract in dataweave.

Mule properties – Secure configuration properties

Properties management : Externalizing properties from mule configuration help us in better code
management and need not touch applications on configurations property changes.

1. Create property file or yaml file in src/main/resources.

2. Encrypt password property values:

• Choose 16 digits encryption key : abcdef0123456789

• Use algorithm and mode to encrypt password using above key.

3. Create secure configuration property global element.

1. Use ${secure::key} expression extract the property from property file or yaml file.

2. Use Mule::p(‘secure::key’) dataweave script to extract in dataweave.

Mule API life cycle

DESIGN

DEVELOPMENT

MANUAL UNIT TESTING

MUNIT TESTING

MANUAL DEPLOYMENT

CICD DEPLOYMENT

API MANAGEMENT
Mule API management

API management : API Management is the process of designing, publishing, documenting,

analyzing, versioning, securing and managing API users, traffic, SLAs.

Mule API management

Mule Gateway API Management Universal API Management

Mule API management

uho-dev-uhub-sapi
Auto discovery

API Instance ID
uhub-sapi 18387974
18387974

uho-dev-uhub-sapi
API Instance ID
uhub-sapi 18387975
18387975
uho-dev-aws-sapi

1. Create auto discovery global element using API instance id.

2. Provide below runtime properties:

• Organization business group client_id

• Organization business group client_secret
Client id enforcement policy

The Client ID Enforcement policy restricts access to a protected resource by allowing requests only from registered client
applications. The policy ensures that the client credentials sent on each request have been approved to consume the API.

1. Register client app on API in exchange.

2. Specifies from where in the request to extract the values:

• HTTP Basic Authentication Header: Requires credentials as part of the authorization header. The application
consuming the API must use the basic authentication scheme to send the credentials in the requests.

• Custom Expression: Accepts an expression each for client_id and client_secret in. the headers, indicating where to
extract the credentials from the request.
Rate limiting policy

The Rate Limiting policy enables you to limit the number of requests that an API can accept within a time window. The API
rejects any request that exceeds this limit. You can configure multiple limits with window sizes ranging from milliseconds to
years.

1. Apply configuration to all API method & resources

2. Apply configuration to specific API method & resources

Rate limiting – SLA based policy

The Rate Limiting policy is combination of rate limiting and client id enforcement that enables you to limit the number of
requests specified by the level of access granted to the requesting application. The API rejects any request that exceeds this
limit. You can configure multiple limits with window sizes ranging from milliseconds to years.

1. Apply configuration to all API method & resources

2. Apply configuration to specific API method & resources

3 requests per minute

Hospital A

uho-dev-uhub-sapi
2 requests per minute

Diagnostic A
THANK YOU

HAPPY
LEARNING J