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

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

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

I was contacted by [PACKT] publishing to give a reviews of the book SOA Patterns with BizTalk Server 2009, in order to do so they also send me a free copy of the book. Instead of glimpsing through the book and writing a brief review within couple of days, I took nearly 2 months till I completed reading the whole book, before writing this review. This review is purely based on my experience reading the book and not influenced by any external factors.

Reader Level:
In my opinion this book will be suitable for novice BizTalk user to Advanced BizTalk user.

Rating:
My overall rating for this book will be 3.5 out of 5.

First of all the title of the book itself is so appealing, Richard picked up two hot topics (SOA + BizTalk) and made an interesting title. This is the first book released with the heading BizTalk Server 2009, hence it will be obvious from the readers they expect new stuff from BizTalk 2009 explained in the book.

Chapter 1: BizTalk Introduction:
Users with basic understanding of BizTalk Server can skip this chapter. You need an introduction to the book, it will be hard to jump into advanced topic without setting the base.

Chapter 2 and 3 : BizTalk Server and WCF:
Users with basic understanding of BizTalk Server and WCF (if you have consumed/published WCF services in BizTalk), can skip these chapters.

SOA is an architectural style, its all about the way people build software rather than they go and buy something off the shelf. Even though SOA can be build without any Web Services, often people relate SOA with web services and majority of the times web services acts as key building blocks/foundations in order to take the enterprise SOA ready.

When we are talking about web services in Microsoft stack, it maps directly to the usage of Windows communication Foundation (WCF) as a single unified development platform for building distributed applications.

Usage of Windows Communication Foundation (WCF) inside BizTalk was brought main stream from BizTalk Server 2006 R2. Unfortunately there are no books published specially for "R2" and hence none of the available BizTalk books explained anything about WCF. Readers purely relied on bunch of online articles, blog posts and product documentation to learn and understand BizTalk and WCF. Richard broken that barrier by dedicating 2 chapters of the book talking purely about BizTalk and WCF. He also explains the Asynchronous messaging pattern, WCF and BizTalk in Chapter 6 of the book. The chapters provides a well guided tour of WCF-BizTalk.

Chapter 9 - WCF SQL Adapter, Chapter 10 - UDDI Service, Chapter 11 - ESB Guidance 2.0:
In my opinion these chapters are more like stand alone articles rather than a chapters in the book. They are isolated on their own rights and explain the topic. Chapter 9 explains all about WCF SQL Adapter, this is the best piece of content I've seen for WCF SQL Adapter. Chapter 10, introduces readers to UDDI Service V3 and explains how you can set it up and start consuming it. Chapter 11, introduces readers to the ESB Guidance 2.0 (renamed to ESB Toolkit 2.0 after the release of the book). It explains the basics of Error handling framework, itineraries, various web services that comes as part of the tool kit. Chapter 9 and 10 gives a quick start to UDDI and ESB Toolkit. I personally reverted back to these chapters, when the ESB Toolkit 2.0 was released to get started.

Readers can jump into these chapters directly, without reading any part of the book, which is good in a way. If in case you don?t have the book you can read these chapters online

New SOA Capabilities in BizTalk Server 2009: WCF SQL Server Adapter

New SOA Capabilities in BizTalk Server 2009: UDDI Services

Chapters 4 to 8:
These chapters are the key ones explaining the relationship between BizTalk Server and SOA principles. In these chapters Richard explains some of the key SOA concepts like Canonical Schemas, message exchange patterns, schema/end point versioning, loose coupling, abstraction, etc. Advanced BizTalk users might feel some of the basic concepts of BizTalk server architecture like Publish/Subscribe, supports for schemas, rules engine, direct binding ports in Orchestration service consumption/publishing etc are directly mapped to SOA concepts and reading those pages more of a refresher rather than something new. But the writing does the justice to the book title, linking SOA concepts and BizTalk concepts.

Chapters 12:
In this short chapter, Richard glimpsed through Dublin, .NET Services and Oslo giving users some hint about, what's coming out of Connected Systems division at Microsoft.

