BizTalk 101 - Back to Basics

The Road to Oslo

Alan Smith — Thu, 31 Jan 2008 22:22:41 GMT

If you have been keeping up to date with developments within the Connected Systems Division within Microsoft you will be aware of the “Oslo” initiative. Microsoft has released information about this here, and Charles Young has a very informed summery of the initiative here.

I’m not going to discuss too much about what Oslo is, what I will look at is how current and future BizTalk developers can start to consider the impact that Oslo will have on development, and how we can start looking at technologies and developing skills that will be relevant on the new platform. This is just my opinion, as a BizTalk developer I’m keen to keep up to date with new developments, and I’m currently following these guidelines myself.

The first version of Oslo is scheduled for release sometime in 2009, which means we may see TAP, CTP and Beta releases sometime in 2008. If you are a seasoned BizTalk developer or a newbie, Oslo will have a major impact on your development over the next few years. So how should we go about navigating the road to Oslo?

What if I am a BizTalk 2004/2006 developer?

It remains to be seen what the general architecture and feature set for the first release of Oslo will look like. One thing that Microsoft has promised us is that “nothing is going away”, meaning that we will still be able to develop using the tools that we are familiar with, and the applications we are developing today will still work on the new platform. This is very different from the transition from BizTalk 2002 to 2004, when people were saying that having no knowledge of BizTalk 2002 was an advantage to learning 2004, and migrating applications was often more of a re-write than a migration.

We are already seeing some of the technologies that may be refined to make up parts of the Oslo platform; some of those are available in BizTalk Server 2006 R2, others as side projects. These are discussed in the “How do I get a head start in Oslo” section. If you are working with BizTalk today and want to start planning for the future, it’s maybe worth spending time checking them out.

I need to start an integration project, should I use BizTalk 2006 R2?

Absolutely. Since the 2004 release BizTalk Server has been the natural choice for developing integration solutions on the Microsoft platform. The feature set has been strengthened considerably in the 2006 and 2006 R2 releases, including strong EDI and WCF support in 2006 R2. As mentioned earlier “nothing is going away”, so if you need to start a project in the near future, BizTalk 2006 R2 is still the best choice.

When we get nearer the release dates, have more concrete information on the architecture and feature set, and CTP or Beta releases become available the choice of going for Oslo may start to become an option. There may be a chance to become involved in the TAP program and have early access to the bits. Bear in mind that in the early days Oslo will be a very new platform, whilst BizTalk has a wealth of documentation, knowledge, books, courses, blogs, and community experience, Oslo will be a voyage of discovery for everyone, and you will need to plan for this in your development cycle. If, like me, you were an early adopter for BizTalk Server 2004 you will know what I’m talking about.

I want to start learning about BizTalk, what should I start looking at?

Depending on your experience it can take up to twelve months to become a proficient BizTalk 2006 developer (I’ve been hard at it for over four years and am still learning new stuff about the core BizTalk engine). As Oslo is scheduled for a release some time in 2009, we may well see public Betas and CTP releases within twelve months. If you are planning on learning BizTalk to strengthen your CV it may be more worthwhile looking at the new technologies that are becoming available rather than learning BizTalk Server 2006 R2.

As Microsoft are keeping many of the details about the Oslo feature set under wraps it may be the case that if you spend the next twelve months learning 2006 R2, things change significantly and you will be back to the tutorials again. It could also be the case that your 2006 skills are very relevant and applicable to the new platform, so again it’s a bit of a gamble.

One thing we can be certain of is that WCF will increase in importance in the BizTalk feature set, and WCF will be more applicable to general development as well. If you have the time to develop your skills, you could consider looking at the WCF features in the current BizTalk release, and other related technologies, (BizTalk’s WCF adapters, WCF LOB adapter SDK, BizTalk Labs). The next section will discuss these technologies.

How do I get a head start in Oslo?

There are a number of technologies that Microsoft has been releasing that may, in a more mature form, go on to form part of Oslo. If you are keen to get ahead and stay ahead on the Oslo platform it would be well worth investing some time in them. Be aware that plans change, promised features change, and strategies change (remember “Jupiter”?), so be aware that investing time in the bleeding edge technology can be a gamble.

If you are keen to be an Oslo early adapter, here’s some stuff to look at: (Be aware that this is just my personal opinion.)

Windows Communication Foundation

