Today we published a white paper explaining the importance of BizTalk Server monitoring and Top 15 best practices your can follow to get your monitoring story correct.

Read the complete article BizTalk Monitoring - Top 15 Best Practices in our official BizTalk360 blog.

Hope you enjoy it, please feel free to add your views as comments.

Nandri

Saravana Kumar

When it comes to BizTalk environment "Backup and Disaster recovery", the only official supported option is Log shipping.

This applies to all the versions of BizTalk Servers listed below

BizTalk Server 2004 SP1, 2006, 2006 R2, 2009 and 2010

Log shipping was originally introduced in BizTalk 2006 and back ported to 2004 via SP1. MSDN article contains very good resources, explaining the steps involved in setting up and restoring BizTalk databases.

Microsoft story on BizTalk Server backup/restore has never changed for the past 6 years. When it comes to disaster recovery there are 2 standard industry terms people refer to

1. Recovery Point Objective (RPO), and
2. Recovery Time Objective (RTO)

RPO is the amount of data loss acceptable for business, and RTO is the amount of time it?s acceptable for business without a live environment. With BizTalk Server log shipping default settings, these values will be RPO value of 15 minutes (transaction log back up interval, which can be altered), and RTO will be approximately 1 hour.

Depending on your system volume and amount of background noise it can tackle, you can experiment with reducing the transaction log back up time from default 15 minutes.

Why Log shipping, not any other methods?

BizTalk Server uses multiple databases as part of its runtime requirement.  These databases need to be transactionally consistent (including DTC transactions) at any given point of time to ensure integrity of the server. 

