Here is the demo code, and presentation (in swedish) from the BAM talk I gave at the BizTalk User Group Sweden event on the 20th. Thank you all who attended, and to Precio for hosting it. Please contact me with any questions you might have about the samples, how to get them running and how best to go forward to utilize the benefits they demostrate. I’ll add an additional blogpost as soon as possible, describing the sample code. But until then I just wanted to put the code out there for you to look at if you would like to. This download does not include the Purchase Order demo that I used to demonstrate aggregations, that’s part of the Business Activity Monitoring Training kit, which I highly recommend, and that you can get here. It also does not include the WCF Calculator Interceptor sample, which is part of the BizTalk Server samples that Microsoft provides, get that one here. Also check out Mikaels post to get the BAM Session 1 slides and demo code, and read the explanation at the biztalkusergroup.se site (also in swedish).
Category: BizTalk
BizTalk and Big Design Up Front
Some companies seem to think that doing a Big Design Up Front (BDUF) before starting out implementing a BizTalk solution is the way to go. However it isn’t a BDUF from the aspect that they first would like to go through all their requirements and then through a waterfall style design phase for all of the requirements they have in mind. Had it been BDUF it would have been bad. now it’s worse. They want to install an all purpose integrations plattform with full support for BPM, Human Workflow and Governance from day one.
Although I’m not an agile fanatic of any sort, I just don’t believe that should or can be done. You can’t just decide on all the pieces you wish you had in your infrastructure and go out and buy them and think you will get the benefit of those pieces included with the purchase. For that matter it’s not even certain the pieces you think you want are the pieces your business really needs. And what’s worse, doing so is a fast way to waste a huge amount of money. Although they are all great products, you just can’t put what you needed for that – SQL Server, BizTalk Server, MOSS, K2, SOA Software and a couple of other products – together from day one when starting out establishing a new integration plattform. You are smart if you start small. Integration is about being agile, BizTalk is about being agile. Being able to exchange one product for another whilst not impacting the rest of the systems within the company. You can’t just install an enterprise architecture because you want to “start doing SOA”. Sorry to those of you missing out on all that juicy license money 😉
Now with that said, you can do a BDUF if you wan’t to. I believe there are sitiations where that method works, although I think a slightly more agile approach is more likely to succeed. But even if you do, don’t translate that design directly over to products and a Big Bang install and think you’re there. It’s just not that easy.
I was thinking about this while building lego with my son recently, and I took this picture. You can draw your own conclusions as to its meaning.
Q: Can I run BizTalk Server 2006 R2 on Windows Server 2008?
Q: Can I (should I) run BizTalk Server 2006 R2 on Windows Server 2008?
A: No. And these are the main resources I give customers who wants to see some kind of Microsoft reference to this:
BizTalk Server 2006 R2, System Requirements -> http://www.microsoft.com/biztalk/en/us/system-requirements.aspx
When BizTalk Server 2009 was announced there was a PressPass interview with Oliver Sharp, the GM of the BizTalk Server group. You can find that here -> http://www.microsoft.com/presspass/features/2008/sep08/09-05BizTalk.mspx.
Quote from above:
BizTalk Server 2009 will be a full release of the product. It delivers a full upgrade to enable customers to take advantage of the latest platform wave (delivered through Windows Server 2008, Visual Studio 2008, SQL Server 2008, .NET Framework 3.5). In particular the platform updates enable greater scalability and reliability, new Hyper-V virtualization support, and many advances in the latest developer tools.
There is also the BizTalk Server Roadmap page -> http://www.microsoft.com/biztalk/en/us/roadmap.aspx.
MS KB about what applications are supported on Windows Server 2008 -> http://support.microsoft.com/kb/948680/en-us
Q: Can I (is it technically possible to) run BizTalk Server 2006 R2 on Windows Server 2008?
A: As I mention (but perhaps do not emphasis) in the answer to the first question of this post “Can I (should I)” is an answer directed at customers. From an technical aspect it is possible to install and run at least the main parts of BizTalk Server 2006 R2 on Windows Server 2008 (see this post), however it is not supported. As such the answers to customers is (so far) still no. But then again up until quite recently it wasn’t really supported to run BizTalk Server virtualized on VMWare either (but now it is) and we still did that so maybe I’m being over-cautious? It’s not the same kind or level of support we are talking about though…
Q: Can I (should I) run Windows Server 2008 as the host OS on which I run virtualized guest OS with BizTalk Server 2006 R2 though Hyper-V?
A: Yes. As long as the guest OS is compatible with BizTalk Server 2006. Ie Windows Server 2003 (, XP or Vista). See the BizTalk Server 2006 R2 Hyper-V Guide.
UPDATE: I updated this post after comments. Thanks Jocke, it’s certainly more complete now.
Usergroup talk
PAL not working with restricted account
Just thought I’d post this since I couldn’t find a concise hit myself when searching for it. I’m using the PAL (Performance Analysis of Logs) tool in a restricted environment where my default user isn’t an administrator. In certain scenarios this will cause PAL to fail. The definition of certain in my case is when the LogParser CSVInMaxRowSize registry key is too low, causing PAL to want to write a new value, on line 173: WshShell.RegWrite “HKLMSOFTWAREMicrosoftLog ParserCSVInMaxRowSize”, iRowSize, “REG_DWORD”. The error message that PAL will display in its Command window is: C:Program FilesPALPAL v1.3.3PAL.vbs(173, 9) WshShell.RegWrite: Invalid root in registry key “HKLMSOFTWAREMicrosoftLog ParserCSVInMaxRowSize”.
I “solved” this by running PAL (the call to CScript that is) as an administrative user, since I had that option. I guess smaller (less counters collected) logfiles than mine would not get this error, as would situations where the LogParser maximum row size is already set to a large enough value.