Mule ESB also known as mule, is a lightweight Java-based enterprise service bus

(ESB) and integration platform that allows developers to connect applications

together quickly and easily, enabling them to exchange data. Mule ESB enables easy
integration of existing systems, regardless of the different technologies that the
applications use, including JMS, Web Services, JDBC, HTTP, and more.

Mule is the runtime engine of Anypoint Platform.

-----------------------------------------------------------------------------------
--------------------
Why Mule is preferred than other ESB implementations?
Mule is lightweight but highly scalable, allowing you to start small and connect
more applications over time. The ESB manages all the interactions between
applications and components transparently, regardless of whether they exist in the
same virtual machine or over the Internet, and regardless of the underlying
transport protocol used.

Several commercial ESB implementation provide limited functionality or built on top

of an existing application server or messaging server, locking you into that
specific vendor. Mule is vendor-neutral, so different vendor implementations can
plug in to it. You are never locked in to a specific vendor when you use Mule.
-----------------------------------------------------------------------------------
-----------------------
MULE FLOW:Flows are initiated by a Message Source
Flows contain message processors
Message processors are responsible for processing the received message.
Components: perform business logic & are typically application specific
• Transformers: transform the message
• Filters: accept/reject messages
• Routers: control the message flow
• Endpoints: send/receive messages over a transport
Subflow – A subflow is always synchronous. It is similar to a synchronous flow,
subflow executes in the same thread of the calling process. Calling process
triggers the sub-flow and waits for it to complete and resumes once the sub-flow
has completed.
Synchronous Flow– Same as sub-flow, the only difference is that in synchronous
flows you need to separately define an exception strategy to it, it does not
inherit the exception strategy of its calling flow.
Asynchronous Flow – As in sub-flow and synchronous flow, calling process triggers
the sub-flow and waits for it to complete; for asynchronous flow the flow, calling
process triggers an asynchronous flow and moves ahead to its next activity. An
asynchronous flow executes in parallel to its calling/parent flow in a different
thread. An asynchronous flow does not return its output it its parent/calling flow.
Private Flow – flow that does not have an inbound connector in the source. Means a
private flow cannot start of its own on receiving the inbound message as it does
not have any inbound connector, A private flow can only be called using flow-ref
same as sub-flow.

-----------------------------------------------------------------------------------
----------------------------
MULE Message: data moves the Application through flows
Header:contains metdata about message
Inbound properties:
- Read-only Access
- Set from the Message Source
- Persists throughout the flow
Outbound Properties:
Read/Write Access
- Added by Property MP
- Ability to:
∙ Write
∙ Delete
∙ Copy
Payload:Business Specific data.
Contains primary information to be processed by Mule
Contains a Java Object
Attachment:
Variable: Name Value pair that represent data about message
Exception Paylaod:

-----------------------------------------------------------------------------------
----------------------------
Mule Exception:
System Exception Strategy
• System Exception Strategy is invoked when an exception is thrown at the
system- level (i.e., when no message is involved).
• When a system exception occurs, Mule sends an exception notification to
registered listeners, logs the exception. It executes a reconnection strategy
if the the exception was caused by a connection failure
• System Exception Strategies are not configurable in Mule. Reconnection
strategy can be configured.
Messaging Exception Strategy:
• Messaging Exception occurs when an exception is thrown within a flow whenever
a message is involved.
• When a message being processed through a Mule flow throws an exception,
normal flow of execution stops. Mule transfers the message to the message
processor sequence within the exception strategy.
• Default Exception Strategy
– Applied by default for all Messaging Exceptions if no other exception
strategy matches for that exception
– Causes rollback of any transaction if it exists and then logs the exception
• Catch Exception Strategy
– Invokes a customized flow to handle the exception
– Consumes the inbound message and commits the transaction
• Rollback Exception Strategy
– Inbound message is not consumed
– Causes rollback of the message. In some cases, where the message supports it,
causes redelivery of the message.
– If the message exceeds the redelivery attempts (defined by
maxRedeliveryAttempts attribute), the flow defined by <on-redelivery-attempts-
exceeded> section is invoked, failed transaction is committed and the
message is consumed.
• Reference Exception Strategy
– Does not itself consume the message or cause rollback or commit
– References a global exception handler defined with a global catch, rollback
or choice exception strategy.
• Choice Exception Strategy
– Does not itself consume the message or cause rollback or commit
– Routes to an exception strategy from a set of strategies based on an
expression defined with the when attribute for each exception strategy.
– If a suitable exception strategy is not found then the default exception
strategy is invoked.

