Mattias Lindberg : BizTalk

News about BizTalk Server 2009 and alignment with Oslo

mattlind — Fri, 05 Sep 2008 23:13:06 GMT

The roadmap for BizTalk Server has been updated with details about BizTalk Server 2009 (previously known as BizTalk Server 2006 R3). Some highlight are:

Support for the latest and greatest development platform; Windows Server 2008, Visual Studio 2008 SP1, SQL Server 2008 and the .NET Framework 3.5 SP1. It also adds support form virtualization through Hyper-V.
Extends the developer experience by adding support for Team Foundation Server (TFS).
Enhanced support for SOA and Web Services; UDDI 3.0 registry, ESB Guidance 2.0, WCF support for WebSphere MQ
New LOB adapters for Oracle E-Business Suites and SQL Server and updates for existing adapters.
EDI and AS2 support will be enhanced along with updates to the SWIF. RFID support will also be extended.

Even though future versions of BizTalk (after the 2009 version) will add support for Windows Workflow Foundation (WF) it is clearly stated that Microsoft is "committed to continued support for BizTalk Server’s XLANG orchestration technology".

Follow this link to go directly to news about the future releases: http://www.microsoft.com/biztalk/en/us/roadmap.aspx#WhereWereGoing

BizTalk Server 2004 SP2

mattlind — Fri, 27 Oct 2006 09:50:00 GMT

Service Pack 2 for BizTalk Server 2004 has just been released!

Read about List of bugs that are fixed in BizTalk Server 2004 Service Pack 2 and download Microsoft BizTalk Server 2004 Service Pack 2. Download, test, deploy and enjoy!

Summary of BizTalk Server Documentation Updates

mattlind — Thu, 05 Oct 2006 20:18:00 GMT

Below is a summary of documentation updates that has been published during the last three months.

I would just like to add a link to the page that contain the new code samples.

Core Documentation | Download

The BizTalk Server 2006 Help is updated every two weeks and posted in downloadable chm. format. Check out the following new and updated topics!

Improvements to the Orchestrations help, including the following new topics:

How to Use MessageBox Direct Bound Ports
How to Use Partner Orchestration Direct Bound Ports
How to Use Self-Correlating Direct Bound Ports
Working with Direct Bound Ports in Orchestrations
How to Debug Design Time Errors and Build Errors
Writing Information to the Event Log
Interactive Debugging of an Orchestration in HAT
Tracking Orchestrations with HAT
Working with the Orchestration Debugger
How to Use Expressions to Transform Messages
How to Create Role Links in Orchestrations

Improvements to the Business Rule Engine help, including the following new or updated topics:

Invoking Static Members of a Class
Support for Generic Types and Generic Methods
Accessing Nested Members of a Class
Support for Type Casting
Support for Class Inheritance in the Business Rule Engine
Support for Nullable Types
How to deploy policies (programmatically)
Performance Considerations When Using the Rule Engine

Improvements to the SAP adapter help, which was integrated into the BTS06 collection:

Added the "Architecture and Planning" section.
Reinforced .NET Connector version requirements in the installation topic.
Added "Enabling and Disabling SAP RFC and CPIC Trace" with additional details about CPIC trace (CPIC trace supports 4 different trace levels including none). Includes script per doc.
Added " How the Adapter Communicates Using RFCs and IDoc: SAP Connector for Microsoft .NET" section.
In the "How to Troubleshoot the Adapter" topic, added section for transaction lock error.
Modified the troubleshooting topic to mention SAP Monitoring area and SAP RFC testing.
Added troubleshooting information for "BizTalk service is not receiving IDOC's from the SAP system."

More troubleshooting information!

How to troubleshoot BTS administration, permissions, performance, adapters, dependencies, and configuration.
How to capture a memory dump of a BTS processes.
Which tools and utilities you should use for troubleshooting.

Updated Installation, Configuration, and Upgrade Guides | Download

The installation instructions explain how to install BizTalk Server 2006 on Windows XP, Windows 2000 Server, or Windows Server 2003 in a single server or multiserver environment.

Whitepapers

The following is a list of whitepapers that have been published since RTM.

Localization Updates for the BizTalk Server 2006 Documentation

The documentation has also been updated and is available in .chm format in the following languages:

An outside-of-Visual-Studio-BizTalk Explorer

mattlind — Thu, 05 Oct 2006 14:07:50 GMT

Are you using BizTalk Server 2004 and discuss if Visual Studio should be installed on production server? Then I've got the tool for you!

