The 2009 version of BizTalk Server is soon to be released, but we have been asked to give feedback to the product team on what features we’d like to see in future releases. My plan was to focus on smaller things that I think would make a big difference (all though I let my self go a bit further at the end).
If you think I’ve missed something, please let me know and I’ll make sure to pass it forward.
- In the 2009 version, as the BizTalk projects became C# projects we were given a better support for MSBuild and TFS Build. The possibility to build to and on a server that has not got Visual Studio installed is really great from a deployment perspective. However, since we have not been given any tooling for the actual deployment/undeployment, it requires lots of work to make it useful. I'd really like MS to either create a supported Deployment API or make the Microsoft.BizTalk.Deployment library more "public" by documenting it.
- The bindingsfiles are one of the key components for automated deployment. First I'd like for you to make use of the Application property in the BindingInfo class. The problem is today that when you create your custom tasks for deployment/undeployment you would need to store the information about the Application and its references somewhere else since it's not to be found in the bindingsfiles.
- Bindingsfiles are all together a very difficult thing to manage in different environments. A tool for this where we could edit and manage our bindingsfiles, would increase our productivity immensely.
- There has been a lot of talk about this. I don’t really think of it as a big issue anymore as Dublin is on its way. However, one small thing that would REALLY make a difference would be to move the polling interval setting from the group to the host.
- In 2006 we were given the possibility for configuring pipelines at runtime. This was a really good thing, where we don’t need to have hundreds of almost identical pipelines. Although I'd really have like this feature to be implemented with a “real” property box that supported UI editors.
- To be honest, I don't really like the notion of pipelines at all, and would rather see them as default settings of components, which I could select and use as-is or alter at runtime by adding or removing components.
- Use table partitioning rather than the views and tables we have today. This way we could make better use of indexes and boost the performance. This feature where implemented in SQL Server in 2005…catch up!
- BAM administration in the admin console
- Simple BAM reports in the admin console
- Better schema support
- Message Archiving
- Supports regular expressions
- Support for FTPS
- Remove the mail address from the URI, so that we can make better use for the adapter in a messaging scenario.
- Enforcing a Tracking host
- Failed message routing for orchestrations
- Code windows for functoids and the expression should be made sizeable
- Project templates for pipeline components and Functoids.
- Improved visualization for mappings
- Simulation and Orchestration debugging from VS
- Self service portal. Almost 90% of all all issues that comes to our support is about –"Where is my f***** message?". Providing a BAM driven portal where these rude "customers" can find this information themselves, would greatly boost the productivity of our dev team.
If you don’t follow Don Box on Twitter you might have missed this poem:
I love ML.
Literals, constants, and values, oh my!
A compiler for all of these in the sky.
With parsers and lexers and checkers and such.
It makes me love my team so much.
Objects you say? Oh no, none of these!
Our data and behavior - kept separate if you please.
Eviscerate all of that OO-based junk.
Just bring in da noise; Bring in da func.
Patterns and practices turned on their ear.
With a match in the front and an apply in the rear.
To match is human, to bind divine.
fn Water w => Wine w;
- Don Box