Santosh Benjamin's Weblog

I’m back in the NUnit world after a long time. We are looking at packaging up the NUnit GUI along with some BizUnit tests for my current gig so that we have a set of integration tests to run on the rigs. Ironically, the project isnt even a BizTalk one, but BizUnit is still a useful framework, nonetheless. More about that in a later post and back to the main subject here.  

I created a separate NUnit project file and specified assemblies etc. I intend the project file to be deployed on the rigs as well so we can just open the GUI, select it and run the tests. The first hitch I ran into was that the NUnit GUI didnt recognize my app config file. After some digging around I found this post by Charlie Pool which shed some light on how NUnit looks for config files however the key point missing in Charlie’s post  (or maybe its obvious and i’m just dense   )there is the exact location of the file. The file should be a sibling of the NUnit project file and not in the bin\debug folder (unless of course your nunit proj file is there)

To summarise  Charlie’s point with my extra clarification:  If you load an NUnit project, such as mytests.nunit, the config file must be named mytests.config and should be co-located with the .nunit file.

I also found a gem in the comments that helped me sort the issue. The commenter indicated that we can examine AppDomain.CurrentDomain.SetupInformation.ConfigurationFile  in debug mode. I didnt know this could be done and found a ton of interesting stuff in the SetupInformation structure too which i should look into some more.

Hope this helps anyone running into this issue.

BizUnit meets XAML

So, Kevin has got round to making an alpha release of BizUnit v4. This time the steps are all in XAML which i think should now faciliate new tooling. I’m getting my grubby hands on it now.

BizUnit (3.x) Snippets

This is sooo like me. Always late to the party.  . Just this evening, before i found out that v4 had been released (although i knew it was in the works for sometime) , in the latest code drop for BizUnitExtensions (3.0.0.1) , I’ve included some snippets that i wrote quite a while ago and just never got round to uploading. Take a look. I know its rather late and probably completely out of date now that v4 is released but hey, v4 is still alpha so i have some time to catch up.

BizUnitExtensions Futures

So what of the BizUnitExtensions project itself? As you may have seen, there hasnt been any updates or releases for many  months now. The reason is that although for the past 18 months I have been involved in a major BizTalk gig, we have been required to use a custom test framework which has left no scope to use BizUnit at all. Consequently,  I let the codebase languish with only one or two minor updates.

Although project-wise nothing has changed, just today I decided it was time to give BizUnitExtensions some attention. I have recompiled the sources (after the codeplex TFS upgrade) and added the snippets in. I have also started to do some major restructuring of the code-base and recompiling against .NET 3.5, EntLib 4.1 etc which I will make available shortly and possibly include some fixes that folks have described in the forums.

Beyond a minor release, I dont think I will continue to maintain BizUnitExtensions as a separate project. I’ve had discussions with Kevin Smith about merging the steps from this project into the main BizUnit distribution and v4 is where this will happen as soon as i get the go-ahead from him. With MockingBird and WSCFBlue  taking up the majority of my limited spare time, I have to let go of some projects. But i think merging the code into BizUnit (core) will be good for the community so it becomes a one stop shop. Most of the steps complement the core nicely by supplementing it with missing features and with the XAML foundation, efforts can now be directed towards tooling.

Check out the snippets and let me know if they add any value to you. If this is of some value, then I can try and do the same for v4 so when we merge we have a full set of new snippets. If you are an early adopter of BizUnit v4 and want to use Extensions functionality and can help with porting to XAML and/or writing snippets, do let me know.

MockingBird v2 has almost reached RTM. Just a few more days to make some final touches and it will be ready. The team has been discussing how to take it further and one thing that’s been on my mind for a long time is the topic of mock BizTalk adapters. What I would like to do is write some adapters with the WCF LOB Adapter SDK that link up with MockingBird’s simulation engine so we can then simulate various protocols such as SQL, Oracle, MSMQ, MQSeries etc.

The first question that anyone would ask me is “Why? “. Currently MockingBird works decently as a receiver from BizTalk in one way and solicit response mode. (It also supports duplex channels). If you have a one way message from BizTalk or a solicit response, then all you need is to replace the URL of the endpoint with the MB url and with the right config, the system will send back the messages you were expecting. So, why do we need to mock an adapter when we can simply avail of the WCF-Custom adapter?

While the first thing that comes to mind is that MB only handles the send side and does nothing on the receive side, i do think that there are many other reasons to go down the adapter route (on both the send and receive sides)

For the send side