WCF is becoming increasingly important on the Microsoft platform, especially the “Connected Systems” projects. If Oslo is to be a SOA platform, WCF will be the foundation that platform will be built on. We are already seeing WCF being adopted in the BizTalk product line (WCF adapters in R2, WCF Line of Business Adapter SDK, BizTalk Adapter Pack, BizTalk Labs), expect this trend to continue. Having a solid knowledge of WCF will likely be one of the core skills required for the Oslo platform.

Considering the importance of WCF on the Microsoft platform, it should be on most developer’s to-do lists. If you run Vista, or can run a virtual image with Server 2008 (you need a fast PC to do this!) check out hosting WCF in WAS.

Windows Workflow Foundation

WF has been around for a while now, and it has been discussed as a replacement for the BizTalk Orchestration Engine in BizTalk vNext ever since it appeared. As we know that the Orchestration Engine will still be present (“nothing goes away”), it remains to be seen how much of an impact WF will have on Oslo development. If Microsoft can deliver a solid workflow host with comparable development and management tools to the current orchestration designer, WF may be the weapon of choice for building business processes. As we know Oslo will be a long term strategy, there is a chance that we may still be choosing to build orchestrations rather than workflows on the early versions of the platform. It will be a while before we can make a decision on this.

If you will be looking at WF, the integration between WCF and WF in .net 3.5 looks like something worth exploring. The first version of WF had no concept of sending and receiving messages, the core functionality of most BizTalk orchestrations. In .net 3.5 we have a SendActivity and a ReceiveActivity, allowing WF workflows to publish and consume WCF endpoints. WF may be a skill worth having, but I’d prioritise on learning WCF if you are limited for time.

WCF Line of Business Adapter SDK

http://www.microsoft.com/biztalk/technologies/wcflobadaptersdk.mspx

Microsoft’s strategy to migrate adapters to use WCF instead of being dependent on BizTalk makes a lot of sense. In the future we will be using .net adapters, rather than BizTalk adapters. The BizTalk Adapter Pack is making a start on this move; expect to see more adapters migrated in the future.

A great way to learn about the new adapter framework is to download the WCF LOB adapter SDK and take a run through the tutorial. Even if you are not going to develop your own adapters, it will give you an insight into how the new adapters will be built, it’s also great to look at the more advanced aspects of WCF development.

BizTalk Labs

http://labs.biztalk.net/

BizTalk Labs is a pilot project to investigate the use of an Internet Service Bus (ISB) in connected system development. The future of BizTalk labs has not been determined, but there is a good chance that one of the aims of running this project is to prototype ideas that may form part of the Oslo platform. If you want to explore BizTalk labs, there is an SDK to download, and you will need to set up an account. As it’s an experimental project it’s not guaranteed that the servers will running 24/7.

The relevance of BizTalk labs to the Oslo platform will not become clear for a while (the FAQ is worth reading for more info), so investing a lot of time learning them is a bit of a gamble, but it may well pay off in the future. BizTalk labs uses WCF as a framework, rather than BizTalk, so it’s another chance to get more WCF experience.

It’s all about WCF

The WCF-WF integration in .net 3.5, the BizTalk WCF adapters, the WCF LOB adapter SKD and BizTalk Labs are all based on WCF as their foundation. It’s fairly easy to conclude that WCF is going to be the key technology to understanding and leveraging this new wave of products.

Reboot for the BizTalk User Group Sweden (BUGS)

Alan Smith — Thu, 17 Jan 2008 09:22:27 GMT

After meeting with Johan and Mikael from WMData we have planned a new start for the BizTalk user group. We plan to hold about six meetings during 2008, about one every two months.

The first meeting will be at 17:45 on the Tuesday the 12^th February at the KnowIT offices in central Stockholm (Klarabergsgatan 60, two minutes walk from the central station). . If you would like to attend, or be on the mailing list for future events, contact me via the blog with your email details.

The agenda for the first meeting is:

17:45 Samling

18:00 Start

Introduktion till Usergroupen och dess arbete

ESB Guidance (Mikael Håkansson och Johan Hedberg)

19:00 Paus, mingel, diskussioner. Något att äta och dricka kommer finnas.

19:30 ESB Guidance avslutas

Oslo (Alan Smith)

Q & A, avrundning, diskussioner