More than once I've had discussions with customers about the need to use Visual Studio to manage BizTalk Server 2004 solutions. There is no absolute need to use Visual Studio but it helps if you need to verify that your deployment has been successful. Installing Visual Studio always starts the pain process for the people who are responsible for the production servers, and I can only explain their options...

But two weeks ago one of my customers showed me a tool which is described as "an outside-of-Visual-Studio-Biztalk Explorer". This is a tools that looks so similar to BizTalk Explorer in Visual Studio that I wonder if they are somehow hosting that tool in their own UI, but probably they have only been "inspired" by the look-and-feel.

I must admit that I have not really used this tool, we installed it and then used it to examine the deployed application which took perhaps 30 minutes. But the person who told me about the tool say that it works great.

You can download the tool here: http://www.gotdotnet.com/workspaces/workspace.aspx?id=c2bd2cac-6fd8-4ee5-b524-4dcba88f7464

For those of you who are not familiar with BizTalk I must end by saying that BizTalk Server 2006 has solved the problem discussed above. BizTalk Server 2006 comes with an MMC called BizTalk Server Administration which allow you to perform all types of configuration and administration. So this post only applies to BizTalk Server 2004 customers.

New Whitepaper: Managing a Successful Performance Lab

mattlind — Tue, 26 Sep 2006 09:29:00 GMT

A recent whitepaper called Managing a Successful Performance Lab was just brought to my attention, if you're about to perform a performance or stress test this whitepaper is for you. Even though it is written in the context of BizTalk Server 2006 I think you can utilize the techniques described in many types of applications, use it as a template and utilize the parts that apply to your application.

Please note that this whitepaper is not only a high-level discussion, it provides sample on purposes, testbeds, gathering of results, checklists, etc. The abstract says:

An essential part of every mission-critical application’s pre-release testing should always be simulated performance and stress testing. This paper outlines some key strategies for managing a successful performance lab with Microsoft BizTalk® Server 2006.

BizTalk Server 2006 Developer’s Troubleshooting Guide

mattlind — Thu, 14 Sep 2006 08:30:00 GMT

I just got a tips to look at a recently published document called BizTalk Server 2006 Developer’s Troubleshooting Guide. It's huge (133 pages), it's detailed and it covers all technologies in BizTalk.

I cannot say that I have read it, but I downloaded it and intend to keep it near when trouble appear.

Does BAM Require Local Installation of SSIS? No!

mattlind — Wed, 30 Aug 2006 10:46:00 GMT

Today I helped a customer install BizTalk Server 2006, they did not have much experience with BizTalk so I was assigned to assist them. We followed the BizTalk Server 2006 Installation and Upgrade Guides documents, mostly the multi-server version but the single-server Windows Server 2003 is also useful for reference (as part of the multi-server version is too complex due to fail-over cluster configurations). What I wanted to share was one of the problems that was came across and how we solved it (ever heard of RTFM?).

Installation was done and we the had BizTalk Server Configuration application started. We had entered all information about groups, accounts, databases, ... But one problem still remained, there was an an error related to BAM Analysis. When when we clicked on the error this window was shown.

For the benefit of the search engines I'll also type the text:

Microsoft SQL Server 2005 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine. Please install Microsoft SQL Server 2005 Integration Services. (Microsoft.BizTalk.Bam.CfgExtHelper.ToolsHelper)

Additional information:

Could not load file or assembly 'Microsoft.SqlServer.ManagedDTS, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dc8080cc91' or one of its dependencies. The system cannot find the file specified. (Microsoft.BizTalk.Bam.CfgExtHelper)

Even after reading this message multiple times we did not really understand what the problem was. The error clearly states that SQL Server 2005 Integration Services (SSIS) should be installed on the same machine as BizTalk is running on, but that just sounds silly! After having verified that the remote SQL Server actually had SSIS installed and that the Microsoft.SqlServer.ManagedDTS assembly really was missing, we started suspecting that we had taken a short-cut during installation of SQL Server Client Tools (one of the pre-requisites for BizTalk).

We modified the client tools options to also include the Business Intelligence... and the Management Tools options. While still keeping BizTalk Server Configuration application open we once again clicked Apply Configuration, but we still got the same error. I thought that perhaps the configuration application caches this information, so we restarted the application. After having imported the previous configuration we once again clicked Apply Configuration. And it worked!

When reading the documents referenced above they clearly list which options in the client tools installation that should be included. Business Intelligence... is not included but the Management Tools is. The conclusion is that the Microsoft.SqlServer.ManagedDTS assembly is installed and registered as part of the Management Tools option, but we cannot be 100% sure.

Disclaimer: The order of our actions are somewhat modified to be able to properly illustrate how the problem can be solved.

Summary

