This post was originally published here
Introduction
BizTalk server state based artifacts such as receive location, send port, orchestration may go down due to various reasons. This could stop a business critical interfaces from processing messages. Monitoring the artifact states is a tedious task for both operational and administrative users. The operational users must monitor the state of artifacts constantly if any violation happens to the artifact state the operational user will intimate the administrative users immediately. In turn, administrative users should take corrective actions to bring the artifact to the expected state to avoid/minimize the business impact. This process involves the operational and administrative users be available throughout the clock to enable the interfaces again. BizTalk360 overcomes this challenge with its auto healing capability.
I am writing series of articles on “Automating BizTalk Administration Tasks Using BizTalk360”. First Blog was focused on service instance data monitoring. In this article, I will be explaining how you can leverage auto healing capability in BizTalk360.
How it works
With the auto healing functionality, Administrators can set up monitoring on any “State-based” artifact and let the monitoring service to automatically heal the artifact any time when there is a mismatch between the “Expected State” and “Current State”. For instance, Administrators can set up monitoring on the receive location(s) of an application and additionally set up the auto correct functionality for the Expected State of the artifact (which should be “Started”). Whenever the receive location goes down/gets disabled, there will be a state mismatch and the auto correct will try to bring the artifact back to the expected state. If the operation is successful, the artifact will come back to the Expected State within the next monitoring service cycle (60 seconds).
State Based Monitoring
Artefacts State Based monitoring is one of core feature in BizTalk360. State Based monitoring is included for Application Artefacts
- Send Ports
- Receive Location
- Orchestrations
- Host Instances
- NT Services
- SQL Jobs
- Logic Apps
To avoid this manual intervention, administrators can set up the “Max Retries” count in the auto healing. This would allow the auto healing (BizTalk360 monitoring service) to continuously try and bring back the receive location to “Enabled State”. If the operation was successful within the Max Retry count, the artifact would be automatically healed to ensure business continuity. If the operation was not successful within the Max Retry count, the artifact would move into a Critical state.
Email Notification
Artefact (Receive Location) is configured for monitoring and auto healing when the receive location violates the threshold condition means monitoring service will first trigger the down alert.
Monitoring service will auto correct the state of receive location to expected state and trigger an auto correct email.
Custom BizTalk Adapters
Custom BizTalk adapters are used in Receive Location/Send Port; In this case, we must install Custom adapter components in BizTalk360 servers.
If you have installed BizTalk360 Monitoring service in multiple servers for BizTalk360 HA then install Custom Adapters pack in multiple servers.
We can few cases where custom adapters pack needs to be installed;
1. BizTalk Scheduler Adapter
When you are using BizTalk Scheduler in BizTalk Artefacts and not installed in BizTalk360 Box. Then you will get the error as like below
“ReceiveLocations: Exception raised while trying to set receive locations to the expected state. Ex: Microsoft.BizTalk.ExplorerOM.BtsException: Could not validate TransportTypeData, Address or Public Address properties for Receive Location ‘Receive_INV_Scheduler’ “
To address this issue we need to GAC Microsoft.BizTalk.Scheduler.dll in BizTalk360 Box(es).
2. nSoftware Adapter
nSoftware Adapters are used in BizTalk Artefacts (e.g.: FTP(s)/SFTP Adapters). Exception raised while trying to set receive locations to the expected state by auto correct feature.
“Ex: Microsoft.BizTalk.ExplorerOM.BtsException: Failed to create ‘nsoftware.SFTP v4’ Transport Component at Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer.SaveChangesWithTransaction(Object transactionObj)”
Overcome this challenge we need to install the nSoftware adapters where BizTalk360 Monitoring service is running.
3. Host Integration Adapter Pack
BizTalk Artefacts are using MQSC (HIS) adapters in your BizTalk Environment means you have to install Host Integration Pack Adapters.
The following are adapters in Host Integration Adapter Pack
- Host Applications
- DB2
- WebSphere MQ
- Host Files
User Permission
Taking automatic actions on BizTalk Artefacts, SQL Jobs, Host Instances and NT Services we need adequate permissions to Service Account user with respect to Windows, SQL, and Azure.
Feature | Minimum Required Permission |
---|---|
BizTalk Artefacts – To change the status of BizTalk Artefacts | BizTalk Operators Group |
Host Instances – Operations (WMI) | BizTalk Administrator Group |
SQL Jobs – Change state of Jobs | SQLAgentOperatorRole |
Logic Apps – Enable/Disable | Owner (Subscription User) |
You can see more information about BizTalk Server Security.
Conclusion
BizTalk users can leverage this most powerful feature “Auto Healing” in BizTalk360 to maintain/monitoring the states of various Artefacts. It will minimize the downtime of BizTalk Artefacts.