Oslo är en samling tekniska lösningar som ska förenkla byggandet av applikationer för en tjänsteorienterad arkitektur. Med Oslo förflyttar vi oss från att modeller beskriver applikationer till att modellen är applikationen. Läs mer på http://www.microsoft.com/soa/products/oslo.aspx.

ESB Guidance är ett steg i riktningen att lyfta BizTalk till mer av en Enterprise Service Bus (ESB) med utökat stöd för löst kopplade tjänster. Läs mer på http://msdn2.microsoft.com/en-us/library/bb931189.aspx. Presentationen kommer belysa hur BizTalk relaterar till SOA, SOI och inte minst ESB. Vi kommer gå igenom stöd, riktlinjer, komponenter och tillhörande portal, och ge en bild av hur ESB Guidance kan konfigureras, användas och utökas

Free BizTalk Skills Assessment Quiz from Quick Learn

Alan Smith — Thu, 03 Jan 2008 17:23:28 GMT

As with any certification one of the hardest things is deciding if and when you are ready to sit the exam. The BizTalk 2006 exam will test you on general BizTalk development, deployment, BAM and business rules and you will have to have quite a bit of real world hands-on experience to get a good score.

If you want to measure up your skills, Quick Learn has a free practice test on their site. The test was developed so that students can assess their skills and see if they have the experience required to take the advanced BizTalk Deep Dive course. The practice test is focused on general development, so you will still need to know about rules, BAM, and deployment and maintenance. But if you get a good score and are fairly comfortable with the other topics, then go for it and take the real exam.

If you feel you need to skill-up, you should consider attending a Deep Dive or Immersion course dependant on your experience. Both courses have been updated to cover the BizTalk 2006 R2 functionality, and the Deep Dive is aimed at getting you up to the required level for the exam. Even if you think you know your stuff you will benefit from a Deep Dive course. I have been teaching BizTalk Deep Dive for over two years now and I still learn a lot from the technical discussions that take place in a class of BizTalk experts over the five days.

The quiz is here.

SOA & Business Process Conference

Alan Smith — Mon, 29 Oct 2007 13:34:39 GMT

I’m currently in Bellevue, near Redmond and the SOA & Business Process Conference kicks off today with a meet up at Parlor Billiards in the evening.

A few of us decided to meet up in Manzana’s for a meal Sunday Night, Jon Flanders made a brief appearance, Sam Gentile, Tim Rayburn and Saravana Kumar stayed around for food, and we were joined by the guys from KnowIT.

This will be my first time presenting, I’ll be talking about “Reliable Messaging on the Microsoft Connected Systems Platform” on Thursday afternoon. There are a lot of great presentations to look out for this year:

Steve Swartz and Clemens Vasters will be talking about the evolution of the SOA platform, Darren Jefford will be telling us how we should be testing our BizTalk applications, Jon Flanders has a session on BAM and WCF, Matt Meleski on error handling in BizTalk, Dwight Goins on mobile WCF services, John Callaway on SOA anti-patters and Stephen W. Thomas on advanced orchestrations are a few that I have on my list.

The schedule will be hectic, Marjan has been busy organizing another MVP and Influential’s dinner, and I have a few engagement meetings with various people from the BizTalk team, I’ll also be spending time with the QuickLearn guys working on the new DeepDive course, and helping out on the QuickLearn stand in the exhibitors booth.

If you are at the conference, drop round to the Ask the Experts session Tuesday evening and say “Hi!. I’ll be answering questions on BizTalk team development. If not, keep your eyes open for the next one around the same time next year. If you are focused on BizTalk, WF, WCF and related stuff this is the place to be.

BizTalk Server 2006 Virtual Multi-Box Install Lab

Alan Smith — Tue, 29 May 2007 10:12:07 GMT

I wrote this lab about a year or so ago, with a view to posting it when I got the time. If you want to learn about multi-server installs with BizTalk, it may be a good idea to run through it in a virtual environment first. It will probably take you about half a day to run through the lab, but most of the time will be spent waiting for the various installs to complete.

You can find the lab here.

BlogCast Interview By Dag König

Alan Smith — Tue, 15 Nov 2005 14:35:00 GMT

Hi,

One of my work colegues, Dag König, finally persuaded me to sit an interview for his blog. Dag is one of Sweden's experts in all things SOA, Microsoft, and beta, and has been running one of the most popular developers blogs in Sweden for a couple of years.

Dag was, of course, interested in BizTalk 2006, and how it fits in with SOA and workflow Foundation. The blog is in Swedish, but we took the interview in English.

