For some time now I've had a side project brewing called MapCop. This program is a code-analysis tool for BizTalk Maps. It works against the uncompiled .BTM files and will ensure a variety of rules are being observed ... eventually. The project has been languishing, and tonight I forced myself to "just do it" and get MapCop to the point it would run at least 1 rule. I've done exactly that. This release, which is immensely alpha type release examines the structure of a map to ensure that every link between two functoids has its Label property set. Nothing superbly exciting yet, but the structure exists to do alot more. You can download the code and files here. The rules are written to follow a simple interface which passes in the Map object and allows you to examine it, like so: class LabelLinksMapRule : IMapRule{#region IMapRule Memberspublic List<MapError> AnalyzeMap(Map map){List<MapError> errList = new List<MapError>();foreach(MapPage loopPage in map.Pages){foreach(MapPageLink loopLink in loopPage.Links){if (loopLink.LinkFrom.DestinationType == LinkDestinationType.Functoid &&loopLink.LinkTo.DestinationType == LinkDestinationType.Functoid &&loopLink.Label.Trim().Length.Equals(0)){MapError newError = new MapError();newError.Page = loopPage;newError.Severity = ErrorSeverity.High;newError.Title = "Label all Links between functoids";newError.Description = "All links between functoids should have " + "their Label property set to ensure readability of functoid " + "parameter boxes.";errList.Add(newError);}}}return errList;}#endregion}
It's been a crazy weekend, worked a ton of hours already. That said, I thought I would archive here some information that can be found other places, but I wanted at hand when next I needed it.The following table contains the macro replacements that work within the File Adapter for BizTalk Server.Macro nameSubstitute value%datetime%Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).%datetime_bts2000%UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).%datetime.tz%Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).%DestinationParty%Name of the destination party. The value comes from message the context property BTS.DestinationParty.%DestinationPartyID%Identifier of the destination party (GUID). The value comes from the message context property BTS.DestinationPartyID.%DestinationPartyQualifier%Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier.%MessageID%Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.%SourceFileName%Name of the file from where the File adapter read the message. The file name includes extension and excludes the file path, for example, foo.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value, for example, if message was received on an adapter other than File adapter, then the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%).%SourceParty%Name of the source party from which the File adapter received the message.%SourcePartyID%Identifier of the source party (GUID). The value comes from the message context property BTS.SourcePartyID.%SourcePartyQualifier%Qualifier of the source party from which the File adapter received the message.%time%UTC time in the format hhmmss.%time.tz%Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).
Today I had the pleasure of finally integrating the BizTalk solution at my current client site into the Deployment Framework for BizTalk created by Scott Colestock. They are still using BizTalk Server 2004 so the process began with downloading the 2004 version of the Framework from Scott's site and getting the latest version of NAnt and NAntContrib. Overall I've always considered the Deployment Framework to be a joy to work with, but this is the first time I've had to retro-fit it into such an extensive existing solution. Some of the things which I encountered follow as reminders of gotchas in such an endeavor. It is not mentioned in the documentation, but Scott's framework has an "additionalComponents" property which deploys pre-compiled assemblys from the Deploy Tools directory. My client was already using log4net, but a newer version than what ships with the framework and I had to override this property so it didn't deploy two versions of log4net to the GAC. Remember that any Visual Basic .NET assemblies need to have their Build configurations changed to compile to bin\debug and bin\release. By default VB.NET has one location "bin" which holds whatever you compiled last. When retrofitting your existing bindings file to use XmlPreProcessor to swap out local environment settings, I found that CodeRush from DevExpress saved the day. It allowed me to create a simple expansion template which took whatever was on my clipboard and inserted it twice into the structure of the expension, once inside the PreProcessor directive, once outside. If you are working with alot of directly linked receive and send ports, then you'll want to modify the XPaths file in deploy tools to encode the Filter tag for ports as well as all the other tags it does already. I submitted this back to Scott who graciously thanked me for catching that and said he'd include it in the next 2006 release, and in 2004 if he ever did another release of that version. You'll definitely want to look at this article by Scott which discusses how to add additional HAT queries to the deploy framework as well.
