BizTalk: List of options to store configuration information
There are various ways we can keep the configuration information in BizTalk, but we have to check what the advantages of one over the other are.
The question also arises what kind of information or key value information we want to keep. Do I need to add any sensitive information or how frequent I want o change? Who is going to change?
Before jumping into the list of approach. We need to consider that these values are going to change frequently and the person doing these changes does not be BizTalk expert. So in order to use any interface it will be better to come up with own layer which abstract the implementation layer from business layer. Making this will reduce the complexity and ease the work of business user.
List of configuration options
Storing configuration information in BTSNTSVC.exe.Config
Advantage:
- I don’t think using or adding key value pair to BTSNTSVC.exe.config has any advantage Disadvantage.
- Many people opt this because it is easiest places to store the configuration information from a developer’s perspective and deployment perspective.
- Can define you own custom sections or key value pair
Disadvantage:
- This approach does have more disadvantages over advantage.
- Machine configuration file is common to all application running on that server. Any issue with configuration causes all application to stop.
- Also maintenance perspective it will be more challenging just from the fact that keeping files in sync, and any if you have a setting wrong on just 1 server then it can be hard to troubleshoot as HAT doesn’t distinguish which orchestration shape executed on which server
- Only administrator can add or change values in machine configuration file.
- The Information will be stored on a separate file on each BizTalk server in your group. You will need to ensure these are in sync.
- It is not possible for different application hosted on same server to use same key name with different values.
- Data will be in text format.
SSO
The other option and most frequently used on is storing configuration or key value pair in SSO database.
Advantage:
- Central store which will service all BizTalk servers within your group
- A layer can be created on the top of it to abstract implementation and complexity.
- Out of the box encryption
- Control the changes to data based on group.
- Allow export and import option.
- Chances or error are less.
- Key value pair are maintained based on application.
Disadvantage:
- On the other hand from developer perspective it is a bit of a pain to work with this, Create more complexity for automated build process.
- Would need to use the SSO manage utility to deploy your SSO Application from the command line
- In deployment could not work out how to set the custom property values using the SSO utilities so I ended up wrapping some of the code from the tools above as an MS Build task
- From a maintenance perspective it could be a bit of a pain to manage the configuration. There is an MMC snap in for ESSO but it does not seem to allow you to edit your custom property values.
Storing at database level:
This technique is also quite common.
Advantage:
- Storing configuration details in the database you don’t have to worry about syncing the data across servers like you would with a configuration file
- Caching can be implemented and need to consider how to refresh and pick up changes to the underlying data and that components may become out of sync
Disadvantage:
- Helper class or custom code is needed to read write and update details at db end.
- Need to define a maintenance plan and have your DBA manage this database
- Need to create an interface to allow management of the configuration data
- Custom databases are well known as a cause of bottlenecks in flood gate scenarios.
Store it as vocabulary in BRE:
Advantage:
- Provides a central store for configuration information
- Provides Graphical interface to business users
Disadvantage:
- Data are not encrypted
- Manual need for BizTalk fail over or back up process is required.
- You could use only the latest version of a policy
- In order to perform any changes to policy is to publish new version of the policy
See Also
Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.