1. Adapters will allow us to manipulate & use context properties. For situations where transport level correlation is being used (MQSeries, MSMQ etc), the adapter will let us force copy correlation identifiers to the response. Without this, we would need to have a queue listener that understood the MQ/MSMQ protocols and set properties accordingly.
2. Adapters will allow us to simulate transactional behaviour.
3. Minimizes the ‘intrusion footprint’ of the tool. Currently even if you were targeting SQL you would need to switch to WCF Custom and make a lot more binding changes. If we could adhere to the SQL adapter properties, it would reduce the amount of work. In fact all we should require is a change of url (eg: mbsql:// )
4. If an application interface doesn’t support web services, then piggy-backing on WCF LOB adapters will allow us to mock that system (assuming we are wrapping that system with the WCF LOB Adapter, we could potentially leverage that adapter to direct messages into mockingbird). So if there is a SQL/Oracle database, because we can connect to that via WCF-SQL , WCF-Oracle etc, we can just add the mock flavors of the same otherwise we would have to mock the entire SQL/Oracle protocols which is not feasible.

For the receive side

1. Although we can always create a test receive location with the file adapter, this is limited to ‘unit tests’. We cannot simulate other transport protocols (for example, polling sql. Also with queues (MQ/MSMQ) we would need an app that could send to the queue to activate the receive location.
2. We could extend an adapter to use the ‘Submit Direct’SDK  sample to send messages into BizTalk directly and configure this.
3. The context properties argument also applies here. A lot can be set artificially on the message. Similarly transactional behaviour could also be applied.

So, what about other current tools in this general area ?

1. Some of this kind of testing can be done with BizUnit (example : sending messages to a queue or reading from a queue). BizUnit could also be extended (example : a correlation aware queue listener) but BizUnit’s focus is on distinct steps that verify behaviour rather than on causing/forcing some behaviour which we can do via the adapters. The adapter approach also keeps this testing ‘within the boundary of Biztalk’ . while BizUnit will complement this nicely from the outside.
2. LoadGen can also help on the receive side. Again, LoadGen’s focus is on load/stress testing rather than functional behaviour. I think it may be possible to use LoadGen with Mockingbird (maybe as part of these adapters).
3. BizMock is another tool that is in similar territory. But having discussed MockingBird with Pierre Milet Llobet, the author of BizMock, I don’t see any overlap here. BizMock is focussed on providing a fluent interface to help with a TDD approach to BizTalk testing and on providing a mock adapter that is used within that test scope, but MockingBird’s adapters will be ‘proper’ infrastructure and integration test faciliators rather than a unit test tool.

Okay, so these are my thoughts on extending MockingBird into the arena of mock BizTalk adapters and I would really like to get feedback from the BizTalk community on this. What do you think of the idea? If you have some experience with the WCF LOB Adapter SDK (which I’ve only played with briefly) perhaps there’s some suggestions you can make or tips/gotchas you can make us aware of ? Is this an area you could get involved with (not necessarily have to contribute code, there are bandwidth constraints on all of us, but potentially send us suggestions, design ideas , maybe be an early tester etc?) .

Let me know. All feedback would be greatly appreciated.

It’s finally arrived. The BizTalk Documenter v3.4  can now be run on 64 bit systems. There are a few other fixes and features as well

• Firstly it now supports SxS scenarios. In the past if you had an orch or a schema with the same name in 2 different assemblies (different versions of the assembly), the tool would not allow you to add the second instance. The internals have now been thoroughly revised (now using a custom collection instead of the previous hashtable) so SxS is no problem.
• The Tracing has been overhauled. To keep it simple, there is no bitmask of trace levels. It is just set to ON or OFF. Trace can be monitored via a tool like DebugView or you can choose to turn on EntLib tracing if you wish (the system allows configuring the logger name).
• The command line parsing has been rewritten to allow usage of path separators (incl colons). The target list of applications must be comma separated and if you want to use application names that have spaces in them , remember to enclose the entire list in quotes.
• Command line parsing now supports overriding of defaults as well as storing of some defaults in the exe.config file.
• A number of other fixes and corresponding work items closed.

For those who have sent in enhancements and reported (minor) issues with the XSLT, please note that your changes are NOT in this point release as there was just enough time to get the 64 bit and SxS support.  I am planning for v3.5 which should have all the XSLT issues sorted and any other critical bugs and possibly include some multi-threading as well to improve performance against large installations. There have also been some requests for being able to run the tool against remote installations and that will be investigated.  I wont make any promises on timescale but will keep working on it. Please try out the latest version and send feedback via this blog or on the codeplex workspace. Looking forward to hearing from you.

Although BizTalk is in many respects ‘contract driven’ (with the emphasis on first setting up the XSDs for the messages etc), WSDL First development has, IMO, always been a bit ’iffy’. The purpose of this post is two-fold. One is to (re) start the discussion around Contract First development with BizTalk and the other is , through the discussion, to get a list of pain-points that I can go back to the product group with via our field channels and which would be of use to them in planning features for the next versions. I’m hoping that even if we cant get these into the core product, we could at least influence  and/or help set up a CodePlex project to provide some of the missing ingedients.

In v2004 (and 2006 R1) absence of support for Contract First was a huge shortcoming because we couldnt even import a WSDL let alone round-trip it while maintaining fidelity to the original. With the advent of v2006 R2 and the WCF adapters, to some extent things are better. At least we can now consume WSDL or MEX endpoints.

However, Contract First isnt just about importing WSDL. The round-trip experience and being able to maintain fidelity to the original is critical, especially in interop scenarios. While we cannot always expect service consumption and publishing to be single-click / push button, IMO, there’s currently far too many steps involved in building a provider or consumer that adheres to a supplied WSDL (and this is assuming you manage to coax it into rendering the WSDL exactly as you want).  Added to this, in the WCF world you also have to consider how you will handle strong typed SOAP Faults (when your client demands that you throw them). My esteemed colleague, Paolo Salvatori has a blog post describing how to add endpoint behaviors to a service to dynamically modify the WSDL exposed and to extend operations with fault messages. Ironically, I see this is part of the problem, namely, having to dive into so much custom code . Sure, its typical WCF, but hey, this is BizTalk, we are supposed to make the hard things easier.

The implementation of the tooling also leaves much to be desired. I don’t know of any people who still use Web Site projects as part of their automated build. Once the novelty wore off in the early days of VS2005, and once web apps came back in VS05 SP1, pretty much everyone went back to them. However, the Web Service and WCF Service publishing wizards still insist on generating website projects and there is no way to customize that to use your own template (has this changed in v2009 ?). While there is a command line tool to automate WCF service publishing, you cannot publish schemas as web services with that nor is there a command line interface (AFAIK) to automate consumption of WSDL/MEX endpoints.

Another problem I found is that Schema web services are great for one way messaging (especially when you can use direct binding so you dont have to tie an orchestration to the receive location) but if you want to expose a request/response operation, then you cant just use direct binding because the response doesnt make its way back to the required location. I read somewhere (could have been Yossi’s blog) that this is because the EPM demotes some properties. So you are forced back into an orchestration and static binding to the port. It’s not a big problem, after all the orch can be just a facade/shim, but it still feels a little dirty.

Ok, I hope that didnt come across as too much of a rant. I would like to hear your thoughts on the subject. Have I gone way off base anywhere ? Do you run up against the limitations of BTS in the Contract First (specifically WSDL First) world? What’s missing in the tooling? What should the product group (or a tool provider) be looking to supply to make things better. Do post your comments and let me know. Hopefully we can get enough consensus and ideas to provide the product group with valuable information. Let’s discuss.

I’m doing a little groundwork for the team that is now developing and maintaining the BizTalk LoadGen tool. The team is planning for vNext and we would like to know from BizTalk developers what your thoughts are on features/functionality that could be added on. This will be added to the planning list and depending on demand, priorities, budget etc (all the usual balancing factors) it may turn up in the next version.

I’ll get the ball rolling here. One of the things that people have asked for in the past is a UI  to simplify adoption. Once you get familiar with the tool , the command line is all you need, which is the reason why the very early UI which you can see on a post by Richard Seroter was dropped. However, it may be useful to have some sort of UI to get people over the initial learning curve. But what kind of a UI should it be? The early UI was pretty much a simple property grid and a window to view the execution. Given that the XSD is available, it should be a simple matter for anyone writing a UI to plug a property grid that serializes out the XML. So is it worth the product team investing time in re-releasing a bog standard UI? How about wizards? Let me know and i’ll pass the info on.

BizUnit has LoadGen steps and the Performance Optimization Guide goes into a lot of detail on how to use BizUnit with LoadGen to test one of the BizTalk SDK end to end scenarios.

What other features would you like to see ? Do let me know via the comments on this post or the contact form and i’ll pass the requests on and keep you all updated.

OrchProfiler has now been updated to support 64 bit systems. Actually this has been available for quite some time now in the Planned releases tab of the codeplex space but i’ve taken the opportunity to give it a quick test drive, updated the version numbers etc and made the new release available.

To use this, you need to have the HTML Help Compiler installed and edit the Profiler .exe.config to set the location of the help compiler.

Point releases will be made as frequently as possible to fix reported bugs but no big functionality changes can be expected. Instead we are working on a new tool that will combine this Profiler with the Documenter (as they share a number of common services including the Analysis OM). It is hard to work on two tools (actually 4 -if you take Profiler, Documenter and OM as separate projects) at the same time so please bear with us if we dont get fixes released frequently.

Check it out and let me know via the workspace if you run into any problems.

BizTalk Documenter has been updated to v3.3. This being a point release, there is still no links to other tools such as MapDocumenter, but thats on the list for the upcoming combined Documenter and Profiler.

The main changes are

• The UI now allows selecting “Word” as an output option. This was always available in the command line but never surfaced in the WinForms.
• Enhancements to the command line so along with specifying “/defaults” you can also specify “/apps: (comma separated list of target apps)” and “/provider:word” The default forced you into CHM earlier).
• Bug fixes to the Word publisher (reported in the forums).

In the case of the Word output, there are no images of the orchestrations since we are actually writing Word 2003 XML directly and launching Winword.exe so there is no control over the transformations. I’ll take a look at including images but I’m not promising anything since I need to use the available time to concentrate on the new version where I plan to use the Open XML SDK.

Also note that the MMC SnapIn wont compile in BizTalk 2009 environments because the MMC API has now changed. The SnapIn is deprecated and will not be available in the next version. If you absolutely must have it, then let me know and I will keep it on the task list for upgrading but again, time is limited so no promises.

Hope you find the small enhancements useful. Check it out and let me know if you run into any issues.

I’m really chuffed to have not one but 3 new team members on board the MockingBird project. Welcome to Shen Chauhan, my MCS colleague and WPF whizz-kid, Bram Veldhoen and Cormac O’Brien.

So, whats cooking for MockingBird in 2010 ? I have a veritable laundry list of features for the next release(s) but here’s the broad themes we are working towards.

(1) WCF : The first is the port to WCF which is long overdue and Bram has been hard at work in getting this off the ground so I expect to have something to announce soon. We will be implementing a message interceptor / router with a generic contract and from there leverage the simulation framework that is currently available with (hopefully) minimal changes. The challenge will be in the area of bindings since most teams customize bindings heavily so the service will need to support custom bindings.

(2) REST, XML/Http etc: Here we are looking at moving beyond just SOAP based services to plain XML/Http services and even REST based services. Cormac had come across some non SOAP services recently for which he had to manually code a mock, so we will be looking to incorporate such functionality here.  REST is an area that I haven’t paid much attention too so i see  a crash course in REST around the corner. If you have experience with REST and are keen to see support for this in MockingBird and can contribute in some way, do drop me a line.

(3) Generic ‘Action’ processing: For processing requests and building responses, there needs to be a more generic approach. Currently there is support for running an XPATH query on the request and returning a response based on the result of the XPath expression., But this is only one solution. What if we wanted to do a custom evaluation of the request where XPath is not enough? Further for the response, what if we wanted something more dynamic than just pointing to a specific response file? for example, Cormac suggested we dynamically execute an XSLT against the request. So, for this we need to look at the system executing a supplied “IAction” (IRequestAction, IResponseAction) and behaving accordingly. Unity and MEF should help here.

(4) Dynamic Mocking With BizUnit: This would be an API (+ a BizUnit step) which reduces the amount of upfront configuration needed. I envisage being able to say “For this endpoint, at the next request, return “X” response (and extend it to say, “do that for the next 10 calls or forever etc). We should then be able to “assert” that the system did indeed send the response. This would require surfacing the configuration file management code so that a config file could be written on the fly by the API/ Test step.

(5) .NET 4, AppFabric and Workflow Service: This is probably a longer term (MockingBird v3) where I am considering implementing the handler as a dynamic workflow service and using XAML. Now with this approach all the header parsing, IAction components etc would all  become custom workflow activities and it would be possible to dynamically compose specialized handlers on the fly. The message interceptor component would move to the official WCF Router.

So these are the big ticket items. For all of them I would appreciate your feedback as to what would give you the most value. We would also welcome more participation and contribution of ideas/code.  Looking forwad to your feedback.

Darren has made available a new release (v.3.2.1) of the BizTalk Documentor. It fixes some long standing issues and also some issues that came up when used with BizTalk 2009. Check it out and let us know if you run into any problems.

We are planning some re-work of this tool as well as the venerable Orchestration Profiler  with a view to combining these tools and introducing new output types. We are also looking at fleshing out an API so that they could be used with other tools or in a programmatic way as well. For instance, in an earlier post,  I had voiced a wish to be able to link OrchProf with BizUnit so we could verify step execution etc directly from a test and make the test a bit more “white box”  (ok, so it wont be as whitebox as BizMonade but it could add more reach for BizUnit)   but at present there isnt an API that is surfaced to allow such a link. But this will change soon. 

I have some ideas for other features as well which I will write about soon and there are a couple of requests on the forum to be able to link the documentor with BizTalkMapDoc which I will look into.

So if you have any feature requests, feedback and other ideas on how these tools could work together in your projects do send them along, preferably on the CodePlex workspace forums or feel free to contact me directly through the blog and let me know.