The error indicate that due to the BizTalk requires managed (i.e. .NET) access to DTS we need to install SQL Server 2005 Integration Services on the same machine as BizTalk. But the actual error is that the Management Tools option in SQL Server 2005 Client Tools has not been installed. This is clearly described in the documentation, so this was a case of RTFM.

Webcasts on BizTalk Scenarios

mattlind — Mon, 28 Aug 2006 12:40:00 GMT

Kevin Lam talks about BizTalk Server 2006 End-to-End Scenarios: Business Process Management and Richard Seroter talk about End-to-End Scenarios: Creating Service-Oriented Solutions with BizTalk Server 2006.

It's interesting how one finds resources when one is not actively looking for them. I was just browsing around at msdn.microsoft.com when I found the two webcasts listed above. I downloaded both, the first is 7 MB with 1:06h of viewing and the second is 8 MB with a length of 1:09h. Both relate to the BizTalk Scenarios, or BizTalk End-to-End Scenarios which is the full name.

I once co-presented the first webcast at an internal conference together with Ken Knight, and as preparation for that I had several discussions together with Kevin as he has been deeply involved in the development of the BPM scenario. That he has influenced my view on this topic is quite obvious when I listen to the webcast, our main points are formulated very similar and he uses a few expressions that I also have used in my text.

I think that the code walkthrough Kevin performs about the Business Process Versioning pattern is very valuable if you are trying to understand that pattern, it is a very nice extension to my attempts to describe it in my post.

As these webcats provide lots of great information I'm going to find inspiration (or steal :-) in their content and base some more BizTalk Scenarios blog posting on the topics in them. I already had the Interruptable Business Process and Request Broker topics lined up, and perhaps I will be able to finish them quicker now.

Business Process Versioning - Updating Running Business Processes

mattlind — Mon, 21 Aug 2006 11:30:00 GMT

Continuing my coverage of best practices and patterns in the Business Process Management (BPM) scenario I examine how the problem of versioning the business process has been addressed. Even though I have been able to base much of the content from a presentation I did on this topic six month ago this has by far been the hardest post to write for me so far, I have been working on it on and off for about a month without really being satisfied with the contents. But after another rewrite over the weekend I think I have managed to catch the essential parts of Business Process Versioning, as illustrated by the BPM scenario.

The Problem

A business process that contains long-running steps, e.g. async receives from external systems or delays, may be hard to update. One example of such a business process is when you involve human interaction in your processes, you simply do not know if someone will complete a task in five minutes or in two weeks. Another example is waiting for a response from an external system which will batch responses to be sent every night.

In BizTalk terminology you wish to deploy a new version of the orchestration implementing the updated business process and the first step is then to undeploy the old version, the problem is that if an orchestration has running instances you cannot undeploy it. If you have a frequently used orchestration with long-running steps there is a high risk that you always will have running instances of the orchestration, so you will never be able to undeploy the old version and hence never be able to deploy the new version...

There are actually two problems:

You cannot easily deploy a new version of the orchestration as the old version cannot be undeployed, this us due to that it has running instances which will have to run to completion first.
Even if you are able to deploy a new version of the orchestration (using two parallel versions) the already running instances will NOT pick up the changes you have made to the business process.

The first problem is probably a good topic for a future post but in this one I will address the second problem, as that is what the BPM scenario addresses.

An Example to Illustrate the Problem

Suppose you have an approval process with the following steps:

Request received => Notify approver => Wait for approval => If approved, send to supplier

Typically this process will swiftly run to the "Wait for approval" step and the it will have to wait for the approver to take an action. Then suddenly requirements change for the approval process, it is now also required due to SOX compliance that we log the result of the approval process. The process now looks like this:

Request received => Notify approver => Wait for approval => Log approval result => If approved, send to supplier

Assuming you are using an approach with monolithic orchestrations all the steps of the approval process will be implemented as a single orchestration. As a result you will not be able to update the business logic of the already running approval processes, even though they have not yet completed the "Wait for approval" step. Of course you can deploy a completely new version of the business process and have new instances of it pick up the changes, but you will still have the problem with the running instances.

The Solution - A Request Manager with Multiple Stages

To understand the solution you need to realize that a business process does not need to be represented as a single orchestration. This is probably nothing new to you as you may have used Call or Start shapes, but have you really considered splitting the main logic of the business process into multiple semi-independent orchestrations. That is what the BPM versioning pattern is about!

Stages

The solution to the problem of updating already running instances of a business process is to avoid building large orchestrations that include all the steps required for the business process, instead you should split your business process into multiple smaller orchestrations which (when executed in sequence) provides the required steps. In the BPM scenario each such step is called a Stage.

