I can only follow Mikaels post and thank everyone who attended the BizTalk User Group Sweden event last thursday about REST with Jon Flanders. It was a great turnout weighing in at about 80 people. According to Jon we were one of the largest usergroups he had ever visited. Also, as posted on the usergroup site (in swedish) Jon now has the slides and samples available for download.
Blog
Interviewing for BizTalk employment
More then a few times I have seen interview questions that people post on their blogs for use when interviewing people for a BizTalk Server job opportunity. I never use interview questions. I’m not sure if the market and access to BizTalk developers is so good in these places where they use the questions that you can pick and choose to get the “best” one. Here, the demand is far greater then the supply it seems. Especially for companies that might not have an outright image as an attractive IT employer. I try instead to form the questions so that they fit into a natural conversation. I suggest that an experienced BizTalk developer and/or architect can derive how knowledge-able the interviewed individual is from how he (or she, but to be fair they are mostly he) talks about his experience with BizTalk Server, which parts he has been responsible or involved with and things like that, without turning it into an interogation. Most of the time (given the lack of supply) the BizTalk Server experience is only part of the picture anyway. I’m not claiming to be a person termometer in any way, but just listening to someone and what and how they offer information about their previous engagements can tell you alot, often enough. Now on the other hand, if you do find the person to appear knowledge-able, and would really like to make sure before deciding to pay that person that far higher the average salary, by all means, do a deeper knowledge based interview. But to pull that of you really need to already have someone that knows his stuff to evaluate the answers.
Welcome autumn
Now that autumn is upon us there is no better start to the fall then BizTalk User Group Sweden and the upcomming event with Jon Flanders. It feels good to start the fall after a prolonged summer vacation with a fun event and meeting up with friends, people of similar interest and other likeminded. See you there!
I would also like to use this post to mention two other events that I find noteworthy.
Alan Smith launches bloggersguides.net, original post here. I’m looking forward to the Guide to Oslo.
Fellow Logica employee Jan Eliasen re-claims his BizTalk MVP title, congratulations, original post here.
Myself I have been on parental leave/vacation. Everyone that has or has had small children know that being on vacation with children doesn’t really mean sleeping in or sitting in the sun sipping some favorite drink or having a cold beer reading your favorite computer book and/or novel or writing blogpost. Still, really fun times – I wouldn’t have traded it for any number of posts. Speaking of which – I have several in mind, I just have to find time to get them down, stay tuned 😉
PDC08 – Meet me there
BAM Tracking and Failed Messages, and a new issue of BizTalk HotRod
Mikael HÃ¥kansson has a post called How to Replace Tracking with BAM in BizTalk that features a performance comparison he made for disabling global tracking in BizTalk Server 2006 and how that would look if you replaced that with BAM – in hard figures. He also posts a sample solution and talks about concepts such as activities and tracking profiles. The post mentions that the approach is meant for tracking successful messages and he suggests (as an example) the use of a WMI service to catch suspended messages. A concept that he leaves out is the tracking of failed messages using BAM and failed message routing. As a fluke, at roughly the same time his post was published there was a white paper released at MSDN that describes the process of creating an activity, tying that to a tracking profile by connecting it to relevant context properties and deploying it for a failed message routing scenario, see How to Track Failed Messages in BAM. It’s a very basic step-by-step article. Now…I am not taking a stance to say that failed message routing is the way to go. There are many considerations to take into account before determining to opt for that or for allowing messages to get suspended. I just wanted to post this to tie these two articles together since I think they are both good reads and gives you a view of what is required to replace tracking in BizTalk with BAM, for both successful and failed messages. And what the performance benefits might be for your solution.
Also check out the new issue of BizTalk HotRod that (among other things) also discusses Failed Message Routing and how to log these message, but does so in the context of the ESB Guidance.
