Thomas F. Abraham – On Technology

I neglected to post about this at the time, but back in June 2008 I had an article published in .NET Developer’s Journal titled “A Walk Through the Process: Creating Services with Contract-First Design Using BizTalk Server 2006 R2 and Windows Communication Foundation.”  The article is available on the .NET Developer’s Journal website and the sample code is attached to this post.

BizTalk makes a great platform for true contract-first service development because it is designed around messaging.  One of the first things one usually does on a BizTalk project is to load or create XML schemas.  With BizTalk Server 2006 R2’s support for Windows Communication Foundation, it’s a natural platform upon which to build services using contract-first design.

The article assumes that you have worked with BizTalk before, but otherwise it is a step-by-step walkthrough of the process to create schemas, create sample orchestrations to carry out the work behind the service interfaces and to publish the schemas as WCF services.

designserviceswithbts2006r2-wcfsample.zip

One of the things I’ve been doing over the last six months is enhancing two well-known BizTalk Server tools: the Deployment Framework for BizTalk and the GenerateTypedBAMAPI tool.  I also created a CodePlex project of my own, Environment Settings Manager, which was incorporated into the Deployment Framework and is very useful in its own right.

I never took the time to stop and mention all of the changes and new features, so here’s a summary:

Deployment Framework for BizTalk:

• Contributed the Environment Settings Manager project, which includes an environment settings spreadsheet that looks like the original one from Loren Halvorson, but does not use any macros and supports saving as either binary XLS or XML (SpreadsheetML).  The companion command-line utility can take in either type of file and export the environment-specific XML settings files that the Deployment Framework uses to create environment-specific configuration files on the fly.
• Added initial support for side-by-side deployment (multiple BizTalk app versions installed at once): added a “project” version property, added the version to the installer title and default install folder path, added version number to the BizTalk application name and SSO affiliate app name
• Added initial support for deployment of BAM activity definitions
• Updated WiX (for MSI generation) to 3.0.x, in the process drastically simplifying GenericBizTalkMSI.wxs and improving the MSI user interface
• Modified the installer to completely clean up on uninstall, removing all dynamically generated files
• Modified SetEnvUI.exe (the wizard) to open the file browse dialog in the current directory vs. C: and replaced a P/Invoke call with a Framework call
• Modified the installer to install “for all users” vs. only for the current user
• Simplified and improved the clarity of the checkbox captions in the server deploy/undeploy wizard
• Added an attribute to the UpdateSSOConfigItem Nant task for the BizTalk Application name
• Made minor documentation updates and replaced the HTML version of the help with a PDF version
• Updated to NAnt 0.85 release from RC1
• Included the Visual Studio Tools menu install scripts in the Sample ZIP file
• Cleaned up the project a bit, removing unused files, etc.

GenerateTypedBamAPI:

• Checked in the source code for the first time
• Added support for a relative path to the Excel workbook vs. explicit path only
• Added the partial keyword to the generated API class
• Added a method to the activity classes to enable continuation and return a continuation ID
• Added a command-line parameter to specify the .NET namespace of the generated code
• Changed “ESApi” to EsApi to conform to .NET capitalization conventions
• Added “Activity” to the end of the activity class names
• Explicitly passed “en-us” culture info to the Excel methods to avoid a globalization bug reported by users
• Made other minor code improvements, removed XSLT resource class in favor of Visual Studio’s built-in resource support

While I was at it, I added to the GenerateTypedBamApi project a completely new command-line utility program called ExportBamDefinitionXml that can extract the BAM definition XML from an XLS file and write it out to a file.  This utility can be used to automatically keep a BAM XML in sync with a BAM XLS file during local or automated builds.  The code reuses some of Darren’s code that was already present in GenerateTypedBamApi.

The majority of the changes listed above are not yet built into official “releases” on CodePlex, but hopefully that will happen soon — I just need to coordinate with the project owners.  In the meantime, hop over to the Source Code tabs and grab the latest from there.  Please feel free to enter new Issues and Discussions topics in the projects with your ideas and bug reports.

Enjoy!

BizTalk Server 2006 R2 makes it easy to expose WCF services from BizTalk’s messaging or orchestration engines via MSMQ, TCP or HTTP (or custom WCF bindings).  For SOAP web services, similar to the old Web Services Publishing Wizard, the WCF Service Publishing Wizard can be used to expose a schema or orchestration as a WCF Web service hosted in IIS.  The WCF service’s .svc file, written by the wizard and used by the WCF hosting support in IIS, always points to a common BizTalk WCF assembly (depending on choice of basic or WS-* binding) versus one specific to your BizTalk application.

