Mule Notes
Mule Notes
5.Components worked on
11.RAMW Structure
12.Naming conventon
Answer - htps://doone.com/artcles/error-handling-in-mule-4
14.Types of variables
Record Variable.
Flow Variable.
Session Variable.
19.Wogging, Splunk
24.What is the MuleSoft Anypoint platorm and How did you use it?
-Try to avoid session variables usage in applicatons. Session variables are serialioed and
deserialioed, which negatvely impacts performance.
a. Add/Remove Headers
b. Client ID Enforcement
Enforces the requirement for calls to the API must include a valid client ID and client secret. See
footnote.
c.Cross-Origin Resource Sharing
Allows JavaScript XMLHtpRequest (XHR) calls executed in a web page to interact with resources
from non-origin domains. CORS is a commonly implemented soluton to the "same-origin policy"
that is enforced by all browsers. This policy enables all origins, and makes all resources of an API
public.
e.IP Blacklist
f.IP Whitelist
Protects the target API against malicious JSON that could cause problems.
Confgures the API so that its endpoints require a mandatory and valid OAuth 2.0 token. You
must reference an external Mule applicaton that serves as the OAuth provider. Update the
RAML of your API using the provided snippet before using this policy.
Confgures the API so that its endpoints require a mandatory and valid OpenAM token. This
policy is only available to organioatons using an OpenAM Federated Identty Management
system.
Confgures the API so that its endpoints require a mandatory and valid token. This policy is only
available to organioatons using an OpenID Connect Management system.
Limits the number of messages per tme period processed by an API at a maximum value
specifed in the SLA ter. Any messages beyond the maximum are rejected. Enforcement is based
on the client ID passed in the request. See footnote.
m.Rate Limitng
Limits the number of messages processed by an API per tme period at a maximum value
specifed in the policy. The rate limitng is applied to all API calls, regardless of the source. Any
messages beyond the maximum are rejected.
Supports a placeholder security manager that can be confgured with a hard-coded username
and password for demonstraton purposes.
o.Throtling - SLA-Based
Throtles he number of messages per tme period processed by an API at a maximum value
specifed in the SLA ter. Any messages beyond the maximum are queued for later processing.
Enforcement is based on the client ID passed in the request. See footnote.
p.Throtling
Throtles the number of messages processed by an API per tme period at a maximum value
specifed in the policy. The throtling is applied to all API calls, regardless of the source. Any
messages beyond the maximum are queued for later processing.
Protects the target API against malicious XML that could cause problems.
Note: Update the RAML of your API using the provided snippet before using this policy.
A policy extends the functonality of an API and enforces certain capabilites such as security. A
policy can control access and trafc. For example, a policy can generally control authentcaton,
access, alloted consumpton, and service level access (SLA). You can apply policies to these
types of APIs:
An APIkit project
For example, deploy the APIkit project to Anypoint Platorm using API Autodiscovery and apply a
policy.
Design an API on Anypoint Platorm, confgure a proxy for Cloudhub, and apply a policy.
API Manager provides a number of policies. You can also build custom policies. You deploy a
proxy API applicaton and apply one or more policies to control how and when a received
request is forwarded to its implementaton endpoint. You can set an API alert to notfy you when
an API request violates a policy for SLA.
By default, a policy applies to the entre API, fltering trafc requests to every resource and
method.
can use the HTTP Request connector to consume RESTful web services. You need to specify host,
port, and optonally a host path for connector confguraton. For Endpoint, you need to specify
path and method.
- htps://doone.com/artcles/circuit-breaker-module
36./isadvantages of APIs
htp://workshop.tools.mulesof.com/modules/modulee
CloudHub provides a default shared load balancer that is available in all environments. The
shared load balancer provides basic functonality, such as TCP load balancing. Shared load
balancers don’t allow you to confgure custom SSL certfcates or proxy rules.
Additonally, shared load balancers have lower rate limits that help ensure platorm stability.
MuleSof regularly monitors and scales these limits as necessary. Rate limits on shared load
balancers are applied according to region. If you are deploying an applicaton to workers in
multple regions, the rate limit for each region might be diferent.
If an applicaton exceeds the rate limit for a shared load balancer, the load balancer returns a
503 Service Unavailable response.
To perform custom load balancer confguraton or have higher rate limit thresholds, you must
use a dedicated load balancer.
The shared load balancer supports TLS versions 1.1 and TLS 1.2.
Enables you to deploy and confgure one or more custom load balancers within an Anypoint
Virtual Private Cloud (Anypoint VPC).
Handle load balancing among the diferent CloudHub workers that run your applicaton.
Defne SSL confguratons to provide custom certfcates and optonally enforce two-way SSL
client authentcaton.
40.What is CloudHUB
CloudHub is an Integraton Platorm as a Service (iPaaS). It enables you to deploy and run the
applicaton in the cloud via Runtme Manager. CloudHub is a scalable, mult-tenant, elastc,
secure, and highly available iPaas. CloudHub is managed via the Runtme Manager console in the
Anypoint platorm
Runtme Management Console:The Runtme Management console is very well integrated with
Anypoint platorm. You can use your Anypoint credentals to deploy, upload,or manage your
Mule applicatons. You can deploy and manage your Mule applicaton through this same console.
This is also useful for monitoring the platorm services.
Platorm Services:CloudHub shared the set of platorm services and API includes CloudHub
Insights, Alertng, , logging, account management, virtual private cloud/secure data gateway,
load balancing, and others.
CloudHub Worker:Applicatons on CloudHub are run by one or more instances of Mule, called
workers. Below is a list of some characteristcs.
Capacity: Each worker has a specifc amount of capacity to process data. You can select the sioe
of your workers when confguring an applicaton.
Isolaton: Each worker runs in a separate container from every other applicaton.
Locality: Each worker runs in a specifc worker cloud, the US, EU, Asia-Pacifc, etc
CloudHub is designed in such way that it can provide various features like high availability,
scalability, intelligent healing, and oero downtme. Mule applicatons deployed in CloudHub can
be easily scalable without any downtme
htps://stackoverfow.com/questons/2947008701/mule-set-htp-header-values-from-postman-
rest-clienterq=1
Mule Credentals Vault can be used to encrypt customer data in a .propertes fle. The .propertes
fle is used by developers to set up the propertes for diferent environments (dev, stage, lt, prod)
as a one-tme actvity. Mule applicatons use the data from the propertes fle during runtme,
e.g. credentals for a secured database, credit card informaton for a customer, social security
numbers, etc.
Anypoint Enterprise Security is a collecton of security features that enforce secure access to
informaton in Mule applicatons. This helps in applying security to Mule Service-Oriented
Architecture (SOA) implementatons and Web services.
Anypoint Enterprise Security suite helps applicaton developers to develop security solutons as
per security requirements, prevent security breaches and facilitate authorioed access to data.
43.What is VM
Messages sent to VM endpoints can be made transactonal and persisted to the disk.
Can be used to implement reliability and decouple fows without the need for an external
messaging broker
We can make connectors as an reusable component by defning them as common resources and
expose them to all applicatons deployed under a same domain, these resources are known as
shared resources. These shared resource needs to be defned inside Mule Domain Project and
then referred to each of the projects that are meant to use the elements in it.
htps://mulesoftrainings.wordpress.com/201e/05/2e/42/
htps://github.com/raml-org/raml-spec/wiki/Breaking-Changes
- name
-Queue path
- Connector Confguraton
Sync Vs async
Async - How fow will work
Batch Jobs -
Excepton Strategies
-------------------------------------------------------------------------------------------------------
- This approach is based on Pace layers. The main purpose of API-led connectvity is to enable
the integraton fows to be reused by many partes and to be reused inside the integraton
platorm. With the reusability of the already available logic (implemented in fows), the
developers can evolve their logic in faster and safer ways, leading to a short tme to market. APIs
are created in layers and the best plus point as compared to E2E approach is that more
components (fows) can be reused which makes easier to implement new systems and services.
In this approach, the APIs are based on three distnct layers: System, Process, and Experience.
System Layer - This is the foundatonal layer of the three-layer architecture. These APIs can be
defned for various domains of an organioaton, for example, ERP, key customer and billing
systems, proprietary databases, etc. System APIs provide a means of accessing these underlying
systems of records and exposing the data in canonical formats. A System API defnes the contract
RAML/WSDL to describe how to interact with the domain. For example, a System API for a
customer domain can contain resources with methods like GET, POST, PUT, and DELETE, and the
related schemas (XSD, JSON) and responses (200, 400, 500, etc).
One can modify the System API logic without afectng the other APIs (Process and Experience).
For example, if a System API is using SAP and, in the future, SAP needs to be replaced with
Salesforce, this replacement can be done easily modifying only the System API without touching
anything in Process and Experience layers.
Process Layer-Process layer APIs are responsible for shaping the data by orchestratng and
choreographing various data by calling multple System APIs. The orchestraton involves the
aggregatng, splitng, and routng of data. The main purpose of Process APIs is to strictly
encapsulate the business process independent of the source systems (System APIs) from which
the data originates.
For example, in a purchase order process, it needs to interact with various domains of the
organioaton. The Process API (purchase order/order fulfllment) interacts with the already
available System APIs to implement the logic.
The Process APIs should be held privately inside the organioaton as per recommendaton and
should not be exposed for public use.
Common business logic can be shared across the organioaton. For example, if an organioaton
already has the purchase order process API implemented, it can be reused whenever necessary.
Experience Layer-At this point, we have all the sensitve informaton of an organioaton exposed
privately by System APIs, and the Process APIs have already exposed the business process logic.
The business process data is consumed across a broad range of clients/channels with diferent
formats. For example, our Order Purchase API (Process Layer) has exposed data in the JSON
format, but we have a client applicaton that accepts only XML format, or vice versa. This simple
transformaton logic is implemented in the Experience Layer and the implementatons are
exposed as Experience APIs.
In other words, Experience APIs are the means by which data can be reconfgured easily to meet
the needs of multple audiences. Also, we can remove the unnecessary methods and expose
only the necessary methods in Experience APIs in a simple way.
The Experience APIs are the ones which should be exposed publicly for consumpton. In short,
they are the fnal products of an organioaton in the API-led connectvity approach. Various
policies can be applied to the APIs as well, as they can be monetoed to earn revenue for the
organioaton.
Experience APIs are simple. Basically, they involve only the transformaton of data. So, to meet a
wide range of clients that accept data in diverse formats, the Experience APIs do this rapidly,
decreasing the tme to market
b) Queued-Asynchronous Flow Processing Strategy : Mule uses a queue to decouple the receiver
thread from the rest of the fow.
The queued-asynchronous approach uses a queue to decouple the fow’s receiver from the rest
of the steps in the fow
This means that once the receiver places a message into a queue, it can immediately return and
accept a new incoming message. Furthermore, each message waitng in the queue can be
assigned a diferent thread from a pool of threads. A component called a Work Manager assigns
pending messages to available threads, so they can be processed in parallel. Such parallel
processing is ideal for situatons where the receiver can, at peak tmes, accept messages
signifcantly faster than the rest of the fow can process those messages.
However, the increased throughput facilitated by the asynchronous approach comes at the cost
of transactonal reliability.
This strategy is applied to Mule fows implicitly and it can handle all exceptons in your fows. It
can be overridden by adding a Catch, Choice, or Rollback excepton strategy to the fow. Mule
applies this strategy automatcally and rolls back any pending transactons and logs the
excepton. If there is no transacton, it will stll log the excepton.
The default excepton strategy can be used when you don’t want to take any specifc actons in
case of exceptons.
Mule’s default excepton strategy automatcally actvates when any error occurs in any of your
fows. It cannot be confgured in Anypoint.
When a message throws an excepton, the default excepton strategy rolls back the message and
logs the excepton.
This strategy should be used when it is not possible to correct the error that occurs in a fow. It
can be used in transactonal fows to handle errors. If an excepton is thrown while processing a
message, this strategy rolls back the transacton and Mule delivers the message to the inbound
connector of parent fow to reprocess the message.
In additon to managing transactonal errors, the rollback excepton strategy can be used to
Manage exceptons that applicatons cannot catch.
A rollback excepton strategy can introduce an infnite loop of actvity within a foww a message
throws an error, the rollback excepton strategy catches the excepton and redelivers the
message back for reprocessing. The message throws an error again, the rollback excepton
strategy catches the excepton again, again does the redelivery, and so on.
To avoid this infnite loop and responsibly manage unresolvable errors, you can apply two
limitatons to a rollback excepton strategy:
Defne another fow to handle messages that are failing afer the maximum number of redelivery
atempts.
The rollback excepton strategy provides multple atempts for a message to successfully move
through a fow before commitng a failed transacton and consuming the message.
This strategy catches all exceptons thrown within its parent fow and processes them, thereby
overriding Mule’s implicit default excepton strategy. Mule’s catch behavior is similar to a Java
catch block, except that you cannot throw a new excepton or catch another excepton within a
catch excepton strategy.
Ensure that a transacton processed by the fow is not rolled back when an error occurs.
When a message throws an excepton, the catch excepton strategy always commits the
transacton and consumes the message.
d) Choice Excepton Strategy
This excepton strategy is useful when you want to handle the excepton based on the message
content afer an excepton is thrown. It catches all exceptons thrown within its parent fow,
checks the message content and excepton type, and then routes the message to the
appropriate excepton strategy.
There is more than one excepton strategy which is defned within this strategy. Catch or
Rollback uses MEL to advise the Choice excepton strategy as to which message it accepts and
will be doing further processing. If none of the Choice excepton strategies are able to handle the
error, it routes the message to the default excepton strategy.
A Choice excepton strategy contains one or more catch or rollback excepton strategies.
A Choice excepton strategy cannot be nested within other choice excepton strategies.
Any Mule expression evaluator can be used as the expression atribute of an excepton strategy.
Remember that a choice excepton strategy checks the expression atribute of each of its
excepton strategies one by one, serially, to see which one should handle the errorw it then
routes the message to the frst excepton strategy that evaluates to true. Arrange your excepton
strategies as the top-most evaluates frst, then the one below it, and so on.
The choice excepton strategy never actually performs any rollback, commit, or consume
actvites.
This is to refer to a common excepton strategy which you can defne in a separate confguraton
fle. You can create one or more global excepton strategies to reuse in fows throughout your
entre Mule applicaton.
For this, add a Reference Excepton Strategy to a fow to refer the error handling the behavior of
a specifc global excepton strategy.
When a message throws an excepton, the reference excepton strategy refers to the error
handling parameters defned in a global catch, rollback, or choice excepton strategy.
The reference excepton strategy itself never actually performs any rollback, commit, or consume
actvites.
#[excepton.causedBy(org.mule.example.ExceptonType)]
#[excepton.causedExactlyBy(org.mule.example.ExceptonType)]
#[excepton.causeMatches('org.mule.example.*')]
#[excepton.causeMatches('*') &&
!excepton.causedBy(java.lang.ArithmetcExcepton) &&
!excepton.causedBy(org.mule.api.registry.ResolverExcepton)]
7.What is scatter-gatter?
- Scater-Gather is a routng message processor in Mule ESB runtme that sends a request
message to multple targets concurrently. It then collects the responses from all routes and
aggregates them back into a single response.
Once a message is received by Scater-Gather, it sends a message for concurrent processing to all
confgured routes. The main thread executng the fow that owns the router waits untl all routes
complete or tme out.
If there are no failures, Mule aggregates the results from each of the routes into a message
collecton (MessageCollecton class). Failure in one route does not stop Scater-Gather from
sending messages to its other confgured routes, so it is possible that many or all routes may fail
concurrently.
8.Scenario like if scater-geter send the request simultaneously to multple fows and one of the
fows throws the excepton then how can handle the exceptone
If and when some of the route fails,Scater-Gather performs the below operatons:
9.Message Enricher?
Mule Message Enricher is one of the scopes in Mule which allows the current message to be
augmented using data from a separate resource, which we call the Enrichment Resource. The
Mule implementaton of the Enrichment Resource (a source of data to augment the current
message) can be any message processor.
In simple language, we can say a message enricher enriches the current payload with some
additonal message or informaton and this is done without disturbing the current payload.
Enricher is used if the target system needs more informaton than the source system can
provide. It enriches the Mule message by calling an external system or doing some
transformaton to the existng payload and saving it into some scope of variable, like session,
outbound, or invocaton, and the transformaton happening in the enricher scope doesn't afect
the actual payload. Set-property: Save some informaton extracted from payload or original
payload to some invocaton or fow scope variable.
10.Cache scope?
The Cache Scope is a Mule feature for storing and reusing frequently called data. The Cache
Scope saves tme and processing load.
a)In-memory-store: data is stored in Local Mule Runtme Memory and it is non-persistent which
means data would be lost if an event of restart or shutdown the mule applicaton.
Confguraton required:
Store name
The “lifespan” of a cached response within the object store (i.e. tme to live)
Confguraton required:
Store name
The “lifespan” of a cached response within the object store (i.e. tme to live)
c)Simple-test-fle-store: As the name denotes, data in this approach is stored as a flew also a
persistent storing mechanism where in the event of any shutdown or restart of the Mule
applicaton, the data would stll be intact.
Confguraton required:
Store name
The “lifespan” of a cached response within the object store (i.e. tme to live)
The name and locaton of the fle in which the object store saves cached responses
The Transform Message component in Anypoint Studio gives you the tools to leverage the
DataWeave language, allowing you to map and connect to anything, regardless of data type or
structure.
This DataWeave Quickstart Guide introduces the key functonal features of the Transform
Message component and DataWeave:
Type Transformaton
htps://docs.mulesof.com/mule-runtme/3.9/dataweave-quickstart
%dw 1.0
%output applicaton/json
---
Output
{
"users": [
"JOHN",
"PETER",
"MATT"
- On-Premise/Cloud/Hybrid
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
operatons can be invoked.
RAML helps the developer in creatng the inital structure of this API. RAML can also be used for
documentaton purpose.
ResourceTypes:
ResourceTypes is like resource in that it can specify the descriptons, 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 defne the descriptons, methods, and
parameters that can be used by multple resources without writng the duplicate code or
repeatng code.
Traits:
Traits is like functon and is used to defne common atributes for HTTP method (GET, PUT, POST,
PATCH, DELETE, etc) such as whether or not they are flterable, searchable, or pageable.
Traits can be declared in the same RAML fle or you can create diferent fles for creatng the
traits.
Traits can be called from ResourceTypes using the "is" keyword only.
Also
Data types: a unifed, 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
Simplifes coding, compared to the JSON Schema or XML Schema, by virtue of being YAML-based
In RAML 1.0, the date type has been replaced by a set of more specialised types such as date-
only (yyyy-mm-dd), tme-only (hh:mm:ss[.f...]), datetme-only (yyyy-mm-ddThh:mm:ss[.f...]),
and datetme
In RAML 0.8 it was valid to defne baseUriParameters also on non root-level nodes such as
resources. RAML 1.0 removes that ability and supports the declaraton of any base URI
parameters only at the root-level of your API defniton
htps://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md/
- You can defne a rollback excepton strategy to ensure that a message that throws an excepton
in a fow is rolled back for reprocessing. Use a rollback excepton strategy when you cannot
correct an error that occurs in a fow. Usually, you use a rollback excepton strategy to handle
errors that occur in a fow that involve a transacton. If the transacton fails, that is, if a message
throws an excepton while being processed, then the rollback excepton strategy rolls back the
transacton in the fow. If the inbound connector is transactonal, Mule delivers the message to
the inbound connector of the parent fow again to reatempt processing (that is, message
redelivery).
19.is Catch excepton strategies will use message? and how it will use message?
21.Scenario like if the request contains Username then it is going to hit your fow suppose your
passed username is invalid and you have to catch that excepton and display like invalid
username How do you do it?
- Throw Excepton using Groovy and Catch using Catch Excepton Strategy
- HTTP/HTTPS
htps://docs.mulesof.com/mule-runtme/3.9/htp-listener-connector#htps-protocol-
confguraton
Flows contain message processors.Flows can send messages of to other fows and eventually
external resources
a)Subfow
Cannot have their own error handlingw errors caught in parent fow
b) Private Flow
27.Suppose if ArrayWist contains duplicate elements then how can you display only duplicate
elements?
28. Suppose I have employee table contains columns: empno ename age sal
---------------------------------------------------------------------------------------------------------------------
1. Explain the Mule message in the context of Mule Flow.What Are /ifferent Type Of Messages
In Mule ?
- Read-only Access
Outbound Propertes:
Read/Write Access
- Added by Property MP
- Ability to:
∙ Write
∙ Delete
∙ Copy
Atachment:
Excepton Paylaod: holds any error that occurred during the processing of the event.
Ø Echo and log messages: Log messages and move them from inbound to outbound routers.
Inbound propertes are immutable, are automatcally generated by the message source and
cannot be set or manipulated by the user. They contain metadata specifc to the message
source. A message retains its inbound propertes only for the duraton of the foww when a
message passes out of a fow, its inbound propertes do not follow it.
Outbound propertes are mutablew can be set/modifed in a fow and can become inbound
propertes when the message passes from the outbound endpoint of one fow to the inbound
endpoint of a diferent fow via a transport. They contain metadata similar to that of an inbound
property, but an outbound property is applied afer the message enters the fow. Note that if the
message is passed to a new fow via a fow-ref rather than a connector, the outbound propertes
remain outbound propertes rather than being converted to inbound propertes
3. what is the difference between SOAPKit Router and APIKit Router and when to use what?
SOAP Kit Router is used when a SOAP service is to be developed via WSDL. SOAP Kit Router will
read the WSDL confgured, validate the request message coming in (if confgured) and send it to
the appropriate fow for processing based on the operatons been confgured in WSDL.
API Kit Router is used when a REST base service is been created developed via RAML. API Kit
Router will read the RAML confgured, validate the request message coming in (if confgured)
and send it to the appropriate fow for processing based of the HTTP methods in RAML.
Parallel actvate/fows can be executed in mule by using Scater-Gather fow control component.
The routng message processor Scater-Gather sends a request message to multple targets
concurrently. It collects the responses from all routes, and aggregates them into a single
message.
The default value of autoDelete is true. Therefore, a fle inbound endpoint will, by default,
remove the fle from the source directory once it is read by the inbound endpoint. If you do not
want to delete fle automatcally then you can set autoDelete property to false.
The fleAge property specifes how long the endpoint should wait before reading the fle again.
For instance, a fleAge of e0000 indicates Mule should wait a minute before processing the fle
again
6. What all are the HTTP methods that can be confgured in RAMW?
- GET,POST,PUT,PATCH,HEAD,Optons,DELETE
8.Updaton/Changes in Mule 4e
htps://blog.vsofconsultng.com/blog/mule-4-vs-mule-3-release-which-is-more-benefcial
9.What are the different catagories of policies and what are the types of APIs where its
applicable?
Policy Category Fulfills Required
200 OK, 201 Created ,202 Accepted, 401 Unauthorioed, 404 NOT Found,405 Method Not
Allowed,400 Bad Request, 502 - Bad Gateway
14. what is API gateway? what mule connectors does API -ateway support ? HTTPnS
,Jetty,File,J/BC,WS-Consumer connectors
An API Gateway is just that — a gateway protectng APIs. Any tme you create an API and make it
publicly available, there are two issues that need to be addressed:Performance and Security
The API Gateway runtme points to the backend APIs and services that you defne and abstracts
them into a layer that Anypoint Platorm manages. Consumer applicatons invoke your services.
APIs route to the endpoints that the gateway exposes to enforce runtme policies and collect and
track analytcs data. The API Gateway acts as a dedicated orchestraton layer for all your backend
APIs to separate orchestraton from implementaton concerns. The gateway leverages the
governance capabilites of the API Manager, so that you can apply throtling, security and other
policies to your APIs.
API Gateways are designed and optmioed to host an API or to open a connecton to an API
deployed to another runtme. The API Gateway runtme performs functons critcal to running
and managing APIs:
Gateways serve as a point of control over APIs, determining which trafc is authorioed to pass
through the API to backend services, to meter the trafc fowing through, to log all transactons
and to apply runtme policies to enforce governance like rate limitng, throtling and caching.
API Gateways integrate with the backend services that power them. An API is just an interface
that calls functonality living in a service or applicaton and unless that functonality lives in a
well-defned web service, integraton and orchestraton capabilites are required to connect it to
the API.
htps://www.mulesof.com/resources/api/secure-api-gateway
15.. How can we deploy Mule API on different environment without changing the code or
confguraton details?
16. What are policy in Mule and how to implement custom policy?
MuleSof provides certain built-in policies which can be referred to address general situatons to
flter unwanted trafc coming to your API. However, MuleSof provides the capability to create
custom policies, which are designed primarily to address complex scenarios like SQL injecton.
Custom policies are confguraton fles that defne the behavior of your API for each incoming
request.
Mulesof Defniton fle (YAML) - File in which you defne characteristcs of the custom policy.
Characteristcs are defned using:
:standalone - true if policy can work independently, false if it can only be applied as a
sub-part of another.
MuleSof Confguraton fle(XML) - File in which you defne the actual logic/implementaton of
your defned custom policy. There are two main tags:
<before> - Code writen within the <before> tag executes on every incoming request BEFORE
sending it to main API services.
<afer> - The afer tag gets executed afer completon of main API services, i.e afer completon
of the request.
Generally, it happens that we don't have anything to do once the API request is completed. The
<afer> tag will not contain anything, but we can't have <before> and <afer> tags lef empty. In
such scenarios, simply remove the declaraton of the tag to avoid errors.
Similarly, for MuleSof 3.8+, you can create an API custom policy project in Anypoint Studio. It
will automatcally have two fles with extensions .xml and .yaml.
- htps://docs.mulesof.com/anypoint-connector-devkit/v/3.8/
Annotatons:
iii) Import java class and and Global Functon and provide java method in that
iv) call the same method in dataweave which defned in global functon of Confguraton
mentoned in step iii)
Connecton pooling means that connectons are reused rather than created each tme a
connecton is requested. To facilitate connecton reuse, a memory cache of database
connectons, called a connecton pool, is maintained by a connecton pooling module as a layer
on top of any standard JDBC driver product.
Connecton pooling is performed in the background and does not afect how an applicaton is
codedw however, the applicaton must use a DataSource object (an object implementng the
DataSource interface) to obtain a connecton instead of using the DriverManager class. A class
implementng the DataSource interface may or may not provide connecton pooling. A
DataSource object registers with a JNDI naming service. Once a DataSource object is registered,
the applicaton retrieves it from the JNDI naming service in the standard way.
If the DataSource object provides connecton pooling, the lookup returns a connecton from the
pool if one is available. If the DataSource object does not provide connecton pooling or if there
are no available connectons in the pool, the lookup creates a new connecton. The applicaton
benefts from connecton reuse without requiring any code changes. Reused connectons from
the pool behave the same way as newly created physical connectons. The applicaton makes a
connecton to the database and data access works in the usual way. When the applicaton has
fnished its work with the connecton, the applicaton explicitly closes the connecton.
------------------------------------------------------------------------------------------------------------------
MuleSof Questons
================
Mule is lightweight but highly scalable, allowing you to start small and connect more
applicatons over tme. The ESB manages all the interactons between applicatons 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.
Q.What is RAMW ?
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
operatons can be invoked.
RAML helps the developer in creatng the inital structure of this API. RAML can also be used for
documentaton purpose.
Q.If you don't have Anypoint Studio and Anypoint platorm available then how you create
RAMW ?
https:nndocs.mulesoft.comnmule-runtmen3.9nusing-spring-beans-as-fow-components
- User can verify raml in design center or while uploading RAML in Anypoint Studio
Q.What is API ?
API is the acronym for Applicaton Programming Interface, which is a sofware intermediary that
allows two applicatons to talk to each other.
- User can publish API in exchange and Deploy in Runtme Manger of Anypoint Platorm.
Q.REST vs SOAP ?
ü SOAP stands for Simple Object Access Protocol. -> REST stands for REpresentatonal State
Transfer.
ü 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.
ü SOAP uses services interfaces to expose the business logic. -> REST uses URI to expose
business logic.
ü SOAP defnes standards to be strictly followed. -> REST does not defne too much standards
like SOAP.
ü SOAP defnes standards to be strictly followed. -> REST does not defne too much standards
like SOAP.
ü SOAP requires more bandwidth and resource than REST. -> REST requires less bandwidth and
resource than SOAP.
ü SOAP defnes its own security. -> RESTful web services inherit security measures from the
underlying transport.
ü SOAP permits XML data format only. -> REST permits diferent data format such as Plain text,
HTML, XML, JSON etc.
ü SOAP is less preferred than REST. -> REST more preferred than SOAP.