Conclusion:
SOA and BizTalk are two complicated subjects, if I say everything related to these topics are explained in this 375 page book, then its not fair. In fact I'm currently reading the book Web Service Contract - Design and Versioning (http://www.soabooks.com/book.asp?book=soa_web_service&page=overview) 800+ pages book dedicated purely for contracts. Richard had put his fair share introducing readers to some of the core SOA principles, explaining some of the new stuff in BizTalk 2009 and creating a link between some of the well known concepts in BizTalk Server to SOA principles. Overall this book is a good read, some of the advanced BizTalk users may find some of the chapters more of a refreshing read rather than learning something new. I need to praise the way Richard had composed this book, if you enjoyed reading his blog, you'll enjoy reading this book as well.

Nandri!
Saravana

In the previous  post I've shown a Hello World example utilizing the ESB Toolkit Exception management framework inside an Orchestration. Its very common a BizTalk solution can be purely based on messaging (aka content based routing) without any Orchestrations. In this post, I'll show you how you can take advantage of the ESB Toolkit 2.0 exception management framework inside your messaging only solution.

ESB Toolkit 2.0 Exception Management Framework relies on BizTalk servers "Failed Message Routing" capabilities in a messaging only scenario. You can enable failed message routing either at the Receive Port  or Send Port. Once its enabled, whenever there is an exception while publishing the message into MessageBox or transmitting the message to the end point BizTalk Server will create and publish routing failure message with all relevant promoted properties into the MessageBox database.

Installation of ESB core components (or just Exception management components) installs a generic send port called "All.Exceptions" as part of the Microsoft.Practices.ESB BizTalk application. The send port basically contains 3 pipeline components, configured with SQL Adapter and the filter condition is set as shown below.

The top property ErrorReport.FailureCode is promoted by BizTalk Server whenever it publishes a Routing failure message into the MessageBox, so the generic Send Port (All.Exceptions) subscribe to any failed messages that get published into the system. The core logic relies on the 3 pipeline components configured in the send port as shown below.

The first component ESB Exception Encoder is the one responsible for normalizing the fault message generated by either BizTalk Servers Failed Message routing in messaging only scenario or the one we explicitly published from the exception handling block in the Orchestration into a canonical message that comply with the ESB Exception reporting Schema.

The ESB BAM tracking component is responsible for logging the exception details into the BAM Primary import database, in our case its disabled (Enabled:False).

The final component ESB Transform is responsible for transforming the canonical ESB Exception message into SQL Adapter expected format. The message then finally gets processed by SQL Adapter and get stored in the ESB Exception management database (EsbExceptionDb).

Now, you can see the logged exception details via the ESB Exception management portal as shown below.

In the Fault viewer page, you can click on the Message Id link to view the original message that failed to get published into the MessageBox database, you also got the option to resubmit the message back into the BizTalk server from the Message Viewer Page if required.

Nandri!

Saravana

ESB Toolkit 2.0 comes with set of components that help you build loosely coupled ESB/SOA application on top of BizTalk Server 2009. You can take advantage of the ESB Toolkit by using only certain components of the package relevant to your application. One of the core components of the toolkit is the Exception Management Framework, which comes with the required helper components, web services, BizTalk ports, a sophisticated management portal etc that will help you build a standard and scalable exception management platform for your application without much custom coding.

It's always a problem for lot of us to get a starting point. In this post, I'll put a complete walk through of building a Hello World application to show you the basic idea of the Exception Management Framework in the ESB Toolkit. Before starting this exercise please make sure the ESB Toolkit is installed and configured correctly, and you got a working Exception Management Portal. Refer to my previous posts (here and here) showing how to set it up.

Solution:

Our sample application receives an Employee Request (id, firstName, lastName, Date of Birth) into an Orchestration. Age is calculated and an Employee Response (id, age) is send to an end point. If DOB field is invalid, it will result in an exception. The Orchestration got an exception handling logic (the way you do it normally using scope and exception handler). The only addition to "Catch Exception" logic is we construct the ESB fault message and submit it to MessageBox via Direct binding (no additional send ports required). The below figure shows the whole orchestration.

Step 1:

In order to use the ESB exception handling framework you need to reference couple of dlls. Add Reference to the following dlls inside your Orchestration project.

C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bin\Microsoft.Practices.ESB.ExceptionHandling.dll