The interview is here.

Dag König's Blog is here.

Sweden BizTalk Users Group

Alan Smith — Tue, 08 Nov 2005 15:44:00 GMT

Hi,

I'm thinking of seeing if there is enough interest to start a BizTalk User Group in Sweden. The plan is to meet in Stockholm, in the city, after work hours, maybe 5pm. You will have to put up with me talking the first time, but I plan to involve other speakers to talk about Windows Workflow, SOA, and other BizTalk related stuff.

If you are interested, hit the "Contact" link and I will get back to you with further details. I am aiming for late November, early December for the first meeitng.

Cheers,

Alan

New Bloggers Guide Out

Alan Smith — Wed, 21 Sep 2005 14:28:00 GMT

Get Your Kicks with 2006…

It’s been a busy summer, and in Sweden you have to make the most of it. But, eventually, here is the latest version of the guide. Big credit to Stephen Thomas and Matt Hall for keeping the good posts coming.

There’s a whole bunch of 2006 posts here, BAM, Suspended Message Routing, ESSO SnapIn, Install + Config, Mapper Improvements e.t.c.

I’ve automated the process a bit by C#ing to create the table of contents for the help compiler, HTML Help Workshop was getting a bit out of hand with over 300 articles. Hope this went well, let me know if it didn’t.

Sorry if I have missed adding your blog/articles, my inbox was in chaos after the summer, and I may have missed your mail. Ping me again and I’ll add it to the October release (Also the first anniversary, Wohooo!!!).

Get it here...

I Passed BizTalk Exam!

Alan Smith — Thu, 30 Jun 2005 18:09:00 GMT

I took the BizTalk 2004 exam today and passed. I thought it was pretty hard, but the questions were fair, and a good test of your hands-on experience and understanding of the product. It would be hard to just cram for the exam from documents, if you don’t know the product, you won’t do too well. It has a reputation for not being an easy exam, so that’s more credit to anyone who passes.

Some resources I found helpful:

BizTalk Server 2004 Unleashed

Good info in the more detailed sections, and helpful for the admin, and management stuff.

BizTalk Documentation

Read the more advanced stuff (and make sure you have the latest update!)

SDK Samples

Run through these, deploy them, and get an understanding of how the code works.

Deep Dive Course

If you have a chance to get on the course, go for it, it’s a great help for the exam. If you have taken the course and understand the content you have a good chance, re-read the slides on the stuff you are unsure of.

Whitepapers

There’s a good section of whitepapers appearing on MSDN, they are worth checking out.

TechEd Europe

Alan Smith — Tue, 28 Jun 2005 12:32:00 GMT

I’ll be working on the “Ask the Experts” stand for BizTalk Server at TechEd in Amsterdam next week, along with other MVPs and Microsoft staff. Feel free to drop in if you have any BizTalk related questions. There’s a lot of BizTalk 2006 presentations that I want to catch, I got an early build of 2006 a couple of weeks ago, and I’d be keen to see a run-through of the new features. The new admin console is great, and the setup and config is a lot easier (have not tried a multi-box install yet though…), and working in Visual Studio 2005 is very sweet.

If any “Bloggers Guide” contributors can catch me anywhere near a bar next week, you are welcome to a free beer (or drink if you are wise enough not to indulge). It would be great to say “Cheers” for all the contributions, and keeping the guide alive. (That’s not an offer I could afford to make in Stockholm J).

Bloggers Guide to BizTalk 2006*

Alan Smith — Sun, 12 Jun 2005 17:21:00 GMT

There’s a new edition out now, get it here. I’ve added a “BizTalk Server 2006” section, there’s only one post there, but this should change in the next edition as you guys get your hands on the TechEd builds, and the beta becomes available.

I’m thinking of keeping the 06 stuff in the same guide rather than creating a new guide. As the orchestration and messaging engine are the same, a lot of the stuff is relevant to both products. I’m thinking of adding a header to the articles depending on which version they are relevant to, and keeping the structure the same, rather than creating a separate 06 structure (the 06 folder I added is just for the “What’s New” stuff etc).

I also need to streamline the process so I’ll switch to Visual Studio 2005, and some automated process to compile the CHM (the Help Workshop is no fun with over 300 articles), this should allow me to restructure the guide as well, and produce more frequent updates.

* Not quite, but heading that way ;-)

