by Lex Hegt | May 9, 2018 | BizTalk Community Blogs via Syndication
Why do we need this feature?
The BizTalk Health Monitor (BHM) and its predecessor MessageBox Viewer (MBV) are important tools to learn about the overall health of BizTalk environments.
The tools are developed and maintained by Microsoft and firstly used by their Premier Field Engineers, to help them identify problems with BizTalk environments. Later, the tool became publicly available, enabling BizTalk administrators to run the tool themselves as well. Since that time, we have seen many updates of the tools, although MBV is deprecated for few years now.
The BizTalk Health Monitor can be downloaded here:
https://www.microsoft.com/en-us/download/details.aspx?id=43716
The best practice is to run BHM frequently, say once per day at a quiet time, to be aware of overall health and check for any critical issues.
MBV did not offer a built-in scheduler, so you had to schedule it yourself with Windows Scheduler. With the introduction of BHM, the tool came with a plugin, to use it from the BizTalk Server Administration console and it also came with scheduling features.
Once scheduled, you’ll receive the output in the configured mailbox. So you have the fully detailed report easily at hand.
What are the current challenges?
Although it’s good to have the output of MBV/BHM runs in your mailbox, we think that the overall experience still can be improved.
In your day to day activities as a BizTalk administrator, you might receive many notifications in your mailbox. If not setup properly, the amount of notifications might be overwhelming, which might result in starting to ignore the notifications, thereby risking to miss important notifications.
So, you will want to focus on just the notifications which indicate something needs to be taken care of. In case of the MBV/BHM output, you will only be interested in critical and non-critical errors on which some actions must be taken. In other words, if all is healthy, you might not be interested to receive that output at all.
With BHM you will always receive the output, regardless if all is healthy or some (non-)critical issues exist. No clear notification can be received, in case something serious is going on.
Besides that, MBV/BHM is another tool/console you need to be aware of to consider the overall health of a BizTalk environment. As we want to apply our One Platform philosophy as much as possible, we brought integration with MBV/BHM to BizTalk360.
In the next section of this article, we’ll show you how BizTalk360 helps you to improve the experience of BHM and how you can have monitoring on the output of MBV/BHM runs.
How BizTalk360 solves this problem?
BizTalk360 has integration with MBV/BHM for many years. This integration enables the BizTalk360 user to schedule MBV/BHM and view the output of the different runs of the tool directly from within BizTalk360.
This makes it easy to run MBV/BHM and view its output in BizTalk360, instead of delivering the output of each run to the mailbox of the user.
However, this does not yet solve the problem of just being notified in case of critical errors. To achieve that, you can simply add the BizTalk Health Monitor to a BizTalk360 alarm. In BizTalk360, you can do this by navigating to Monitoring => Manage mapping => BizTalk Environment => BizTalk Health Monitor. Here you can configure how many critical or non-critical may occur in the output of BHM, before a notification is being sent.
As you can see from above screenshot, under Error Threshold, you can configure how many critical/non-critical errors may exist, before a notification is being sent. From the Current Configuration of the screen, you can see that in the last report there were 2 critical and 20 non-critical errors. So, in above scenario, the error thresholds have been met and a notification will be send.
If you want more fine-grained monitoring of the BHM output, BHM offers you the option to store the output of the BHM runs in a database. Say, you want to monitor on specific categories like Tracking or the BizTalk jobs, you could achieve that with Database query monitoring.
When you would like to know more on how to set this up, feel free to contact us (support@biztalk360.com) and we are happy to work with you on the scenario at hand.
Conclusion
The integration of MBV/BHM with BizTalk360 adds to the One platform philosophy. By also bringing monitoring of the output of MBV/BHM, we remove some of the clutter which appears in the mailbox of the user, providing good focus on the topics which really matter. With some customization, you could have even more fine-grained monitoring on the output of BHM.
There are some more articles on MBV/BHM integration. Check them out here:
Get started with a Free Trial today!
If you would like to try BizTalk360, why not give it a try. It takes about 10 minutes to install on your BizTalk environments and you can witness and check the security and productivity on your own BizTalk Environments. Get started with the free 30 days trial.
Author: Lex Hegt
Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt
by Lex Hegt | May 2, 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?
The BizTalk Health monitor (BHM) is the successor of the Message Box Viewer (MBV). Both tools have been developed by Microsoft for health analysis of BizTalk environments. Despite its (former) name Message Box Viewer, the tool checks many more parts of BizTalk Server than just the Message Box database(s).
For example, the tool checks whether:
- the latest Cumulative Updates are installed
- relevant hotfixes are installed
- all kind of configuration (Windows, BizTalk, SQL) is conform best practices, think of
- Correct Host Configuration
- Auto-growth settings of your BizTalk databases
- Unnecessary Tracking switched on
- your BizTalk databases are in good health
- the well-being of your BizTalk related SQL jobs
- there are (relevant) Event Log errors
After Microsoft deprecated the Message Box Viewer software few years ago, they introduced the BizTalk Health Monitor (or BHM). BHM uses the same engine as the Message Box Viewer, but also comes with some improvements. These improvements are mainly related to:
- Visibility – the BHM software comes with a MMC snap-in, which allows you to have both the BizTalk Server Administration console and the BizTalk Health Monitor software in a single MMC snap-in
- Scheduling – you can now setup runs of BHM directly in the tool itself. In the background BHM still uses the command line version of the tool and the Windows scheduler to perform the runs. By creating multiple profiles, you can even perform runs for different BizTalk Server environments, from the same instance of BHM.
Just like with the Message Box Viewer, it is advised to run BizTalk Health Monitor on a regular basis. The tool comes with most recent versions of BizTalk Server and needs to be installed on the BizTalk Server. The tool can also be downloaded here:
https://www.microsoft.com/en-us/download/details.aspx?id=43716
Once you have installed BHM, you can setup scheduling so you will automatically retrieve health reports in your mailbox.
What are the current challenges?
Although BHM contains important information on the health of your BizTalk environment, it is yet another console you must be aware of. Especially organizations with less knowledge of all the consoles needed to support BizTalk Server, this one can easily be overseen or forgotten, with potentially, catastrophic results.
To be able to access BHM, be it for configuration of the runs of BHM or viewing (historic) reports, you need Remote Desktop access to the BizTalk server on which the BizTalk Health Monitor software is installed. Logging in to the BizTalk server repeatedly is time-consuming and can prevented by using the MBV/BHM integration which is discussed in the next paragraph.
How BizTalk360 solves this problem?
As you probably know, the vision behind BizTalk360 is to provide One platform for BizTalk Server. By providing One platform, aka one user interface, we bring all the different consoles, a BizTalk administrator might need to be able to do his job, under one hood.
For that reason, we already brought integration with Message Box Viewer years ago and updated the integration to support the BizTalk Health Monitor. This integration exists of the following features:
- Schedule runs of BHM
- Run BHM profiles
- Manually run BHM
- View reports of BHM
- Monitor the results of BHM runs
Schedule runs of BHM
For many years, BizTalk360 already had integration with the predecessor of BizTalk Health Monitor, being Message Box Viewer. This integration included the scheduling capability, which was brought by BHM, when the tool became available, as well.
So, when we replaced MBV integration with BHM integration, of course we made sure that you would be able to setup BHM schedules from BizTalk360 as well.
Run BHM Monitoring profiles
BHM allows users to create specific so-called Monitoring profiles, which can be used to execute a subset of all the available queries and rules. This can be used, for example, to monitor just specific components or artifacts.
BizTalk360 allows you to run or monitor on such a profile, by creating such a profile in BHM and manually copying it to the BizTalk360 installation folder. If you want to read more about this capability, read below article:
Getting BizTalk360 to run a BHM Monitoring profile
Manually run BHM
Besides being able to run BHM based on a schedule, as shown in the previous paragraph, you can also run the tool immediately from BizTalk360. By clicking the ‘Run BHM Now’ button (see the picture below), BizTalk360 schedules a run immediately and the results can be checked after the run has been processed.
View reports of BHM
The reports of all the different runs of BHM can be viewed directly in BizTalk360. The screenshot below shows the dropdown from where you can select, which report you would like to see. The most recent report is shown on top.
Storing the output of BHM runs
The BHM reports are stored in the BizTalk360 database and can reside there for a configurable time frame. By default, this time frame is 5 days, but you can choose values between 1 day until any number of days/weeks/months you prefer. Of course, it is wise to not to keep the date for too much time, as this will affect the size of the BizTalk360 database.
After the time frame expired, BizTalk360 will automatically delete the expired reports.
Monitor the results of BHM runs
Besides running and viewing the output of BHM, you can also setup monitoring on the output. This way you can get notified easily of critical and non-critical errors which might be found by BHM.
In another article of the `Why we built XYZ feature in BizTalk360` series, we`ll explain monitoring of BHM output in more detail.
Conclusion
By executing BizTalk Health Monitor runs, the tool reports about important topics on all kind of health and best practice related stuff. Having MBV/BHM integration in BizTalk360, the product makes it easier to schedule runs of BHM and provides you with easy access to the output of the BHM.
Get started with a Free Trial today!
Do you prefer to setup your BHM schedules and view BHM output in BizTalk360, instead of setting up RDP connections to your BizTalk server? Why not give BizTalk360 a try! Installation takes about 10 minutes on your BizTalk environment. Get started with the free 30 days trial.
Author: Lex Hegt
Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt
by Lex Hegt | Apr 24, 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”.
Why do we need this feature?
Being able to track messages and processes in middleware software like BizTalk Server can be used for few reasons, amongst them are:
- be sure all processes run like expected
- analysis of issues
- debugging during development/test phase
However, especially for live environments, the best practice is that only limited tracking should be turned on, to prevent a performance penalty. Therefore, there needs to be a balance between the amount of tracking which is turned on and the ability for the BizTalk administrator to be able to do his job when it comes to analysis of issues.
In general, when no message context/content tracking is turned on and only the default tracking is switched on, you should be good.
To prevent performance penalties, it is obvious that it helps to have a good overview of all the tracking settings of the BizTalk environment.
What are the current challenges?
All BizTalk Server related tracking settings can be maintained in the BizTalk Server Administration console. However, the tracking settings are found in different parts of the console. For example:
- the Group Level Tracking property is found in the BizTalk Group Settings Dashboard
- the BizTalk artifact settings are found at application/artifact level
- Each artifact like (receive ports, send ports, orchestrations, pipelines etc) all come with their own UI to manage tracking.
This results in not having a good overview and easy maintenance of the tracking settings with the standard BizTalk Server Administration console.
How BizTalk360 solves this problem?
At BizTalk360 we decided to design one screen, which can be used for all tracking settings, enabling to have a good overview of all the tracking settings, meanwhile working as a central hub to configure all these settings.
We came up with the Tracking Manager screen, which can be found in BizTalk360 under Operations / Infrastructure setting.
As you can see from the screen, it contains an overview of all tracking settings. On a high level, the screen is divided into two parts:
- Quick actions
- Applications and Rules
The Quick actions allow you to easily turn on/off tracking on a global level for the BizTalk artifact types, but also to turn on/off group level tracking.
The second part of the screen allows you to view/configure tracking until the application level. If a more fine-grained configuration is needed, you can simply click on the application and set the desired tracking for one or multiple artifacts at once. The overall result of the settings will be reflected in above screen.
Also, maybe less familiar, Business Rules can be tracked. BizTalk360 enables you to easily configure these settings from the Rules tab page.
All in all, we can conclude that the Tracking Manager in BizTalk360 gives easy access and maintenance to all the tracking settings for BizTalk Administrators.
Get started with a Free Trial today!
Download and try BizTalk360 on your own environments free for 30 days. The installation will not take more than 5-10 minutes.
Author: Lex Hegt
Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt
by Lex Hegt | Apr 18, 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“.
Why do we need this feature?
Microsoft BizTalk Server is a powerful middleware product which allows integrating all kind of information systems, independent of whether these systems are on-premise or in the cloud. BizTalk Server uses Receive and Send ports to communicate with a broad set of on-premise/cloud systems, both on the technology level (FILE, FTP, POP3, SMTP, etc.) as on the business level (ERP, CRM, etc.).
Besides just receiving and transmitting messages, BizTalk solutions might also contain Orchestrations, which can process all kind of business logic, for example, Order processing, Credit card validation, Claims processing etc.
As BizTalk Server is very scalable, a BizTalk environment can contain many deployments for all kind of different integrations. All together a BizTalk environment may contain hundreds of ports and orchestrations. The well-being of these artifacts is of vital importance to have the integrations working properly. When not running properly, these interruptions may cause serious damage to the business processes they support.
What are the current challenges?
To be well aware of the state of the BizTalk artifacts, the BizTalk administrator needs to consult the BizTalk Administration console multiple times per day. However, there are few challenges when depending on the BizTalk Administration console for checking the state of these artifacts.
Access to the Administration console – Often, the BizTalk Administration console is only installed on the BizTalk servers. Besides that there is the risk of unintended damaging the BizTalk server while accessing the server, you need to be authorized to access the servers. Not to be forgotten, is the fact that it constantly takes time to setup Remote Desktop connections to access the BizTalk server and the Administration console. Time which can easily be used for something more tangible.
Not suited for less experienced administrators – The Administration console is such a powerful tool, which is great when you are an experienced BizTalk Administrator. However, in the hands of less experienced administrators, unintentionally a lot of damage can be done. Think of for example stopping ports or terminating processes!
Not an efficient way of monitoring – Checking the state of the ports and orchestrations manually, multiple times per day, is just not efficient. It can easily be forgotten in the rush of the day, thereby putting the wellbeing of your integrations at stake.
Too many artifacts to monitor efficiently – BizTalk environments can contain hundreds of ports and orchestrations. In most scenarios, the artifacts should be in the Enabled/Started state. But there can be several reasons why certain artifacts are not in the expected state. Just to mention a few:
- After the deployment of an update of a BizTalk application the artifacts are in a wrong state
- Due to a temporary maintenance window, some of the artifacts need not be in the Enabled/Started state, to prevent suspended instances
- Artifacts might be Disabled as a result of a temporary outage
- Certain artifacts need only be Enabled/Started as a fall back scenario
By the given examples, it must be clear, that it can be very challenging to constantly be aware of the desired state of all the artifacts. This makes it hard to manually monitor the state of the artifacts in an efficient way.
Instead of having to monitor BizTalk manually, it is much more efficient to have automated, state-bound, artifact monitoring. Automated BizTalk monitoring will prevent you of constantly having to check for the state manually, enabling you to spend your time on more important activities. In the next section, we’ll show which features BizTalk360 has, to allow you to automatically monitor your BizTalk artifacts.
How BizTalk360 solves this problem?
To give you that comforting feeling that you are in control over the state of your ports and orchestrations, BizTalk360 provides multiple features.
Threshold Monitoring – While using the concept of Threshold Monitoring, BizTalk360 allows you to setup state-bound monitoring. This means that you can easily setup monitoring to have the product check for the Expected state of your ports and orchestrations.
In above screenshot, you can see how some Send Ports are being monitored against their Expected State. Once, the Current State deviates from the Expected State, a threshold violation has occurred and BizTalk360 will notify you of that fact.
Positive and Negative monitoring – In most scenarios, the Expected State of your Ports and Orchestrations will be Enabled/Started; which is called Positive Monitoring. However, there might be valid reasons that certain ports/orchestrations need NOT be Enabled/Started. Setting up that kind of monitoring is called Negative Monitoring. BizTalk360 allows to setup for both Positive and negative Monitoring.
Receiving Notifications via multiple channels – Once a threshold violation has occurred, by default, you will receive notifications by email. Moving forward, BizTalk360 also allows you to receive notifications via multiple other channels.
We are constantly considering new ways to send notifications, but currently, the following Notification Channels are provided out-of-the-box: Email, SMS, Event Log, Slack, Microsoft Teams, ServiceNow, HP Operations Manager, Webhook. In addition, you can build your own custom notification channel like writing to a database, calling an internal system etc.
Auto Correct – BizTalk360 not just monitors your artifacts, it can also try to bring the artifacts back to their Expected state, once there is a mismatch between the Current State and the Expected State. Think of for example that FTP Receive Location which goes down at night or during the weekend.
The Auto-Correct feature works for the following artifacts:
- Receive Locations
- Orchestrations
- Send Ports
- BizTalk Host Instances
- Windows NT Services
- SQL Server Agent Jobs
- Azure Logic Apps
There is an extensive article on BizTalk360 Auto correct, which also explains in which kind of scenarios this feature comes at hand. You can that article here:
Monitoring Dashboard – Although receiving notifications of any mismatches between the Current State and the Expected State is very handy, it will equally be handy to have a large screen, at for example the Support Desk, which simply shows the current health of your artifacts. For this, we bring the Monitoring Dashboard, which does exactly that.
As you can see from below screenshot, it brings you a nice Expandable/Collapsible and filterable treeview, with automatic refresh, thereby constantly showing the current state of the artifacts.
Health Check Reports – Last but not least, are the Health Check Reports you can receive at your convenient timing. These reports function as your daily health check, providing you with an overview of the state of all the artifacts from your alarm. Very handy to receive for example at the beginning of your working day!
Conclusion
In this article, we have seen why being aware of the state of your ports and orchestrations is important. We have also seen why manually monitoring that state is very inefficient and sometimes very complex. As a company which knows these challenges from our own experiences, we have brought multiple features which will help the BizTalk administrator being in control, without having to manually check the state.
Get started with a Free Trial today!
Download and try BizTalk360 on your own environments free for 30 days. The installation will not take more than 5-10 minutes.
Author: Lex Hegt
Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt
by Lex Hegt | Apr 11, 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”.
Why do we need this feature?
In the day to day activities of a BizTalk administrator, you might come across integrations where FTP sites are used for receiving and transmitting messages. FTP sites are often used for cross-platform integrations. For example, when you have an SAP system on Unix that has to be integrated, via BizTalk Server, with other systems, you might use FTP for receiving and transmitting of messages.
SFTP & FTPS are just the secured version of FTP with advanced transport encryption mechanisms, so your end-to-end data transmission is secure and safe.
To keep the business process going, it can be of vital importance that the FTP/SFTP sites are online and the messages are being picked up. So, when a BizTalk administrator needs to be constantly aware whether the FTP/SFTP sites are online and working properly, the administrator needs to monitor the sites and the activities which take place on these sites.
What are the current challenges?
BizTalk Server offers no monitoring capabilities, not for Receive Locations / Send Ports and also not for endpoints like FTP, SFTP and FTPS sites. So, using just the out-of-the-box features of BizTalk Server, a BizTalk administrator will have to manually check whether the FTP sites are online and whether all (appropriate) files are being picked up for further processing.
Manual monitoring
This kind of manual monitoring can be quite cumbersome and time-consuming. The administrator will probably use multiple pieces of software to be able to perform these tasks. Think of for example the BizTalk Administration console to check whether the Receive Locations/Send Ports are up and some FTP client to check whether files are being picked up.
It is obvious that this is not a very efficient scenario, which could easily be automated by setting up monitoring.
Maintaining scripts for monitoring FTP sites
To reduce their workload, we experience that BizTalk administrators are creating their own scripts to monitor FTP sites and all kind of other resources. Although this kind of scripts certainly can be of help, we still think this does not fully solve the problem.
For example, often these kinds of scripts need maintenance when FTP sites need to be added, changed or deleted from monitoring. This kind of tasks can be easily forgotten.
Also from a knowledge transfer perspective, it’s easy to forget to update new colleagues about the existence of this kind of scripts, as they will probably be installed on some (monitoring) server.
Another challenge with solving this kind of problems with scripts is that not each administrator is capable to write this kind of scripts, which makes knowledge transfer even harder.
To keep the overview, we think that it is easier to use software, like BizTalk360, to have everything in one easily accessible place, with good visibility of all the features/capabilities, fine-grained security/auditing and without the need to maintain custom scripts etc..
How BizTalk360 solves this problem?
With BizTalk360, we make monitoring of FTP/SFTP/FTPS sites a lot easier. For a very long time, the product offers monitoring of Receive Locations and Send Ports, but for some time now, BizTalk360 also offers to monitor of the physical FTP/SFTP/FTPS endpoints.
We wanted to make setting up this kind of endpoint monitoring as seamless as possible and therefore we simply show all the ports in the current BizTalk group which make use of the FTP/SFTP/FTPS adapter.
In BizTalk360, you can find FTP monitoring under Monitoring => Manage Mapping => File Locations (File, FTP, SFTP).
Next, you can set up monitoring rules based on File Count and Directory Size and have BizTalk360 send Warning or Error notifications through the notification channels which are configured on the associated alarm.
A fully monitored FTP endpoint might look like shown below.
Of course, besides the greater-than-or-equals operator, also other common operators are available.
Conclusion
As a final point, we see from time to time that administration teams maintain a administrators handbook, which contains all the tasks a (BizTalk) administrator should take care of. We think that by using software like BizTalk360, we can reduce the number of pages in such handbooks, as the kind of scripts we mentioned no more have to be described in that kind of books.
This description could be replaced by, for example, a general guideline on how FTP sites should become monitored and the monitoring rules with BizTalk360.
As a result, we hope to make the work of BizTalk administrators a bit easier so the team can focus on the more exciting parts of the job of BizTalk administrators, instead of constantly having to update their handbooks.
So, we think that we make the day to day life of a BizTalk administrator, who needs to monitor the well-being of FTP sites, a little bit easier by bringing this feature.
If you want to read more on FTP/SFTP monitoring in much more detail, you can check the following article:
FTP, FTPS, SFTP Location monitoring
BizTalk360 also offers an advanced monitoring capability called “Data Monitoring” which allows monitoring the traffic/volume of messages going through the ports for a given period, ex: expected 50 PO orders from our partner via FTP/SFTP. Please check out this article. Introducing BizTalk Server Data Monitoring in BizTalk360
Get started with a Free Trial today!
Download and try BizTalk360 on your own environments free for 30 days. Installation will not take more than 5-10 minutes.
Author: Lex Hegt
Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt
by Lex Hegt | Apr 4, 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?
On a daily base, our customers use BizTalk360 for a lot of their activities related to BizTalk operations and monitoring. However, in a number of scenarios, BizTalk administrators are faced with activities which need to be automated, for example: during the deployment of BizTalk Applications. It is easy to forget some tasks and doing them manually can be error-prone. So, it may be better to address such challenges in an automated way.
Here are some example automation scenarios in that can happen in your BizTalk Server environment
BizTalk Server Operations
- You might want to automatically stop certain Ports over the weekend, because of regular or temporary maintenance of internal or external systems
- External systems, like portals, might need BizTalk data/metrics on a regular basis, like information around EDI transactions, BizTalk usage or BizTalk performance metrics
- You want particular users to have easy access to download links for the messages of suspended instances, without having to give them access to BizTalk Server and/or BizTalk360
- You may want to Deploy/Publish a Business Rule Policy at a particular moment (additional discounts for the holiday season or laws to which should be complied as of a particular moment)
BizTalk Applications Maintenance and Deployment
- Before or after deployment of BizTalk Applications, you may want to automatically stop and start Host Instances
- After a deployment, you may want to set certain ports/orchestrations to a particular state
- You want to bring BizTalk down at a given date and time, due to system maintenance
Identity and Access Management
- Your organisation uses tooling for Identity and Access Management and you want to automatically create User Access Policies for accessing BizTalk360 and BizTalk
- For auditing purposes, you need to provide user lists and profiles and audit information on a regular bases
Because of the nature of this kind of scenarios, the administrators would need programmatically access to BizTalk server and rely on command files or PowerShell scripts to be able to fulfil the requirements.
What are the current options and challenges?
BizTalk Server comes with different tooling for programmatic access to BizTalk Server. This tooling is described below.
WMI and ExplorerOM
Let’s briefly discuss the purpose of both WMI and ExplorerOM:
- WMI (Windows Management Instrumentation) – an infrastructure, which comes with Windows, and which allows you to automate administrative tasks on (remote) computers. BizTalk Server comes with its own WMI management pack to do preliminary management activities like starting/stopping host instances, restarting ports etc.
- ExplorerOM – a DLL used to perform all kind of BizTalk Application related tasks like exploring the schemas, maps, orchestrations, operating on them like starting/stopping etc.
BizTalk PowerShell Provider
There is also a community initiative to provide a BizTalk PowerShell provider so you can execute some of the management tasks using PowerShell (since PS has become the core of any automated administrative tasks). However, the project is not actively maintained anymore and it’s not advisable to rely on this for any critical usage.
BizTalk Server 2016 Feature Packs
Starting with BizTalk Server 2016, Microsoft started to release Feature Packs. With the first Feature Pack (BizTalk Server 2016 Feature Pack 1). a unified API became available for BizTalk Server 2016 (not for earlier versions).
This Management API enables you to perform some of the scenarios which we mentioned in the first paragraph but still lacks API’s to do extensive automation. For example, stop and start host instances.
So, although BizTalk Server comes with multiple capabilities for programmatic access to BizTalk Server, writing and testing all kind of scripts is time-consuming and not all scenarios can be covered.
Even when these custom scripts seem to work nicely, non-functional requirements, like security, auditing and logging, are not taken into account in these kinds of scripts. This would leave you in the dark when something unexpected happens. Definitely, not a scenario where you want to be.
How BizTalk360 solves this problem?
BizTalk360 consists of multiple components, a responsive user interface, few backend services and a rich API service layer.
The API service layer consists of over 400 REST API operations. The user interface of BizTalk360 uses these extremely rich API’s to perform all the tasks to manage the BizTalk environment.
A couple of years ago, we thought, exposing our API’s will hugely help BizTalk Server Administrators to automate most of their routine activities we mentioned in the beginning. Hence we documented all the BizTalk360 API’s (which are of course the management and monitoring API’s for your BizTalk Environment) using swagger and live test within the BizTalk360 application.
The API currently contains 14 services with more than 400 API operations, covering a breath of management activities you can do on your BizTalk Environment. To give you a better understanding of the capabilities, these services are:
- ActivityMonitoringService – BAM related services
- BizTalkQueryService – Execute all kind of MessageBox and Tracking oriented queries
- AlertService – All kind of Monitoring related API’s
- BizTalkGroupService – BizTalk Platform oriented API’s
- SchedulerService – Data Monitoring Scheduler related API’s
- ESBManagementService – Exception Management related API’s
- AdvancedEventViewerService – API’s to query the Eventlog entries which are collected by the Advanced Event Viewer feature
- BizTalkApplicationService – Search for and action on BizTalk Application artifacts
- AdminService – Get and maintain all kind of settings within BizTalk360
- EDIManagementService – Get/Set EDI configuration and get EDI statistics
- EnvironmentMgmtService – API’s mainly for Knowledge Base and Dashboard management
- RulesEngineService – API’s for maintenance of Business Rules
- AnalyticsDataService – Analytics, Message Patterns and Throttling related API’s
- AzureService – Get/Operate on Logic Apps and get Integration Account artifacts
With the API you cannot just retrieve information from BizTalk via GET operations, but you can also action on BizTalk Server, BizTalk360 and even certain Azure services via POST operations.
Each API can be tried from the API documentation, which comes with a Swagger definition file, by using the Try it out! feature. This helps you testing with the required parameters. All you need to do is to choose the needed API, provide the needed parameters for the API, click the Try it out! button and view the results.
Let’s have a look at few examples of how you could make use of the API.
- Stop and start Host instances before and after deployment of BizTalk applications
- Disable/Enable Receive Locations and/or Stop/Start Orchestrations/Send Ports
- Get a list of currently deployed BizTalk Applications for Support purposes
- Get Event Log data of all the BizTalk servers in one go
- Get Throttling data from the BizTalk Hosts
- Get all kind of Performance metrics of your BizTalk system
- Test, Deploy, Undeploy and Publish Business Rules
- Disable/Enable BizTalk360 alarms during deployments
- Show data in an Operations Dashboard widget, for example, the state of your SQL jobs
- Automatically create BizTalk360 alarms during deployment of BizTalk applications
Conclusion
By using the BizTalk360 API and its documentation, the complexity from WMI and ExplorerOM is shielded from the user. Besides being able to act on BizTalk, the API also allows you to action on BizTalk360. You can even show the output of API calls in the Operations Dashboard!
Few examples of how the BizTalk360 API`s can be used in real-world scenarios: Automate Monitoring Alarm creation in BizTalk360
If you are using BTDF (BizTalk Deployment Framework) we have a wrapper console application called BT360Deploy that can be used to automate certain tasks like creating monitoring alerts during deployment. The project can be accessed here.
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 expose all of our BizTalk Operations and Management REST API’s? appeared first on BizTalk360.
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 Lex Hegt | Feb 7, 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?
Azure API Apps is a modern way of building web services hosted in Microsoft Azure. Out of the box it provides capabilities such as security, load balancing, auto-scaling, and automated management. You can also take advantage of its DevOps capabilities such as continuous deployment from VSTS, GitHub, Docker Hub, and other sources, package management, staging environments, custom domain, and SSL certificates.
In the context of Azure Logic Apps connectors, Azure API Apps plays a vital role. Sometimes there may not be an out of the box connector to an external system and you may need to wrap a web service on top of that external system to create a custom Azure Logic Apps connector. This article explains how you can easily Create a custom connector for a web API.
The Azure API App can contain multiple endpoints to be able to perform multiple actions like creating an order or requesting the status of an order.
The Azure API Apps are powerful building blocks for your hybrid integration scenarios. As these API Apps can be of critical importance, you should be well aware of the status of these API Apps.
What are the current challenges?
We have already seen why Azure API Apps are important building blocks and can be of vital importance for your integration scenarios. So, whether you are consuming the external Azure API Apps from other parties or you are exposing your own API Apps, depending on the importance of the Azure API App, it is equally important to constantly be aware of the state of the Azure API Apps and their endpoints.
The main challenge at the moment is the management and monitoring of Azure API Apps in isolation via the Azure Portal. You’ll miss the end to end context of the importance of the API App in your integration scenario.
For example, you might have an order processing system that uses few BizTalk Receive Locations, Orchestrations, Send Ports and few Azure API Apps connected via BizTalk WCF-REST/HTTP adapters and are part of the same end-to-end solution. If the Azure API App is down or returning errors, then your end-to-end purchase order solution is broken. It’s important to monitor the API Apps and understand the end to end context.
We address this challenge in BizTalk360 by providing a unified platform to monitor and manage both BizTalk artifacts and some of the key Azure artifacts which are important from the integration point of view.
How BizTalk360 solves this problem?
Depending on whether you want to monitor your own Azure API Apps or the API Apps which are exposed by others, BizTalk360 offers multiple methods to setup monitoring. This is due to the fact that to be able to monitor whether API Apps are enabled, you need access to the Azure subscription which contains these API Apps. In case of API Apps which are exposed by others, you won’t have access to that Azure subscription, so you’ll only be able to monitor the HTTP Endpoints of the API Apps.
To monitor API Apps from within BizTalk360, the product offers the following features:
- Azure API App of others – Web Endpoint monitoring
- Your own Azure API Apps – Azure API App monitoring
Web Endpoint Monitoring
If you are simply consuming the Azure API Apps from external parties, then they are not any different from a standard REST/HTTP web services. In this case, the BizTalk360 web endpoints monitoring solution will be sufficient. The features and capabilities of BizTalk360 Web Endpoint monitoring are described in the Why did we build Web Endpoints Monitoring in BizTalk360? article.
Azure API Apps Monitoring
If you are owning the Azure API Apps, then BizTalk360 provides a rich set of capabilities to monitor the Azure API Apps like auto-discovery of multiple endpoints and granular control on monitoring setup.
Monitoring API Apps from BizTalk360 consists of the following types of monitoring:
- State Monitoring – monitor whether the API Apps are Enabled/Disabled
- Endpoint Monitoring – monitor if the HTTP Endpoints of the API App are accessible
State Monitoring API Apps
From BizTalk360, you can monitor the state of API Apps. An API App can have the following 2 states:
- Enabled – the API App is active and can receive requests
- Disabled – the API App is disabled and cannot receive requests
With BizTalk360, you can monitor for both states and of course, we want to provide a monitoring experience which as seamless as possible. After you have selected the correct alarm and Azure subscription, it is just a matter of selecting the Azure API Apps and select the required expected state from the drop-down box. Once that’s done, BizTalk360 immediately starts to monitor the API App(s).
Endpoint Monitoring
Azure API Apps basically are REST services which use JSON for data exchange. These REST services are the actual endpoints of the API Apps, which can be called by other systems. Each Azure API App has at least one endpoint but can contain many more endpoints.
BizTalk360 has a quite extended feature set for Web Endpoint Monitoring, and it comes with advanced capabilities like adding custom GET parameters and HTTP headers:
- Custom GET parameters – provide required/optional parameters
- HTTP headers – provide additional HTTP headers (for example for authorization)
When the Endpoint sends a response, you can perform multiple checks to find out whether the Endpoint is in good health. You can check, for example:
- HTTP Return codes – like HTTP 200 must exist, else throw warning/error
- Existing and Non Existing keywords – like ‘success’ must exist in the response message
- Response times – if it takes longer than, say, 5 seconds before the response is received, something might be wrong
HTTP Return codes
You can add multiple monitoring rules for HTTP return codes. This allows you to check for the existence, but also the non-existence of certain HTTP return codes. Besides that, you can also determine whether a Warning or an Error will have to be thrown in case the monitoring rules have not been met.
Existing and Non-Existing keywords
This is a very strong capability, as it allows you to check whether certain keywords exist or do not exist. As the response message might be in different formats, BizTalk360 allows you to check for the following formats and throw a Warning/Error based on the outcome of the monitoring rule:
- Plain Text – search for keywords which should/should not exist
- XML – enter an XPath query and the expected value which should/should not exist
- JSON – enter an XPath query and the expected value which should/should not exist
For each format, you can search for just one keyword or multiple keywords to (not) exist.
Response times
Bad response times of endpoints might indicate that the endpoints (or the system/service behind it) are under stress. So monitoring on response times helps you to be aware of such situations.
As all of the above mentioned checks can be combined with each other, this provides very strong monitoring capabilities.
Multiple Azure Subscriptions
You might have multiple Azure subscriptions which contain different Azure API Apps. You can register all the relevant subscription and attach them to corresponding BizTalk Server environments within BizTalk360. This provides a seamless management/monitoring experience.
Conclusion
With Azure API Apps monitoring, we make it easy to constantly be aware of the well-being of your API Apps, without having to check that yourself manually. Besides monitoring whether the Azure API App is Enabled, we bring strong features for monitoring the actual HTTP endpoints.
You can read more about Azure API App monitoring and the other Azure services for which BizTalk360 provides support.
Get started with a Free Trial today!
If you want to monitor your Azure API Apps or have other BizTalk Monitoring related challenges, why not give BizTalk360 a try! It takes about 10 minutes to install on your BizTalk environments and you can witness and check the security and productivity of your own BizTalk Environments. Get started with the free 30 days trial.
Author: Lex Hegt
Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt
by Lex Hegt | Feb 6, 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?
Traditionally, a lot of system integration happened on-premise. When integration with partners or external systems was the need of the hour, this was achieved using SOAP/REST/HTTP/FTP/SFTP etc.
With the rise and adaption of cloud technologies like Amazon AWS and Microsoft Azure, cloud solutions became more and more capable to support scenarios where on-premise systems needed to interface to the on-premise systems of your partner(s) or with SaaS solutions like Office365 and SalesForce.
Microsoft is positioning Azure Logic Apps as the integration platform in the cloud mainly for connecting SaaS based solutions like Dynamics 365, Salesforce, ServiceNow, Workday etc.
Since the introduction of the Azure Logic Apps adapter for BizTalk Server 2016 and Azure Gateway, it is possible to integrate your on-premise systems via BizTalk Server with Azure Logic Apps seamlessly. This opens up great possibilities — it opens up some 300+ SaaS connectors that are available to Azure Logic Apps that can be utilized from BizTalk Server. Also, vice versa you can make the 100’s of external SaaS systems to talk to your on-premise BizTalk Server.
So it becomes very important to have a management/monitoring platform that’s capable of supporting both on-premise BizTalk Server and Azure Logic Apps from a single place.
What are the current challenges?
Azure Logic Apps provide a great way to extend your integration scenarios and capabilities to the cloud. However, from an operational and monitoring perspective, the Azure Portal is yet another portal the BizTalk Administrators need to be aware of and fit in their daily tasks.
So, besides their on-premises oriented BizTalk Server monitoring, organizations now also need to monitor their Hybrid solutions (which involve Azure Logic Apps) as events might occur they want to know about.
Think of, for example, somebody could have disabled your Azure Logic App (that’s part of your end-to-end integration scenario), which prevents the Azure Logic Apps from being executed. Also, executions of the Azure Logic Apps might fail or run very slow, indicating that some other system might be under stress.
As it would take too much time to regularly check this kind of scenarios to take place, an administrator just wants to be informed automatically when these kind of events occur. You can use some of the monitoring features of Azure Portal, but you’ll not get the end to end visibility and it will operate on silo without giving the full context.
How BizTalk360 solves this problem?
At BizTalk360, we are closely following the trends in the integration landscape. We can clearly spot the necessity of using Azure Logic Apps in enterprise integration scenario along with BizTalk Server.
Because of this, we brought the support for Azure Logic Apps with BizTalk360. In addition to Azure Logic Apps, we also support other relevant integration technologies in Azure like Azure Service Bus, Azure API Apps and Azure Integration Account with BizTalk360.
In this article, we will just focus on how you can monitor your Azure Logic Apps from BizTalk360. Azure Logic Apps Monitoring with BizTalk360 consists of the following two parts:
- State Monitoring – Monitor whether the Logic Apps are in the expected state
- Data Monitoring – Monitor whether the executions of Logic Apps take place as expected
State Monitoring of Logic Apps
A Logic App can have the following two states:
- Enabled – an instance of the Logic App can be started by means of a trigger
- Disabled – the Logic App cannot be instantiated by means of a trigger
Azure Logic Apps monitoring with BizTalk360 consists of checking whether the state of a Logic App reflects the Expected state. In most cases, a Logic App will have to be in the Enabled state, but there might be scenarios where you want to monitor for the Logic App to be in the Disabled state, which is often referred to as Negative Monitoring. BizTalk360 allows you to monitor for both states.
Auto Correct
BizTalk360 has developed the Auto Correct feature for state-bound artifact monitoring. The feature allows you to let BizTalk360 try to bring the state bound artifact back to the expected state, once the artifact gets into the undesired state. This feature exists for the following artifact types:
- Receive Locations, Orchestrations and Send Ports
- Host Instances
- Windows NT Services
- SQL Server jobs
- Logic Apps
As you can see from the list above, Azure Logic Apps monitoring can be decorated with Auto Correct. In case the Azure Logic App can’t be get back to the expected state, BizTalk360 will try to bring it to the desired state. You can also configure a maximum number of retries in the BizTalk360 portal. This is to prevent BizTalk360 to constantly keep on trying to bring the Azure Logic App back to the expected state, in case of some problem.
Multiple Azure Subscriptions
You might have multiple Azure subscriptions which contain different Azure Logic Apps. You can register all the relevant subscription and attach them to corresponding BizTalk Server environments within BizTalk360. This provides a seamless management/monitoring experience.
Data Monitoring of Logic Apps
With Data Monitoring of Azure Logic Apps, you can monitor for example whether:
- expected number of runs are met in a certain time frame
- a number of failures occur during a certain time frame
- number of billable trigger executions in a certain time frame
The above scenarios are just an example – there are many more combinations.
Data Monitoring of Logic Apps will be discussed in more detail in another article, but here we just wanted to reveal a bit of that feature.
Conclusion
With the rise of Hybrid integration solutions, the job of BizTalk administrators has extended to the (Azure) cloud. BizTalk360 helps these administrators by providing operational and monitoring support for a number of Azure services, thereby taking away the need to constantly have to check the Azure portal to be aware of the health of these services.
In this article, we discussed the state monitoring capability of Azure Logic Apps. If you want to read more about the other Azure services BizTalk360 supports, just follow the articles in the Why did we built series.
You can read more on setting up Azure Logic Apps monitoring on our Documentation portal.
Try BizTalk360 Free for 30 days today!
Download and try BizTalk360 on your own environments free for 30 days. Installation will not take more than 5-10 minutes.
Author: Lex Hegt
Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt
by Lex Hegt | Feb 5, 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?
As you will probably be aware of, BizTalk Server heavily relies on SQL Server databases for storing, for example, the configuration of BizTalk artifacts and the state of in-flight and completed processes. After installing and configuring BizTalk Server, few databases are created. The most important databases are the Configuration database, the MessageBox database and the Tracking database, but depending on the configured features, other databases might be created for BAM, BRE and SSO.
Further, there are a number of SQL jobs that gets created when you install and configure BizTalk Server. These SQL jobs are maintenance jobs and are of vital importance for the health of the BizTalk Server environment. The BizTalk SQL Jobs take care of making backups of the BizTalk databases, transfer tracking data from the MessageBox database to the Tracking database and all kind of cleaning up data from the databases.
Without having these jobs enabled (in cases disabled, not all the jobs are supposed to run) and properly running, it is just a matter of time, before you will get into trouble. This kind of trouble might lead to interruptions of the business process(es) which are being processed through BizTalk. For that reason, it is important to be aware of the (health) status of the SQL Jobs.
What are the current challenges?
There are two basic challenges at the moment with the current default tooling.
- There is no out of the box support for monitoring SQL Jobs and keeping an eye on the health
- Accessing SQL jobs for viewing, changing state, etc requires access to SQL Server
Although for experienced BizTalk administrators, it is obvious that they need to be well aware of the health of their BizTalk databases, for organizations with less experience on administrating BizTalk, this might come as a surprise.
We have seen that BizTalk administrators did not have access or insufficient access to the SQL Server management tools. This could especially be true, in case BizTalk Server has to share its SQL Server instance with databases of other systems, which is not a good idea anyway.
Even if the administrator has access to the SQL Management tools, having to manually monitor these SQL jobs is a time consuming and adds up to all the other assignments of the BizTalk administrator.
How BizTalk360 solves this problem?
As we, at BizTalk360, understand the importance of the SQL jobs, we brought both operational and monitoring features related to these jobs. In this section, we will discuss the Monitoring features.
BizTalk360 allows you to set up monitoring on SQL jobs seamlessly. You need to simply register the name of the SQL Server instances where your SQL jobs are running via the Settings -> Monitoring -> SQL Server Instances and all the SQL jobs will be ready for monitoring configuration.
Once configured, BizTalk360 enables you to achieve the following:
- Monitor the Expected Job State (both enabled and disabled)
- Configure Auto-correct
- Monitor the Expected Last Job Run State
Below, all these capabilities will be discussed.
Monitor the Expected Job State
With this kind of monitoring, you can check whether the SQL job is in the correct state. In most cases, the expected state will be Enabled, but in certain cases, the expected state must be Disabled. BizTalk360 allows you to monitor for both states.
The possibility of negative monitoring comes in handy for BizTalk Server, as the MessageBox_Message_Cleanup_BizTalkMsgBoxDb jobs need to be in disabled state. This job works like a stored procedure and used internally by other jobs. It should not be manually started by a DBA or BizTalk Administrator.
Configure Auto-Correct
The Auto-Correct feature is an extension of Expected State Monitoring. Basically, it allows you to bring State-bound artifacts back to the expected state after they reached the wrong state.
Auto-correction works 2 ways. If an artifact, say a SQL Job, is expected to be in the Enabled state but reached the Disabled state, the Auto-Correct feature will try to bring the SQL job back to the Enabled state.
However, when a SQL job is expected to be in the Disabled state (like the MessageBox_Message_Cleanup_BizTalkMsgBoxDb job) but got Enabled, the Auto-Correct feature will try to bring the job back to the Disabled state.
This helps to maintain the state of the SQL jobs in the desired state even if there is a human error.
This feature works not just for SQL Server jobs, but also for:
- Receive Locations, Orchestrations and Send Ports
- Host Instances
- Windows NT Services
- Azure Logic Apps
Monitor the Expected Last Job Run State
This allows you to check whether the job runs successfully. Once you have setup monitoring for Expected Last Run state, you will be notified in case the Last Run State was unsuccessful.
Conclusion
By bringing SQL job monitoring, including the auto-correct feature, we think that this will make the life of both BizTalk administrators and SQL Server DBA’s a bit easier.
If you want to read more about SQL job monitoring, please read this article.
Get started with a Free Trial today!
If you are struggling with all the above-mentioned challenges, why not give BizTalk360 a try. It takes about 10 minutes to install on your BizTalk environments and you can witness and check the security and productivity of your own BizTalk Environments. Get started with the free 30 days trial.
Author: Lex Hegt
Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360. View all posts by Lex Hegt
