If you are interested in the BizTalk Business Rules Engine here’s one for you: we have recorded the Auckland Connected Systems User Group meeting from last Thursday by Jeffrey Chilberto on ‘A Practical Exploration of the BizTalk Business Rules Engine’. It’s a very hands on presentation that goes over basic and advanced topics – exposing rules engine rules via WCF for example. It serves as a great precursor (and good timing) to Charles Young’s presentation next week at the Sweden BizTalk User Group on the BizTalk Business Rules Engine. Here are the links:

• Video – zipped WMV file
• Slides
• Code Samples

Enjoy!

There was a great discussion that ensued after the presentation that I didn’t include in the video. Jeff asks: why aren’t companies using the BRE and its functionality more? Some of the points from the discussion:

• Time consuming/ramp up – It is a completely different technology to the rest of BizTalk or just coding, different concept, with its own list of gotchas, so the developer has to learn them
• Worth it though – performance is very high. The performance experienced is usually from the external classes used and not the rules themselves.
• BRE composer interface is old and hasn’t changed since BizTalk 2004, no changes in BizTalk 2009 other than the splash screen
• Extra functionality and updated interface would be well accepted
• No out of the box functionality to allow business users to creation of rules
• But ok to expose to an operations team to make modifications to rules especially if the vocabularies involved are already well defined
• Currently to expose the creation of rules to a specific group of business users, in their own domain, the solution is to create and edit the rules programmatically via a custom UI or website restricting what and how they can see and do
• Lack of more advanced functionality like decision trees
• Currently has to be done in code that calls multiple policies
• Business Rules being used in the ESB Toolkit and RFID is a good indication that it is here to stay, just needs to be improved
• Still required to have a license to use the business rules engine but can get away with a standard license

Regards,

Thiago Almeida

This week Microsoft have announced details about BizTalk 2009 R2 at the Professional Developers Conference. Since BizTalk 2009 was released this year in around May this is a very tight timeframe for the next release. What is exciting about it from my perspective is that Microsoft have released BizTalk 2009 to align with the latest version of MS build project types, support for Visual Studio 2008, Windows Server 2008, and SQL Server 2008 – but haven’t introduced many new features per se from a development, management and operations perspective. This means that with BizTalk 2009 R2 they can release new features that they have been working on for a while. This is the list announced so far:

• BizTalk Server 2009 R2 to be released in 2010 together with the AppFabric wave of releases
• Support for Visual Studio 2010
• Support for Windows Server 2008 R2
• Support for SQL Server 2008 R2
• New Dashboard for performance management over BizTalk farm
• PowerShell support for management
• Revised and improved System Center Operations Manager object model
• Improved RFID support to client applications
• Improved mapper
• Support for FTPS and enhancements to the existing FTP adapter
• Updated B2B accelerators to keep up to date with standards
• A few other smaller updates

For more details about the features see Brian Loesgen’s post:

http://www.brianloesgen.com/blog/2009/11/21/biztalk-server-2009-r2-announced.html

Also watch the video from PDC:

http://microsoftpdc.com/Sessions/SVR15

Since this is the first official announcement we should see more smaller features announced and more details about the above so keep tuned!

Regards,
Thiago Almeida

I had to go through this a few times recently so I thought I’d document it:: when does BizTalk Server save tracking information to the tracking database, and how does it all link together?

Basically BizTalk will track information about a messages in the following locations:

• On a receive port right after the adapter receives the message and before the receive pipeline or any maps are executed
• On a receive port right after the pipeline and the maps are executed – this means the message type tracked after the receive port is the message type after the map execution
• On an orchestration as a message is received
• On an orchestration as a message is sent
• On a send port right before any maps or the send pipeline is executed
• On a send port right after the pipeline is executed just before the adapter sends it out

Let’s consider a typical scenario: a message is received via a receive port with the file adapter. No disassembly is made (i.e. there is only one document in the message). An orchestration subscribes to the message, does some processing, and sends out only one message. A send port bound to the orchestration sends the message out.

This diagram shows the stages where BizTalk would record information about the message to the tracking database:

Note that BizTalk records that the message has gone through those stages even if you haven’t enabled property or message body tracking on the ports or orchestration. This is recorded online by the Tracking Data Decode Service to the dta_MessageInOutEvents and other tables in the BizTalk Tracking database. If message content and context tracking is enabled on the particular service then the BizTalk SQL Agent  jobs will take care of moving this from the Message Box database to the Tracking database on a scheduled basis (every minute with the default setting).