A key decision when using the BPM design is to decide which business logic goes into which stage. One way to do this is to do a prototype design using a single orchestration to understand the characteristics of the business process, and the split the business logic into stages using the following guidelines:

Split along long running persistence boundaries, i.e. where you wait for async responses from other systems. Typically this is immediately after a request-response exchange.
Keep atomic parts together. Parts that should be executed as a unit-of-work should be in the same stage, even if they don’t formally enlist into a transaction.
Each stage will add overhead to the system, which will impact both performance and scalability. So to create a stage out of every single shape in your orchestration is probably not a good idea.

While I have not used this pattern in any real project yet I feel that keeping the number of stages low is key. If you create a stage for each of the logic part of the business process you will end up with a large number of stages that you will have to administrate and maintain. In the example above I would only create two stages: one with the "Request received", "Notify approver" and "Wait for approval" steps and one with the "Log approval result" and "If approved, send to supplier".

The key design issue with stages are that at every point where your orchestration does not immediately complete a step there is a risk that someone have deployed a new version of business logic that needs to be used by the already running business process. So I would concentrate on the the guideline: split along long running persistence boundaries.

Request Manager

The BPM scenario also require that you implement an über-orchestration that is responsible for driving the business process forward, it does this by calling the stages in sequence. This über-orchestration is called a Request Manager which does not contain any business logic.

When the business process must be started the request is routed to a new instance of the Request Manager (RM), each specific process will have it's own instance of the RM orchestration. The RM initiates the first stage and wait for it to complete or fail, it decides which by examining the message which is sent back from the stage. When the first stage has completed the second stage is initiated by the RM and then it waits for its completion. And so on… This way the RM doesn't really need to have any knowledge about the specifics of each stage, it is only responsible for driving the process forward by calling the stages one by one, as long as the are successful.

A key design requirement for the Request Manager is that it should be so generic and free of business logic that you would never have to version it. Because if you have to version the Request Manager while you have running instances of it you're back on square one, you have gained nothing!

Implementation

How do you implement this pattern? It may not be completely clear when you examine the implementation of the BPM scenario exactly how the implementation is done and which parts of the implementation is most important. Let me give you a few guidelines:

