BizTalk - EAI - B2B

About compatibility…

Gregory Van de Wiele — Mon, 26 Sep 2005 07:53:00 GMT

The BizTalk 2006 version and API is 100% backwards compatible with the 2004 version and API. BizTalk 2006 is built against .NET2.0 while the BizTalk 2004 assemblies were built against .NET1.1. Although I’m not working for Microsoft this surely means that for the BizTalk 2006 version the Microsoft BizTalk product team has:

1. Checked the re-used BizTalk 2004 code parts against the new .NET version for incompatibilities and resolved all of them for the BizTalk 2006 release.

2. Rewritten parts of the original BizTalk 2004 implementation in order to benefit from the new framework version (such as a performance gain) without breaking compatibility with the previous BizTalk version.

3. Added a lot of new BizTalk functionality written from scratch in .NET2.0 code.

In general .NET framework supports installing and running different framework versions side-by-side on a single machine. By default your custom old .NET1.1 applications will run with .NET2.0 when you run them on a machine with 2.0 installed. If you detect incompatibilities you can instruct .NET to load the old runtime version you originally built your application against (by means of configuration). Or you can choose to fix the incompatibility in your code and recompile for .NET2.0.

Whole different story for your newly written .NET2.0 applications: they only run with 2.0 or higher compatible version (for example 2.1).

Microsoft BizTalk 2006 is a ‘new application’ and is ‘built against’ .NET 2.0 (beta) and as a consequence will only run with .NET framework 2.0 or higher compatible version. The BizTalk 2006 host instances will load and execute code using CLR .NET2.0 and as a consequence the assemblies it loads will execute within .NET 2.0. Your assemblies used inside orchestrations, your custom adapters and your pipeline components and their dependencies will all have to be compatible with .NET2.0. You don’t have the option to instruct to load the .NET framework version you built your assembly against because loading 2 different CLR versions in the same process is not supported. Here is a good post from Junfeng Zhang about the subject: The CLR Side by Side and Compatibility.

This means that as a BizTalk developer you should at least perform step 1 from the above steps for all your BizTalk 2004 custom code. If you’re lucky you detect no incompatibilities and it will work by default. But if you do detect incompatibilities then you’ll have to re-code and re-compile. For more information on the .NET CLR see Suzanne Cook’s weblog

BizTalk 2006 SDK: new BaseAdapter

Gregory Van de Wiele — Fri, 23 Sep 2005 04:40:00 GMT

The SDK of BizTalk 2006 Beta2 will include a new version of the adapter base classes. These will not be backwards compatible with the original BizTalk 2004 SDK classes.

The API has changed and the internals have changed (uses System.Transactions for example). Adapters that have been originally built with the 2004 adapter base classes should continue to use and be deployed with this version.The .NET1.1 compiled assembly of the old base classes should by default work with.NET2.0 CLR.

You could of course prefer to re-compile for .NET2.0 but you will get some warnings during compilation time.

Some great news...

Gregory Van de Wiele — Wed, 06 Apr 2005 15:08:00 GMT

Although I'm still recovering from an earlier *shock* (from when I received the totally awesome MVD award), I'm proud to announce that as of this month I'm a genuine, fully-fledged Microsoft MVP for BizTalk Server. This is really fantastic!

‘Processing convoy workflow scenarios’ patent

Gregory Van de Wiele — Mon, 21 Mar 2005 08:06:00 GMT

For those who are wondering why I’m not blogging very regularly: It’s not that I’m lying on my back and sun-bathing on the beach or anything (which was never been an option since it has been snowing a lot), I'm just rather busy lately. I was doing a SP1 evaluation earlier, for which MS has granted me a prestigious award for ‘Most Valuable Debugger’. It’s a kind of a joke, but nevertheless I’m very proud and amused at the same time :-). I guess I will have to change my blogging style in order to make it up in the future. So expect some more ‘publish some ideas quickly’ posts soon…

Here is something very interesting - I’ve discovered it some time ago when I was searching for general background information about convoys. This explains why it’s so hard to find anything theoretical and not directly from MS. More precisely, the ‘Processing convoy workflow scenarios’ patent has been linked to 8 different people, amongst them 1 very famous blogger named Lee.

