by Sowmiya Subramanian | Feb 6, 2019 | BizTalk Community Blogs via Syndication
BizTalk360 v8.9.5 has been released for the public with lots of exciting new features. Many of our customers have already ugraded to the latest version and started experiencing the new features. As you know, BizTalk360 will always listen to customer ideas and implement them for the product development as like
“Software quality begins with the quality of the requirements.”
We gather those requirements through the BizTalk360 feedback portal and make sure to address customers ideas and suggestions. Based on the number of votes. we came up with new features and enhancements, with intuitive design, in our latest version, as follows:
- Action on Send Port Groups
- Alarm Reset Capability
- Autocorrect Reset Capability
Above three features are the most awaited features by the customers. This will increase usability and will ease the process to maintain and monitor the BizTalk artifacts. Here we go!
Action on Send Port Groups
One of the major functionalities we are bringing is the ability to action on Send Port Groups. After getting several customer feedbacks, we are bringing this new feature in our latest release, which will ease the operation and monitoring capabilities.
A Send Port Group is a collection of Send Ports that BizTalk Server can use to send the same message to multiple destinations in one configuration. In earlier versions, user can search and view the Send Port Groups, however there was a gap in performing actions in BizTalk360. In this new version, we have added operational capabilities such as Start, Stop, Enlist and Unenlist for Send Port Groups as in line with BizTalk server.
As there is a famous saying “Intuitive design is how we give the user new superpowers”, we have improved the Application Home Page UI. From now on, you can view all the available Send Ports, Receive Ports, Receive Locations, Orchestrations, Send Port Group and the associated Host Instances in the home tab for easy access.
The BizTalk user can also audit the Send Port Groups activities in the Governance and Auditing sections. Once the user performs an action on Send Port Groups, it gets tracked on Application activities and User Activities with details as below.
The actions you perform on Send Port Groups are getting tracked and you can audit that on live through “Live Feed” as shown below.
As you already know, Monitoring is one of the core functionalities of BizTalk360. With this functionality, you can monitor all the BizTalk artifacts and when the artifacts go down, you can perform actions through the auto-healing functionality, except, until earlier versions of BizTalk360, for the Send Port Groups. Now, the Monitoring capability has also been provided for the Send Port Groups.
Note: To know the detailed information of Send Port Groups monitoring click here.
Alarm Reset Capability
Prior to v8.9.5, the alarm will get reset in two scenarios as follows.
- Manually select the respective alarm and Reset the Notification Counter
- Notification Counter will be reset once all the mapped artifact status are in the healthy state
As per the feedback from several customers (as below), we have included Auto Reset ability in our latest release.
Alert Reset limit can be set in Alarm configuration section as shown in the below screenshot.
Once the notification limit has been reached, the alarm will auto reset the counter after the configured X minutes.
Autocorrect Reset Capability
Prior to v8.9.5, as same as with an alarm, the Auto Correct configuration will get reset in two scenarios. The Auto Correct will get reset, once after the auto healing is successful:
- 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
But we don’t have the capability, to reset the Auto Correct automatically. As per the feedback from several customers, we have implemented Auto Correct Reset functionality in the latest version.
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 it limit.
Conclusion
We hope that the above features will increase the usability and reduce the manual work to reset. Are you tired of constantly having to monitor your BizTalk environment in a manual fashion? Give BizTalk360 a try and take benefits of newly added features. A trial version of BizTalk360 can be requested here.
by Lex Hegt | Mar 28, 2018 | BizTalk Community Blogs via Syndication
This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.
Why do we need this feature?
Imagine the following scenario. It’s Monday morning, you arrive at the office and you do some extra health checks on your environment, as planned maintenance has been done over the weekend, also involving the BizTalk servers. You notice that the Host Instances are not started! This occurred because, after a reboot of the BizTalk servers, the Host Instances and other vital services like the Enterprise Single Sign On service did not start. Because of this, ever since that reboot no processing has been done by BizTalk, which results in an enormous backlog of processing for an already busy Monday morning.
There is one more very common scenario. Let’s assume you are using an FTP/SFTP receive location polling files (Purchase Orders, Invoices etc) from a remote server. There are various reasons we might encounter the problem in this setup, example network connectivity, the remote server is down, someone changed the password etc.
In these instances, the BizTalk FTP/SFTP receive location will attempt to connect few times and finally quietly shut down (without notifying anyone). This is a major problem, we need a solution where a system can notify the BizTalk Administrators and also try to recover the failure condition automatically.
Above scenario is just a couple of the example of possible outage conditions. Besides Host Ithe instances and other Windows NT services, not being in the expected state, think of Receive Locations being disabled because of network disruptions, Orchestrations being unenlisted, so no messages will be picked up by then or performance degradation because the wrong Windows NT services are being started (either manually or automatically).
All these kind of artifacts being in the wrong state, may lead to disruptions of your valuable business processes and put your business at stake.
What are the current challenges?
Off course you want to prevent your business processes from being disrupted by just a few Windows NT services, or other state-bound artifacts, being in the wrong state. Ideally, you want the expected state to be recovered as soon as the artifact hits the wrong state.
No auto-recovery support by BizTalk
Unfortunately, BizTalk Server itself provides no functionality to detect that artifacts are in the wrong state, let alone that these artifacts are brought back to the desired state. So what’s left is creating custom scripts to take care of that task. More on custom scripting, a little bit later in this article.
No auto-recovery support by SCOM
Your organization might already use SCOM for monitoring your server platform. Although SCOM has a so-called Management Pack for BizTalk server, it is quite challenging to setup SCOM for proper BizTalk monitoring and operating.
Check out below whitepaper, to find out the differences between BizTalk360 and SCOM when it comes to maintaining your BizTalk environment.
Auto-recovery is one of the reasons why SCOM is not the best fit for maintaining your BizTalk environment as SCOM offers very little support for auto-recovery of your BizTalk and other artifacts which are important for your integrations. SCOM provide event-handlers which can be used for executing custom scripts, you as an administrator, still have to create these scripts.
Custom scripting
So, whether you are using just BizTalk Server or use SCOM, in case you want to auto-recover your artifacts which are in the wrong state, you need to develop custom scripts to have something in place for auto-recovery of your state-bound artifacts. Developing such scripts can be time-consuming and often it is hard to properly maintain such scripts. Also, the visibility of such scripts is bad, as they are being run through Windows Scheduler, which is, in turn, another component you should be aware of, when you are considering the overall health of your BizTalk environment.
At BizTalk360, we have the philosophy that businesses should take care of their core businesses and not be developing scripts and tools to maintain their BizTalk environments. As we have many years of experience in the field of BizTalk Server and Microsoft integration, we understand the problems you might run into, as we have faced them ourselves as well.
The goal of BizTalk360 is to take away your challenges when it comes to operating and maintaining your BizTalk environment. Even though anything can be done using custom coding/scripts, that’s not the best use of your time + management overhead of maintaining that code base.
How BizTalk360 solves this problem?
For many releases now, BizTalk360 contains the Auto Healing feature for recovery of artifacts which have hit the wrong state. While in the beginning, mainly the BizTalk artifacts could be brought back to the expected state, the feature has evolved to support below artifacts:
- Send Ports
- Receive Location
- Orchestrations
- Host Instances
- Windows NT Services
- SQL Server Jobs
- Azure Logic Apps
The Auto Healing can be configured as part of the monitoring settings for the above-mentioned artifacts. Below picture shows a Receive Location for which monitoring has been set up. The Expected state of this Receive Location is Disabled. Besides that, also Auto Healing has been set up.
Once set up, the BizTalk360 Monitoring service will evaluate whether the Receive Location is still in the expected state. In case the Receive Location hits a state which is not the expected state, the Monitoring service will try to bring the Receive Location back to the expected state. Depending on the configured value for the Max Retry setting, this will be tried at most 10 times. If the Receive Location still is not in the expected state, the artifact will move to the Critical state.
Note: To the Auto Healing, it makes no difference whether the expected state is Enabled or Disabled, or Unenlisted or Started. Depending on what you have configured for the Expected state, BizTalk360 will always try to bring the artifact to that Expected state.
Conclusion
In this article, we have seen how valuable it can be to have your artifacts being brought back to the expected state without manual intervention. Auto Healing is easy to setup with BizTalk360 as, instead of having to develop custom scripts, it is just a matter of configuring Auto Healing on the required artifacts. This increases ease of use and minimizes downtime.
Do you want to read more about Auto Healing? Here you have few articles on this topic:
Introducing Auto Healing for BizTalk Environment
Automating BizTalk Administration Tasks via BizTalk360 Auto-Healing
Get started with a Free Trial today!
Why not give BizTalk360 a try. It takes about 10 minutes to install on your BizTalk environments and you can witness the benefits of auto-healing on your own BizTalk Environments. Get started with the free 30 days trial.
The post Why did we build Auto Healing capability in BizTalk Server Monitoring? appeared first on BizTalk360.
by Senthil Palanisamy | Sep 6, 2017 | BizTalk Community Blogs via Syndication
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.
Author: Senthil Palanisamy
Senthil Palanisamy is the Technical Lead at BizTalk360 having 12 years of experience in Microsoft Technologies. Worked various products across domains like Health Care, Energy and Retail. View all posts by Senthil Palanisamy