The OrderManager project contains the OrderManager.odx orchestration which is the implementation of the Request Manager in BPM.
The stages are implemented by CableOrder1.odx and CableOrder2.odx (in projects CableOrderStage1 and CableOrderStage2), but much of the business logic is actually implemented by orchestrations in the CableOrderActions which initialized using Call shapes in the actual stages. It is not necessary to look at the orchestrations in CableOrderActions in order to understand the versioning pattern in BPM.
The message send from the Request Manager to each Stage is a multi-part message, see OrderMgrMsgType in the Orchestration View. The first part contains routing information used to find the correct stage, and the second part is an XmlDocument which can contain any type of message. Using XmlDocument is key to keep the Request Manager free from stage-specific implementation details which may change, and if they change there is a risk that the Request Manager in no longer valid and need to be versioned (back to square one!).
The Request Manager does not contain any specific knowledge about the type of stages involved in the business process and not even the number of stages is hard-coded (it's read from the SSO).
To initiate a stage it publishes a message to the MessageBox using a direct bound port (actually it uses Inverse Direct Binding which you can read more about here), and it is the responsibility of each stage to activate itself when its stage number is published. The stages uses a filter expression on the activating receive shape to determine if a message is targeted for them.
There is a Loop-shape which executes while there are unexecuted stages. So when one stage has been successfully executed the next will be started.
The implementation becomes a bit cluttered as it also contains an implementation of the Interruptable Business Process pattern (which I will examine next in this series on BizTalk scenarios).

One thing that I find a bit unsatisfactory about the implementation is that the stages are executed in sequences based on numbers (1, 2, ...). I would have preferred a somewhat more complex control process, I have one in mind and will think about it some more to see if it works.

Conclusion

Using the Request Manager - Stage to implement versioning of business processes a great pattern that everyone should know about, but you should only use it when you really need it as it complicates the design a bit.

The implementation of the pattern in the BPM scenario is not entirely easy to digest, as it contains implementations of other complex patterns as well. I'm considering providing a smaller and cleaner implementation which only focuses on the Request Manager - Stage pattern, but I won't promise to do this.

Whitepaper Comparing BizTalk 2004/2006 Adapter Performance

mattlind — Tue, 15 Aug 2006 10:30:00 GMT

Richard Seroter's blog made me aware of a new MSDN whitepaper that compare performance in adapters BizTalk 2004 vs. 2006. You can download the whitepaper here

While comparisons between the two versions are interesting I find the most interesting thing to be that the hardware used in the test is small and common enough (ignoring 15k SCSI drives and the SAN) that it should be possible to reproduce these tests at customer sites and get similar results.

So how can one use this? Well, whenever someone complains about BizTalk performance you can start by helping them set up a test some of these simple tests and compare throughput to the numbers in this document. If you find big differences you know to look at the server configuration as similar hardware etc. should give similar results. If the performance on the other hand is near those quoted in the document you can conclude that the server configuration is ok and can start looking at the design of the solution.

Even though the report is not as detailed as a full TPC-C report (3 MB example)(but who really wants that anyway?) is does include useful information about how to increase HTTP connections for BizTalk and also a sample on how to poll data from SQL Server reliably (this was once a favorite topic of mine, so I think I will have to follow up with a separate post on this).

Please note that the throughput quoted in the doc is sustainable throughput, read Wayne Clark's explanation of this.

EDIT 2006-08-28: Added link to whitepaper...

Accessing and Listing Message Context Properties in Pipeline Components

mattlind — Thu, 10 Aug 2006 11:00:00 GMT

Stephen Kaufman has in a blog listed all message properties that you can access when you are in a pipeline component. I have recently needed to use some of these properties so I wrote the code below which lists all context properties. The call to ctx.Read is how you access the information in the property.

IBaseMessageContext ctx = inmsg.Context;
string name;
string nspace;
for (int loop = 0; loop < ctx.CountProperties; loop++)
{
   ctx.ReadAt(loop, out name, out nspace);
   string value = ctx.Read(name, nspace).ToString();
   System.Diagnostics.Trace.WriteLine(name + "\t\t" + nspace + "\t\t" + value);
}

When I compared the lists generated from my receive and send pipelines I noticed that they were different from Stephen's. My guess is that the reason for this is that his list was generated on BizTalk 2004 while my list is generated on BizTalk 2006. The following tables list all properties that I found (as the File adapter was used for these tests there are a few File adapter-specific properties included). You may note that the properties is sorted by namespace, this is not my doing because this is the order in which they were printed!

For each property I list if the property is new or not, the name, the namespace, and a sample value. The sample value is to help you understand what type of information the property contains.

Receive Pipeline Properties

There are now 19 properties in the receive pipeline, one deleted and six new. Please note that MessageType, SchemaStrongName and SourceCharset only appears after the Disasseble stage has been executed. If you grab the context in the Decode stage of the receive pipeline these properties will be missing!

Note that the WasSolicitResponse property that Stephen listed has are not present in this list! If they have been removed or if the are missing for some other reason I do not know.

Status	Property Name	Property Namespace	Sample Value
New	FileCreationTime	http://schemas.microsoft.com/BizTalk/2003/file-properties	2006-08-09 12:39:26
	ReceivedFileName	http://schemas.microsoft.com/BizTalk/2003/file-properties	C:\Temp\In\{AC08712D-D3D3-4563-B3FA-7D4D16AF204E}.xml
New	ActivityIdentity	http://schemas.microsoft.com/BizTalk/2003/messagetracking-properties	{5AFF4DA8-01F8-475D-833C-B5F2B4EB90C0}
New	AdapterReceiveCompleteTime	http://schemas.microsoft.com/BizTalk/2003/messagetracking-properties	2006-08-09 12:39:27
	PortName	http://schemas.microsoft.com/BizTalk/2003/messagetracking-properties	LoggerTest
	InboundTransportLocation	http://schemas.microsoft.com/BizTalk/2003/system-properties	C:\Temp\In\.
	InterchangeID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{719EC689-6B8D-43C0-A22C-D30D5FB91AF7}
New	ReceiveInstanceID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{0F014418-E50E-4696-A799-909CA49D57B5}
New	ReceiveLocationName	http://schemas.microsoft.com/BizTalk/2003/system-properties	LoggerTest
	ReceivePortID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{753B1829-8B4B-4DBF-AEAE-B40CB39D9F38}
	ReceivePortName	http://schemas.microsoft.com/BizTalk/2003/system-properties	LoggerTest
	AuthenticationRequiredOnReceivePort	http://schemas.microsoft.com/BizTalk/2003/system-properties	False
	InboundTransportType	http://schemas.microsoft.com/BizTalk/2003/system-properties	FILE
	LRPMsgBodyTracking	http://schemas.microsoft.com/BizTalk/2003/system-properties	0
	MessageExchangePattern	http://schemas.microsoft.com/BizTalk/2003/system-properties	1
	ReceivePipelineID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{19002860-A279-4F4F-8FD3-5BCD7FC3B646}
	MessageType	http://schemas.microsoft.com/BizTalk/2003/system-properties	http://LoggerTest.Schema1#Root
	SchemaStrongName	http://schemas.microsoft.com/BizTalk/2003/system-properties	LoggerSchemas.LoggerSchema, LoggerSchemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8136305dbdd920be
New	SourceCharset	http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties	utf-8

Send Pipeline Properties

In the send pipeline I now find 42 properties! 15 is new and 4 has been removed.

Note that the PartyName, RetryInterval, WasSolicitResponse and SourcePartyID properties that Stephen listed has are not present in this list! If they have been removed or if the are missing for some other reason I do not know. The reason for two of the deleted properties may be that I did not use a Party Resolution stage in the receive pipeline, but I do not find it interesting to amend my tests with this right now...

Status	Property Name	Property Namespace	Sample Value
	CopyMode	http://schemas.microsoft.com/BizTalk/2003/file-properties	1
New	FileCreationTime	http://schemas.microsoft.com/BizTalk/2003/file-properties	2006-08-09 12:56:53
	ReceivedFileName	http://schemas.microsoft.com/BizTalk/2003/file-properties	C:\Temp\In\{AC08712D-D3D3-4563-B3FA-7D4D16AF204E}.xml
	AllowCacheOnWrite	http://schemas.microsoft.com/BizTalk/2003/file-properties	False
	FileName	http://schemas.microsoft.com/BizTalk/2003/file-properties	%MessageID%.xml
New	UseTempFileOnWrite	http://schemas.microsoft.com/BizTalk/2003/file-properties	False
	PartNames	http://schemas.microsoft.com/BizTalk/2003/messageagent-properties	System.String[]
New	ActivityIdentity	http://schemas.microsoft.com/BizTalk/2003/messagetracking-properties	{DE53D9D4-B8D8-431C-B330-A9EB578CC2FB}
New	AdapterReceiveCompleteTime	http://schemas.microsoft.com/BizTalk/2003/messagetracking-properties	2006-08-09 12:56:54
	PortName	http://schemas.microsoft.com/BizTalk/2003/messagetracking-properties	LoggerTest
New	BAMTrackingNeeded	http://schemas.microsoft.com/BizTalk/2003/system-properties	False
	LTPMsgBodyTracking	http://schemas.microsoft.com/BizTalk/2003/system-properties	0
	SPID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{06775E3D-7CE7-4275-B415-ABACA7F65F8C}
	ActualRetryCount	http://schemas.microsoft.com/BizTalk/2003/system-properties	0
New	OrderedDelivery	http://schemas.microsoft.com/BizTalk/2003/system-properties	False
	ReceivePortName	http://schemas.microsoft.com/BizTalk/2003/system-properties	LoggerTest
New	RouteMessageOnFailure	http://schemas.microsoft.com/BizTalk/2003/system-properties	False
New	InterchangeSequenceNumber	http://schemas.microsoft.com/BizTalk/2003/system-properties	1
New	IsSolicitResponse	http://schemas.microsoft.com/BizTalk/2003/system-properties	False
New	OutboundProcessingStartTime	http://schemas.microsoft.com/BizTalk/2003/system-properties	11432999
New	RetryInterval	http://schemas.microsoft.com/BizTalk/2003/system-properties	5
New	StopSendingOnFailure	http://schemas.microsoft.com/BizTalk/2003/system-properties	False
	OutboundTransportCLSID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{9D0E4341-4CCE-4536-83FA-4A5040674AD6}
	SPName	http://schemas.microsoft.com/BizTalk/2003/system-properties	LoggerTest
	InboundTransportLocation	http://schemas.microsoft.com/BizTalk/2003/system-properties	C:\Temp\In\.
	InterchangeID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{B024B2BB-9287-4883-97D7-C4670E003D01}
New	ReceiveLocationName	http://schemas.microsoft.com/BizTalk/2003/system-properties	LoggerTest
	ReceivePortID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{753B1829-8B4B-4DBF-AEAE-B40CB39D9F38}
New	SPLastUpdatedTime	http://schemas.microsoft.com/BizTalk/2003/system-properties	2006-08-09 09:35:18
	SPTransportID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{260F8795-74FA-447A-9B7A-0435B0FBD97E}
	TransmitPipelineID	http://schemas.microsoft.com/BizTalk/2003/system-properties	{ACDFD936-83A6-4088-97D5-DD1B2327CD29}
	AuthenticationRequiredOnReceivePort	http://schemas.microsoft.com/BizTalk/2003/system-properties	False
	InboundTransportType	http://schemas.microsoft.com/BizTalk/2003/system-properties	FILE
	LRPMsgBodyTracking	http://schemas.microsoft.com/BizTalk/2003/system-properties	0
	MessageExchangePattern	http://schemas.microsoft.com/BizTalk/2003/system-properties	3
	OutboundTransportLocation	http://schemas.microsoft.com/BizTalk/2003/system-properties	C:\Temp\Out\%MessageID%.xml
	ReceivePipelineID	http://schemas.microsoft.com/BizTalk/2003/system-properties
	MessageType	http://schemas.microsoft.com/BizTalk/2003/system-properties	http://LoggerTest.Schema1#Root
	OutboundTransportType	http://schemas.microsoft.com/BizTalk/2003/system-properties	FILE
	RetryCount	http://schemas.microsoft.com/BizTalk/2003/system-properties	3
	SchemaStrongName	http://schemas.microsoft.com/BizTalk/2003/system-properties	LoggerSchemas.LoggerSchema, LoggerSchemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8136305dbdd920be
New	SourceCharset	http://schemas.microsoft.com/BizTalk/2003/xmlnorm-properties	utf-8

Details on Direct Bound Ports

mattlind — Mon, 07 Aug 2006 12:00:00 GMT

I'm currently working on a post about how the BPM scenario show-cases versioning of business processes. As part of this I looked up Kevin Lam's blog as I know that he has worked with the BizTalk Scenarios, particularly the BPM scenario. What I found was quite interesting!

Kevin has written a number of detailed articles about how direct binding works. He starts with an introduction and then dives into details about message box direct bound port, partner direct binding (including inverse direct binding), self-correlating direct bound ports and dynamic direct bound ports. At the time of this writing there are five articles, if more becomes available I will update this post.

Store config-info in BizTalk SSO

mattlind — Tue, 01 Aug 2006 12:07:00 GMT

Introduction

I have started looking the Business Process Management (BPM) scenario and this time I will talk about its usage of BizTalk's Single Sign-On (SSO) to store configuration information. The SSO is normally seen as something that is not directly used by applications (at least I do), it's primary purpose to me is to be used by internal BizTalk components (e.g. adapter configuration) aside from the actual SSO scenarios. But there is actually nothing that stops you from using SSO is your BizTalk applications, which the BPM scenario proves.

But let's start with a search-poll to find out what others have written about this. When I search for "ISSOConfigStore GetConfigInfo" I get four hits! My conclusion is that these APIs are well hidden secrets, otherwise someone, somewhere would have written something about them.

SSO in BPM

In the BPM scenario the SSO is used to store this info: cable provisioning system location, total stage count and the cache refresh interval. The first two are actual business data while the cache refresh interval is used internally by the SSOConfigHelper to determine how often it should refresh the cached data.

The class used to access the SSO by the BPM scenario is SSOConfigHelper (located in the Utilities project). During initialization this class reads from the SSO and caches the values, the cache is then refreshed by creating a timer which will fire an event at regular intervals. The actual reading of SSO configuration values are pretty simple as a call to ISSOConfigStore.GetConfigInfo fills a property bag with all key-value pairs for the specific application.

Accessing SSO in your Application

At a high-level the code to read data from SSO looks like this:

ConfigurationPropertyBag configBag = new ConfigurationPropertyBag();
ISSOConfigStore ssoStore = new ISSOConfigStore();
ssoStore.GetConfigInfo("ApplicationName", guid, 4, (Microsoft.BizTalk.SSOClient.Interop.IPropertyBag)configBag);
object prop = null;
configBag.Read("YourPropertyName", out prop, 0);
string val = (string)prop;

When looking for info about ISSOConfigStore you get directed to the BizTalk 2004 documentation ISSOConfigStore.GetConfigInfo@MSDN. The docs say that the second parameter to GetConfigStore "Contains the identifier for the configuration info. This string is typically a GUID." The BPM scenario does not use a GUID, which only proves that any string can be used.

Jon Flanders has written a bit about using SSO to store configuration information and he also has some code to download, read more here.

Pros and cons

The biggest advantage of using SSO to store config info is that exactly the same values are available to all servers in the installation. There is no need to distribute a config-file across multiple servers when a value changes, you eliminate the risk of using different config info for different servers. Another advantage is that all information in the SSO is automatically encrypted which makes it harder for someone to read it. However, this is only a false sense of security if you don't limit access to your SSO application config store (and to tell the truth I don't know how to do this, hence that might be a topic for a future post...) as otherwise anyone who can write code can write an application which reads your "secured" config info.

