Thursday, 5 November 2015

Asserting Database Facts Per Environment

I've recently been using database facts in Biztalk Business Rules Engine and this has required an assertion of the connection string into the policy which includes the database server/instance, database name, and table name. The database name and table are likely to be static for the life of the application but the database server needs to change based on which environment we have deployed to. I've been considering where to set the configuration for this. The options are:

  • BTSNTSVC config. A per server configuration is possible in this but I think it's best to avoid using such a file.
  • Business rule policy which determines the local machine name then sets the database server based on this. A bit overkill.
  • Business rule vocabulary with static value we can use. Doesn't work too well for different environments.
  • Fact Retriever which will pull the value from somewhere else.
Considering that the database being used is on the same server/instance as the Biztalk databases, I opted to use the Fact Retriever to pull the database/instance configuration from the windows registry.

using System.Data.SqlClient;
using Microsoft.RuleEngine;
using Microsoft.Win32;
namespace My.BRE
    public class AssertSiteConverterDB : IFactRetriever
        public object UpdateFacts(RuleSetInfo ruleSetInfo, RuleEngine engine, object factsHandleIn)
            object factsHandleOut;
            if (factsHandleIn == null)
                object servObj = Registry.GetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\BizTalk Server\\3.0\\Administration", "MgmtDBServer", ".");
                SqlConnection SQLConn = new SqlConnection("Data Source=" + servObj.ToString() + ";Initial Catalog=SIP;Integrated Security=SSPI;");
                DataConnection RulesConn = new DataConnection("my database", "my table", SQLConn);
                factsHandleOut = RulesConn;
                factsHandleOut = factsHandleIn;
            return factsHandleOut;

Gac this and configure your policy to use this Fact Retreiver and this will ensure that the correct database/instance will be asserted no matter which environnment you deploy to.

Sunday, 1 November 2015

Troubleshooting BAM

I've recently had some difficulties with BAM which made the service unavailable. I will outline some of the steps I've taken to get it working again. Below outlined is only general advice as you may have a different problem compared to what I've experienced.

Backup before you start

Before working you may want to take a backup of the database tables under BAMPrimaryImport. Another option which I took instead was to modify the database table bam_Metadata_Activities in BAMPrimaryImport to a short time interval, then run the SSIS job which moves all the data to BAM archive. Doing this means the data won't be available in the BAM portal even though it's stored away in the BAM Archive, but also takes away the headache of dealing with partitions.

Unable to Configure BAM Portal

If you are unable to modify BAM Portal configuration because input is not possible like in the below window which shows we can't configure the accounts used for BAM.

Hit the button at the top to export the configuration. Modify the xml by removing all <Feature> elements except for <Feature Name="BAMPortal". Leave all the <InstalledFeature> elements. Now modify the elements under <Feature Name="BAMPortal" so that all the usernames, domain and passwords are set. In Biztalk Server Configuration, import this xml file. Click next on the following dialogs to finish.

Another option to try is to edit the BamConfig.xml file in C:\Program Files (x86)\Microsoft BizTalk Server 2010\Tracking. Turn element <GlobalProperty Name="BAMVRoot" into an empty element so as to get rid of your existing site. Then use bm.exe by bm update-config -Filename:BamConfig.xml.

Default Web Site is not valid

You may also come across this problem where using the Default Web Site is not possible during configuration of the BAM portal.

You can try deleting the app pool BamAppPool from IIS and deleting any existing BAM website under Default Web Site then restarting the Biztalk Server Configuration tool. In my case this didn't solve the problem so I created another web site in IIS and used it instead of Default web site. This allows BAM to install in the new website. From there you can manually create the BAM application under Default Web Site by copying all the settings. This will allow the BAM portal to function under Default web site. Beware though that removing the other web site you created will cause the BAM portal under Default web site to stop working. So far I haven't been able to figure out where the connection is that requires the other website to stay functional.