BizTalk Server is an enterprise product; there is no second thought about it. Any enterprise product will go through the phase of being left out with very older version on production environment. Ones the code is up and running in a production environment with live business, it becomes mission critical. Enterprise just don't upgrade either their applications drastically or the platform on which they are running until there is a compelling business case behind it.

The organisation I'm working on is also in a similar situation, and I been tasked to put the future road map for BizTalk Server in the organisation. I just need to come up with proper reasons, why we should move on to latest version of BizTalk Server (keeping in mind the cost associated with it). We are currently on BizTalk Server 2006 (not R2), and our plan is to move to BizTalk 2009 R2 (skipping 2 versions in between 2006 R2, and 2009).

This list is not going to be exhaustive, the scenarios will vary from organisation to organisation based on the usage (example: B2B integrations, SAP integration, Health care with flat files etc). In our case we use BizTalk for couple of different scenarios.

• A BPM process, more like a human workflow kind of solution interfacing with one of our internal in-house BPM software.
• A composite Business Services layer on top of our middle tier integrations services.

So both the solution uses lot of standard Orchestrations, Maps, Schemas, WSDL, SOAP adapter, MQSeries adapter, and a custom adapter to talk to in-house BPM software, BizTalk web publishing capabilities, and BAM

Note: Some of the features were available in BizTalk Server 2006 R2 and BizTalk Server 2009 (example: WCF Support). This list just shows the cumulative gain for moving from BizTalk 2006 to BizTalk 2009 R2.

Reason #1: Nearing end of life (EOF) mainstream support

This is our number one reason for thinking about moving to BizTalk Server 2009 R2.

Product	Mainstream Support Retired	Extended Support Retired
BizTalk Server 2006	12/07/2011	12/07/2016

It's not just the BizTalk server end of life threatens us; it's also the end of life for Windows Server 2003 R2.

Product	Mainstream Support Retired	Extended Support Retired	Service Pack Retired
Windows Server 2003 R2 Enterprise x64 Edition	13/07/2010	14/07/2015	14/04/2009

Running your solution on out of support platform is going to be expensive and results in indirect costs. Apart from the cost reason, there may be scenario where the support cycle may take longer time to resolve issues.

Reason #2: Platform upgrade and performance gain

Platform upgrade for moving from BizTalk Server 2006 to 2009 R2 looks like this

From	To (at least)
Windows Server 2003 R2	Windows Server 2008 R2
SQL Server 2005	SQL Server 2008 R2
Visual Studio 2005	Visual Studio 2010

BizTalk Server (environment) performance is always closely tied to the performance of the platform upon which BizTalk server is installed/running. BizTalk Server heavily depends on the performance of SQL Server and Windows server itself. So moving to the latest platform should provide considerable performance gain (depending on the scenario) on the same application code base.

Reason #3: Virtualization Support:

Virtualization support for BizTalk Server 2006 is on best effort basis. Meaning, if you can reproduce the problem on a physical environment, support will be provided. But with 2009 Hyper-V based virtualization is fully supported.

Licensing around Virtualization

Text Snippet from http://www.microsoft.com/biztalk/en/us/pricing-licensing-faq.aspx

"Similar to SQL Server Enterprise, BizTalk Server 2009 ENT can be licensed for unlimited virtualized processors that are available on a single physical server. The customer will be required to license the number of physical processors on a server."

This is one of the key factors for us; we are seeing more and more projects getting done in BizTalk Server within the organisation. In some cases due to the volume and size of the project its not worth having a dedicated BizTalk Server environment at the same time due the criticality of the applications its not possible to run the applications in a shared environment.

With the support for virtualization and liberal licensing model, it will help us to isolate the applications from one another and keep the costs low.

Reason #4: Support for Windows Communication Foundation

