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;
                engine.Assert(factsHandleOut);
            }
            else
                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.

Wednesday, 14 October 2015

What to do if you can't get the time into BAM via orchestration.

I've experienced a problem with trying to get the current datetime into BAM from within an orchestration. All my attempts of using the PortStartTime and PortEndTime in any of the orchestration shapes have ended up with Null values or a date like '1900-01-01 00:00:00.000'. Normally I think this works for other orchestrations I've worked on but this particular orchestration I'm currently working on seems to not want to work.

Before I move onto the solution, I'll mention that as an alternative you could take the PortStartTime from the receive location and use a continuation to link it to your orchestration.

To work around this I'm going to call the BAM API directly. Firstly we drop an expression shape in the orchestration and call BeginActivity


Microsoft.BizTalk.BAM.EventObservation.OrchestrationEventStream.BeginActivity(<<activity name>>, <<activity instance>>);
 The activity name can be taken from the activity you created from the BAM addin for Excel. The activity instance is any id. Normally TPE uses ActivityID. You won't have access to this value from within your orchestration so you will need to provide a new one. So go ahead and drag a new id such as MessageID or InterchangeID onto the ActivityID in TPE like so


Now from your expression shape in you orchestration, use the following code.
Microsoft.BizTalk.BAM.EventObservation.OrchestrationEventStream.BeginActivity("my activity", receivedMessage(BTS.MessageID));
 Microsoft.BizTalk.BAM.EventObservation.OrchestrationEventStream.UpdateActivity("my activity", receivedMessage(BTS.MessageID), "DateTime", System.DateTime.UtcNow);
 Microsoft.BizTalk.BAM.EventObservation.OrchestrationEventStream.EndActivity("my activity", receivedMessage(BTS.MessageID));
And that's it. We call the BAM API and update the activity providing it the current datetime.

Wednesday, 27 May 2015

Biztalk Binding Schema

In my Biztalk solution I have a need to check for the existence of configurations in certain ports. The unit test I created exports the binding from the Biztalk application then Bizunit applies Xpath to check for the existence of configurations. Before you do this though you need to supply a schema to Bizunit.

The schema for the Biztalk binding file can be generated by running the following in the visual studio command prompt:
xsd.exe “C:\Program Files (x86)\Microsoft BizTalk Server 2010\Microsoft.BizTalk.Deployment.dll” /type:BindingInfo
Now when you go to use it for validation you'll find it's unusable. Firstly the import at the top throws an error, then you'll find that the SendPipeline tag used in exported bindings are invalid. Something isn't right when a tag in real life use comes up as invalid.

To get a working schema I ended up using an exported binding and xml software to generate a schema based on the exported binding file.

Wednesday, 25 February 2015

Biztalk360 BRE Standalone Access to Assemblies

One of the problems with using a standalone server with Biztalk360 is the unavailability of assemblies. When you load the business rules page in Biztalk360, you may find it inaccessible with various errors stating that various assemblies could not be found.

To solve this, grab all dll's for any custom BRE components you use in addition to all the dll's under C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Bin from another system if you use the ESB toolkit. A simple way to gac these assemblies on a server which doesn't have access to Gacutil is to copy these dll's to C:\Windows\assembly. At this point the problem still persists and I've tried restarting the Biztalk360 service. In the end I couldn't figure out how to get Biztalk360 to access these dll's. Wait another 24 hours at which point Biztalk360 will have access to the dll's and will work correctly.

Sunday, 15 February 2015

Thoughts On Biztalk360

After a month of using Biztalk360, I thought I'd share a few of my experiences.

Standalone Installation

You have the option of installing Biztalk360 on a Biztalk server or as a standalone. A standalone installation will require that you install some Biztalk components and get your accounts and permissions right, in theory. In practice you'll find that various parts of Biztalk360 will not be functional. An example of this is if you use custom components in BRE, then BRE will fail to load. You'll then need to install the custom components on the standalone server. Another example is an inability to start/stop an application due to a bug in the Biztalk installation. Most of these problems can be avoided by installing on a Biztalk server as all the assemblies you need will already be gac'd.

Although it seems counter intuitive to put your monitoring tools on the system that will be monitored, you can let your system administrators use their monitoring tools to monitor the basic system and database availability and let Biztalk360 monitor the rest.

TL;DR avoid the grief of installing Biztalk360 as standalone. Install it on your Biztalk server instead.

BAM and ESB Portal

Both BAM and ESB in Biztalk360 are no-where near feature parity with the existing web sites in terms of functionality or usability. A pity since we use these features heavily, although I hear that there are updates coming which will close this gap. I think this is one area where Biztalk360 can really shine as the existing BAM & ESB portal are really dated, but nobody has the time to re-implement these to do a better job. I still find myself using the existing solutions because they are still better in most ways. I think this will change soon.

Monitoring

I've had a few problems with monitoring due to permissions related to the service account in use, but other than that it has been smooth sailing. The fine grain monitoring is excellent and in particular I love the process monitoring which allows you to check that a process has run and alert you if it hasn't. Massively useful for things such as daily processes.

Support

I've had to call on support a few times and they are a pleasure to deal with. No problems here.

Sunday, 1 February 2015

ESB Import Failure: Microsoft.Practices.Modeling.Services

You've got your solution all tested and ready to go. You've practiced deployment on your test systems. You go to run BTDF to deploy the solution to your production system and you get an error about Microsoft.Practices.Modeling.Services being unavailable. This occurs at the step when BTDF is deploying one of your itineraries using ESBImportUtil.


The problem you'll find is that the tools folder doesn't exist at C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1 in your production system. So go into the folder C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Tools\Itinerary Designer on your test system and copy the files

  • Microsoft.Practices.Modeling.Common.dll
  • Microsoft.Practices.Modeling.ExtensionProvider.dll
  • Microsoft.Practices.Modeling.Services.dll
to the folder C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Bin in your production system. Redeploy the solution and your itinerary should get through fine.