BizTalk Rules Engine
If you are working with the BizTalk Rules Engine then here are two sites that are definitely worth checking out:
Defining Business Rules and The Business Rules Manifesto
Wish List for BizTalk 2008 (Biztalk vNext)
With the official launch of Biztalk 2006 just weeks away, I could not help but start thinking about what I would like to see in Biztalk vNext (a.k.a Biztalk 2008 / 2009).
It will most likely have support for workflows written using Windows Workflow Foundation or even better it may be built on top of the Windows Workflow Foundation.
That is great and all, but it is important not to forget that Biztalk is an integration tool. The support of workflows using Windows Workflow Foundation alone will not help solve some of the existing tricky integration scenarios we are facing today.
With that said, what improvements and enhancements would I like to see in the next version of Biztalk…
Convoy as a setting on the receive port
Many times convoys are used to achieve first-in first-out for various conditions. This requires a Receive followed by a 2nd Receive and usually a timeout (using a Listen Shape). Rather than using multiple Receives that add little value other than making a Convoy, add a setting on the Activate Receive Port so it can be marked as “FIFO” thus providing Convoy behavior based on the correlation set on that Receive Port. This would be similar to the new FIFO support on the Send Ports in Biztalk 2006.
Ability to suppress event log messages via a context property
When using Delivery Notification it is common to have extensive exception handling built inside the Orchestration to react to any problems and possibly write to some other event log (other then Application). It would be nice to be able to suppress the events written to the Event Log in this case. Also, having an easy way to change what event log is written to would be nice.
Better control over property promotion
This applies mostly to direct message box binding with untyped messages – that is messages that are System.Xml.XmlDocument. I am a big fan of direct binding to the message box. This is an underlying key component to Biztalk Server even though it is hidden nicely to new developers. It would be nice to have better control on what is promoted when sending messages out of an Orchestration. There are some tricks using a correlation set to get values promoted that works. But, I would like to see something a little better or at least to have this process documented.
Checking a promoted property that does not exist does not throw an exception
It sure seems silly to have to put checks on promoted properties inside a Scope Shape just in case the value does not exist.
When a default value is set on a promoted property and it is associated with a schema the default value should always exist in the message context
This can currently be done rather easily using a custom pipeline component but that can be a maintenance nightmare and error prone. This would also help support a “Not Exists” subscription condition by allowing the default value to be treated as the “Not Exists” condition. The value could be overridden in a pipeline for normal processing. It would also help with the exceptions when checking properties that do no exist as noted above.
Support for multiple Acks and NAcks with send port groups
It would be nice to be able to process multiple Acks and NAcks when using Delivery Notification inside an Orchestration. This would allow for the use of send port groups for these scenarios. I have been trying to build a process to do this but after MANY hours of work I have not been able to get it to work.
Feel free to post your own thoughts and comments.
Business Rules Enhancements in Biztalk Server 2006
I tend to see more and more clients using Rule Engines now then I did in the past. So, what can we expect to see different and better in Biztalk 2006?
At the BPI Conference two weeks ago we found out some of the new enhanced features that the Business Rules Engine would have in Biztalk 2006.
Some of these are:
– Ability to be installed without Biztalk
– No longer needs to be called inside an Atomic Scope
– Document type will try to be auto populated when you add a schema from an existing Biztalk project (this is great – until it gets it wrong)
– Ability to have debug information written to file at run time
Of course, these can change before the final release of the product early next year.
Business Rules Message Construction in Biztalk Server 2004
Wow. I was in the middle of working on a blog post about message construction and the Business Rules Engine (BRE) in Biztalk 2004.
Several other Biztalk Developers and I were talking about this topic at Tech Ed and at the BPI Conference. I looked at Richard’s Blog and he posted an excellent post on the exact same topic!
At first glance, it looks like the BRE changes an immutable message or does it?
The long and short of it is:
No: the BRE does not change an immutable message
Yes: the Call Rules Shape does construct a message without using a construct shape
Yes: you can lose Context properties in the are set on your original message inside the Orchestration (see Nishil’s post for more info)
That got me thinking… I wonder if you put a persistence point after setting the Context Property if you would still lose the value?
Twin Cities BizTalk User Group
On September 22nd we held the first Twin Cities BizTalk User Group at the Microsoft offices in Bloomington, MN. This was a great opportunity to see and talk to fellow BizTalk enthusiasts and catch up with people I hadn’t seen in a while.
I would like to thank the other people who helped me put this user group meeting together:
Andy Morrison,
Scott Colestock,
Jim Gaudette and
Todd Van Nurden
I presented on BizTalk 2006 and the changes and additions that will be coming with the new version. The presentation can be downloaded here.
If you are in the Twin Cities we would love to have you attend. Our meetings are every other month and our next meeting will be Thursday, November17th, 2005 at the Microsoft offices in Bloomington
As far as we can tell this is the first BizTalk User Group in the country. If there are others please post a comment – we would love to hear about it.
BPI & Workflow Conference 2005…
I had the pleasure of delivering a short talk at the Business
Process Integration & Workflow Conference last week in Redmond. The
whole conference was great, especially meeting quite a few folks in person I’d only
conversed with via email. Being notified of MVP status for BizTalk on Friday
was a great cap to the week!
Although the sample I presented during my talk isn’t quite ready to release, the slides (on
scatter/gather scenarios in BizTalk) can be downloaded here.
BPI & Workflow Conference 2005…
I had the pleasure of delivering a short talk at the Business
Process Integration & Workflow Conference last week in Redmond. The
whole conference was great, especially meeting quite a few folks in person I’d only
conversed with via email. Being notified of MVP status for BizTalk on Friday
was a great cap to the week!
Although the sample I presented during my talk isn’t quite ready to release, the slides (on
scatter/gather scenarios in BizTalk) can be downloaded here.
Unofficial Abbreviation for Windows Workflow Foundation is now simply WF
Is it KFC or Kentucky Fried Chicken? Well in that case legally it doesn’t matter because the same company owns both the name and the abbreviation. Of course for marketing reasons they have swapped from the full-name to the abbreviation and back but that’s another story.
In the case of Windows Workflow Foundation we own the name Windows Workflow Foundation. However, we didn’t trademark an abbreviation so there is no official abbreviation. Indeed we tried, albeit with a phenomenal lack of success, to launch the technology referring to its name and its name only. It was an interesting study in Microsoft and press culture to see people abbreviating to WWF with a few notable exceptions here and here. Given people’s natural desire to abbreviate the technology name to three letters and potential, untested, issues with the WWF acronym we feel compelled to strongly suggest you use the acronym “WF” for the technology only.
Remember its Kentucky Fried Chicken (Windows Workflow Foundation) not KFC (WF) so use WF when you are severely space constrained.
Message Replay…
You can find my thoughts on a really simple message replay (message
re-processing) technique for BizTalk in Stephen Thomas’ The BizTalker newsletter.
Check it out here.
For additional clarification, I’ve created a quick Visio here.
Message Replay…
You can find my thoughts on a really simple message replay (message
re-processing) technique for BizTalk in Stephen Thomas’ The BizTalker newsletter.
Check it out here.
For additional clarification, I’ve created a quick Visio here.