Since the .svc file for the BizTalk WCF web service is “generic,” BizTalk needs a way to link the WCF Web service, hosted in IIS, to a port and receive location in the BizTalk messaging engine (in a different process).  This mapping is based on the service’s relative URL, the part after the domain name (like ‘/MyBTSWCFWebService/MyBTSWCFWebService.svc’).  If there is a mismatch in the virtual directory name or SVC file name in IIS vs. the relative URL string entered in the receive location in BizTalk, the two will not make the connection, and you will receive an error when you attempt to connect to the web service.  If you try to bring up the service in Internet Explorer, you’ll see an ASP.NET error similar to “Receive location for address “/MyBTSWCFWebService/MyBTSWCFWebService.svc” not found. (The BizTalk receive location may be disabled.)”.

The very important thing to note is that the URL matching is case-sensitive!

Not knowing this may lead to a scenario that can consume most of a day in frustration (trust me on this one).  Being unaware that the virtual directory and SVC filename are case-sensitive in BizTalk, let’s say that you create the virtual directory on a new BizTalk workstation with a different case than what is configured in your common port bindings XML file (assuming that you maintain one).  After deploying the BizTalk application and attempting to view the service description through Internet Explorer, you find that you receive an error stating that the receive location does not exist or is disabled.

Now, if you somehow realize that you need to correct the case, you go back and delete the virtual directory, recreate it with the correct case, and try to view the service again.  Unfortunately, you see the same error again!  Careful inspection will reveal that throughout the error page text, some occurrences of the virtual directory name are in the correct case, and others show up in the incorrect case of your original virtual directory name.

I can tell you that no amount of restarting IIS, redeploying the BizTalk application, re-creating the virtual directory, rebooting, or even un-configuring and re-configuring BizTalk will get you past this error!  It is really nasty.

As a last hope, we started a mass search of the registry and a complete text search of the entire hard disk — and that finally resulted in the answer: the ASP.NET Temporary Files cache (<windir>Microsoft.NETFrameworkv2.0.50727Temporary ASP.NET Files).  Through all of the re-creating, restarting and reinstalling, the same cached files were still being used every time!  Blowing away everything in the ASP.NET cache folder solved the problem.  My co-worker James ran the hard disk text search and discovered this when he came back the next morning and checked out the search results.