BizTalk WMI programming: How to write cleaner WMI code a lot faster

Gregory Van de Wiele — Wed, 16 Mar 2005 05:00:00 GMT

I’ve seen numerous handy WMI scripts and code samples from fellow BizTalk bloggers and from the BizTalk help. Amazingly every one of these samples use late-bound objects calls to invoke methods and access properties from the BizTalk management objects. This makes the code rather verbose, it’s very inconvenient and also very error prone. There's a better way to write your WMI code. Therefore you have to download first and then install the 'Management (WMI) Extensions for Visual Studio .NET 2003 Server Explorer'. This tool makes WMI programming much easier and enjoyable (at least for me). It's no rocket science or anything but it comes in very handy for making your first steps on the WMI moon. You don’t have to take my word on it, look for yourself:

After having installed the extension you can go into your Visual Studio’s Server Explorer and select the namespace you want to add management classes from (select ‘add classes’ from the context menu).

After selecting the desired classes from your namespace (‘root \MicrosoftBizTalkServer’ I assume) the Server Explorer window will contain a list of the selected management object-types. It also shows a list of all instances for a given class when you click it. When having selected an instance, all of its properties will be shown inside the property-window (you could modify them from there too, but I wouldn’t recommend doing it this way).

Also methods can be invoked on classes and instances; this is nice for testing purposes. *No big deal* you are thinking of course; now pay attention:

When selecting 'Generate Managed Class' from the menu, the extension will automatically generate a wrapper class and add it to your solution’s startup project (it targets your .net project language).

The generated classes have strongly typed properties and methods, so you have access to and can invoke by simply using their name (even enum-types are created). You benefit from good old Intellisense again. Behind the covers the generated wrapper classes still use late-bound objects and calls of course, but you don’t have to care at least about this, nor write ugly late binding code. Now you can write clean high-level WMI code a lot faster.

Take a look at this little WMI sample (where I make a call to ‘GetInstances’: this overloaded method is created automatically and it requires only the where-part of the WQL query to return a typed collection of your WMI object-type).

Try to rewrite the following method (please don’t focus on the language change; it’s purely for educational purposes. I’ve never executed a single line of this code :-)

Into this:

Which one do you prefer?

Enterprise Library is -also- there...

Gregory Van de Wiele — Tue, 01 Feb 2005 08:00:00 GMT

A Biztalker's focus is primarily on the BizTalk SP1 release nowadays so I thought it might be useful to post about the arrival of the Enterprise library. Yep, it's finally out! For more information check MSDN.

Here are 2 fine bloggers that blog about the EL like we do on BTS:

Being Scott Densmore

Tom Hollander's blog

The BizTalk SQL Server Adapter isolation level

Gregory Van de Wiele — Thu, 25 Nov 2004 15:35:00 GMT

The isolation setting is fixed and is SERIALIZABLE. So beware that even your most basic receive locations that only execute those very simple SQL statements such as 'select * from tablename' can generate locks. BTW, this is a general misconception: usually people think that select-statements never lock resources. Nothing is less true of course.

While having a shared lock on a range of keys, in addition to the keys themselves having locked, no records can be inserted.
Here's a sample to demonstrate the effects of the SERIALIZABLE isolation setting:

Open your SQL Query analyzer
Open 2 seperate query windows to the local Pubs database
Copy & paste these samples statements:

Window A:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRAN
Select * from authors where contract = 1
GO

Window B:

BEGIN TRAN
INSERT INTO [pubs].[dbo].[authors]([au_id],[au_lname], [au_fname], [contract])
VALUES('666-66-6666','Grego', 'El', 1)
GO

Now, if you try to execute both queries you will see that the second query will always be blocked by the first, irrespective of the order. You can immediately unblock the process by typing, selecting and executing 'ROLLBACK TRAN' in the blocking transaction's window. Now repeat this test and replace 'SERIALIZABLE' with 'READ COMMITTED' and you will see that when you first start batch A, you can still execute Batch B simultaneously (which wasn't so with the SERIALIZABLE level).