Now that we’ve established the basics of where BizTalk records the message information, how does it link together? How do you know the sequence of what happened after BizTalk has processed the messages? If you look back at the diagram you will see that there is a direction and a different message GUIDs at each message tracking point, and there is a different Service Instance GUID on receive ports, send ports and orchestrations.  Service instances are the specific instance of the service (receive pipeline, send pipeline, orchestration) that handled that particular message. A service instance will receive a message with a message GUID and send a message with a different message GUID, with the exception of when failures occur. So a receive port service instance receives a message with message GUID 1. It then sends one or more messages out, each with their own message GUIDs. The next service instance (send port or orchestration) that subscribes to those messages will have their own service GUID, but the received message GUID is the same as the message GUID sent by the receive port. Then if this orchestration or send port service instance sends out one or more messages these will have their own message GUIDs as well, and so forth.

To make it clear, let’s look at a scenario where a receive port receives an XML message and disassembles it into two messages; then two instances of an orchestration that subscribes to the disassembled messages performs some operation on them; then the orchestration instances send out a final message via a send port. With this you will have this GUID tree structure in the tracking database:

• Receive Port Service Instance 69dee51d-21c0-4f85-ba80-58fdb08da6ec
• Receive Message 2b220b2d-a07a-4752-ad23-4cfd9f769c25 << Unparsed Interchange (ie original unchanged message)
• Send Message 56684d73-5dac-4bd8-a2ce-faba9bc89b6c
• Send Message 7553db2f-3ea6-47a1-9cf4-fdb02d6d3c37
• Orchestration Service Instance f3dfe962-3718-4995-bcfb-d3f0cdf82772
• Receive Message 56684d73-5dac-4bd8-a2ce-faba9bc89b6c
• Send Message dade4b4b-cc39-4464-b587-d8fa09772796
• Send Port Service Instance a96660f7-9665-4a05-b440-6929679eafd5
• Receive Message dade4b4b-cc39-4464-b587-d8fa09772796
• Send Message 854a04da-d1b1-4c26-94df-7e36fbe8cb3b << end of tree
• Orchestration Service Instance 380185b9-0c0e-4b21-afd5-94afebc11dfb
• Receive Message 7553db2f-3ea6-47a1-9cf4-fdb02d6d3c37
• Send Message 36baa5ba-3cb8-45aa-afe3-1d0e0b60469a
• Send Port Service Instance 68041f1b-242f-4043-8f95-a6227b82dd12
• Receive Message 36baa5ba-3cb8-45aa-afe3-1d0e0b60469a
• Send Message 67e51bf5-e530-47d9-90b5-48ffeaca8ad0 << end of tree

As you can see there is an initiating tracking entry with an unparsed interchange receive and the tree builds from there with any number for nodes. If you enable message body tracking on the receive port, orchestration or send port BizTalk will also track the message content. It is with the information from the GUID values that the ‘message flow’ option in the BizTalk Administration Console is built. If you open the BizTalk Administration Console and look at the Tracked Message Events you can see the direction in the Event Type column, the schema name (with unparsed interchange as the first one), and the service class/service name to determine the service that was handling the message. With the above scenario you will get a result like the below: a received unparsed interchange and two sends from the same pipeline service instance. Two orchestration instances receive each message and send a message out. And two send pipeline instances receive the messages from the orchestration and sends them out:

If you right click on the unparsed interchange entry and select ‘message flow’ you get the good old HAT view of the message flow, that gives us a lot of information: the ‘Instance ID’ at the top is the service instance id of the receive pipeline. Each entry on the table has an in or out event depicted by the envelope with an arrow coming in or an arrow going out. Each entry also shows the message id and has a clickable link to the next or previous step in the tree if there is one. I’ve highlighted in red the parts of interest:

From the above you can then click on one the orchestration links and the message flow will show the flow from that orchestration instance’s perspective (where you can also switch to the orchestration debugger but that’s another story):

This way you can traverse the entire tree of what happened after the original message was received. Another way of following this structure is by querying the dtav_MessageFacts view on the BizTalk Tracking database and building a common table expression query (with MUCH caution) around the three values [MessageInstance/InstanceID], [ServiceInstance/InstanceID], [Event/Direction].

I hope with this insight into message tracking in BizTalk you can now follow the tracking of messages and events through the BizTalk Administration Console with ease!

Regards,

Thiago Almeida

