Published on : Mar 17, 2023
Category : BizTalk Server
Welcome again to another BizTalk Server Best practices, Tips, and Tricks blog post! In my previous blog posts, I discussed some essential tips and tricks for BizTalk Server administrators:
And for BizTalk Server Developers:
Today I will speak about another critical Best practice, Tips, and Tricks, this time for BizTalk Server developers: Stop using BizTalk Server Config files to store application configurations.
Stop using the BizTalk Config files to store application configurations
The BizTalk Server engine uses an XML file called BTSNTSvc.exe.config, or BTSNTSvc64.exe.config, to determine certain behaviors. This is probably one of the easiest places to store the configuration information from a developer’s and deployment perspective. Any changes placed here will be applied to all host instances regardless of their names. This file is always located in the same directory as the BTSNTSvc.exe file, which is usually “C:\Program Files (x86)\Microsoft BizTalk Server <version>”.
You can find more information about the BizTalk Server configuration file here.
At first look, this can be a good solution and can bring some advantages:
- Development: from a developer’s perspective, this is a very straightforward approach and very easy to implement. Any changes placed here will be applied to all host instances regardless of their names in the machine of the configuration file.
- Deployment: from a deployment perspective, this can also be archived very easily, especially in small environments where you just need to update the files.
However, you definitely need to stop using BizTalk Server configuration files. It is the worst place to put application configurations. Don’t get me wrong, you need to use it to configure the BizTalk Server engine but not your solutions/applications, and the reasons are many:
- Maintainability: Once again, from a maintenance perspective, it is a challenger just from the fact of keeping files in sync, BTSNTSvc.exe.config (for 32 bits host instances) and BTSNTSvc64.exe.config (for 64 bits host instances) and even more challenges in environments with multiple BizTalk Servers machines (all of the files must be synced in each machine). It will also be a nightmare if you need to troubleshoot for errors.
- Availability: Another big problem is that for changes to take effect, you will need to restart the host instances, which will cause minor downtimes.
- Data Security: By default, the data will not be encrypted;
- Accessibility: The configuration values can only be changed by an administrator;
- Environment Security: You must be very careful when you mess around with the BizTalk Server configuration file (please do not change this file without backing up); otherwise, you can stop all our BizTalk environment.
- Standard: In many organizations, there are standards that describe how you typically handle configuration information, and because storing configuration information in BTSNTSvc.exe.config is BizTalk related, it can be difficult to change the companies’ standard configuration store (configuration files or databases).
There are many alternatives to BizTalk Server configuration files to store Application Configurations like:
- Custom Configuration Files: not ideal also, for almost the same reasons as BizTalk Server configurations files.
- Windows Registry: Despite being better than config files, it still has important disadvantages like:
- Maintainability: From a maintenance perspective storing values in the Registry can be hard to maintain in large environments because we need to maintain multiple registries, and it’s hard to back up individual application settings.
- Data Security: By default, the data will not be encrypted.
- Accessibility: The configuration values can only be changed by an administrator.
- Custom Databases: It may seem a good option, but it will be so far the worst!
- Deployment: Although the deployment can also be achieved very quickly, that is a false sensation because the developer needs to statically specify the connection string or save it in another place.
- Business Rules Engine: what? Is that not for Business rules? Yep, it may be shocking and used not for its original goal, but Business Rule Engine (BRE) can be used to store configuration data, and it is an amazing option!
- Advantages:
- Availability: You can change the values whenever you want, and the changes will be applied in runtime. You don’t need to restart the host instances. Also, you can prepare a new version without affecting the existing one.
- Accessibility: By default, all BizTalk Hosts have the same level of access to rules engine artifacts. The configuration values can be changed by anyone with access to BRE; BizTalk Server restricts access to the Business Rule Engine resources by using two SQL Server roles: The RE_Admin_Users SQL Server role is for users that need to perform administrative tasks in the Business Rule Engine, such as deploying rules. Members of the RE_Admin_Users SQL Server role include BizTalk administrators).
- Maintainability: From a maintenance perspective, it is extremely simple, and you would get the normal BizTalk failover/backup processes out of the box for free.
- Deployment: BizTalk will provide out-of-the-box tools (Business Rules Engine Deployment Wizard) where you can easily import or export business rule policies or vocabularies for you to use in your development, staging, and production environments.
- Versioning: As the configuration is defined as constants, they would be read-only. However, we can follow the BRE deployment/versioning strategy to implement configuration changes.
- However, we also have disadvantages:
- Development: from a developer’s perspective, storing values in BRE is a very straightforward approach and very easy to implement. Biztalk Server will provide all the tools out-of-the-box to accomplish that. However, developers sometimes do not understand BRE for many reasons, which can become an obstacle for the team.
- Accessibility: This can also be a disadvantage. The configuration values can be accessed by anyone with access to BRE;
- Data Security: By default, the data will not be encrypted;
And we end up with the best alternative possible: Enterprise Single Sign-On Database:
- Maintainability: From a maintenance perspective, it is extremely simple, and you would get the normal BizTalk failover/backup processes out of the box for free. Because it’s a central store, there is no need to distribute a configuration file across multiple servers when a value changes, therefor you eliminate the risk of using different configurations for different servers. The SSO Configuration Application MMC Snap-In tool will allow administrators to import and export configuration applications.
- Availability: You can change the values whenever you want, and the changes will be applied in runtime. You don’t need to restart the host instances.
- Accessibility: It is a central store, so all the configuration values will be exactly the same for all BizTalk Servers within your group.
- Data Security: One of the main advantages is that you get out-of-the-box encryption. The SSO is automatically encrypted, which makes it harder for someone to read it. It offers the ability to store sensitive information.
Here is a good tool for managing SSO Application Configurations: BizTalk Server SSO Application Configuration Tool.
BizTalk Server SSO Application Configuration tool provides the ability to add and manage applications, add and manage key-value pairs in the SSO database, as well as import and export configuration applications so that they can be deployed to different environments.
You can download the tool on GitHub.
Stay tuned for the following BizTalk Server Best practices, Tips, and Tricks.
