In this article, we will show practically how to solve the problem when we want to raise a custom alert and automatically restart the certain application on the Mulesoft Anypoint platform if the starter activity in some flow within that application is failing. We have a case when the starter of the flow is the FTP connector (inbound connector). When the connection was down for some reason, we always had the problem of not being able to react since we were not able to raise an alert based on a system exception which was thrown. From a high-level perspective, errors that occur in Mule fall into one of two categories: System Exceptions and Messaging Exceptions. Mule invokes a System Exception Strategy when an exception is thrown at the system-level (i.e., when no message is involved, exceptions are handled by system exception strategies). For example, system exception strategies handle exceptions that occur:
- during the application start-up;
- when a connection to an external system fails.
System Exception Strategies are not configurable in Mule.
There was no possibility to create an alert in the existing flow where the FTP connector is the starter, so we started reviewing other possibilities for solving the problem. We got an idea for creating an external API and implementing the logic there, where in the ftp connection checker flow as an inbound connector will be set other type of connector, with that difference that the FTP connector will be implemented in the middle of the flow instead of being a starter in order to be reproduced the message exception. Based on that we will be able to raise an alert and later perform an automatic restart. In that regard we have started with the development of an external API consisting of four flows, the main one with the purpose of checking the connection, flow for alerts creation, flow for performing automatic restart when the connection is down and flow named global used for setting up the global references.
The main flow where the whole logic is implemented is consisted of two connectors, two logger activities and catch exception strategy where the formatter, logger, variable for storing the error message, variable for setting the application name and two flow references, one for referencing the alerts-creator flow and the other one for referencing the applications – restarter flow are placed. In addition we will explain how to properly configure each activity in order to achieve our main goal which is creating the custom alert notification and restarting the application where we have connection which is down application.
File poller connector (File poller to trigger the flow) – we are creating standard File connector configuration where the Path, Polling Frequency and File Age are set. For that purpose, we are using the predefined properties which values are stored in the properties file.
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 in the properties file we need to uncheck “Auto Delete” check box option in the File connector configuration.
Second thing, once we have packed the application into a deployable zip archive the structure of the file system is changed compared to how it looks inside the Anypoint Studio. In that regard it is better to use absolute paths based on the application home directory. In our case we have created folder named “check_connection” under the “src/main/resources” and there the file named “check_ftp_connection_testfile.txt” is stored which is used for triggering the flow. In this situation we need to set the following path: “${app.home}/classes/check_connection” instead of “src/main/resources/ check_connection” otherwise the flow will not start when the application will be deployed on CloudHub Anypoint Platform.
Logger (Log the payload) – We are using the logger activity in order to be logged the payload which will be sent to the FTP location.
FTP connector (FTP store location) – we are creating 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 Pattern tab the expression #[message.inboundProperties.originalFilename] is set that is presented on the picture which is used for getting the original file name and in that way storing the file on the appropriate FTP location.
Logger (Log the time and name of the successfully processed file) – 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 some 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 catch exception strategy will be called.
Flow reference (StandardErrorFormatting) – We are calling the external flow which is used to format the error message that will occur in a predefined structure.
Logger (Log the payload on ERROR level) – we are logging the error message.
Flow variable (FTPConnectivityError) – 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 for which we are checking connection. This variable is later used in the apps-restarter flow for restarting the application automatically in which we have 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 and the logger activity after that in order to be logged the information once the alert is created. 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.
In the apps-restarter flow we have a transformer activity where we are creating the request needed for restarting the application:
%dw 1.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 advantages of implementing this kind of external API for connections checking is that it is easy maintainable, easy upgradable, can be used for checking many different type 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.