-----------------------------------------------------------------------------------
-------------------------------------
VM:
• Allows sending messages inside the JVM in which Mule is running.
• Messages sent to VM endpoints can be made transactional and persisted to the
disk.
• Can be used to implement reliability and decouple flows without the need for
an external messaging broker

-----------------------------------------------------------------------------------
------------------------------------
Object Store:Object stores are used to store an object. Mule uses object stores
whenever it needs data persistent for later retrieval. Mule uses object stores
internally for various filters, routers, and other processors that need to store
state between messages
The object store connector can perform various operations like Contains, Dual
store, Remove, Retrieve, Retrieve all keys, Retrieve and Store and Store.
Contains-used to verify if given key is present in the object store.
Dual store - stores a value using a key and also stores a key using a value.
Remove - to remove the respective key from the object store.
Retrieve - used to retrieve an object from the object store and make it available
in the specified property scope of a Mule Message.
Retrieve all keys - will return a list of all keys present in the object store.
Retrieve and Store - used to retrieve and store an object in the same operation.
Store - used to store the object in an object store.
Mule provided two types of object store as follows
In-memory store: This allows you to store objects in memory at runtime. Generally,
objects are lost when runtime is shutdown.
Persistent store: Mule persists data when an object store is explicitly configured
to be persistent. Mule creates a default persistent store in the file system.

-----------------------------------------------------------------------------------
--------------------------------------

Munit:MUnit is a Mule application testing framework that allows you to easily build
automated tests for your integrations and APIs. It provides a full suite of
integration and unit test capabilities, and is fully integrated with Maven and
Surefire for integration with your continuous deployment environment.
Various features available with Mule MUnit:
.Create and build Mule tests by writing Mule code.
.Create and build Mule tests by writing Java code.
.Verify Message Processor calls.
.Mock Message Processor.
.Mock outbound endpoints.
.Disable outbound endpoints.
.Disable flow inbound connectors.
.Disable inbound endpoints.
.Debug the tests.
.View coverage reports.
.Various asserts available like Assert Equals, Assert Not Equals, Assert Payload,
Assert False, Assert True, Assert Null Payload, Assert Not Null Payload.
.Spy Message Processor.

-----------------------------------------------------------------------------------
---------------------------------------
REST:REST stands for Representaional State Transfer or RESTful web service. REST is
a client-server architecture which means each unique URL is representation of some
object or resource. Any REST API developed uses HTTP methods explicitly and in a
way that’s consistent with the protocol definition. This basic REST design
principle establishes a one-to-one mapping between create, read, update, and delete
(CRUD) operations and HTTP methods. According to this mapping:
To create a resource on the server, use POST.
To retrieve a resource, use GET.
To change the state of a resource or to update it, use PUT.
To remove or delete a resource, use DELETE.
JSON and XML are the two markup language that can be used in restful web api

-----------------------------------------------------------------------------------
-------------------------------------------
Mule Credentials Vault:
Mule Credentials Vault can be used to encrypt customer data in a .properties file.
The .properties file is used by developers to set up the properties for different
environments (dev, stage, lt, prod) as a one-time activity. Mule applications use
the data from the properties file during runtime, e.g. credentials for a secured
database, credit card information for a customer, social security numbers, etc.
Anypoint Enterprise Security is a collection of security features that enforce
secure access to information in Mule applications. This helps in applying security
to Mule Service-Oriented Architecture (SOA) implementations and Web services.
Anypoint Enterprise Security suite helps application developers to develop security
solutions as per security requirements, prevent security breaches and facilitate
authorized access to data.