The biggest disadvantage of using SSO to store config info is that it is dependent on BizTalk. In many organizations there are standards that describe how you typically do thing in a development project (this is often called a Programming Handbook), one of many topics in such a document is (or should be) how to handle configuration information. It may be hard to change a companies standard config store is that not all projects use BizTalk, and even those that do may have web servers etc. which may not be able to access the SSO database due to FW issues.

Another disadvantage is that the admin GUI to SSO is not very good, or more specifically it doesn't exist! There is a command line tool which can be used to access part of the SSO information, but it does not support application-level config info. If you wish to have a GUI/command line application to manage your information you will have to write it yourself!

Conclusion

Even though it is possible to use SSO to store configuration information it is not always the most appropriate way to do it.

I will probably continue to advocate using my configurationHelper class as it is available to web, thick client and any other services.

BizTalk Scenarios - Real-life samples in the box

mattlind — Thu, 20 Jul 2006 12:00:00 GMT

One of the really cool new features of BizTalk Server 2006 is that it contains large sample scenarios that illustrate how BizTalk can be used to build solutions. These are fully working implementations that showcase how different parts of BizTalk can be used. When you open BizTalk Server Documentation these scenarios are listed on the start page. The are described as: "Information about designing, building, and running three complete, model BizTalk Server solutions: a service oriented solution, a business process management solution, and a business-to-business solution."

