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 for developing an API for fast monitoring, alerting, creating JIRA tickets, and auto-restarting MuleSoft applications. Thus, the possibility of checking 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 the practical implementation of the API step by step.
We are going to start with the flow where the main logic is developed. 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 remains 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 the absolute path to the directory of the file location is set, 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 every 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 that will trigger the flow based on the defined Polling Frequency interval, we need to keep the “Auto Delete” option set to false which is a default one. The second thing is using the absolute paths because the structure of the project will be changed once we prepare it for deployment on the Anypoint Platform Runtime Manager.
Scatter-Gather – we are using this router in order to trigger connection checks 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 the initial payload which is stored in the test file is set.
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, those values are stored in the properties file, exactly the same as it was done for the File connector configuration.
In the Path label, we are setting the path where we want to store the file if the connection is up and running along with the file name on the FTP server.
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 that 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 the connection is taking place originally. This variable is later used in the apps-restarter flow to perform an automatic restart on that exact application.
We will quickly mention what is important to be known for the other two flows “alerts-creator.xml” and “apps-restarter.xml” based on the pictures presented above.
In the alerts creator flow, we have a 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 creating an 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 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 ticket creation. With this feature, the process of reporting of the issues 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 a ticket
- the 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:
A very 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.
After we summarize the explanation above we can say that implementing this kind of solution will rapidly increase processing time, decrease costs, and automate the process of monitoring, alerting, handling exceptions, and reporting the issues. There are many advantages that can be mentioned if we implement this kind of API in our working environment. We want to emphasize that it is 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 applications is down, this API will do that for you.
If you want to try it for yourself and you need help, do not hesitate to contact us.