C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\Bin\Microsoft.Practices.ESB.ExceptionHandling.Schemas.Faults.dll

Step 2:

Declare a new Orchestration message (ex: MSG_FAULT) and set the MessageType to Microsoft.Practices.ESB.ExceptionHandling.Schemas.Faults.FaultMessage, which you can find under the "Select from Referenced Assembly.." option.

Step 3:

Inside your Exception handling block construct the fault message (the one created in step 2) with relevant information required. The code will look like

   1: // Create Fault Exception Message

   2: MSG_FAULT = Microsoft.Practices.ESB.ExceptionHandling.ExceptionMgmt.CreateFaultMessage(); 

   3:  

   4: //Assign some properties

   5: MSG_FAULT.FailureCategory = "Some User Category";

   6: MSG_FAULT.FaultDescription = ex.Message;

   7: MSG_FAULT.FaultCode = "3002002"

   8: MSG_FAULT.FaultSeverity =

   9: Microsoft.Practices.ESB.ExceptionHandling.FaultSeverity.Severe; 

  10:  

  11: //Add request message (any other message if present)

  12: Microsoft.Practices.ESB.ExceptionHandling.ExceptionMgmt.AddMessage(MSG_FAULT,MSG_EMP_REQUEST);

Step 4:

Create a "Direct" bound port and link this logical port with the send shape that's configured to send MSG_FAULT as shown in the above figure. Since its a Direct bound port no additional port configuration is required from your orchestration apart from your regular business related ones.

That's all really, how simple is it!!