[In case you're curious, the specific location of the bad vdir name in the cache is Temporary ASP.NET Files<vdirname><random alphanum><random alphanum><svcfilename>.svc.<random alphanum>.compiled.]

Hopefully this will save some of you many, many hours of frustration!

I’ve recently been working with an existing WCF service that does not properly export its metadata.  [Note to WCF service developers: when testing your service, you need to explicitly test metadata export along with the actual service functionality.  There are many ways to break it.] The Service Model Metadata Tool (a.k.a svcutil.exe) can connect to the service for metadata download (svcutil.exe /t:metadata <url>), but the result is a brief WSDL that contains no type information (no messages, no bindings, no schema at all).

The company that built the service uses the Web Services Contract First (WSCF) tool from Thinktecture to generate serializable .NET proxy classes and WSDL files from XML schemas.  The service contract is defined by the XSD’s.  [Note: WSCF does not directly support WCF.]  Since we can’t download metadata from the service, the developers gave us a copy of their XSD’s and WSDL file (the latter generated by WSCF).  Should be no problem to consume them.

In my case the service client is BizTalk Server 2006 R2, using its built-in support for WCF.  BizTalk can generate a proxy (message and port types and schemas) for a service using the WCF Service Consuming Wizard.  In a great example of unfriendly UI design, to reach this tool you must first have a BizTalk project open.  Right-click the project and select “Add” then “Add Generated Items…”, then choose the “Consume WCF Service” option.  The wizard can import directly from a running service, or it can import directly from a WSDL and associated XSD’s.  The second option was perfect for our situation.  Almost.

When I ran through the wizard, the wizard ended with the error “Error consuming WCF service metadata.  Object reference not set to an instance of an object.”  Not so good.  One solution to this is quite simple, fortunately.  There may be other variations in the WSDL or XSD’s that can cause the same error, but check this out first.  In your WSDL file, make sure that the <xsd:schema> element has a targetNamespace attribute.  It doesn’t matter what attribute value you use, just make sure it looks like <xsd:schema targetNamespace=”anything”>.  The WSCF tool did not generate this attribute.  Once it was in place, the wizard quickly generated the proper items in the project.

Another note: the WSCF-generated WSDL was also missing a <service> element.  Without a service defined, BizTalk will generate empty binding files for the service.  Be sure to include something like this in your WSDL:

<service name=”service1″>
  <port name=”BasicHttpBinding_IService1″ binding=”tns:BindingName”>
    <soap:address location=”http://localhost:8080/service1″ />
  </port>
</service>

Make sure that the name in the binding attribute corresponds to the name attribute of your <binding> (or <wsdl:binding>) element, otherwise you’ll still end up with empty binding files.

When it’s working (most of the time), BizTalk 2006 R2 makes it really easy to both consume and publish WCF services.  I’m glad that we are finally starting to move beyond the WSE and ASMX days!

Digineer continues to be a leading Microsoft partner for BizTalk Server in the Twin Cities area.  As of this writing, we are proud to have six consultants who have passed exam 70-235, and several like myself who also completed the 2004 certification exam.  We are active in the Twin Cities BizTalk Server User Group and regularly provide content for the BizTalk Hotrod e-mag.

Since I have been so behind on my blog this year, I’m writing this in November but I passed the 70-235 exam in June (!).  Passing is 700 with 50 questions total.  I was pleased to walk away with an 842, despite the diabolical BAM questions they always throw in.

I think the exam was quite good as certification exams go.  It covered many aspects of the product and in order to pass you will have to spend hands-on time with the product.  There was quite a bit of BAM and BRE, some poorly written questions, but pretty much as expected overall.  There was a question on BRE FactRetrievers that I wasn’t expecting, but otherwise, no code-focused questions.

The question types are a lot of “choose X of Y”, some straight choose-one multiple choice and some “choose the necessary steps from a list and put them in the right order.”

If you’re a current or aspiring BizTalk developer and want to be part of a group who really knows and loves BizTalk, and you’re in the Twin Cities area, please contact me.  We are always looking for people who have a passion for BizTalk!

This has turned out to be a very busy year, thanks in part to Microsoft’s ever-accelerating stream of product releases.  Even five years ago I never thought that I’d hope Microsoft would slow down!

One of those exciting new products is Microsoft BizTalk Server 2006 R2, which features Microsoft’s new RFID platform, extensive support for EDI and all-new native WCF adapters (my favorite!).  I had the pleasure of presenting at the Minneapolis/St. Paul-area BizTalk Server 2006 R2 Launch event on October 9th.  My session was entitled “BizTalk Server 2006 R2: A Core Component of a Service-Oriented Architecture” and was very well-attended.  Thank you to everyone who listened in!  We even had Jon Flanders from Pluralsight and Michael Woods from the BizTalk product group on hand, and Michael introduced my sessions with an overview of Microsoft’s vision of SOA.

Tonight, November 15th, I’m presenting a session with my co-worker Randall entitled “Message Queuing with BizTalk 2006 R2: MSMQ, IBM WebSphere MQ and Ordered Delivery” for the Twin Cities BizTalk User Group.  I’m going to talk about queuing and the pros and cons, go through some MQ configuration issues and demo the MSMQ and WebSphere MQ adapters for BizTalk.  Randall is going to show some code as part of a solution for ordered delivery using MSMQ.  We hope to see you there!

You’re already familiar with the Microsoft Management Console (MMC) if you’ve ever opened Computer Management, IIS Administration or any of the other Windows management tools.  The most common version today is 2.0, found on Windows Server 2003 and Windows XP.  Back in March 2006, Microsoft released MMC 3.0 without much fanfare.  The big changes in 3.0 are a new programming model for .NET-based snap-ins and reliability improvements.  MMC 3.0 can isolate snap-ins from each other, at least if they are .NET-based, and do a bit better job of error handling and logging in general.

If you have not already installed MMC 3.0, you’ll need it before too long.  BizTalk Server 2006′s Enterprise Single Sign On Admin tool requires MMC 3.0, and there will be many more in the future.

There are freely available versions of MMC 3.0 for the various editions of Windows, but you need to get the right one for your OS.  Search Microsoft Downloads for ‘MMC 3.0′ to find the one you need.  You’ll need Windows XP SP2 or later, or Windows Server 2003 SP1 or later.  If you’re running Vista, you can stop reading now, because you already have MMC 3.0 and it is pre-optimized!

Once you have MMC 3.0 installed, you may find that snap-ins that rely on it (and you generally won’t know which ones do) start up slowly.  You may find yourself staring at the screen for a long time each and every time you start up one of those snap-ins.  The reason is that a bunch of code in MMC 3.0 is written in .NET.  No, that in itself does not make it slow!  For some unknown reason, Microsoft does not optimize the MMC 3.0 .NET code upon installation as it does with the .NET Framework itself.  (For you developers, the DLLs aren’t automatically GAC’d, nor are native images generated.)

There’s a very easy fix for this.  Speed up your MMC 3.0 snap-in startup times by opening a Command Prompt and running ‘mmcperf.exe’.  It’s in your Windows\System32 directory.  This will create ready-to-run versions of the MMC .NET code (native images).  You’ll notice a big difference in startup time — and we may never know why Microsoft didn’t just do this out of the box!  Note that this does not speed up the snap-ins once they are actually running.  This is related only to the startup time when you run MMC and load a .NET-based snap-in.

BizTalk Server has long been one of the most powerful — and unwieldy — tools in Microsoft’s server arsenal. Sadly, BizTalk 2006 is what BizTalk 2004 should have been, and one wonders why it took so long to arrive. Frankly, I’m not sure that Microsoft really knows what to do with BizTalk. I believe that the product is misunderstood even within Microsoft itself, and I do not think the marketing and sales teams really know how to market and sell it. When you consider the number of years that BizTalk has existed (six), it has a very small number of customers.

Developers naturally want to write custom code, so it’s not easy to convince them of BizTalk’s benefits. It certainly doesn’t help when Windows Workflow (WF) comes along with a big marketing bang and further distracts the developer community. Now you’ve got developers looking at the WF design surface and thinking that it looks just like BizTalk’s, so it must be the same, and it must be better because it’s newer. True or not, this is the kind of problem that Microsoft has created for itself.

I believe that Microsoft needs a different approach to selling BizTalk. First of all, the product group needs to get a grip on the product’s future direction, and then educate — repeatedly! — Microsoft’s sales teams until they finally understand the product and how to sell it. Second, pushing feature lists is a lost cause. Your average CIO/CTO doesn’t care. Microsoft should be selling BizTalk with specific business scenarios. They could build example solutions that are written in both C# and in BizTalk, and show explicitly how BizTalk reduces code, brings in management and monitoring features, etc. Reducing the barrier to entry is critical. Providing extensive samples and prescriptive guidance for developers would help adoption from the technical side.

Here’s my list of the top three issues in BizTalk 2006 that the product group should address in v.Next:

Inadequate support for medium to large sized messages. In an ideal world all messages would be 0-150KB, but realistically people need to send around metadata plus documents like PDFs, etc. The larger the message size the quicker problems are encountered, from hosts running out of memory and crashing to high CPU utilization to extreme SQL Server stress.
BAM is extremely valuable but still too hard to configure, so it is not used as often as it should be, and that is really a shame. The tools need to be brought together into the Visual Studio IDE or into the Admin Console.
Debugging tools are not even CLOSE to Microsoft standards. Visual Studio is known for an outstanding debugging experience, and BizTalk has a horrible debugging experience. We should be able to open a BizTalk project and directly debug pipelines and orchestrations in the IDE.
What else should the product team improve upon? How could Microsoft better position BizTalk in the market? I’d love to hear your opinions.

Thanks again to everyone who attended my session entitled “Effective Techniques for Handling Large Messages in Service Oriented Solutions” at the Microsoft SOA & BP Conference.  The session covered the difficulties of working with large messages in service-oriented environments, then provided general strategies and specific guidance for both BizTalk Server 2006 and ASP.NET Web services.

Here’s the PowerPoint presentation from the session.  I’m still debating how to release the Slice/Splice BizTalk pipeline component code.  One option is to create a new community project at either CodePlex or GotDotNet.  Another option is to use a GPL or similar open-source license.  Any ideas?  Please let me know what you think.

soa04_abraham.zip

It’s the last day of the Microsoft SOA & Business Process Conference and just about time to head for home.  I’ve had a great week in Redmond and have had a chance to talk with many other members of the BizTalk community.  The conference has more than 700 attendees, and I was surprised to discover that 40% or more were international.  QuickLearn has been running some great training classes on BizTalk, WCF, WF and Atlas both before and after the conference.

Thanks to everyone who attended my session on working with large messages in BizTalk and ASP.NET Web services!  The session was well attended and, not surprisingly, a lot of people are having these issues.  As soon as I get approval from Microsoft, I’ll get a post together with the PowerPoint slides and the pipeline component code.

Overall, the conference was worthwhile, but I would have preferred much more detail in the sessions and greater presence from the MS product developers.  Hopefully that will be improved for next year.  No real news from the conference other than the limited availability to partners of an ESB guidance package for BizTalk.

Thanks for reading and please stay tuned for the session materials.