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.