Whenever there is an exception in our application an ESB Fault message will be generated and published to the MessageBox. Lot of properties will be promoted when this fault message is published, so you can construct your own error handling Orchestration to deal with the situation or have a send port configured to send email, send to MQ etc, etc the choice is yours. In addition to your own logic, the ESB Core application got a standard "All.Exception" send port (SQL Adapter) configured to capture any Fault message arising in the system and log it to the Exception management database. As part of the fault message lot of properties are added things like machine name, application name, service name, service instance id, etc etc which all gets inserted into the exception management database automatically and show up nicely in the portal as shown in the below figure taken from the management portal (default address http://localhost/ESB.Portal ).

Hope this gives a quick intro to get you started.

Nandri,

Saravana

I started doing some prototype using ESB Toolkit 2.0 Exception management framework and encountered the following exception when FaultMessage was transmitted to the Exception Management database via the generic ALL.Exceptions SQL send port under Microsoft.Practices.ESB application.

The adapter failed to transmit message going to send port "ALL.Exceptions" with URL "SQL://(local)/EsbExceptionDb/". It will be retransmitted after the retry interval specified for this Send Port. Details:"Could not load file or assembly 'Microsoft.Data.SqlXml, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.".

Looking at the GAC, there were couple of Assemblies with the name Microsoft.Data.SqlXml with version number 3.* and 9.*. But in our case its looking for 10.*. Doing some quick search revealed the dll is part of SQLXML 4.0 SP1, download and installation of SQLXML 4.0 SP1 (which is part of Microsoft SQL Server 2008 Feature Pack, October 2008) from the following link resolved the issue.

http://www.microsoft.com/downloads/details.aspx?familyid=228DE03F-3B5A-428A-923F-58A033D316E1&displaylang=en

Nandri!

Saravana

There is enough buzz in the BizTalk community about the announcement of the newly renamed ESB Guidance Toolkit 2.0 which sits on top of BizTalk Server 2009. You can download it from here.

The documentation that comes out of the package is really good, but since its a first release of the tool kit there is obviously some gaps. In this post I'll explain the issues I came across while configuring the Exception management portal on Windows 2008 machine with IIS 7.0 and how I overcame them to have a working portal. The issues are mainly surrounding the supporting technologies like power shell and Windows communication foundation.

Step 1: Install the BizTalk ESB ToolKit Core.msi

This MSI file is a typical BizTalk Application MSI file so follow the procedures you'll follow to install a BizTalk Application MSI. Open the BizTalk administration console and import the MSI, later in the wizard select the "Run the MSI" option to install it.

Step 2: Run the Management_Install.cmd powershell command:

You need to unzip the ESBSource.zip file which contains the set of sample applications. Exception management portal is provided more like a sample web site, which you can enhance it according to your needs. Before running this command, you need to make sure

1. You generated the key file under C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\ESBSource\Keys\Microsoft.Practices.ESB.snk

2. Fix the Windows PowerShell execution policy restriction as described below.

Navigate to \Samples\Management Portal\Install\Scripts, and then run ManagementInstall.cmd. At this stage you'll receive an error message as "ManagementInstall.ps1 cannot be loaded because the execution of scripts is disabled on this system.. Please see "get-help about_signing" for more details"

The problem is mainly because Windows PowerShell restricts the execution of saved scripts by default. To see your current settings, open power shell command window and type "get-executionpolicy", the output will be "Restricted", which is default. Change it to unrestricted by issuing the command "set-executionpolicy Unrestricted". This changes the policy until you change it again (For obvious reasons you'll need to change the execution policy to restricted after finishing your task).

Now, you'll be able to run the ManagementInstall.cmd, which should complete without giving any errors.

Now, If you navigate to the url http://localhost/ESB.Portal/Default.aspx, you will be redirected to an error page asking you to check your event log. The event log will have an entry saying 404 not found.

Step 3: Follow the instructions in the documentation under "Configuring Services and Components".

The Exception management portal internally relies on set of web services (operations, ExceptionService etc) to function correctly. So, if these services  are not installed an exception will be raised. Follow all the steps under "Configuring Services and Components" to install the supporting services.

Step 4: Update IIS script maps to register .svc extension

Exception management portal relies on a WCF service called http://localhost/ESB.Exceptions.Service/ExceptionService.svc for its internal operations. By default there is no script map for .svc file with default IIS 7.0 installation, so register the script map using the following command

C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation>ServiceModelReg.exe -r -y

Step 5: Make sure the users are in right NT roles

Exception management portal relies on BizTalk NT groups for authentication and authorization. So make sure you are in the correct group "BizTalk application users" for normal users and "BizTalk Administrators group" for admin users.

If you still face issues, there is a trouble shooting section in the documentation, which will give you more help.

Nandri!

Saravana 

BizTalk Server 2009 Hyper-V guide is released on 17th April which can be downloaded on Microsoft Download Center.

I'm very happy to be one of the reviewers for this guide. I'm also grateful to Microsoft for mentioning my name on the Acknowledgment section. I just wanted to highlight some of the points

1. The emphasis on this guide is mainly around BizTalk Server performance, it contains details about lot of performance counters and ways you can performance test your BizTalk application. So, just don't get fooled around by the heading.

2. Also, apart from the virtualization topic majority of the performance testing considerations are still valid for older version of BizTalk server like 2006 and 2006 R2.

I guess its going to be hard job to go through the 135 page document, unless otherwise you are thinking about virtualizing your BizTalk environment. For those of you who are interested in getting a very high level impact of BizTalk  on a virtualized environment I guess this graph gives a good indication (taken from the guide - page 75).

Nandri!

Saravana

Today I was trying to install the BizTalk 2009 public beta bits on a virtual machine running

• Windows XP SP3 ( BizTalk 2009 won't install if you don't have SP3, so I did a windows update to get all the latest bits)
• SQL 2008 RTM
• VS 2008

BizTalk installation went fine without any issues. Most of you guys who have used BizTalk long enough knew always the tricky bit starts with BizTalk configuration, it can fail for variety of reasons right from MS DTC setting, Database Access, permission etc etc.

I selected basic configuration with a local account. Installation was failing constantly right on the first step configuring Enterprise Single Sign on. Received following error messages

Error 1:

Failed to generate and backup the master secret to file: C:\Program Files\Common Files\Enterprise Single Sign-On\SSO48AE.bak (SSO) Additional Information (0x80070005) Access is Denied.

Error 2:

An error occurred while attempting to access the SSO database. See the event log (on computer 'SK-XP-VM') for more details.
(SQL: 0x000000E9: A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.))

Solution:

1. Create the SSO Administrators group manually

2. Add the service account and logged in account to the group.

3. Re-run the configuration wizard.

Bit weird, but it works!!

Nandri!

Saravana