This is one of the key factors for us to think about migration. The web service support on BizTalk server 2006 is provided primarily by the SOAP adapter and Web Services publishing wizard. By moving to 2009 R2 will open up the opportunity to Microsoft's unified distributed platform Windows Communication Foundation (WCF) seamlessly from BizTalk Servers. WCF provides great enhancement like support for lot of WS * protocols. There is also considerable gain on the WCF adapter configuration.

Examples:

• Choice of Encoding,
• Transactions support using WS-Atomic Transaction
• Imposing restrictions of received message size,
• Better control on the incoming and outgoing message (whole envelope, body, and xpath)

Overall you'll get better web services support compared to the SOAP adapter story.

Reason #5: Developer productivity enhancements

Just by moving to latest Visual Studio platform opens up lot of productivity enhancements for developers.

BizTalk Server 2009 R2 enhanced the mapper productivity to great extend. This is the first major update for the mapper tool UI since BizTalk Server 2004. There are features like

• Moving links between pages
• Searching for nodes
• Hiding out of context nodes
• Auto scrolling to the active nodes
• Relevance tree - show only mapped nodes, to reduce clutter etc

BizTalk Administration console improvements like:

• Ability to configure polling interval on host level
• Ability to export/import setting from one environment to another (ex PERF to PROD)
• Ability to setup host instance registry settings from console.

Support for testing maps.

This is not an extensive list, but you get the idea

Reason #6: Moving to IIS 7.0 from IIS 6.0

This is one of the less highlighted features. As part of platform alignment, it will help us to move from Internet Information 6.0 to 7.0. The difference between 6.0 and 7.0 is revolutionary. IIS 7.0 works on the principal of bare bone configuration, you add required modules your application demand. Again this is going to indirectly support your BizTalk environment configuration if your solution is heavily dependant on Web Services based SOA integration.

Reason #7: Support for new Visual Studio project template and support for MSBuild

BizTalk Server 2006 uses its own proprietary visual studio project template with its own extension points. This makes it harder to do things like MSBuild /Continuous integration etc. Moving to 2009 R2 will give consistent experience with other Visual Studio projects like class libraries.

Reason #8: Enterprise Service Bus (ESB) Toolkit 2.0

This will be one of the great candidates for moving to 2009 R2. Microsoft fully supports the Toolkit which got some nice features like Exception Handling framework with portal. Transformation service, Dynamic routing, construction composite services without using orchestration etc.

More information can be found at http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx

Even though we are not using it at the moment, moving to 2009 R2 will help us think/architect new solution by taking some of the advantages of ESB Toolkit reducing the plumbing work.

Reason #9: Support for Host Integration Server 2009

One of the reasons for move to 2009 is the support for Host Integration Server 2009 which includes WCF Channel for WebSphere MQ support. Being an enterprise coming from IBM background its not a surprise we use MQ heavily in the organisation.

Reason #10: BizTalk Adapter pack and custom WCF LOB Adapter framework

This is one of the nice to have features for us.

Reason #11: Extended BAM Interceptor support for WCF and WF

BAM interceptors extend the functionality enjoyed by BizTalk server to Windows Workflow Foundation (WF), Windows Communication Framework (WCF), and other runtimes. By using the BAM interceptors, you can track your business processes without recompiling your WF or WCF solution - integration is done through a configuration file.

This ability provides the opportunity to bring your external WCF services to participate in the same BAM monitoring framework you build for your applications.