Messaging-Database Aggregator Pattern

Alan Smith — Mon, 06 Jun 2005 15:34:00 GMT

Messaging-Database Aggregator Pattern

It’s been a while since I blogged an article, and a long while since I blogged about the “Sequential Convoy Aggregator” pattern. Back then I was fairly new to BizTalk, I was aware of persistence points, and orchestration state, but did not have a really clear understanding of how badly they could affect an orchestration design.

Since then I have been thinking about this more, and wondering how well my aggregator implementation would stand up in a high load scenario. After running a few tests, I discovered the design pattern does not scale well to aggregate large batches of messages. The problem then was to come up with a design that would…

Pattern Implementation Using an Orchestration

The sequential convoy aggregator pattern is implemented by building a sequential convoy orchestration with two receive shapes correlated to receive all the messages that are to be aggregated. The orchestration maintains the state of the aggregation, by creating a .NET XmlDocument object, and adding each message as a node to this document. When the aggregation is complete, the XmlDocument object is assigned to a BizTalk message, which is then sent from the orchestration to a subscribing send port.

Sequential Convoy Aggregator Performance

The performance tests are using the aggregator pattern I created and blogged about last August. The orchestration was modified slightly to use a message count for the completeness criteria so it could be tested with different numbers of messages. The tests were then run, starting with 100 messages then increasing the size of the messages being aggregated.

After each test, the “Backup BizTalk Server” SQL Server Agent job was manually started to create log backups for the processing of the message aggregation. The results of the test are shown below.

Msg Count	Log Size /KB	KB/Msg
100	7,038	70.38
200	16,446	82.23
300	29,999	100.00
400	47,703	119.26
600	96,976	161.63
800	171,584	214.48
1,000	262,825	262.83

Msg Count	The number or messages used in the test.
Log Size /KB	The size of the message box database file produced by running the Backup BizTalk Server SQL Agent job after the test.
KB/Msg	The size of the log file divided by the number of messages.

From the results of the tests, it can be seen that the size of the message box database log increases dramatically as the number of messages being aggregated increases. As the log file is a log of the database activity on the message box database, this implies that the aggregator implementation does not scale well as the number of messages increases.

If there were thousands of messages to aggregate over a 24-hour period for example, the size of the message box database log files would become a significant problem.

The Problem or Persistence

In order to provide reliable messaging, the BizTalk Server orchestration engine saves its state to the message box database at specific points during it’s execution. This serialization of the message state is known as persistence, and each saving of the orchestration state is known as a persistence point. Whilst these orchestration persistence is great from the reliability perspective, it can have some detrimental effects in terms of performance if orchestrations are designed without paying a thought to the mechanics of the orchestration engine.

In the aggregator pattern, as the orchestration starts to aggregate messages, the size of the XmlDocument object that aggregated the messages is small. At each persistence point, this XmlDocument object is serialized to the message box database to allow recovery form a possible failure. As the orchestration aggregates more and more messages, the size of the XmlDocument object increases.

This object is persisted to the database (three times for each message aggregation loop in this case), every time a message is received, so when the orchestration is holding the stare of a few hundred messages, the load on the message box database starts to get heavy. If the patterns is used to aggregate thousands of messages, and the messages themselves are large, the pattern will quickly become unusable.

Building a Scalable Aggregator

The problem affecting the scalability of the aggregator was caused by maintaining the state of the aggregated message as the orchestration looped to receive the other messages in the convoy. If a way can be found to escape the state persistence problem, it should be possible to design a scaleable aggregator pattern.

Aggregator Design Using Messaging and a Database

One of the possible designs would be to abandon the convoy orchestration, and create a solution that was based purely on messaging. At present, in BizTalk Server 2004, there is no way to aggregate messages in the pipeline of a send port in a similar manor to splitting in a receive pipeline. This pattern uses a SQL Server database to store the messages as they are aggregated, and uses the SQL Server adapter to add the orders to the database, and to receive the aggregated list when the aggregation is complete. The completeness criteria is determined in the database, and in this case, a message count is used.

Messaging-Database Aggregator Pattern

