Mulesoft external API for custom alerts creation, automatic application restart and Jira ticket creation - Mule version 4

Nowadays, to be a leader in the market requires investment in process automation. It is crucial if you want to remain competitive in the market. Companies in all industries have recognized the necessity for a stable working environment imposing the need for 24/7 monitoring and fast reaction in case of issues. This has been our starting point to develop an API for fast monitoring, alerting, and auto restarting MuleSoft applications. Thus, the possibility to check any kind of connection setup in any existing Mulesoft application has never been easier. Implementing this kind of API significantly speeds up the process of reaction and resolving possible connection issues.
In this article, we will explain step by step the practical implementation of the API.

We are going to start with the implementation xml named iw-monitor-api.xml where is developed the main logic. It consists of three different flows:
• iw-monitor_Flow
• iw-monitor-ftp_Flow
• iw-monitor-db_Flow
Here we will explain the first and the second because the logic in the third one is remaining the same as for the second one just the type of connection which we are checking is different (DB connection instead of FTP).

1.iw-monitor_Flow
On new or Updated File – we are using the file connector where is set the absolute path to the directory where is placed the file, the values for that absolute path are stored in the properties file. This is a scheduled process that will trigger the connections check-in our case each fifteen minutes.

Two things are important to be mentioned when we are configuring the File connector. The first thing is if we want to use the same file which will trigger the flow based on the Polling Frequency interval defined we need to keep “Auto Delete option set to false which is a default one. The second thing is using the absolute paths because the structure of the message which is packaged for deployment is changed.
Scatter-Gather – we are using this router in order to trigger connection check in both flows at the same time along with the two flow references each one dedicated to the appropriate target flow.

2. iw-monitor-ftp_Flow

Set Payload - we have a Set Payload where is set the initial payload which is stored in the test file.
FTP outbound connector – we are creating a standard FTP connector configuration where the Host, Port, Path, User and Password are set. For that purpose, we are using the predefined properties whose values are stored in the properties file the same as it was done for the File connector configuration.

In the Path label, we are setting the path where on the FTP server we want to store the file if the connection is up and the file name.

Logger - as the name explains this logger activity is used for logging the name of the file used for testing and the time when the file is successfully stored on the FTP location.

If the connection is alive and everything is working fine the flow will end and the next check will be performed after the time interval defined by us, but in order to complete our explanation, we will cover the scenario when the FTP connection will go down. In that situation, the error will occur and the On Error Propagate error handling will be triggered.

Flow variable (FTP connectivity error) – we are storing the error message in a variable which is needed later for setting the alert message in the Message label of the CloudHub connector in the alerts-creator flow.


Flow variable (App name) – we are using the flow variable to set the application name where we are checking connection. This variable is later used in the apps-restarter flow for restarting the application automatically in which we have a problem with the inbound connector connectivity.


We will quickly mention what is important to be known for the other two flows “alerts-creator.xml” and “apps-restarter.xml” from the pictures above.
In the alerts creator flow, we have CloudHub connector implemented with the standard connection set for our needs. The other thing which is important to be mentioned here is that for receiving the proper alert message on some specified email address an alert notification should be created on the Anypoint Platform.

This is an example of creation Anypoint Platform alert for a specific application.
In the apps-restarter flow we have a transformer activity where we are creating the request needed for restarting the application:

%dw 2.0 output application/json ---{status:'Restart'}

After creating the restart request message we need to set up the HTTPS POST call to the Anypoint Platform on the environment where the application for which we are checking the connection is deployed. We have standard HTTPS configurations with the values for the host, port and the base path. What is important to know here is that you need the environment ID placed in the header with the name “X-ANYPNT-ENV-ID” and the path will be: /applications/”application name which we are restarting”/status

The last feature of this API is added to automate the process of JIRA tickets creation. With this feature, the process of the reporting of the issue is automated and requires practically no human interaction.

The JIRA ticket is reported using JIRA REST APIs. For this action two steps are needed:
1. Create ticket

• request in our case is in the following json format: As we can see, the request contains the fields that were configured by the JIRA administrator.

2. Adding the attachment and sample request message:

An important note is that when we want to send an attachment to the Jira API the output type must be declared as multipart/from-data.

The advantages of implementing this kind of external API for connections checking is that it is easily maintainable, easily upgradable, can be used for checking many different types of connections and you do not need to perform manual restarts when the connection in some application is down, this API will do that for you 🙂

Source code
The practical code can be found:
https://github.com/sashorajchin/muleiw/blob/master/iw-monitor-api.zip
https://github.com/sashorajchin/muleiw/blob/master/iw-monitor-api.jar

If you have some questions feel free to contact me:
sasho.rajchinoski@gmail.com