Mapping Fundamentals - Organization is the Key

Show of hands, who has opened up a map created by someone else and been filled with dread at the concept of modifying the map, even for something relatively simply.  I'm willing to bet the answer is nearly everyone who has ever done mapping.  It usually starts when you open a map and see something like this: [Yes, that is from a real client.  No, I won't say who.]   As if that alone wasn't enough to make one cry, layouts like that lead to property dialog boxes like this: So to help you avoid leaving wonderful presents like these for someone else who follows you onto your projects, I'd like to suggest the following guidelines to follow when you are working with the Mapper. Organize on Pages - The Mapper will allow you to create an infinite number of pages on which to organize your maps.  You should use this to great advantage.  Find a system of organization that works for you and stick with it.  The two most common systems are a "destination structure" approach where a page is used to organize the contents of a particular element on the destination schema and the "mapping concepts" approach pages tend to get names like "Direct Links" and "Looping" to indicate that type of mapping that is occuring on that page.  Personally I like to mix the two depending on the problem in front of me. Label your Links - If you select a link (a line) in the mapper and look at the Properties window you will see that it has a property named "Label".  This is the most under used property in all of BizTalk.  If you label a link (and a label can be any string value) then when you open the properties dialog box of your next functoid you will see the label next to the icon, rather than the above property box you'll end up with something like this:

How to put PDBs in the GAC

This TLA (Three Letter Acronym) littered post is about how to add PDB (Program DataBase) files to the GAC (Global Assembly Cache).  Today my current client had the need to get the true source of an exception.  They had a catch statement which logged the exception (via log4net) to a file, but the location in question was a poorly designed component with hundreds of lines of code all wrapped within a very large Try-Catch which logged errors.  The error was likewise unhelpful as to the source because it was an array out of bounds exception, and this code did alot of string array manipulation.  The solution was clear to me, we needed to load the PDB files onto the server so that when an exception was thrown there would be line number information to go with it.  The problem?  The assembly was being called by BizTalk Server and as such it was strongly named and in the GAC. The solution?  Add the PDB files to the GAC, of course.  The Global Assembly Cache which is located at %WINDIR%\assembly ("c:\windows\assembly" on most boxes) is in fact organized into many different directories all of which exist under %WINDIR%\assembly but which by default are hidden from view by Explorer.  Fortunately, the command prompt does not suffer the same problems.  If you open a command prompt and "cd %windir%\assembly" and do a "dir" you will see several directories as you can see in the first image. If you change directory to "GAC" you will see a directory for every single assembly in the GAC.  From here, cd to the directory for the assembly you want, in my example nunit.framework, and you will see another interesting set of directories.  Here you will see one directory for every combination of version number and public key in the GAC.  You need to know what version you are working with, and the public key for that.  cd into that directory and you will find a copy of your assembly.  Now all you have to do is copy your PDB file to this location and your next exception should contain line numbers for the offending code.  Since the work to generate line numbers is only done when an exception is being thrown there is little to no reason not to include the PDB files in all your production deployments to the GAC.  Yes, generating them takes time, but if you're throwing an exception this shouldn't be a problem.  After all, you are treating exceptions as exceptional, right?

Great BizTalk Resources

There are a slew of new resources that have become available in the last few days for BizTalk Server.  Here is the quick run down. Developer Troubleshooting Guide for BizTalk Server 2006 by Microsoft via TechSavyGal BizTalk Integration with SAP Labs via TechSavyGal BizTalk Custom Adapters Guidance from Microsoft via TechSavyGal New Book : BizTalk 2006 Recipes via Stephen W. Thomas Also, added another fabulous BizTalk blogger to my list, as you might guess, Lakshmi Murthy aka TechSavyGal.  Lakshmi is a BizTalk MVP from India and is always on top of her game.  Definitely check out her blog!