Even though they are quite heavily advertised in the documentation they are not that well known to many developers. Some people have never heard of the scenarios while other have heard of them but simply dismissed them as just another sample. Let's be clear on the last issue, these scenarios are not just another sample they are something much better than that. The scenarios are real implementation and does not limit themselves to a small and uncomplicated scope. The problem with the scenarios may even be that they are too real-life, there is a lack of focus on a specific issue which is often present in normal documentation and samples. But hey, that is what it’s like out there in the real world…

My interest in these patterns started when I during two weeks had the opportunity to work with the product group in Redmond that has built the scenarios. Then in January I had to dive deep into some parts of the Business Process Management (BPM) scenario when I made a presentation about BizTalk patterns at an internal conference.

The problem with the scenarios, which might frighten some people who start digging into the details (I know it frightens me!), is that they are so large. Being so large one would like them to be well-documented to enable one to understand how the work, but this is not the case! I'm not saying that there aren't any documentation (there are plenty of that which can be viewed at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS06ConceptsPlanning/html/f6239905-a1bf-4223-bdca-6677f2d6049b.asp), but to me there is no overall architecture and design documented. All the patterns that are mentioned in the docs simply become a blur and it's hard to identify exactly which pattern matches which code.

As a developer working with BizTalk I consider these scenarios to be more than large samples, they are pointers that show how the product group in Redmond intends us to use BizTalk to solve business problems. Therefore I have decided to dive into these scenarios and highlight design and implementation patterns that I consider useful.