-----------------------------------------------------------------------------------
--------------------------------------------
RAML:(RESTful API Modeling Language)
RAML is similar to WSDL, it contains endpoint URL, request/response schema, HTTP
methods and query and URI parameter.
RAML helps client (a consumer of the service) know, what the service is and
what/how all operations can be invoked.
RAML helps the developer in creating the initial structure of this API. RAML can
also be used for documentation purpose.
ResourceTypes:
ResourceTypes is like resource in that it can specify the descriptions, methods,
and its parameters. Resource that uses resourceTypes can inherit its nodes.
ResourceTypes can use and inherit from other resourceTypes.
ResourceType is basically a template that is used to define the descriptions,
methods, and parameters that can be used by multiple resources without writing the
duplicate code or repeating code.
Traits:
Traits is like function and is used to define common attributes for HTTP method
(GET, PUT, POST, PATCH, DELETE, etc) such as whether or not they are filterable,
searchable, or pageable.
Traits can be declared in the same RAML file or you can create different files for
creating the traits.
Traits can be called by resources using the "is" keyword.
Traits can be called from ResourceTypes using the "is" keyword only.
in RAML URI paramter is defined by /{employeeID}:
In RAML 0.8, the default value for a required attribute is false
In RAML 1.0, the default value for a required attribute is true
RAML 0.8 repeat on named parameters,removed in 1.0 version.
Also
Data types: a unified, streamlined, and powerful way to model data wherever it
appears in an API.
Uniformly covers bodies, URI parameters, headers, and query parameters and
eliminates the need for a separate formParameters construct
Supports wrapping XML Schema and JSON Schema and even referring to sub-schemas, but
in many cases just obviates the schemas
Simplifies coding, compared to the JSON Schema or XML Schema, by virtue of being
YAML-based
Examples: multiple examples, expressible in YAML, and annotatable, so semantics can
be injected
Annotations: a tried-and-tested, strongly-typed mechanism for extensibility
Libraries: improved modularity for broad reuse of API artifacts
Overlays and Extensions: increased extensibility through separated files
Improved Security Schemes:
Wider OAuth support
Support for pass-through (key-based) security schemes
Several smaller changes for consistency and expressivity

In RAML 1.0, the date type has been replaced by a set of more specialised types
such as date-only (yyyy-mm-dd), time-only (hh:mm:ss[.ff...]), datetime-only (yyyy-
mm-ddThh:mm:ss[.ff...]), and datetime

In RAML 0.8 it was valid to define baseUriParameters also on non root-level nodes
such as resources. RAML 1.0 removes that ability and supports the declaration of
any base URI parameters only at the root-level of your API definition.

-----------------------------------------------------------------------------------
-------------------------------------------------
Scatter- Gather Routers:
Scatter-Gather is a routing message processor in Mule ESB runtime that sends a
request message to multiple targets concurrently. It then collects the responses
from all routes and aggregates them back into a single response
Once a message is received by Scatter-Gather, it sends a message for concurrent
processing to all configured routes. The main thread executing the flow that owns
the router waits until all routes complete or time out.
If there are no failures, Mule aggregates the results from each of the routes into
a message collection (MessageCollection class). Failure in one route does not stop
Scatter-Gather from sending messages to its other configured routes, so it is
possible that many or all routes may fail concurrently.
Ever wondered how to get hold of an individual activity exception inside a set of
activities inside Scatter-Gather scope, as #[exception] would always return:
"org.mule.routing.CompositeRoutingException."

-----------------------------------------------------------------------------------
-------------------------------------------------
Batch-Proceesing:
Mule has the capability to process messages in batches.
It splits the large messages into individual records that are processed
asynchronously within batch jobs.

Input Phase: This is an optional part of the batch job that can be used to retrieve
the source data using any inbound connector. It also allows chaining of multiple
message processors to transform the source data before it is ready for processing.
Load and Dispatch: This is an implicit phase and Mule runtime takes care of it. In
this phase, the payload generated in the Input phase or provided to the batch from
the caller flow is turned into a collection of records. It also creates a job
instance for processing records. The collection is then sent through the
collection-splitter to queue individual records for processing.
Process: This is the required phase where the actual processing of every record
occurs asynchronously.
Each record from the input queue is processed through the first step and sent back
to the queue after processing of the first step completes.
At the step level, you can also specify what type of records each step should
accept. This can be configured using accept-expression in the step definition.
Records satisfying the accept-expression condition of a step will be processed by
that step, or otherwise moved to the next eligible step. You can also define
accept-policy to filter out messages based on their processing status.
Processing of records through the next step DOES NOT wait for the previous step to
finish processing all records. Mule manages the state of each record while it moves
back and forth between the queue and steps.
Complete:This is an optional phase. It provides a summary report of records
processed and helps you get insight into which records fail so that you can
properly address the issue. Payload is a BatchJobResult. It has properties for
processing the following statistics:
loadedRecords, processedRecords, successfulRecords, failedRecords, totalRecords.
Batch Commit:A scope that accumulates records into chunks to prepare bulk upserts
to the external source or service is called a batch commit. You can add batch
commits at the process record stage and wrap up the Salesforce connector with batch
commit and set the commit size depending on your requirement.
Batch Execute:Batch execute can be used to trigger the batch job. If you are not
using poll scope or any message source in your batch job, then you can use batch
execute to trigger a batch job.

