Some more information for those who have been following my posts on this topic.

MSMQT : It appears that the MSMQT behavior is by design. Since it is a pseudo queue and really puts stuff into the messageBox, the basic msgBox principle has to apply (ie) a subscriber has to exist. So a dummy send port sending stuff to a file is acceptable even if it is stopped or unenlisted temporarily. Tomas Restrepo, an MVP on the newsgroup suggested i consider moving to MSMQ instead and use the MSMQ adapter since that is the MS recommendation for doing message queueing. Fancy that!! they release a pseudo queue and ask us to consider using something else!! Of course, there are pros and cons for each. For a comprehensive discussion on the history of MSMQ adapters in Biztalk, refer to this article . Anyway, the key point for me is that there is no guarantee of ordered delivery and in this phase of my project we have a service that pumps out customer data into a queue which is then picked up by an orch and sent to the hub which does the dispatch to other systems. Since the customer data involves inserts, updates, merges etc, the sequence is vitally important otherwise we would end up with unnecessary exceptions at the other end. (We may send an update message to the target system before sending an insert and so on). It was also suggested that i consider piping the MSMQT files to a folder while an update is going on and then resubmitting the files once the patch/redeploy is complete. A good suggestion, but the FILE adapter doesnt guarantee sequencing either. So im going to have to either write a custom adapter or work out some other tool which submits the files to the receive location one after another in the correct sequence. I did write something like this for my previous project (the controlled submission was to avoid locking in the database) so perhaps i can reuse that here.

BizUnit, XML Validation and AltovaXML: Turns out that there are problems in XMLValidation when using BizUnit. It cant handle validating against a collection of schemas even when all the ‘included’/imported schemas are in the same folder. Additionally, the XPath statements are constrained to those that can return nodesets only (in BizUnit 2006 there is an enhancement which works around this). So we had to look outside of BizUnit. We considered writing our own custom steps, but for the present the time element is critical and although that is a good long term solution, we didnt want to go down that route today. Fortunately, BizUnit has an inbuilt ‘extensibility’ mechanism or in other words, an escape route, in the form of a DotNetObjectInvoker which allows you to invoke any dotnet type that can take input parameters and return a result. So all that was needed was the requisite classes which could then be invoked from BizUnit. For XPath we wrote a helper class to evaluate and return expressions of integer, string and boolean values. For the XMLValidation, we found that Altova provides the AltovaXML 2006 library free of charge for developers ( i need to check the production license, just to be safe) and that has .NET interfaces as well as Java, COM and XSLT interfaces. So we wrote a wrapper around it and called it from the DotNetObjectInvoker. It works like a charm. So we are going to make extensive use of that in our tests. We also found that there is no ‘CommandLineStep’ which could be used to run a Shell exec on some command line statementas but that should be trivial to write (a bit like the NAnt ‘exec’ task) .