Our customer base is increasing and we constantly receive this question. This article explains all the known best practices for BizTalk360 we have learned from various customer engagements.
Deployment Options:
First let us take quick look at the deployment options you have for BizTalk360. We support 2 main types of deployment as shown in the below pictures.
Option 1 : You basically install BizTalk360 on one of your existing BizTalk servers (either production, or QA) and you can add multiple remote environments. This is very straight forward setup, since all the required prerequisites will be present in the server.
Option 2: You install BizTalk360 on a completely standalone server and you can point to remote BizTalk environments. Some customers prefer to do it this way, since there is no foot print of BizTalk360 in any of their BizTalk environments. The complete installation steps can be found here
BizTalk360 Standalone Installation
Option 3: You can also install multiple versions of BizTalk360 in your organisation, cover each environment separately. We support this as well and we do not charge any additional cost for this setup.
#1. Do not configure all your BizTalk environments in single BizTalk360 Installation
This is one of the common problems we have seen, customers install BizTalk360 on a single dedicated server and configure all the environments in this single installation. There are couple of problems with this approach.
First Issue: BizTalk360 is an agentless architecture, there is only one monitoring service running for all the configured environments. So having all the environments in one single configuration just puts lot of load in the monitoring service.
Second Issue: If you have any issues with BizTalk360, it makes it so difficult to diagnose the issue, since it effects lot of environments.
The recommendation from us is, have one installation for your PROD+DR, one installation for QA environments. If you have lot of QA environments, add more installations and split them logically. It’s something similar to your host/host instance configuration, you just need to strike a balance.
#2. Cluster the BizTalk360 database
BizTalk360 holds the following data in the database
- All the configuration settings (supers users, user access policy, Message Box, Alert configuration, etc. etc.)
- Governance/Auditing data
- Event log collection
- Throttling counter data collection
- Monitoring collection (for dashboard)
- Plus few additional things like alert history, environment settings etc..
For healthy functioning of BizTalk360, it’s vital the database is available all the time. So make sure you place the BizTalk360 database in a clustered SQL instance for at least your BizTalk Production environment.
#3. Configure BizTalk360 monitoring service as highly available
BizTalk360 monitoring service is one single service that is responsible for various things. Internally there are various sub-services inside the monitoring service, each can be controlled separately (started/stopped, different polling interval etc.) via the UI.
- Create Alert Service
- Send Alert Service (Email)
- Send External Alert Service (SMS, HP Operation Manager)
- Event log Collector
- Throttling Collector
- Purge Controller
- Message Box Viewer Collector
Since there are no agents installed anywhere, health of this monitoring service is crucial to the over all health of BizTalk360. The easiest way to make this highly available is, install the monitoring service in two servers and cluster it using Microsoft cluster service in Active/Passive mode. Only one instance of the service can be active at any one time. Having multiple instances running simultaneously will interfere with the internal logic.
Note: In the pipeline we have plans to have automatic HA configuration in the future.
#4. Avoid having too many super users
One of the main objective of using a tool like BizTalk360 is to avoid too many people having too much power in your BizTalk environments. Our recommendation to customers is to allow 90% of your support staff use BizTalk360 with defined user access policies and allow 10% to have super user rights and access to BizTalk Administration Console. Ex: If you are team of 10, just two persons should have super user rights.
#5. Schedule Message Box Viewer to run at least once a week per environment
Message Box Viewer is incredible tool from Microsoft, it comes with over 400 rules. It can detect various issues in your BizTalk environment like whether you are running on right service packs, hot fixes, whether your message box is healthy, are there too much data is certain tables, etc., etc., If you raise a call with Microsoft support, the first thing they will ask you do is run MBV and send them the report. In BizTalk360 you can schedule to run MBV at certain time and also can have alerts configured when MBV reports certain number of critical or non-critical errors. This way you’ll get notified automatically in a pro-active way before things goes out of control. This will also very useful when you have automatic patching of your environments.
#6. Do not set SQL data/log files to indefinite growth
We suggest you setup up your data/log file growth for the BizTalk360 database to set values. Example: 10GB. Do not configure it to grow indefinitely, with increments like 10%. It’s better to know if something failed at certain point rather than leaving it grow till your disks are full. The same principle applies to your BizTalk database db/log files as well. Once the disks are full, it’s more difficult to recover the system.
#7. Configure at least 1 or 2 Regular alerts per environment
BizTalk360 supports two different types of alerts.
- Regular, and
- Threshold Violation
Regular alerts are designed keeping in mind environment owners (Example: Production environment owner). You will be interested to get a daily alert at say for example 10am, showing the overall status of your environment. This alert will be sent in spite of the environment condition. When everything is fine, and shows all green, it gives peace of mind.
Threshold violation alert is only triggered when there is a violation condition. Example: Receive location stopped, suspended instances count greater than configured value, disk space going below configured value etc.
By setting 1 or 2 regular alerts you will know the monitoring system is working (you can use it like a reminder). If you don’t receive your regular alerts you can take a look immediately. If you rely only on threshold violation alerts, and if there are any issues with monitoring, you may simply think everything is fine.
#8. Take advantage of custom SQL queries capability
You want to avoid users accessing your BizTalk database directly. You never know what kind of queries they are going to run against those databases. With BizTalk360 custom SQL queries capability, super user (or someone who have the rights) can write and store well defined useful queries (ex: what’s the spool size?). The normal support users then can simply execute the queries directly in BizTalk360 UI rather than accessing SQL management studio. This avoids unnecessary security access and also restrict users to only specific SQL queries.
#9. Take advantage of Integrated Knowledge base
You may be keeping a support document in SharePoint or maintaining a help Wiki. Problem with this approach is, it’s difficult to educate support people to go and look into those resources when they see the error. BizTalk360 allows you to write knowledge base (rich HTML) articles and attach it with service instance error code and event viewer event id, so next time when they see the error in the BizTalk360 UI, they will also see the corresponding KB article, which will speed up the diagnosing process.