-----------------------------------------------------------------------------------
---------------------------------------------------
Until Successful:
The until successful scope is one of the scopes available in Mule which processes
messages through its processors until the process succeeds.
By default, until successful’s processing occurs asynchronously from the main flow.
IMP Attributes of Until Successful Scope
objectStore-ref: Reference to the org.mule.api.store.ListableObjectStore that is
used to store events pending to process or reprocess.
maxRetries: Specifies the maximum number of retries that are attempted.
millisBetweenRetries: Specifies the minimum interval between two attempts to
process, in milliseconds. The actual interval depends on the previous execution,
but should not exceed twice this number. The default value is 60000 milliseconds
(one minute).
deadLetterQueue-ref: The endpoint or message processor to which undeliverables
messages are sent after all retries have been executed unsuccessfully.

-----------------------------------------------------------------------------------
-----------------------------------------------------
Keystore — In short, Keystore is a server-side asset that stores the private keys
and the certificates with their public and private keys.
Truststore — Truststore is a client-side asset that serves as a repository of
certificates (CA or simple) that the client should trust.

During the SSL handshake,

A client tries to access https://

And thus, Server responds by providing a SSL certificate (which is stored in its
keyStore)

Now, the client receives the SSL certificate and verifies it via trustStore (i.e
the client's trustStore already has pre-defined set of certificates which it
trusts.). Its like : Can I trust this server ? Is this the same server whom I am
trying to talk to ? No middle man attacks ?

Once, the client verifies that it is talking to server which it trusts, then SSL
communication can happen over a shared secret key.

Note : I am not talking here anything about client authentication on server side.
If a server wants to do a client authentication too, then the server also maintains
a trustStore to verify client.

keystore simply stores private keys, wheras truststore stores public keys. You will
want to generate a java certificate for SSL communication. You can use a keygen
command in windows, this will probably be the most easy solution
-----------------------------------------------------------------------------------
-------------------------------------------------------
Oauth2.0:
The OAuth 2.0 authorization framework enables a third-party application to obtain
limited access to an HTTP service, either on behalf of a resource owner by
orchestrating an approval interaction between the resource owner and the HTTP
service, or by allowing the third-party application to obtain access on its own
behalf
When a client accesses a protected resource, it needs to provide an access token to
the resource server.
The client obtains the access token from OAuth server using one of the four ways
(grant types, flows, dances, whatever you want to call it)
Once the client (application) gets the access token, the client will supply the
token to the resource server and gain access to the resources (Web services, web
pages API’s and what not).
All grant types can get the access token in a single step, except “Authorization
Code” which requires 3 steps and involves the interactive login from the resource
owner as well.
-----------------------------------------------------------------------------------
----------------------------------------------------------
CloudHub:CloudHub is an Integration Platform as a Service (iPaaS). It enables you
to deploy and run the application in the cloud via Runtime Manager. CloudHub is a
scalable, multi-tenant, elastic, secure, and highly available iPaas. CloudHub is
managed via the Runtime Manager console in the Anypoint platform
MuleSoft CloudHub Architecture
Runtime Management Console:The Runtime Management console is very well integrated
with Anypoint platform. You can use your Anypoint credentials to deploy, upload,or
manage your Mule applications. You can deploy and manage your Mule application
through this same console. This is also useful for monitoring the platform
services.
Platform Services:CloudHub shared the set of platform services and API includes
CloudHub Insights, Alerting, , logging, account management, virtual private
cloud/secure data gateway, load balancing, and others.
CloudHub Worker:Applications on CloudHub are run by one or more instances of Mule,
called workers. Below is a list of some characteristics.
Capacity: Each worker has a specific amount of capacity to process data. You can
select the size of your workers when configuring an application.
Isolation: Each worker runs in a separate container from every other application.
Manageability: Each worker is deployed and monitored independently.
Locality: Each worker runs in a specific worker cloud, the US, EU, Asia-Pacific,
etc

