MULE SOFT ANYPOINT PLATFORM
ASSIGNMENT – 2
1)Write down the steps to configure the mule application by importing the API from
anypoint Platform.
Ans:
This experiment demonstrates how to import a designed and published RAML-based API (from
Experiment 4) from Anypoint Exchange into Anypoint Studio. It also covers how to create a Mule
flow that sends a request to the mock endpoint and returns the response.
Steps:
• Launch Anypoint Studio on your system.
• Go to File ➜ New ➜ Mule Project.
o Enter the Project Name: EmployeeAPIConsumer, then click Finish.
• Click Import a published API, then click the green + button as shown in your image.
• In the Add Dependencies to Project dialog:
o Your Anypoint username should be visible in the dropdown.
o If not, click Add Account and log in using your Anypoint Platform credentials.
• In the search bar, typ the name of your published API — e.g., Employee API
• Once it appears in the list:
o Select the API
o Click Add > to move it to the right-side (Selected modules)
• Click Finish and Again click Finish again.
• Your Mule project will now include:
o The RAML files under src/main/resources/api
o A scaffolded flow for each method and resource defined in the RAML
o A pre-built router using APIkit to handle /employee paths
• Open the generated flow file eg:. [Link]
• In the [Link] file, you will find auto-generated flows like:
o get:/employee:application/json
These flows were created based on the methods you defined in your RAML
specification.
• Don’t change anything and save it.
• Wait until you get the message deployed.
• Now, test your application by opening a browser and open this URL
[Link]
• You will get output like this:
2)Explain the concept of Mule Events and illustrate their structure with diagram?
Ans:
Mule Events
A Mule event contains the core information processed by the runtime. It travels through components
inside your Mule app following the configured application logic.
Note that the Mule event is immutable, so every change to an instance of a Mule event results in the
creation of a new instance.
A Mule event is composed of these objects:
• A Mule Message contains a message payload and its associated attributes.
• Variables are Mule event metadata that you use in your flow.
A Mule event source (previously called a "message source") triggers the generation of a Mule event
and dispatches that event to the flow. Examples of event sources include triggers, such as the
Scheduler, and listeners, such as the HTTP Listener and On New or Updated File components.
1. A trigger reaches the event source.
2. The event source produces a Mule event.
3. The Mule event travels sequentially through the components of a flow.
4. Each component interacts in a pre-defined manner with the Mule event.
In some cases when an issue occurs in an event source, the component does not produce a Mule event.
For example, invalid or incorrect paths in an HTTP listener configuration prevents the creation of a
Mule event. Connectors log such issues in ERROR, WARN, or INFO messages.
Mule Event:
A Mule Event contains all the core information processed by the Mule runtime. A Mule event is
triggered by a message source, such as a Listener or an HTTP request. These Mule Events are critical
for the smooth execution of flows in an API creation. As we discussed earlier, each flow has its event,
and thus events are immutable, which means a small change to an instance of a Mule event will create
a whole new instance. When an event is triggered, all the core information like attributes, payload, and
variables are passed to the next processor.
It is important to note that for a flow to execute, the event processor plays a more crucial role than the
event source.
A Mule event consists of two main components: the Mule Message and Variables.
Mule 4 contains a simplified Mule message model in which each Mule event has a message and
associated variables.
Mule Message
The Mule Message contains two different parts, namely the attributes and the payload. It serves as a
container for message content and metadata, from external sources, as it is processed within flows of
a Mule 4 application.
Attributes contain metadata such as headers and properties, including the method type used, host, and
port. When an HTTP request is sent, attributes such as method type, host, and port are included. These
attributes are stored in the attributes section under the Mule Message. These attributes will be passed
to the rest of the flow until the attributes are updated.
The payload contains the core data being processed throughout the flow. It stores the data that is
processed by the application. 'Set payload' is usually used to set the payload, and is carried till the end
of the flow in the payload section of the Mule message. Whatever JSON or XML code you write will
be stored in the payload section. It is also considered as the main body of a Mule message. The payload
is replaced when a new 'set payload' is triggered every time in the Mule runtime flow.
Variables
Variables are used to store per-event values for use within a flow of a Mule app. Variables in a Mule
event are created using the Set Variable component. They are used to store temporary values specific
to an event within a flow. Variables can hold any supported data type, such as objects, numbers, or
strings. They are accessible only within the scope of the flow where they were created.
3) What is debugging? Write the steps to debug a mule application
Ans:
Debugging Mule Applications
Debug your Mule application using the embedded debugger in Anypoint Code Builder.
The process for debugging a Mule app is:
1. Set breakpoints to pause the execution of a flow at lines that you want to inspect or fix.
Breakpoints are markers that you add on line numbers in a configuration XML file for a Mule
application that you are developing.
2. Run the application in debug mode.
3. Start execution of a flow in your Mule application.
For example, trigger an HTTP Listener or configure a Scheduler component.
4. When the execution stops at a breakpoint, use the debug toolbar to navigate, inspect, and
fix issues.
5. After addressing an issue at a breakpoint, redeploy (hot deploy) the running instance of
your application.
6. Execute your flow again, and continue debugging until you address all issues.
7. Stop the debug session.
Debug Console Overview
Add a Breakpoint
A breakpoint enables you to pause your Mule application at a specific place to learn more about what
is happening. You can either add a breakpoint to a configuration XML file or to a component in the
canvas UI.
Add a Breakpoint in a Configuration File
To add a breakpoint in a configuration XML file:
1. In Anypoint Code Builder, on the Explorer view, open your configuration XML file, for
example, [Link].
2. Open the Run and Debug panel.
o Click the (Run and Debug) icon in the activity bar.
o Use the keyboard shortcuts:
▪ Mac: Cmd+Shift+d
▪ Windows: Ctrl+Shift+d
o In the desktop IDE, select View > Run.
o In the cloud IDE, click the (menu) icon, and select View > Run.
3. Click the line number in your <flow-ref> component to add a breakpoint on that
component:
You can also use F9 to add a breakpoint to the current line.
4. In your configuration XML file, add two more breakpoints for the <db:select> and
the <set-variable> components.
All breakpoints appear in the Breakpoints panel:
Add a Breakpoint to a Component in the Canvas UI
To add a breakpoint to a component in the canvas UI:
1. In Anypoint Code Builder, on the Explorer view, open your configuration XML file, for
example, [Link].
2. Open the Run and Debug panel.
3. In the canvas UI, right-click on the component you want to add a breakpoint to:
4. Select Add Breakpoint.
A breakpoint icon appears on the component and in the configuration XML for that component.
Run Your Application in Debug Mode
After setting up your debug conditions, run a debug session and evaluate your Mule application at
each breakpoint:
1. Open the Run and Debug panel.
Show me how
2. Click the (Start Debugging (F5)) icon for Debug Mule Application.
Alternatively, if the Start Debugging (F5) icon is not present:
a. Click Run and Debug.
b. If a Select debugger dropdown menu appears, select Mule Xml Debugger to initiate the
debugging session:
When the application deploys successfully, you see a DEPLOYED log message in the output panel:
*********************************************************************
* - - + DOMAIN + - - * - - + STATUS + - - *
*********************************************************************
* default * DEPLOYED *
*********************************************************************
Anypoint Code Builder packages your application and deploys the application to the embedded Mule
runtime engine. A terminal opens so you can view the status:
The terminal displays a message and the status bar turns red to indicate that the application is running.
Use buttons on the debug toolbar to control debugging of Mule applications.