In File Drop	The order messages to be aggregated are dropped here.
Order In Receive Port	The receive port receives the order messages and publishes them in the message box database.
Add Order SQL Send Port (Map Order to SQL)	Port with subscription to the Order In Receive Port, and map to map the order messages to the Add Order stored procedure. The port is configured to call the stored procedure using the SQL adapter.
Add Order SP	Stored procedure to add the messages to a table in the Order Aggregation Db, also checks for the completeness criteria, which is based on the number of messages in the batch to be aggregated. When this number is reached, the status of the messages is updated to mark them for aggregation.
Order Aggregation Db	Database containing the table for aggregated orders.
Get Order Aggregation SP	Stored procedure to poll the database for batches ready to be aggregated. When a batch is ready, the data is returned, and the status flag for the orders updated.
Get Order Aggregation SQL Receive Port	Receive port configured to poll the Get Order Aggregation SP to check for aggregation batches.
Aggregated Order Send Port (Map SQL to Order List)	Send port with a subscription to Get Order Aggregation SQL Receive Port. This port also maps the SQL result set schema to the order list schema.
Aggregated Order File Out	File location for the aggregated messages.

Test Results

The tests were repeated using the messaging-database aggregator pattern, and the following results obtained. The Messaging log size is a sum of the message box database log file, and the order aggregation log file.

Msg Count	Convoy Orch Log Size /KB	Convoy Orch KB/Msg	Messaging Log Size /KB	Messaging KB/Msg	% Log Size Reduction
100	7,038	70.38	3,064.00	30.64	56.46%
200	16,446	82.23	5,984.00	29.92	63.61%
300	29,999	100.00	8,676.00	28.92	71.08%
400	47,703	119.26	10,977.00	27.44	76.99%
600	96,976	161.63	16,866.00	28.11	82.61%
800	171,584	214.48	21,755.00	27.19	87.32%
1,000	262,825	262.83	26,593.00	26.59	89.88%

Msg Count	The number or messages used in the test.
Convoy Orch Log Size /KB	The size of the message box database log file produced by the sequential convoy aggregator orchestration.
Convoy Orch KB/Msg	The size of the log file divided by the number of messages.
Messaging Log Size /KB	The size of the message box database log file, and the order aggregation database log file produced by the messaging-database orchestration.
Messaging KB/Msg	The size of the log file divided by the number of messages.
% Log Size Reduction	The percentage reduction in log file size gained by using the messaging-database pattern.

KB Log File Size for Aggregation / Message Count

The effect of the batch size on the sequential convoy orchestration can clearly be seen in the above graph. As the batch size increases, the messaging-database aggregator offers significantly better performance.

KB Log File Size per Message / Message Count

As the batch size increases, the messaging-database aggregator becomes slightly more efficient, producing less log file activity per message. With the orchestration based aggregator, continues persistence of the increasing aggregation state makes the pattern less efficient.

Why is the Message Box Database Log File Size so Important?

The log files created when performing a transaction log backup on the message box database are an indication of the load that has been placed on the database since the last transaction log backup. As a BizTalk server installation is scaled up, and out, the load on the message box database is often a bottleneck. Adding another SQL cluster to handle increased message box activity is costly. It’s much better to design a solution that uses the message box in an efficient way if there it is anticipated there will be a high load on the system.

Conclusions

From the results it can be seen that the messaging-database aggregator provides a 90% reduction in message box database load compared with the sequential convoy aggregator in this scenario. If the message count were to increase, this design could perform 20 or ever 100 times better than the orchestration based design, in a production system, this could result in significant cost reductions. Your database administrator would also appreciate the difference in log file sizes used for the backups :-p.

I tried to keep the tests as scientific as possible, and had planned to include execution times in the results as well. Unfortunately, Virtual PC is not a great platform for performance testing, and does not seem to give the speed that running on bare metal would do, so I have not included those figures. The log file sizes should provide an accurate indication of performance, (and I did remember to add the log file sizes for the order aggregation database as well ;-).

I think the option of using a messaging-database aggregator should be considered when building an aggregator in BizTalk. Apart from the performance advantages, it also provides the option to recover better from failure, as the messages are present in a database, and the aggregation can be triggered manually.

There’s a few improvements that could be made to the design, I’m not happy with creating a database table that contains the fields in the schema, with a hierarchical schema, this would involve multiple tables, and references. It would be much better to save the XML content of the message in one column.

I’ve herd a few people discussing the option of using a pure messaging based solution to improve performance on high load systems, and it would be great to see more examples of this.

To sum it up…