Also, Microsoft relaxed the licensing requirement to use BAM outside BizTalk Server Environment as long as you got a standard or enterprise license in your organisation (I can't find any links to support this statement, but I remember that was the case).

Reason #12: Better system with cumulative bug fixes in the past 3 year.

The obvious one is cumulative bug fixes in the past 3 years.

Big downside if you don't have a Microsoft software assurance

To upgrade from BizTalk Server 2006 to BizTalk Server 2009, you need to acquire Microsoft Software Assurance for BizTalk Server 2006. Acquiring Software Assurance for BizTalk Server 2006 will ensure you receive BizTalk Server 2009 at no additional cost. Otherwise, customers will pay full price for BizTalk Server 2009 if they want to upgrade.

There are various other areas of improvements like RFID, EDI, B2B, Share point integration, etc worth investigating based on your requirements. I also didn't highlight lot of features, which we are not using example SCOM package upgrade, improved trading partner management etc

There are some deprecated features as well from 2006 to 2009 R2, but none of them are relevant to us.

• Human Work flow support
• Business Activity Services Support
• Migration of HAT functionality to BizTalk Admin Console, etc

Nandri!

Saravan

Reposting after server crash!!

Scenario: In this article we are not going to discuss about how to utilize BAM for your BizTalk applications. I've made the assumption; you created few BAM activities and utilized them inside your BizTalk applications and the system is now running on your productions servers. In my experience, majority of the clients don't take advantage of BAM, when they do they just stick to the basics of creating few BAM activities and utilizing them in their applications. So this article is focused only on this basis and we are going to ignore all the fancy BAM stuff like BAM Views, Alerts, Notifications, real-time data etc.

Production Configuration:

At the very high level your production BAM configuration should like the one shown below

 

Step 1: Make sure you deploy the BAM activities:

This one might look silly :-) but it's possible you might have developed your solution taking advantage of BAM and not deployed BAM activities in your production environment. BAM failures are not treated very seriously by the BizTalk runtime. For example: Your orchestration might have BAM code embedded inside, but you haven't deployed the corresponding BAM activities. In this case the orchestrations will complete successfully without getting suspended but there will be lot of events in the event viewer notifying the BAM failures and also records will start accumulate in the TDDS_FailedTrackingData table in the database. Over a period of time this table will grow substantially, resulting in an unhealthy database and its not nice to see lot of failure events in your event viewer, which will interfere with analysing the real issues.

Step 2: Make sure TDDS sub-service is running.

When you configure a BizTalk host with the option "Allow Host Tracking" to true and created a host instance for that host, then you have created a TDDS sub-service inside that host instance automatically.

The important step is to make sure there is at least one BizTalk Host/Host Instance configured to run "Tracking Data Decode Service (TDDS)" in your environment. When you utilize BAM inside your BizTalk applications (inside your Orchestrations, Pipelines etc) BizTalk runtime will utilize one of the asynchronous event stream to write BAM data for performance reasons. When an asynchronous event stream is used, the BAM data will be first written to the BizTalk message box database and its the job of the TDDS service to move the BAM data from BizTalk message box database to BAMPrimaryImport database. If you don't run the TDDS service the data will start accumulating in the message box database and over a period of time will result in a bloated unhealthy message box database. For more info about Tracking host read this article http://msdn.microsoft.com/en-us/library/ee308950(BTS.10).aspx

Step 3: Setup your active window for the BAM data:

Based on your business needs, it will be critical to keep the historical BAM data for certain period.  The default setting by standard BizTalk installation is to keep the data for 6 months. If you are capturing lot of BAM data, you might need to reduce this value to days, weeks or months. You can change the value by using the bm.exe tool.

You can see the existing value by executing the following command

bm get-activitywindow ?Activity:your_activity_name

You can set the active window to desired value by executing the following command

bm set-activitywindow ? Activity:your_activity_name ?TimeLength:1 ?TimeUnit:Day

Step 4: Make sure BAM_DM_<<activityname>> SSIS packages are configured to run

One of the biggest advantages of BAM is it creates the database infrastructure for you to capture business data. You don't need to manually provision the database tables and views; it's automatically created when you deploy the BAM activities using the management tool bm.exe. For every activity deployed there will be 5 corresponding database tables created in the BAMPrimaryImport database with the postfix _Active, _ActiveRelationships, _Completed, _CompletedRelationships and _Continuations (few SQL views will created to work with these tables and corresponding BAM_DM_<<activity name>> SSIS package will be created).

The main reason for this provisioning is to improve the read/write speed while accessing the BAM data. The number of records in the _Active table will be less; it will contain only in-flight instance data, once the instance complete processing the data will be moved to _Completed tables.