Here are the isolationlevel-enumerator values from system.data:

[Flags]
public enum IsolationLevel
{
      // Fields
      Chaos = 0x10,
      ReadCommitted = 0x1000,
      ReadUncommitted = 0x100,
      RepeatableRead = 0x10000,
      Serializable = 0x100000,
      Unspecified = -1
}

The BizTalk SQL adapter always uses 0x100000. You can check this by viewing the requested locks in Enterprise Manager:

Now, I believe the above will rarely be a problem in real-life. You should only expect performance problems when you have a lot of transactions and a lot of simultaneous lock requests for the same heavy resource while having a bad database-design (having no or having the wrong indexes). You should also know that lock waits are perfectly normal: a simple wait for a lock is different from a deadlock. The waiting process will get the lock anyway when the process that's holding the lock completes.

If you use SERIALIZABLE my best advice is to tune you sql statements for performance (also having correct db-design, normalization, the right indexes,...) in order to make your select statement execute as fast as possible .

**UPDATED**

Is there a solution?

If you try to add the 'SET TRANSACTION ISOLATION LEVEL READ COMMITTED' to a select-statement based receive location then you may have no issues at design time. But when you try to add a RL based on this SQL statement in the BizTalk Explorer you will get a 'The SQL statement must be either a select or an exec' error.

You can add ‘With (Readcommitted)’ to the tables in the select, or data modification statement. 'Select * from authors with (Readcommitted) where contract = 1'. This will override the default Serializeable isolation level, and keep the number of locked records to a minimum. Credits go to Dirk Gubbels from Microsoft...

SQL Server locking experts' comments are very welcome...

About publisher policy assembly chaining

Gregory Van de Wiele — Tue, 23 Nov 2004 10:14:00 GMT

I've just found out the hard way that GAC'ed publisher policy assemblies do not chain. When you have a policy.1.0, redirecting the binding of assembly v1.0.0.0 to assembly v1.1.0.0 and also having a policy.1.1, for redirecting the binding of assembly 1.1 to assembly 1.2, this doesn't result in a binding to the assembly 1.2 when your app requests 1.0 (but rather to 1.1). If you want this kind of binding-behavior I guess you will have to use publisher policy versioning.

Why do I tell all this? Well, I've never read anything about this before so I thought it would be nice to mention here.

I also want to thank Alan Shi, who confirmed and explained this binding behavior to me. For more excellent information regarding the GAC and Fusion you should definitely visit his blog here.

Rule engine - Another way to debug the rule engine

Gregory Van de Wiele — Tue, 05 Oct 2004 03:16:00 GMT

This simulates an orchestration callrules action from code:

MyArrayList = new System.Collections.ArrayList();
MyPolicy = new Microsoft.RuleEngine.Policy(YourPolicyName);
MyTracer = new Microsoft.RuleEngine.DebugTrackingInterceptor();

You will have to create your facts in here. Use TypedXmlDocuments or custom objects (see the BizTalk help for samples)

MyArrayList.Add(MyFact1);
MyArrayList.Add(MyFact2);
MyPolicy.Execute(MyArrayList.ToArray(),MyTracer);
MyPolicy.Dispose();
System.Diagnostics.Trace.WriteLine(MyTracer.GetTraceOutput());

The above line will redirect the traces to the windows event trace.
Use the excellent debugview utility from sysinternals to view the traces.

Flat File Parser Annotations

Gregory Van de Wiele — Mon, 04 Oct 2004 03:23:00 GMT

Here's a presentation containing an overview of the flat file parser annotations that can be manually inserted into the BizTalk message schema. This is part of a presentation I gave at the Belgian BTS user group meeting a couple of weeks ago. There is also a sample project containing different schemas per annotation showing each annotation's purpose. My main source of information was the BizTalk newsgroups where David Downing makes the beautiful weather for this topic. Just for the record: as usual everything is 'AS IS', so there's no warranty at all...

BTW this is my first post using the Simple Blog Editor InfoPath form that I found thanks to Capo…