This series is about how you can use BizTalk360 to get better service availability through the BizTalk360 automated recovery features. This blog post comes as a series of 5 that all discuss different topics around how to effectively benefit from the Automated recovery features of BizTalk360. In this blog post, we will cover the second part of the series.
- BizTalk360 Automated recovery features- Part1- How to deal effectively when your receive locations get disabled.
Get automated reports when your receive locations get disabled. Click here to know more in detail.
- BizTalk360 Automated recovery features – Part2 – How to improve service availability
- BizTalk360 Automated recovery features – Part3 – How to optimize your Windows resources
- BizTalk360 Automated recovery features – Part4 – How to automate suspended instance operations
- BizTalk360 Automated recovery features – Part5 – How to automatically clean up unneeded service instances
Current Challenges in BizTalk Server
In the standard admin console, there is not an ability to monitor states such as “Enabled/Disabled”. Currently, the standard admin console provides stages such as “Started/Stopped/Restart”. We have seen various scenarios where administrators keep host instances in a disabled state for various reasons like the host instances are brought live only during throttling conditions, or they are used for testing purposes (even in a production environment) and may be due to system maintenance as well. This is one of the common scenarios in a real-life BizTalk environment. Hence, they use manual methods to start host instances in the admin console.
User permissions required to setup Host Instances
Note: Regarding host instances monitoring it is common for all tiers in BizTalk360. Click here to get a quote for each tier.
By default, super users will have all access to the host instances and set up monitoring in host instances. However, if you’re a normal user, you must ensure to have access to the following:
- Manage infrastructure setting
- Monitoring of host instances
Once all feature permissions are set, you can just start/stop/enable/disable your host instances from within BizTalk360. In this way, your admin people or support people do not require any admin access to use BizTalk360. Navigate to the steps as follows (Operations -> Infrastructure Settings -> Host instances)
Once the status of the host instances has been set up. The next step is to navigate to the Monitoring section of BizTalk360. (Monitoring -> Manage Mapping -> BizTalk environment -> Host instances)
Configuring monitoring for host instances in BizTalk360 is simple. As shown in the above picture, BizTalk360 allows users to select a particular host instance and set the required (“Expected”) state. In the above example from our test environment, we wanted the host instance “BizTalkServerApplication” to be in started state. Suppose if someone accidentally disables the host instance, BizTalk360 will automatically pick up the threshold violation (since the current and expected state will mismatch) and send notification alerts to the configured notification channels.
Currently, BizTalk360 offers custom notification channels for the following.
To know more follow the steps to configure custom notifications channels in BizTalk360. You can notice from the below screen, the host instance monitoring turned RED because we disabled the particular host instance in the server.
BizTalk360 gives you the flexibility to monitor the host instances for any available state like Started, Stopped, and Disabled. This is one of the great advantages of using BizTalk360 for BizTalk monitoring since it is 100% focused on BizTalk monitoring.
Monitoring Clustered Host Instances
To achieve high availability for adapters, that cannot have multiple host instances running at one point in time, BizTalk allows you to cluster hosts using Windows Failover Clustering. This will make only one host instance running for the clustered host and in case of any failure, it will failover by running the host instance in a different server.
BizTalk360 has the capability of monitoring clustered host instances. Setting up monitoring for clustered instances is the same as all for other artifacts in the environment. To know more about the clustered host instances follow the link.
For a healthy BizTalk environment, there are lots of things that should all work in order to have a healthy environment. With the help of, the “auto correct” feature any state-based artifact can be automatically brought to the desired state such as enabled, disabled, started, and stopped). This helps in providing a higher service availability.
The following artifacts can be configured with Auto Correct
- Receive locations
- Send ports
- Send port groups
- Host instances
- NT services
- Azure logic apps
- SQL Jobs
To know more and to setup auto correct in your environment follow the link
Alarm Reset Capability
The Auto Correct configuration will get reset in two scenarios. The Auto Correct will get reset, once the auto correct is successful:
- The Auto Correct “Max Retry” counter will be reset after the successful auto healing of the mapped artifacts
- Associated Auto Correct mappings will be reset after the alarm reset.
Now, with Auto Correct parameters “Max Retry” and “attempt”, an additional parameter has been added, which is “Reset Interval”. The user can configure the time interval to do automatic Auto Reset. This configuration will reduce the manual intervention every time when the “Max Retry” counter reaches its limit.
In the second article, we have seen how to setup monitoring for your host instances and get to know what happens in your environment via your preferred way of communication. In the upcoming series, we will highlight other capabilities of BizTalk360 as well. If you wish to evaluate our product or take a product tour. Then take a quick go by signing up for our free trial.