CloudHub is designed in such way that it can provide various features like high
availability, scalability, intelligent healing, and zero downtime. Mule
applications deployed in CloudHub can be easily scalable without any downtime

-----------------------------------------------------------------------------------
---------------------------------------------------------
Custom API Policy:
MuleSoft provides certain built-in policies which can be referred to address
general situations to filter unwanted traffic coming to your API. However, MuleSoft
provides the capability to create custom policies, which are designed primarily to
address complex scenarios like SQL injection. Custom policies are configuration
files that define the behavior of your API for each incoming request.
To create custom policies, mainly two configuration files are required

Mulesoft Definition file (YAML) - File in which you define characteristics of the
custom policy. Characteristics are defined using:
:name - used to describe policy in API platform
:description - detailed description of policy
:category - text used in API platform to list policies
:standalone - true if policy can work independently, false if it can only be
applied as a sub-part of another.
:configuration - defines custom configuration parameters for your policy.

MuleSoft Configuration file(XML) - File in which you define the actual

logic/implementation of your defined custom policy. There are two main tags:
<before> - Code written within the <before> tag executes on every incoming request
BEFORE sending it to main API services.
<after> - The after tag gets executed after completion of main API services, i.e
after completion of the request.
Generally, it happens that we don't have anything to do once the API request is
completed. The <after> tag will not contain anything, but we can't have <before>
and <after> tags left empty. In such scenarios, simply remove the declaration of
the tag to avoid errors.

Similarly, for MuleSoft 3.8+, you can create an API custom policy project in
Anypoint Studio. It will automatically have two files with extensions .xml and
.yaml.
-----------------------------------------------------------------------------------
--------------------------------------------------------------
SOAP -> REST
1. SOAP is a protocol. -> REST is an architectural style.
2. SOAP stands for Simple Object Access Protocol. -> REST stands for
REpresentational State Transfer.
3. SOAP can’t use REST because it is a protocol. -> REST can use SOAP web services
because it is a concept and can use any protocol like HTTP, SOAP.
4. SOAP uses services interfaces to expose the business logic. -> REST uses URI to
expose business logic.
5. SOAP defines standards to be strictly followed. -> REST does not define too much
standards like SOAP.
6. SOAP defines standards to be strictly followed. -> REST does not define too much
standards like SOAP.
7. SOAP requires more bandwidth and resource than REST. -> REST requires less
bandwidth and resource than SOAP.
8. SOAP defines its own security. -> RESTful web services inherit security measures
from the underlying transport.
9. SOAP permits XML data format only. -> REST permits different data format such as
Plain text, HTML, XML, JSON etc.
10. SOAP is less preferred than REST. -> REST more preferred than SOAP
-----------------------------------------------------------------------------------
-----------------------------------------------------------------
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
accessed from original source location every time.
Caching in Mule ESB can be done by Mule Cache Scope. Mule Cache Scope has 3 storage
types –
In-memory: This store the data inside system memory. The data stored with In-memory
is non-persistent which means in case of API restart or crash, the data been cached
will be lost.
Configuration Properties:
Store Name
Maximum number of entries
TTL (Time to live)
Expiration Interval

Managed-store: This stores the data in a place defined by ListableObjectStore. The

data stored with Managed-store is persistent which means in case of API restart or
crash, the data been cached will no be lost.
Configuration Properties:
Store Name
Maximum number of entries
TTL (Time to live)
Expiration Interval
Persistence (true/false)

Simple-test-file-store: This stores the data in a file. The data stored with
Simple-test-file-store configuration is persistent which means in case of API
restart or crash, the data been cached will no be lost.
Configuration Properties:
Store Name
Maximum number of entries
TTL (Time to live)
Expiration Interval
Persistence (true/false)
Name and location of the file
-----------------------------------------------------------------------------------
------------------------------------------------------------
Domain Project:
A Mule Domain Project is implemented to configure the resources that are shared
among different projects. These resources can be used by all the projects
associated with this domain. Mule applications can be associated with only one
domain, but a domain can be associated with multiple projects. Note: Mule Domain
Project and the associated Mule applications must be in the same workspace.
to access Domain project in Mule Project we need to add the the domain project name
in the mule-deploy.properties