Over the coming weeks and months I intend to post about the result of my examinations. First up is about how to use BizTalk Single-Sign On (SSO) to store configuration information for your application (which kind of conflicts with by previous post about using the utility class configurationHelper :-).

New BizTalk content on MSDN and GotDotNet

mattlind — Tue, 18 Jul 2006 12:00:00 GMT

The CSD Customer Experience Team's Blog has annonced the following new downloads:

They have also launched a New BPM Site.

Mattias Lindberg : BizTalk

News about BizTalk Server 2009 and alignment with Oslo

BizTalk Server 2004 SP2

Summary of BizTalk Server Documentation Updates

Core Documentation | Download

Updated Installation, Configuration, and Upgrade Guides | Download

Whitepapers

Other Content

Localization Updates for the BizTalk Server 2006 Documentation

An outside-of-Visual-Studio-BizTalk Explorer

New Whitepaper: Managing a Successful Performance Lab

BizTalk Server 2006 Developer’s Troubleshooting Guide

Does BAM Require Local Installation of SSIS? No!

Webcasts on BizTalk Scenarios

Business Process Versioning - Updating Running Business Processes

The Problem

An Example to Illustrate the Problem

The Solution - A Request Manager with Multiple Stages

Stages

Request Manager

Implementation

Conclusion

Whitepaper Comparing BizTalk 2004/2006 Adapter Performance

Accessing and Listing Message Context Properties in Pipeline Components

Receive Pipeline Properties

Send Pipeline Properties

Details on Direct Bound Ports

Store config-info in BizTalk SSO

Introduction

SSO in BPM

Accessing SSO in your Application

Pros and cons

Conclusion

BizTalk Scenarios - Real-life samples in the box

New BizTalk content on MSDN and GotDotNet