This active/completed partition is good to certain extend, until the number of records in your completed tables started to grow, that's where BAM_DM_<<activity names>> SSIS packages comes into picture. This SSIS packages are mainly responsible for 2 tasks:

1. Taking the database table provisioning to the next level, in order to improve read/write access speed, and
2. Removing the old data from the BAMPrimaryImport database. It can either be moved to BAMArchive database or purged as shown in the picture (beginning of the article).

Whenever you run this SSIS package additional tables are created in BAMPrimaryImport database post fixed by a GUID and old data is removed based on the active window configuration.

The SSIS packages for your BAM activities are created when you deploy your activities, but they are NOT configured automatically in your environment. In your production environment it's critical to create a SQL job to run the SSIS packages in a periodic basis (every day or week based on your BAM data volume).

NOTE: If you have installed your BAM databases on a named SQL instance, then you won't see the BAM_DM_ packages automatically when you connect to Integration services. See the topic "Where are my BAM_DM_ <<BAM Activity Name>> packages?" topic in the end of the article for the solution.

Step 5: Whether to archive it or purge it?

Historical Data:

Historical Data in BAM falls under 2 categories.

1. Based on the active window settings the data will be kept in BAMPrimaryImport database for that period. Example: If your active window is set to 5 days, then 5 days BAM data will be held in various activity tables (partitioned with multiple GUID?s) within BAMPrimaryImport database.
2. Any data that's older than the active window will be held in the BAMArchive database until its cleared manually.