Hi everyone, the website for hosting webcasts built on Azure technology spearheaded by fellow MVP Alan Smith has had a URL facelift. The new website URL is http://www.cloudcasts.net/ so update your links and favourites.

You can watch my presentations here (currently just the one on the WCF-SQL Adapter for BizTalk):

http://www.cloudcasts.net/Default.aspx?presenter=Thiago Almeida

Regards,

Thiago

Quick note – to those attending to the PDC in Los Angeles this week make sure you check out the hands on labs on WCF, WF and Dublin put together by Ron Jacobs and the Microsoft team. Lots of good stuff there on the upcoming .NET 4.0 features. Those following the Endpoint.TV podcast on Channel 9 will already have an idea of the great walkthroughs and samples in the labs. If you aren’t attending to the PDC keep tuned as the labs will also be made available publicly as well – I’ll update this post when they are.

Regards, Thiago

I’m happy to announce that the next Auckland Connected Systems User Group meeting is set for the 19^th of November 6:00pm at Datacom, 210 Federal Street downtown Auckland, New Zealand . Free entry, pizza and drinks provided as usual. Register here.

Jeff will take us through a practical exploration of the powerful Business Rules Engine in BizTalk Server, including guidance on creating vocabulary and policies, versioning pitfalls, and exposing the BRE as a WCF service.

Jeffrey Chilberto is a Software Consultant specialising in designing and developing business solutions using the Microsoft technology stack.  His focus is integration solutions using BizTalk, WCF and SQL Server technologies.

More information and registration form.

See you there!

Thiago Almeida

Emil Velinov from the Customer Experience Team in the Business Process Division (CSD + SQL) came to the New Zealand Tech Ed in September to present on BizTalk Server 2009 and Dublin.

During the visit the manager for BizTalk Server in New Zealand, Darryl Burling, spent some time with Emil to discuss BizTalk and Dublin as part of an awesome podcast series that Darryl is running. I highly recommend following the podcast, and this entry in particular for anyone interested in BizTalk and/or Dublin:

http://www.burling.co.nz/post/MSNZ-Podcast-5-e28093-BizTalk-Server-2009-and-Dublin.aspx

Regards,

Thiago Almeida

Every time when creating a Visio diagram for a solution architecture involving BizTalk I can’t really find a good server icon for BizTalk Server. Then I twittered my frustration.

What ensued is one of the best things about Twitter in my opinion.  Two twitter messages away I got the icons! Thanks to Todd Sussman and Rick Garibay for hooking me up. If I had looked around I would have found two of them, but this has a few extra stencils in the file.

Get them while they’re hot:

http://cid-df930ee6f91132fd.skydrive.live.com/self.aspx/Public/Share/BiztalkServer2006.vss

Other useful stencils for BizTalk are:

The icons from Enterprise Integration Patterns available here: http://enterpriseintegrationpatterns.com/downloads.html

Some stencils by André Dammeyer: http://www.acsug.co.nz/files/Downloads/BizTalk-2006-Messaging-Shapes.aspx

Do you have any others?

We’ve recently had some development and test BizTalk environments move data centres, and after the BizTalk Server machines were restarted the BizTalk host instance services stayed disabled.

By default the BizTalk host instance service (the windows services named ‘BizTalk Service BizTalk Group: <host name>’) have a start up type of Automatic. There is a known issue with Windows Server 2008 and Windows Vista where the Enterprise Single Sign-On service doesn’t start quickly enough and the BizTalk host services end up failing to start.

The resolution is simple: change the start up types for the BizTalk services on all the BizTalk machines in the group to Automatic (Delayed Start). This gives the Enterprise Single Sign-On enough time to start before the BizTalk services try starting.

This behaviour has been acknowledged by Microsoft in the support article 942284 and in the BizTalk forums.

So if your company are running BizTalk 2009 on Windows Server 2008, or BizTalk 2009/2006R2 on Windows Vista you should update your installation, release, or deployment notes to include updating the services start up type.

Regards,

Thiago

Just got a note from Ewan Fairweather from the BizTalk Customer Advisory Team. He is presenting a TechNet webcast on the BizTalk performance tests him and his team have performed this year and their results.

The webcast is happening in a couple of days (Tuesday, September 01, 2009 1:00 PM Pacific Time). For those in New Zealand that is Wednesday, 2 September 2009 at 8:00:00 a.m.

To read more about it and register for the webcast follow this link:

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032416252&EventCategory=4&culture=en-US&CountryCode=US

Regards,

Thiago