Error Alerts: MuleSoft CloudHub Connector
This article will discuss how to use custom CloudHub alerts to configure end-to-end error alerts in MuleSoft. To start, assume we have a project with a huge order load coming from legacy system 1 and are creating orders in CRM system 2. If there are issues in the order, some of the order creation would fail. Without any built-in alert, the customer would only be alerted of the order failure from the order creator (i.e., the end user or when somebody notices the discrepancy). It would be very challenging for a support team to determine where the order failed and what team to redirect the issue to.
Now imagine this: what if the appropriate team got an email alert as soon as the order failed and could act upon the issue and inform the customer support team in advance? The support team would be able to provide the end-user with a solution in a faster, and sometimes even preemptive, manner, increasing customer satisfaction.
This is what we will deliver, using MuleSoft. A challenge arises if we don't have an external email hosting service available to send email alerts; however, we can use the CloudHub Alerts feature in Runtime Manager to overcome this.
There are some standard alerts provided by MuleSoft that are useful for standard Mule app events, such as deployment success/failure status. In our case, we need a more specific error alert. We want alerts to be sent when a custom business error or any failure in the Mule app occurs. To achieve this, we must implement that feature using the custom application alerts. Using the out-of-the-box CloudHub Connector, we can configure different types of alerts to be sent to particular recipients, allowing the appropriate groups to act upon the alert-causing event.
For the sake of simplicity, we divide the alert options into three categories: business error alert, internal error alert, and standard alerts.
Business Alerts: as the name suggests, business error are related to failures in business validation or logic. Business errors are known scenarios. Suppose an order from system 1 has failed to create an order in system 2. We can implement logic to check the response of the system 2 connector and send the respective alert containing cause of failure and an identification of the order through CloudHub Connector’s Create Notification operation. For example, an alert for order create failure to the business team would contain order ID 123, along with it a custom cause of failure message explaining the reason of the failure.
It is important to note that there can be different types of business events, and you don’t necessarily want the same email recipients to be alerted for all types of events. Below I will describe how to specify who receives emails for a particular custom business events. Consider the following scenario:
In this case, we distinguish errors by providing a unique ID to each alert type. For example, Business Error Alert Type 1 has ID BEA1 and Business Error Alert Type 2 has ID BEA2.
The process of creating a custom CloudHub alert has two steps:
- Configure the app to send an alert using CloudHub, using the create notification operation
- Define the alerts in the Anypoint Platforms Runtime Manager, under the alerts section
In first step, we provide the unique ID (e.g., BEA1) for the alert in the message section of CloudHub, using the create notification operation.
In the second step, we create the individual alerts in Anypoint Platform Runtime Manager, under the alerts section. We specify the same ID (e.g., BEA1) in the contains section, which is under condition section of the alert.
In each alert we can define the email addresses of all the recipients of the alert under the recipients section.
We can form form the alert messages in the message section of the alert. The required ID (used to recognize the order) can be passed by the application as custom properties from the CloudHub create notification operation. The ID can also be referred to using ${id} in the alerts message section.
CloudHub create notification operation:
Alert in Runtime Manager:
The business orchestration logic lies inside the process API(s), so this alert logic can be kept in the process API(s).
Internal Alerts: failures in the runtime are unpredictable and we must alert the monitoring team when such failures in the Mule application occur. In such instances, we need an internal error alert.
A simple way would configure an internal error alert is to package it in your common error handler, which handles all errors in the Mule app and sends notifications to the support team. This type of alerts can occur in any layer, so it can be kept in all API(s).
What can you use to uniquely identify such errors so that you can identify and find more about the failures in the logs?
The Mule correlation ID is one solution.
Standard Alerts: we can also set an out-of-the-box alert provided by MuleSoft, such as an alert to indicate a failure in app deployment or if the application exceeds the number of events process. If you want to know more about the standard alerts provided by MuleSoft, please check here.
Using this simple method, we are able to send seamless email alerts to the appropriate groups. This allows for a quick turn around time for our customer’s support team and we are able to add value to the customer’s business.
