Here are some more notes that I took down from last weeks BizTalk 2006 course at Microsoft.
• Bulk terminate is definitely not available through the administration console
• No structured performance testing has been undertaken at present. It has been suggested there will be a performance increase, as allegedly every new version of any product always factors in some performance updates. Also, it was suggested SQL 2005 may introduce some benefits in this area, although nothing specific has been added to the BizTalk code to take advantage of anything specific in SQL 2005.
• There are no adapters or support for using SQL 2005 queues at present, as mentioned above they have not implemented anything special for 2005, it simply runs on it the same as it does on 2000. However, they expected an adapter to ship at a later date.
• There will be no finer grained HTTP error descriptions. I had a discussion with one of the product team and requested that this really is highly desirable.
• Throttling does not go any lower than at the Host level. However, you can design your BizTalk group in such a way that this would therefore provide throttling at a more targeted level if that is a requirement. Please note that throttling at the host level is split into three sections, send, receive and general settings. The purpose of the throttling is to simply restrict BizTalk from failing, not as a functional throttling mechanism. However, this is going to be addressed in the next release even though they were stressing how difficult this would be to achieve.
• Pipelines are transactional since 2004; although I did get slightly contradicting views today saying that BAM partakes in transactions inherently after applying a post SP1 hot fix. I need to follow this up. They are working on making pipelines that are called from within an orchestration transactional as well.
• WSE Adapter – They will be providing patches with each build to get working and do not have an answer on v3 yet.
• Ordered Delivery
o Adapter agnostic – all adapters (including custom) will use if specified and use correct interface.
o There are some rules around suspended messages so that you can control the ordered delivery so that it is not broken for suspended messages.
o Ordering is done at a Send Port level
o Ordered by when the message is placed on queue, not completed i.e. large messages do not make a difference.
o The Send Port instance gets suspended if you choose to stop sending subsequent messages on message failure. At present if you modify a failed message then the ordering is going to break – they are currently investigating this.
• BAM Backup scripts are being worked on and should be provided.
• Pipelines – You can now supply parameters to pipelines from within the administration console. There were scenarios whereby clients had created lots of pipelines that essentially did the same thing except for a couple of minor configurations. This is to avoid this situation.
• Flat File Wizard – I have not used flat files much in 2004, but knew it could be painful. This wizard is impressive; quite like the sort of thing you would find in Excel in the way it is intuitive and allows you to provide it sample data.
• You may call pipelines from orchestrations
• Zooming in the orchestration designer!
• BAM
o A considerable amount of work has gone into BAM and although it still looks like a hodgepodge of disparate technologies chucked together, it is certainly an improvement.
o You now have a SPS Portal view that can be accessed by Business Analysts to view results rather than having to use Excel.
o Integrated with SQL Notification Services to provide alerting.
o Native integration with BizTalk Messages so you can have BAM in both pure messaging scenarios along with orchestrations.
o You may distribute the BAM infrastructure so that teams that are closely related to the application data can ‘own’ it.
o There are some web services that expose some management functionality.
• End To End Scenarios
o A huge amount of effort has been spent on creating some SDK scenarios based upon patterns that have been fed back to them from various clients. The goal is to improve product lifecycle experience and validate 2006 for key end-to-end scenarios. For example, they have SO, BPM and B2B scenarios that comprise of various common components you would find in such architectures and these can be deployed on a single server and then spread out to disparate systems if required. I am quite excited about this mainly because I have just spent the afternoon discussing it with numerous people at Microsoft and you really can see how much they value providing some quality examples and associated material in this area. They admit this is the start of a long road, but it was good to see the quality people they have working on it and their eagerness to hear our opinions.