It will be a business decision to keep the historical data for governance purpose.  Until recently, before Microsoft issued the hot fix 971984 (http://support.microsoft.com/kb/971984 ) it was not possible to purge the data directly from BAMPrimaryImport database in BizTalk Server 2006. You always need to move the old historical data to BAMArchive database and then purge it manually (see the script in the bottom of the article for doing it).

With the hot fix (its available by default on BizTalk 2009) you can configure whether or not the data goes into BAMArchive database by using the bm.exe tool.

bm set-archive ?Activity:your_activity_name ?shouldArchive:true|false

Where are my BAM_DM_ <<BAM Activity Name>> packages?

If you have installed BAM databases on a named SQL instance and try to connect to Integration Services and expand the MSDB node, you'll see the following error message.

The SQL server specified in SSIS service configuration is not present or is not available. This might occur when there is no default instance of SQL Server on the computer. For more information, see the topic "Configuring the Integration Services Service" in Server 2005 Books Online.

As noted in the error message the solution is available under Configuring the Integration Services article. You need to open the MsDtsSrvr.ini.xml file located under the folder %ProgramFiles%\Microsoft SQL Server\100\DTS\Binn (90 instead of 100 if you are using SQL 2005) and put the correct server name\instance name inside the <ServerName> element.

You need to restart the SQL Integration Service after making this change.

BAMArchive Purge Script:

There is no clear procedures documented in dealing with the data present in the BAMArchive database. Over a period of time BAMArchive database will also grow to substantial size and it will be required to truncate the data. Here is the script I use to truncate the BAMArchive database, please note this will wipe out all the data present in the BAMArchive database (use it at your own risk), but you will still have the historical data based on your active window configuration in the BAMPrimaryImport database.

truncate table bam_<<your_bam_activityname_1>>_Instances
truncate table bam_<<your_bam_activityname_1>>_Relationships

truncate table bam_<<your_bam_activityname_2>>_Instances
truncate table bam_<<your_bam_activityname_2>>_Relationships

<<repeate the truncate table steps for all of your bam activities>>

Declare @SqlQuery nvarchar(4000)
Declare @num int

Set @num = (Select Count([Name]) From sys.tables
Where [Name] like '%bam_%Instances_200%-%-%' Or
[Name] like '%bam_%Relationships_200%-%-%')

-- Print @Num
Declare @i int
Set @i = 0
While @Num > @i
Begin
    Set @i = @i + 1
    Set @SqlQuery = (Select Top 1 'Drop Table [' + [Name] + ']' From sys.tables
        Where [Name] like '%bam_%Instances_200%-%-%' Or
        [Name] like '%bam_%Relationships_200%-%-%')
    Execute(@SqlQuery)
End

Nandri!

Saravana

Normally when we need to consume a .asmx web service in BizTalk 2004/2006 (NOT R2) inside an orchestration, we add a web reference, which will create all the multi-part message and web port type required to consume the orchestration. You construct the orchestration and configure the SOAP adapter in the send port to consume the web service. I suppose that's the normal route any BizTalk developer will take when you are put under a circumstance to consume an .asmx webservice using WCF-BasicHttp adapter.

But when you are going to use the WCF-BasicHttp adapter, "Add Web Reference" is not going to work, and we need to take advantage of the hidden "Consume WCF Service" wizard, which comes as part of BizTalk 2006 R2. The wizard will generate required schemas, multi-part messages, orchestration port types, and also binding files for both basicHttp and custom binding. I'll put the steps here to consume a basic .asmx webservice in BizTalk 2006 R2 with WCF-BasicHttp adapter.

The sample webservice we are going to use contains a very simple webmethod as shown below.

[WebMethod]
public string ConcatName(string firstName, string lastName)
{
return firstName + " " + lastName;
}

The below walk-through is based on the sample webservice, which comes as part of the download.

1. Create a blank BizTalk Project
2. Right-Click on the project and select Add->Add Generated Items->Consume WCF Service
3. Select the option "Metadata file (WSDL and XSD)", Click "Next"
4. 
5. Open an instance of a browser and navigate to your ".asmx?WSDL" file and save it somewhere in your harddrive (Example: c:\Service.wsdl).
6. Click on the "Add" button (next step in the wizard after the one shown above), browse to the .WSDL file you saved in Step 4, Click "Next" (Accept defaults), Click "Import" and then Click "Finish" to complete the wizard.
7. Once you click "Finish" the following files will be added to your project (File name will depend on the name of the .WSDL file you selected)
   Service.BindingInfo.xml
   Service.odx
   Service_Custom.BindingInfo.xml
   Service.tempuri_org.xsd
8. Open the Service.odx file, inside the orchestration view create 2 messages as shown below
   WSRequest - Multi-part Message Type - ConsumeWebService.ConcatNameSoapIn
   WSResponse - Multi-part Message Type - ConsumeWebService.ConcatNameSoapOut
9. Right-Click on the orchestration "Port Surface", Click "Next", In the port properties page Click "Next", In the "Select a Port Type" page select "Use an existing Port Type" and select "ConsumeWebService.ServiceSoap", In port binding page select "I'll be sending a request and receiving a response." for port direction and "Specify later" for port binding. Click "Next" and then "Finish".
10. Construct an orchestration as shown in the below figure
    Receive_1 -> Activate=true, Message= WSRequest
    Send_1 -> Message = WSRequest
    Receive_2 -> Message = WSResponse
    Send_2 -> Message = WSResponse
11. 
12. I created a FILE Receive and FILE Send (Specify Now) port binding for port_2 and port_3
13. Assign a key file to the project and set the "Application Name" to "ConsumeWebService". Build and Deploy the project.
    Open BizTalk Administration Console, Right-Click on the application and select "Import Binding". Browse to the auto generated binding file "Service.BindingInfo.xml" and select it.
14. Bind your Orchestration to the correct ports and host. For the .asmx webservice logical port, select the auto generated "WcfSendPort_Service_ServiceSoap". (Start the application)
15. Create a sample message by right-clicking on "Service_tempuri_org.xsd" file and clicking "Generate Instance". Drop the message in the folder you configured for port_2 in the orchestration, you should see the output result in folder you configured for port_3 in your orchestration.

Download the sample here

Nandri!

Saravana