As part of this solution, BizTalk uses Marked Transactions (http://msdn.microsoft.com/en-us/library/aa577848(v=bts.20).aspx) that guaranties the transactional consistency for all of the databases included in the backup.   As part of the installation/configuration, BizTalk creates a SQL Agent Job that uses SQL log shipping for providing backup/recovery of its databases.  The backup/restore solution is implemented as an external SQL artifact and is not a native functionality/feature of BizTalk server.  The server runtime only expects availability of its databases in a consistent state and does not make any assumptions about the backup/restore mechanism.  The task of securing a backup and restoring the database in a transactionally consistent state is assumed to be an external activity.

What's Microsoft stand on alternate solutions?

If you use BizTalk Server with any 3rd party database solutions other than Microsoft SQL Server Log shipping for backup/restore, your primary support contact is the third-party solution provider for any support issues that are related to this. BizTalk Server was developed and tested by using Microsoft SQL Server Log shipping. The Third-party solution provider should be your primary contact for any installation issues, performance issues, or backup\restoration issues. CSS provides commercially reasonable support for BizTalk server related issues as long as it is not related to the back\restore functionality provided by the 3rd party solution.

Generally, support for any SQL specific 3rd party solutions are within the scope of support as outlined here http://support.microsoft.com/kb/913945

What does the above mean?

Microsoft as a software vendor provides an out of the box solution for BizTalk backup and restore. If you are choosing a third party vendor or custom crafting something for your own benefit (ex: avoiding the extra SQL server instances required for Log shipping). Then the risk is either with you or with the third party vendor to restore the data/environment back. If in case you can?t restore your DR site using a third party solution, then simply don?t call Microsoft support.

If you look at the SQL server case, there are dozen third party vendors who supply backup/restore tools for SQL server. If you use any of them and you can?t recover the data, then logically you call the third party vendor helpline or sue them, rather than calling Microsoft.

Unfortunately for BizTalk server there are not any third party solutions available that can certify and take the risk. So you are left with Log shipping.

Nandri!

Saravana Kumar
Founder - BizTalk360
Subscribe to BizTalk360 updates

When we discuss about high availability scenario, we typically think about windows failover clustering. In a BizTalk world we commonly use failover clustering in few places. The first and foremost is the SQL server clustering, and clustering other resources like host instances, enterprise single sign on etc.

 
One of the common misconceptions people got with failover clustering is, they presume 100% uptime is guaranteed and the failover is seamless. But the reality is, having a fail over cluster simply reduces the time it takes to bring the service up and running. Still there will be intermittent period without that dependent service. One big advantage of fail over clustering is, that intermittent period could be just few seconds instead of few minutes or hours to manually bring the resource online.
 
Let's dive bit more deep into the issue with a SQL server clustering scenario.
 
When a SQL Server instance is clustered, the sessions do not stay connected to SQL server during failover. Although failing over is quicker than a reboot, the instance must shut down and start back again dropping all the connections. All the normal recovery processes that SQL server goes through, rolling back uncommitted transactions and writing committed transactions to disk, also happens during failover. Any scheduled jobs that are running when failover occurs do not start back up when SQL server restarts. The time that SQL server takes to fail over is similar to restarting it on the same server without a reboot.
 
The good thing about clustering is that in case of a hardware failure, downtime is only minutes or seconds. The application can be up and running quickly after a failover. But any uncommitted transactions will be lost if it's not handled by the application properly.
 
BizTalk Server is designed keeping this in mind and majority of the time you will be able to recover from this failure either automatically or by instances getting suspended and some one manually resuming it. But if you are dealing with the database directly, then you need to keep this restriction in mind.
 
Keeping the restriction in mind, you should not failover your cluster manually during the peak business hours. Fail over clustering is there either for controlled fail over during outage hour or during disaster like hardware failure.

It's one of the common problems I have seen recently :  All of a sudden some of the BizTalk performance counters disappear from the list. Here are the checklist of things you can do

1. Make sure the host instances are running. If they are not running some of the host related counters wont show up in the list

In some place the performance counter could be corrupted, there are 2 useful documents I found that fixes this issue

http://blogs.msdn.com/b/biztalkperformance/archive/2007/09/30/how-to-manually-recreate-missing-biztalk-performance-counters.aspx

http://blogs.msdn.com/b/biztalkcpr/archive/2010/06/23/have-you-manually-recreated-the-biztalk-performance-counter-using-the-following-link-but-some-of-the-counters-were-still-missing.aspx

If you still experience the problem, try running the following command

C:\Windows\system32>lodctr /r

That basically rebuild the perf registry strings and info from scratch based on the current registry settings and backup INI files.

Nandri!

Saravana Kumar

This is one of the common challenges we see in many enterprises. SQL servers will always be owned by a dedicated database team. The bigger the organisation, the partition between the BizTalk support team and database team will increase. One of the biggest challenges with this setup is, from DBA's perspective they wanted to follow all the best practices, they normally follow as a standard for all the SQL Servers/Databases in the organisation. These may include things like standard backup procedures, indexing procedures, standard recovery model, their own SQL bookkeeping jobs etc.

This situation is a real red alert, BizTalk databases are special databases. A typical BizTalk installation at the minimum will have 4 databases BizTalkMsgBoxDb, BizTalkMgmtDb, BizTalkTrackingDb, SSODB. They are designed to work as a single group. There are certain dependencies between them. Example: Some of the SQL jobs are designed to move data from BizTalk message box to tracking DB, the Tracking subservice will also do similar thing to move data from message box. There are lot of chances for distributed transactions spanning across these databases.  So, the general rule of thumb is

"Do not treat your BizTalk databases as your standard database. It's just a black box and you are not allowed to make any changes (there are few exceptions)"

BizTalk server by default comes with all the weapons required to maintain/protect its databases. The product is designed in a way to self maintain. The main challenge here is SQL DBAs are not fully aware of the BizTalk capabilities.  In this article we will see some of the routine jobs SQL DBA's must be aware of when maintaining a BizTalk environment related databases.

1.    Know how to use Message Box Viewer/Terminator
2.    One time settings
3.    Make sure SQL Agent is running
4.    Procedures to rebuild indexes for BizTalk databases
5.    Monitor the growth of certain tables
6.    Monitor the size of databases
7.    Monitor transaction log sizes
8.    BizTalk 2010 Monitor BizTalk Server Job

Know how to use Message Box Viewer/Terminator
Message box viewer and Terminator tool are the two tools the DBA's maintaining the BizTalk environment should be completely aware of. MBV is designed to identify all potential problems in the BizTalk environment that could be critical or need attention and present them in a nice report. Most of the BizTalk environment issues will come down to poorly maintained database(s); MBV is extremely good at picking them up. Full Q&A can be found here
http://blogs.technet.com/b/jpierauc/archive/2008/07/22/msgboxviewer-mbv-q-a.aspx

In earlier days people executed MBV, identified the issues and manually corrected the problems. But with latest version of MBV (10.3 and above), MBV produce a cleanup script, which can then be used with another tool called Terminator to fix the database issues either automatically or manually.

http://blogs.msdn.com/b/biztalkcpr/archive/2011/02/10/using-biztalk-terminator-to-resolve-issues-identified-by-biztalk-msgboxviewer.aspx

One time settings
Here are some of the steps you need to perform once the environment is setup.

1. Install the Latest BizTalk Server Service Pack and Cumulative Update

2. Disable the Auto Update Statistics and Auto Create Statistics options

You must disable the Auto Create Statistics and Auto Update Statistics options on the BizTalkMsgBoxDb database. To determine whether these settings are disabled, execute the following stored procedures in SQL Server:
exec sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics'
exec sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'

You should set the CurrentSetting setting to off. If this setting is set to on, turn it off by executing the following stored procedures in SQL Server:

exec sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off'
exec sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'

3. Set the Max Degree of Parallelism property correctly

On the computer that is running SQL Server and hosting the BizTalkMsgBoxDb database, set the Max Degree of Parallelism run_value and config_value properties to a value of 1. To determine the Max Degree of Parallelism setting, execute the following stored procedure against the Master database in SQL Server:

exec sp_configure 'max degree of parallelism'

If the run_value and config_value properties are not set to a value of 1, execute the following stored procedure in SQL Server to set them to 1:

exec sp_configure 'max degree of parallelism', '1'
reconfigure with override

4. Make sure BizTalkMsgBoxDb and BizTalkTrackingDb data and log files are in separate drives, also if possible make sure you don't put BizTalkMsgBox and BizTalkTrackingDb data files or log files in the same drive.

Rebuilding indexes
The only supported method to rebuild an index in the BizTalkMsgBoxDb database is to run the bts_RebuildIndexes stored procedure. On BizTalk Server 2006 and later versions, you can run the dtasp_RebuildIndexes stored procedure to rebuild indexes in the BizTalkDTADb database.

If lots of data is expected to build up in the BizTalkMsgBox database, you can periodically rebuild indexes during scheduled downtime. The same guidelines apply to the tracking database.

You can use the DBCC DBREINDEX SQL command to rebuild an index in the other BizTalk Server databases. For an example of how to use the DBCC DBREINDEX SQL command, right-click the bts_RebuildIndexes stored procedure, and then click Properties.
http://support.microsoft.com/default.aspx?scid=kb;EN-US;917845

Monitor the growth of certain tables
Message Box Database (BizTalkMsgBoxDb)
Spool:
If the Spool tables have many records, many messages are currently active, dehydrated, or suspended. Depending on the size, the number of parts, and the fragmentation settings in these tables, a single message may spawn all these tables. Each message has exactly one row in the Spool table and at least one row in the Parts table. Create a benchmark for your BAU activities and make sure the spool table is not growing indefinitely. During you quite period when there are no BAU activities if you notice a large number of rows in this table, make sure unwanted suspended instance are cleared periodically. You can also use Message Box Viewer regularly to check if there are any unusual numbers of rows in the table and can use Terminator tool to safely remove them.

TrackingData_0_x and TrackingData_1_x
TrackingData_0_x: These four tables store the Business Activity Monitoring (BAM) tracked events in the BizTalkMsgBoxDb database for TDDS to move the events to the BAMPrimaryImport database.
TrackingData_1_x: These four tables store the tracked events in the BizTalkMsgBoxDb database for TDDS to move the events to the BizTalkDTADb database.

You make sure there is at least one host configured with tracking enabled. This will run TDDS subservice responsible for moving the data from message box db to BizTalkDTADb and BAMPrimaryImport

BizTalk Tracking Database (BizTalkDTADb)
dta_DebugTrace table typically becomes large in environments where orchestration shapes start/end is enabled. If there is no business value and if you got lots of orchestration in your solution, it's better to clear the check box for ?Shape start and end? option in the orchestration(s) properties.

dta_MessageInOutEvents table typically becomes large in environments where ?Message send and receive? is enabled for orchestrations and/or pipelines. If these tracking events are not required, clear the check box for this option in the orchestration and/or pipeline properties.

If the dta_DebugTrace table and/or the dta_messageInOutEvents table in the BizTalkDTADb database are too large, you can truncate the tables manually after you stop the tracking host. The BizTalk Terminator tool also provides this functionality.

dta_ServiceInstanceExceptions table typically becomes large in an environment that regularly has suspended instances. dta_serviceinstances table grows every time the user terminates an instance. DTA Purge and Archive SQL Server jobs should take care of clearing this table, so make sure the jobs are running correctly.

BAMPrimaryImport
TDDS_FailedTrackingData
The TDDS_FailedTrackingData table gets populated whenever there is a tracking failure or even in cases where you haven't deployed your BAM activities, but your solution is trying to insert BAM data. In earlier version of BizTalk (2006 and 2006 R2) the DTA Purge and Archive SQL Server jobs didn't clear this table periodically which resulted in unlimited growth of this table. Make sure you got the hot fix explained here http://support.microsoft.com/kb/977289

Monitor the size of databases
The size of the databases will vary from organisation to organisation depending on the volume of data processing. In any organisation having a bloated/large database will adversely effects the performance of your BizTalk environment. As a general rule of thumb, you can use the following numbers for guidance

BizTalkMsgboxDb: Not more than 5GB. However big your deployment is, your message box database should NOT go beyond this limit. In theory Message Box database only should hold transit data (aka inflight messages).  On a healthy environment all the processed message will either be moved to BizTalk tracking database or BAM database. Having lot of suspended instances will also bloat the size of the message box database, so periodically clear them out or better design your solution in a way you are not going to have too many suspended instances (unless otherwise there is a genuine unhanded exception scenario).

BizTalkDTADb, BAMPrimaryImportDB: Around 10 GB max.  This is again a finger in the air estimate. It's better to keep the tracking data and BAM data within this limit. You can control this by setting the appropriate values for your DTA purging/archiving job and making sure you are moving your BAM data from BAMPrimaryImport table to BAMArchieve database. Also make sure your BAMArchive database is not bloated over a period of time. Do a hard purge after a set period like 3 or 6 months based on your business requirement.

The other databases like BizTalkMgmtDb, SSO, RulesEngine etc all store configuration data and they should be any bigger than 2GB.

Monitor transaction log sizes
The size of the BizTalk databases transaction log is controlled by the BizTalk backup job. By default the recovery model for the BizTalk databases is set to Full. If the transaction log is not backed up or truncated on a regular basis, the log files or files can fill up. So, please make sure BizTalk backup job is configured and running successfully. This job automatically backup the BizTalk databases including transaction log, and thus ensures the transaction log does not grow to an unmanageable size. The backup job should also be performed multiple times during the day as it's the job that lets you recover your messages. The bigger the log file the more messages that could be lost.

It is not recommended to change the recovery model settings of the BizTalk databases. Changing this setting will put the BizTalk environment into a state where it may not be fully recoverable in the event of failure.

Not but the not the least the Backup BizTalk Server job is the only supported method to back up the BizTalk Server databases.

BizTalk 2010 Monitor BizTalk Server Job
If you are using BizTalk Server 2010, you can run the Monitor BizTalk Server SQL Agent job to identify any known issues in Management, Message Box, or DTA databases. The job is created when you configure a BizTalk group in BizTalk Server Administration console or upgrade BizTalk from the previous version.

The Monitor BizTalk Server job scans for the following issues in Management, Message Box, and DTA databases:

• Messages without any references
• Messages without reference counts
• Messages with reference count less than 0
• Message references without spool rows
• Message references without instances
• Instance state without instances
• Instance subscriptions without corresponding instances
• Orphaned DTA service instances
• Orphaned DTA service instance exceptions
• TDDS is not running on any host instance when global tracking option is enabled.

The Monitor BizTalk Server job is configured and automated to run once in a week. Since the job is computationally intensive, it's recommended you to schedule it during downtime/low traffic.

The job fails if it encounters any issues; error string contains the number of issues found. Else, it runs successfully. You can see the details in the job history. If you run the job with Administrator privileges, error string will be logged to Event Viewer also (along with the job history).

Ad-hoc Full backup
It may be required once in a while to force a full database backup. The BizTalkMgmtDb.dbo.sp_ForceFullBackup stored procedure can be used to force a full backup of the data and log files. Execute this stored procedure, and then execute the Backup BizTalk Server SQL Agent job.

Cleanup all the data in test environment
DO NOT do this in PRODUCTION
When you are managing test environment (especially performance testing) it may be required to clean up BizTalkMsgBoxDb and BizTalkDTADb. When I say clean up, completely wipe out all the data, hence the bold warning.

BizTalkMsgboxDb
1.    Copy the Msgbox_cleanup_logic.sql script from Drive:\Program Files\Microsoft BizTalk 200x\schema to the SQL Server.
2.    Execute this SQL script against the BizTalkMsgBoxDb database to update the bts_CleanupMsgbox stored procedure.
3.    Stop all BizTalk hosts, services, and custom isolated adapters. If you use HTTP or the SOAP adapter, restart the IIS services.
4.    Execute the bts_CleanupMsgbox stored procedure on all the BizTalkMsgBoxDb databases.
5.    Restart all host instances and BizTalk Server services.

BizTalkDTADb
1.    Back up all BizTalk databases.
2.    Execute the dtasp_CleanHMData stored procedure. Only use this option if the BizTalkDTADb database contains many incomplete instances that must be removed.

To do this, follow these steps:
a.    Stop all BizTalk hosts, services, and custom isolated adapters. If you use HTTP or the SOAP adapter, restart the IIS services.
b.    Execute the dtasp_CleanHMData stored procedure on the BizTalkDTADb database.
c.    Restart all hosts and BizTalk Server services.

Nandri!
Saravana

It's one of the common best practices in big enterprises and banks to install SQL server on a custom port rather than the default port 1433 for security reasons.

But when you try to connect the BizTalk administration console via the MMC (especially from a remote machine), you?ll be greeted with some unpleasant message as shown below.

The general principle for connecting to a SQL server instance running on a custom port is by specifying the port number after the instance name separated by a comma. The principle is same in any client application like SQL Management Studio, or even the connection string settings in .NET.

Once you specify the port number after the SQL Server name, you can see the list of databases on the drop down menu, BizTalkmgmtDb will automatically be picked up and you can click "OK" to connect.

The home screen (BizTalk Group Overview) page will display without any issues, but as soon as you try to expand the "Applications" node, you?ll be greeted with the following error message. We experienced the same thing with BizTalk360, when we try to iterate through the applications using the ExplorerOM api. The main reason for this is the value of SQL server instances are stored in few tables (adm_otherdatabases, adm_group etc) in the BizTalkMgmtDb without any knowledge about the port numbers.

The solution to this issue is by simply creating an Alias for SQL server with custom port number. Open SQL Server Configuration manager and under "SQL Native Client Configuration (32bit)", right click "Aliases" and click "New Alias". Then enter the details as shown below (make sure there are no spaces at the end) with your custom port information.

It's important to create the Alias under 32 bit nodes, since the ExplorerOM is only 32 bit. Once the above alias is create, simply close and open the BizTalk administration console and you'll be able to iterate through the applications as shown below.

We haven't tested the run-time capabilities with custom SQL port, but I believe the behaviour must be same.

Nandri!

Saravana

Say for example if you want to expose an operation called "AddOperation" which takes 2 input parameters of type "double" and returns a "double" value.

If you are building a standard WCF services, you would have defined the interface as shown below.

[OperationContract]
double AddOperation(double a, double b)

But in order to do the same thing in WCF LOB adapter, you would have done something like this

//Param 1

OperationParameter n1 = new OperationParameter("a"

                                        , OperationParameterDirection.In

                                        , QualifiedType.DoubleType, false);

n1.IsOptional = false;

opMetadata.Parameters.Add(n1);

//Param 2

OperationParameter n2 = new OperationParameter("b"

                                        , OperationParameterDirection.In

                                        , QualifiedType.DoubleType, false);

n2.IsOptional = false;

opMetadata.Parameters.Add(n2);

//Result

opMetadata.OperationResult = new OperationResult(QualifiedType.DoubleType, false);

break;

The reason for the complexity is mainly due the dynamic nature of the WCF LOB adapters, often times you'll be constructing the operation request and response types based on your underlying LOB applications requirement.

WCF LOB Adapter SDK comes with rich set of Metadata object model to cater for various situations. That includes

• Operation/Type Metadata Object Model is used for contract generation
• ParameterizedOperationMetadata class can be used for most common operation representations (as shown above)
• StructuredTypeMetadata can be used for most common types representations
• Metadata object model is extensible by allowing the adapter developer to provide own XML Schema representations for its members using ExportXmlSchema methods.

The last option ExportXmlSchema is the one you'll use when the underlying LOB systems already defined XSD schemas and you just want to reuse it. Example

The EchoAdapter sample and some of the great articles from Sonu Arora's WCF LOB adapter series all explain about the simple scenario where a types is self contained within a single XSD file. But in reality you'll be using multiple XSD files together either with xsd:include or xsd:import. I can see an open thread here at msdn forum without a resolution.

When you try to deal with schemas that include other schemas, you'll typically see the following error

Error while retrieving or generating the WSDL. Adapter message: The 'urn:schemas-XXXXX:b2b:WorkItemNo' element is not declared.

The solution to that problem is quite straight forward. In the ExportXmlSchema method, you loop through the included schemas before doing your regular one. In the below example the code in bold is a common schema, and the code below that is what you'll normally have.

public override void ExportXmlSchema(XmlSchemaExportContext schemaExportContext, MetadataLookup metadataLookup, TimeSpan timeout)
{
    if (schemaExportContext == null)
    {
        throw new AdapterException("Schema export context is null.");
    }

    //Read Common Schemas

    Stream commonXsdFile = Assembly.GetExecutingAssembly().GetManifestResourceStream(COMMOM_METADATA_FILE_NAME);
    using (XmlReader reader = XmlReader.Create(commonXsdFile))
    {
        XmlSchema schema = XmlSchema.Read(reader, null);
        if (!IsComplexTypeAlreadyDefined(schemaExportContext.SchemaSet, schema))
        {
            schemaExportContext.SchemaSet.Add(schema);
            if (!schemaExportContext.NamespacePrefixSet.ContainsKey(this.TypeNamespace))
            {
                schemaExportContext.NamespacePrefixSet.Add(this.TypeNamespace
                    , getUniqueNamespacePrefix(schemaExportContext, 0));
            }
        }
    }


    // Read in XML Schema file or create XmlSchema object yourself
    Stream predefinedXsdFile = Assembly.GetExecutingAssembly().GetManifestResourceStream(CONST_METADATA_FILE_NAME);
    using (XmlReader reader = XmlReader.Create(predefinedXsdFile))
    {
        XmlSchema schema = XmlSchema.Read(reader, null);
        if (!IsComplexTypeAlreadyDefined(schemaExportContext.SchemaSet, schema))
        {
            schemaExportContext.SchemaSet.Add(schema);
            if (!schemaExportContext.NamespacePrefixSet.ContainsKey(this.TypeNamespace))
            {
                schemaExportContext.NamespacePrefixSet.Add(this.TypeNamespace
                    , getUniqueNamespacePrefix(schemaExportContext, 0));
            }
        }
        //reader.Close();
    }
}

Nandri

Saravana Kumar

I spend nearly 5 hours so far today trying to configure Enterprise Library 5.0 for one of our projects. The machine I'm working on got ESB 2.1 installed previously.

ESB Toolkit 2.1 utilises Enterprise Library 4.1. Among the various application blocks, it takes advantage of ConfigurationSource to point to ESB specific configuration information (esb.config and SSOConfigurationSource) from machine.config file.

When you open the machine.config file after ESB Toolkit 2.1 installation you will see the following information.

<configuration>
  <configSections>
    <section name="enterpriseLibrary.ConfigurationSource" 
type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

<enterpriseLibrary.ConfigurationSource selectedSource="ESB File Configuration Source">
    <sources>
      <add name="ESB File Configuration Source" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35" filePath="C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\esb.config" />
      <add name="ESB SSO Configuration Source" type="Microsoft.Practices.ESB.SSOConfigurationProvider.SSOConfigurationSource, Microsoft.Practices.ESB.SSOConfigurationProvider, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" applicationName="" description="Configuration Data" contactInfo="" userGroupName="" adminGroupName="" />
    </sources>
</enterpriseLibrary.ConfigurationSource>

This will break all the applications that uses Enterprise Library 5.0, when you try to initialize the Enterprise Library objects you will encounter errors as shown below.

[A]Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection cannot be cast to [B]Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection. Type A originates from 'Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Windows\assembly\GAC_MSIL\Microsoft.Practices.EnterpriseLibrary.Common\4.1.0.0__31bf3856ad364e35\Microsoft.Practices.EnterpriseLibrary.Common.dll'. Type B originates from 'Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Windows\assembly\GAC_MSIL\Microsoft.Practices.EnterpriseLibrary.Common\5.0.505.0__31bf3856ad364e35\Microsoft.Practices.EnterpriseLibrary.Common.dll'

There is a suggestion on the BizTalk forum for this issue

http://social.msdn.microsoft.com/Forums/en-CA/biztalkesb/thread/8dc6ecda-862c-415a-912c-8215caa67a85

but that doesn't seem to work. When you try to use <enterpriseLibrary.ConfigurationSource selectedSource="Local Application Configuration Source"> in your configuration file, you will receive the following error "Configuration system failed to initialize, Section or group name 'enterpriseLibrary.ConfigurationSource' is already defined. Updates to this may only occur at the configuration level where it is defined.". That's because the section is already added to the machine.config file by EST Toolkit 2.1 installation.

I couldn't find a solution to the problem. I'm just posting this so people are aware of the consequences, before installing ESB Toolkit 2.1.

Nandri!

Saravana

This week was an incredible week for people who were involved in BizTalk Server. At the Microsoft World Partner Conference 2011 Tony Meleg (Microsoft) delivered an important session "The Future of Middleware and the BizTalk Roadmap". Richard Seroter nicely summarized his view here.  After so much buzz in the twitter and blog space, I decided to watch this video. Being a BizTalk Server MVP, we were aware of all these things slightly earlier than the general public, but it was good to get a recap. While watching the presentation, I was tweeting (@biztalk360) all the important statements from Tony Meleg, I summarized everything here so the tweets won't disappear in the wild (you need to read from bottom to top :-).

At the end the main takeaway for me is, BizTalk as a product/brand name may go away after few years, few revisions of AppFabric vNext (which for the time being they call it as future of BizTalk). But the integration concepts like adapters, pipelines, work flows (Orchestration name will die), rules, BAM, etc are going to remain the same. We just need to learn how to do things in new way. This cloudy thing is big, we can't ignore it. The great thing you need to keep in mind is "One strategy, make it run in the cloud, make it run on-premise full stop", that means you don't need to learn multiple things.

Microsoft is great in delivering such things, proof is .NET Framework and it's Languages. Whether you are a Web developer, WPF, Silverlight, SharePoint, BizTalk or whatever you got one framework and your one preferred programming language to do things.

If you remember the saying,

"The Only Thing That Is Constant Is Change" - Heraclitu, Greek philosopher

and I welcome the change.

Text Version

• BizTalk as product/brand name may go away after few years but the integration concepts are going to remain - SK
• Managed to watch the full video http://bit.ly/n2vpth very open transparent view from Microsoft about direction of BizTalk
• Migrate the whole application is not going to happen, its more like migrate each artifacts pipelines, rules, workflows etc -Tony M #WCP11
• Invest in migration tools/guidance, Make the platforms work together - Tony M, #WPC11
• Continue to ship current BizTalk architecture, because we don't know how long this new thing is going to take - Tony M #WPC11
• We are building only one thing, cloud first and then suck those pieces down as server version - Tony M #WPC11
• Set your expectations very low with what we have shipped, it will take a long time to realize the vision - Tony M #WPC11
• This picture is the next BizTalk Server - Tony M #WPC11 http://yfrog.com/khhn0p
• AppFabric ServiceBus team responsible for unifying, rationalizing and delivering a messaging platform on behalf of the company - TM #WPC11
• AppFabric Container is the heart of future middleware, it's the host capable of elastic scale - Tony Meleg #WPC11
• It's multi-year, multi-release vision - Tony Meleg #WPC11
• 1. BizTalk Investments, 2. Build cloud based middleware plat, 3. Solve capability islands, remove duplication - Tony Meleg #WPC11
• One strategy, make it run in the cloud, make it run on-premise full stop - Tony Meleg #WPC11
• Replacing BizTalk Orchestration engine with WF is like doing major heart surgery, really difficult -Tony Meleg
• Finally watching Tony Meleg's talk

Video Link:
http://digitalwpc.com/Videos/AllVideos/Permalink/e821e9f8-e379-45b0-8879-12fe271c86be#fbid=8XvnxCo6v9U

Presentation Link:
http://digitalwpc.blob.core.windows.net/sessions/2011/AP03_Meleg.ppt

Nandri!
Saravana

When you try to install the ESB toolkit BAM definition file Microsoft.BizTalk.ESB.BAM.Exceptions.xml you might encounter this error

OLE DB error: OLE DB or ODBC error: Cannot open database "BAMStarSchema" requested by the login. The login failed.; 42000.
Errors in the high-level relational engine. A connection could not be made to the data source with the DataSourceID of 'bam_ExcByApplication', Name of 'bam_ExcB
yApplication'.
Errors in the OLAP storage engine: An error occurred while the dimension, with the ID of 'ExcByApplication_ExcFaultDescription', Name of 'ExcByApplication_ExcFa
ultDescription' was being processed.
Errors in the OLAP storage engine: An error occurred while the 'FaultDescription' attribute of the 'ExcByApplication_ExcFaultDescription' dimension from the 'BA
MAnalysis' database was being processed.
Server: The operation has been cancelled.

The main reason for the exception is, the SQL Server service account must have read access to BAMStarSchema database. In my case it was configured to run under Network Service account. To fix this issue, open SQL server management studio, expand BAMStarSchema, Security, User. Right-click and select New User and configure it as shown below

Nandri!

Saravana Kumar