Auto Correct

What is Auto Correct?

If you are a BizTalk administrator, there may be many times you have been notified by your colleagues/monitoring system of a potential issue in the BizTalk environment. For example, a receive location was accidentally disabled, NT services failing to restart automatically, and so on. These are quite common problems in the day-to-day life of a BizTalk administrator. To solve this specific problem and make the life of BizTalk administrators easy, BizTalk360 offers the 'Auto Correct' or 'Auto Healing' functionality.

With the Auto Healing functionality, administrators can set up monitoring on any 'State-based' artifact and let the monitoring service automatically heal the artifact at any time when there is a mismatch between the 'Expected State' and the 'Current State'. For instance, administrators can set up monitoring and the auto healing option for receive location(s) by setting the Expected state as 'Enabled'. If any threshold violation happens, say if the receive location goes to the 'Disabled' state, then BizTalk360 will try to rectify the violation, by trying to bring the artifact to the expected state (Enabled). If the operation is successful, the artifact will come back to the Expected State within the next monitoring service cycle (60 seconds).

List of state-based artifacts for which I can set up Auto Correct functionality

Auto Correct can be enabled for the following state-based artifacts:

1. Receive Locations
2. Send Ports
3. Send Port Groups
4. Orchestrations
5. NT Services
6. SQL Jobs
7. Host Instances
8. EDI
9. Azure Logic Apps
10. IIS Website & App pools

We have also provided retry functionality of 'how many times the monitoring service can attempt an auto correct' on a particular state-based artifact. For instance, there may be an FTP receive location that is expecting messages from an FTP server and there might be some network issues in the FTP server that have caused the receive location to be disabled. Once the network issue is fixed, it’s perfectly safe to bring back the receive location, however, the administrator must manually log in to the BizTalk Administration Console to get this working. To avoid this manual intervention, administrators can set up the 'Max Retry' count in the Auto Correct functionality. This would allow the auto correct (BizTalk360 monitoring service) to continuously, with a 1-minute interval, try and bring back the receive location to the Enabled state. If the operation was successful within the Max Retry count, the artifact would be automatically healed to ensure business continuity and send AUTO correction alert to you and monitor status will become healthy immediately. If the operation was not successful within the Max Retry count, the artifact would move into a Critical state. In that case, the Monitoring Dashboard would display the artifact in Red colour and AUTO correction alert will not be sent. Once the attempt count reaches the Max Retry count, then the auto correct will get reset after the configured x minutes in the “Reset Interval” setting.

An In-Depth Look

In this section, we will take a look at the auto correct functionality in detail. As mentioned earlier, the auto correct functionality is available for all state-based artifacts such as Receive Locations, Send Ports, Send Port Groups, Orchestrations, NT Services, SQL Jobs, and Host Instances. We will take one artifact (say, Receive Location) and explain the different auto correct options available. The functionality works the same for all state-based artifacts.

1. Alarm Selection - Select the alarm from the drop-down
2. Artifacts - Select the artifacts for which you want to set up monitoring and auto correct functionality.

• Applications - Receive Locations, Send Ports, Send Port Groups, Orchestrations
• BizTalk Servers/SQL Servers - NT Services
• SQL Server Instances - SQL Jobs
• BizTalk Environment - Host Instances, EDI
• Azure Services – Logic Apps, Standard logic apps, Queues, Topics
• IIS server - Website, App pools

3. State-based monitoring - Select the check box against the artifact for which you want to set up monitoring and set the 'Expected state' of the artifact.

4. Auto Correct drop-down - The auto correct drop-down will not get activated unless you perform an activity in Step 3
5. Enabling Auto Correct - Select the checkbox against the artifact and Enable Auto Correct from the drop-down. You will notice that Auto Correct gets enabled with a Max Retry count of 5 (default), Attempt count of 0, and Reset Interval count of 0.

• Max Retries - Click the numeric value and adjust the slider to set the number of retries the monitoring service should attempt.
• Attempt - Shows the number of times the monitoring service has performed the retry operation.
• Reset Interval - Click the numeric value and adjust the slider to set the minutes to reset the auto correct retry count. The reset interval holds a value of minimum 0 to maximum 1440 mins (i.e., 24 hours). If the reset interval is set to 0, which means the retry count will not reset.

The Auto Correct Reset Interval time and Retry count can be set globally or for individual artifacts, as per the business requirements.
To set the reset interval time and Retry count globally, the user needs to configure the value in the System Settings as shown below. This value will automatically reflect in all newly enabled auto correct configurations.

The Auto Correct reset interval time and Retry count can be configured for each individual artifact as shown below. 

AutoCorrect Not Configured Artifacts is introduced in application mapping with this in a single view you can see the artifacts lists which are mapped for monitoring but not enabled for auto-correction. you can navigate from this section to mapping by clicking on the respective artifact. 

Also, in the application artifacts mapping section, the artifacts which are not mapped to any of the alarm is indicated with an icon.

Auto Correct Notification

Whenever auto correct action is performed, notification will be sent based on the notification configuration in alarm .However user can restrict this notification in the alarm configuration.