Sequential Convoy Aggregators are fine for handling aggregations with a low number of messages.
Sequential Convoy Aggregators do not scale well with higher message traffic if the aggregation state is held within the orchestration.
Building a messaging-database aggregator provides a design that scales well with large numbers of messages.
It is also possible to retain the sequential convoy orchestration design, and use a database to store the aggregation state if the need arises.

Resurfacing from Deep Dive

Alan Smith — Sun, 15 May 2005 21:12:00 GMT

I’ve just attended the latest of the BizTalk Deep Dive training courses in the UK, which Quick Learn have developed, and are running with a special invite to Microsoft Partners. (I was lucky enough to get a place on one of the free sessions.)

The “entrance exam” for the course ensured all the delegates had a solid grasp of most of the product, and brought with them real world experience of BizTalk development. Ensuring this high-level of expertise on the course kept the discussions and questions at the appropriate level; also if you’re new to the product, you would quickly fall over in the hands-on sections.

The course coverage was broad as well as deep, going through the Share Point, WSE2, and SQL adapters, and also looking at Host Integration Server, and connecting to a DB2 database. Quite a lot of this stuff had been on my “To-do” list for months, and it was good to get a look at these areas of BizTalk that I had not touched yet.

One highlight for me was the in class discussions around complex aspects of the orchestration and messaging engine. These often went beyond the depth of the course notes, and I picked up a lot of info that’s just not documented or, as yet, blogged about. John Callaway, the instructor, has spent a lot of time with the key members of the BizTalk development team, and was able to answer almost all the questions we could throw at him, (usually someone on the course could chip in with some insight into the really tough ones).

If you are making the jump from intermediate to advanced BizTalk development, you should defiantly book yourself a place on one this course.

I also got the chance to take a beer with one of the BizTalk Bloggers, Chrostof Claessens, who was attending another training course at the center. It’s the first time I’ve met one of the contributors face-to-face, and good to be able to put a face to the name. I hope to get the chance to meet with all the contributors to the guide, one down, thirty to go…

Changing a VPC Computer Name with BizTalk

Alan Smith — Tue, 26 Apr 2005 15:59:00 GMT

Im looking at using Virtual PC with a team of BizTalk developers. The idea is to install the dev env (Server 2003, SQL Server, Visual Studio, BizTalk etc) on a virtual PC image, and then each team member uses a copy of the image to develop with.

We have network problems if two or more images with the same computer name are started with network access (to SourceSafe). So I attempted to change the computer name in an image. After a while I managed to do it like this:

Export any information from the BizTalk databases (business rules etc.)
Run ConfigFramework /u
Delete BizTalk jobs in SQL Server Agent
Delete BizTalk logons in SQL Server Security
Delete BizTalk databases
Change computer name
Re-start computer
Change SQL Server Name (with sp_dropserver, sp_addserver)
Run ConfigFramework
Change BizTalkMgmtDB connection in Visual Studio
Change rules engine DB connection in Business Rules Policy Editor
Re-enable BackupBizTalk server DBs job
Add any Hosts and host instances using BizTalk Server Administration
Import information to the BizTalk databases (business rules etc.)

I'm wondering if anyone else is using VPC with a BizTalk team, and has come across this issue, or has any tips. (I'll post an article here and include any feedback).

Is there a workaround for having multiple VPCs with the same name? And is there an 'easy' way to change the name of a BizTalk box?

Update
Another Stockholm BizTalk guy called Ali pointed me to this. Looks like it's easy to avoid the "world of pain" of re-naming the VM PC, thanks to Dunk (wonder why that never got in the Bloggers Guide??). I'd still be keen to know if the re-naming procedure could be optimised...

Back on Track with the Guide…

Alan Smith — Sun, 24 Apr 2005 13:42:00 GMT

There’s a new Bloggers Guide out today. I missed the March release, (moving apartments, painting, laying floors etc.). There will be a May release in a couple of weeks, and I will add the new blogs that have been submitted (sorry I could not get them in this release guys). The 5MB size restriction of GotDotNet may cause problems in the future, (the current ZIP file is 5.26MB, so I’m not sure when (or if) the restriction will kick in).

Get it here.

In other news, I am now a BizTalk MVP, so if anyone is working with BizTalk in the Nordic region, feel free to contact me via my blog if you need any help/advice/tips with the product. I plan to hold a “Learning BizTalk” session with the Sweden .net User Group in Stockholm sometime after the summer, I’ll post here when I get further details.