March 2007 - Posts
Hey everyone, I've finally managed to upload the v2006_R2 release. Its actually a rather small release and i know i've got to sort out my version numbering really soon. I promise to do that in the next release. I've been struggling with a VPC from hell that just crawls all the time and doesnt let me write any code at all and combined with the general lumbering behemoth that is VSTS, i'm just about stuffed Since i dont have anything installed on my base laptop(and the workstation in the office wont allow me to connect to CodePlex) i'm forced to work with the VM and i've spent long nights just disabling services and trying to get it to perform, but it wont. Ok, thats enough of my rant for the day.
This
new release has the first cut of entlib logging added in and a new
"MapExecutingStep" to test maps. The AltovaXmlValidateStep has also been
enhanced and it now allows the user to specify whether the file is expected to
fail or pass the validation (to cater to scenarios where we need to test invalid
files). I've also added in some strongnamed EntLib2.0 dlls and a snk file into the References folder. You can of course choose to use your own entlib dlls. There is no separate test as such for entlib logging and the same test base is run and the system logs to a logfile specified in the config file for the tests.exe. I'm thinking of making the core libraries as exe's because we can add references to exe's now and this way i can supply a set of entlib config files with the library if people are interested.
Check it out and let me know if you encounter any problems. If you open
the solution and the system complains about not being able to locate TFS just
let it remove all the bindings. When you run the tests the perfmon test still fails but thats because there are some hardcoded paths in the tests that i inherited and i still havent had time to fix them. But the step works so ignore the failing test.
The next version will incorporate the latest from Kevin Smiths core code base and i will make all the modifications needed to the BizUnit() and Context() classes, or i may just add another BizUnitEx() class and a ContextEx() class so i can continue making my changes without breaking any of his code. I'll also try and make all the properties public. From reading the description on his releases page and blog, it appears that Kevin is planning to do more stuff with BizUnit and im still waiting to hear from him about the possibility of collaborating. If i dont hear soon, then i guess it will be time to make a hard decision about whether to continue with the "extensions" tag for this project or just move to a completely separate code-base. Do stop by on the forums and let me know what you think about this.
Anyway, i hope you find the latest code base useful.
I know its been rather quiet on the BizUnitExtensions front, but never fear, theres lots of stuff to come. But firstly, i do hope Kevin Smith responds to my comments on his workspace on joining forces. Im still waiting patiently. Although its good to see a new BizUnit core release with bug fixes and changes, its actually beginning to get problematic now because we have made changes to the core of the BizUnit class and other classes such as Context and now we have to port everything to the latest BizUnit codebase in order to keep things consistent and doing this to a code base which has now structurally changed is not easy. Added to that is the fact that we also wanted to change the structure of the code base (so we keep the standard test steps in one, biztalk specific things in another, msmq in yet another etc) so thats got to match up as well. I suppose these are the kind of scenarios where the C# 3.0 extension methods would come in really handy. Maybe its a good time now to break away from the BizUnit label and move to the more generic integration testing framework. What do BizUnit (and Extensions) users think about this?
Anyway, a good discussion has started on the forums at the extensions site (www.codeplex.com/bizunitextensions) with one of the new users querying BizUnits actual value (Why BizUnit) and finding some answers in the roadmap. I guess the reply to the question would be worth a blog post on its own!
So whats cooking with the Extensions project? Well, first of all I need to put down a release calendar showing whats coming up (based on the roadmap) in the next few releases, but right now the target is to get all the step properties, constructors etc public and to get entlib logging working. I have finished the entlib logging and will make it available as soon as possible. Its rather raw right now (ie) its a simple log format that more or less mirrors the console log but to a text log sink. i hope that this will stimulate some discussion in the community so we can improve the kind of logging (to event logs, perf counters etc).
Making the properties etc completely public is proving to be rather involved and raises lots of questions. For instance, if one could execute a step (for example, filecopy) independently (by just setting the properties and calling Execute) and could do the same for all steps in the test case, then the question arises as to what value does the BizUnit testRunner provide ? Some possible answers are that it provides
(A) Execution context (but this could also be set and passed in) and the ability to keep a constant thread of logging through all the steps and
(b) also provides parallel execution (but MbUnit could provide that). (Speaking of MbUnit, it definitely looks much better than NUnit and i should try running BizUnit inside MbUnit to see what extra stuff i can squeeze with MbUnit.)
I think it might be a better option to provide the ability to set step properties in code but once we create a collection of steps, we would pass the collection to BizUnit and say RunTest(TestStepCollection). This way BizUnit can manipulate context and keep full control. The Execute() methods would all then become "internal" and available to friend assemblies rather than public. If you are using the tool currently or planning to then head down to the codeplex site and post your thoughts on this or email me.
Well, what do you know, looks like Kevin Smith has turned up again after a long hiatus. The BizUnit project has now been moved to CodePlex and i just pinged him to check if he wants to collaborate with the Extensions project as well. Hope something good comes of this. The extensions project has had a huge number of hits since the content and structure got revised and i'm still trying to squeeze some time from my schedule to write up the tutorials and all that, so if you've been waiting, dont give up, or better still, email me and let me know you're waiting. The last time someone did that, i wrote up the Context tutorial immediately so let me know if you want some information to be put on the site.
I should have taken Jon Fanceys advice (on his blog) seriously and "sacrificed chickens to the demo gods". I had to give a brief workshop on Biztalk to some new clients a couple of days ago and took the classic messaging & CBR example of mapping an employee message to an executive message. As with most demos, this simplest of scenarios failed miserably. Why are demos always like this? Being still stuck in the 2004 world for my current project(s) and demo-ing 2006 for the new project might have contributed,but its really the same product with a rather more shiny interface on top so i guess i had to chalk it down as one of those unexplainable things.
The problem we had was a weird one. Initially when designing the schema, one of the fields (Salary) which i promoted, was a string and then as i refined the schema i changed it to a "long". Unfortunately the property schema had already been set by then and that took me into a rather long loop of re-deploying, changing the prop schema etc since i needed to check the value of that field and set another element in the target (using a scripting functoid). The messaging error that popped up continually was "cannot convert string to long". We just couldnt understand it because we literally wiped the schema and started again and the system seemed to have cached that message and kept throwing the same error. Even disabling the send port which did the mapping and retaining another port which forwarded the incoming message to another folder didnt work. Anyway, ultimately we just gave up in disgust cos we were running out of time and there were other things to work through.
Still, i wont take "no" for an answer from Biztalk and i gotta probe this and get to the bottom of it. Its kinda embarassing to see things like this happen after you have been working with the product for quite a while, but hey, i've seen it happen to well known gurus in the community so why should i be an exception!!
Next time you are planning a demo, dont forget the chickens!!