Put together a little snippet to remind myself of the some of the beautiful language extensions that shipped with the C# language.

namespace CSharpLanguageExperiment
{
    using System;
    using System.Collections.Generic;
    using System.Linq;

    class Program
    {
        static void Main(string[] args)
        {
            // Object Initialiser
            Person bill = new Person { FirstName = “Bill”, LastName = “Gates”, Age = 40 };

            // Type Inference
            var ben = new Person { FirstName = “Ben”, LastName = “Simmonds”, Age = 25 };

            // Anonymous Types
            var john = new { FirstName = “John”, LastName = “Smith”, Age = 18 };

            // Anonymous Delegate
            Func<string, bool> filter1 = delegate(string name)
            {
                return name.Length > 4;
            };
            filter1(“hel”);

            // Lambda Expression
            Func<string, bool> filter2 = x => x.Length > 4;
            filter2(“foobar”);

            // Extension Method
            ben.GetData();

            // Queries
            List<Person> people = new List<Person>();
            people.Add(bill);
            people.Add(ben);
            Func<Person, bool> filter = x => x.Age > 30;
            IEnumerable<Person> exp = people.Where(filter);

            foreach (Person person in exp)
            {
                Console.WriteLine(person.GetData());
            }
        }
    }

    public class Person
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int Age { get; set; }

        public override string ToString()
        {
            return String.Format(“{0} {1}”,
                FirstName,
                LastName);
        }
    }

    // Extension Method
    public static class PersonExtension
    {
        public static string GetData(this Person person)
        {
            return String.Format(“Name: {0} {1} Age: {2}”,
                person.FirstName,
                person.LastName,
                person.Age);
        }
    }
}

A few weeks ago I sat the 70-235 exam. Coming from a real-world perspective I wasnt overly impressed with the exam. To me it felt mind numbingly robotic and very 2006 R1 feature set focused (e.g. BAM and BRE). However the exam successfully probed some interesting areas within BizTalk, encouraging me to learn things about BizTalk that I would not otherwise get exposure to.

Patrick Wellink’s post “How to prepare for the BizTalk 2006 Exam” concisely summarised how to prepare for this exam. At first I sensed some sarcasm in Patrick’s post, but now having successfully passed the exam found his post to be scaringly accurate.

1. Create a nice BizTalk solution
2. Use party resolution
3. Use correlation
4. Send a message to a web-service that requires authentication
5. Use a business rule with a database fact
6. Use business rules that assert and retract
7. Make sure you deploy the solution
8. Run messaages through it
9. See what happens if the orchestrations are not started
10.   See what happens if the rules are not deployed
11.   Remeber the name of each tool you use (e.g. orchestration view in VS.NET)
12.   Know the stages of the pipelines
13.   Finally create a BAM View in excel
14.   Deploy the BAM View
15.   Deploy the tracking profile
16.   See if it works through the BAM Portal
17.   Now modify the BAM view
18.   Update the BAM view
19.   Do some BAM with continuations
20.   Know (memorise) your persistence points

BizTalk messages are very XML centric. A while ago there was a requirement to produce a neatly formatted XHTML report, which was destined to be emailed.

At the time I stumbled across a customised version of the XslTransform pipeline component which ships with the BizTalk SDK. It demonstrates how to apply an XSLT transformation in the pipeline. The customised version I was playing around with, pulled up XSLT from a SQL data store.

Regardless of where or how the transformation be done, we needed to produce an XHTML document as a result. The thing with XHTML is that is it just that. Its XML. A XSD schema can be produced from a well formed piece of XHTML. Therefore it is possible to create a strong message type (e.g. FooReport.xsd) which can then be pub/sub’ed with BizTalk.

High level steps:

1. Generate the document schema using xsd.exe.
2. Write the necessary transformation using BizTalk mapper, using the above as the destination schema.
3. Depending on the client which will be picking up and rendering the XHTML (e.g. outlook, firefox) it is usually necessary to set the MIME type, so it knows to treat the content as a piece of XHTML. To do this from BizTalk set the ContentType context property:
   errorReport(Microsoft.XLANGs.BaseTypes.ContentType) = “text/html”;

Today while doing some vanilla BizTalk 2006 R2 installs, discovered the installer was choking with:

Error 5003.Regsvcs failed for assembly C:\Program
Files\Microsoft BizTalk Server 2006\Microsoft.BizTalk.Deployment.dll.
Return code 1.

Awesome. Other cases of a malfunctioning regsvcs executable have been reported. For reasons that remain unknown to me regsvcs.exe stop functioning following the installation of SP1 for VS.NET 2005 and the .NET 2.0. regsvscs.exe appeared to be intact, but invoking any of it functionality (including listing its command line help) would return nothing—hence the return code 1 problem.

Solution: Repair the .NET Framework 2.0 binaries. I grabbed a fresh copy of the service pack. It is important that regsvcs.exe functions correctly—you can test it while reinstalling the service pack by running “regsvcs.exe /?“. If it lists out help your good to go.

Now my post-grad studies are finalised ive got some spare time to inject into technology. I plan to inject some solid hours into running through the .NET 3.0 certification stream.

Some areas that currently excite me, which I hope to spend more time with:

• ASP.NET MVC
• Advanced Windows Debugging
• Azure/Oslo/Dublin
• BizTalk Server 2009
• Claims Security and BizTalk
• JQuery
• JSON/POX WCF EndPoints
• MsBuild
• NServiceBus
• OpenId
• PKI and BizTalk
• PowerShell
• SharePoint Services
• UDP Multicast based Pub/Sub Engine
• Workflow Foundation

Microsoft has recently released a hotfix to enable font smoothing over remote desktop (RDP).

If your addicted to font smoothing (aka ClearType) you will love this hotfix.

At least service pack 1 is needed in order to install hotfix KB946633 on Windows Server 2003. On the client side you need at least RDC 6.0.

In order for ClearType font smoothing to work it needs to be enabled per computer, on the remote desktop client and the user profile on the terminal server.

• To provide a messaging infrastructure that will:

1. Break the communication complexity problems associated with distributed software – such as the ability to deal with ongoing change, providing management mechanisms for the complex sea of distributed service interactions that typically take place in today’s IT environment,
2. Provide reliable end-to-end messaging,
3. Apply distributed software security.

• To provide a configurable, reusable architecture.
• Deal with common messaging problems generically—i.e. routing, transformation, exception handling and unification.
• Enforce consistency and unification.
• Leverage modern standards.
• Support legacy standards and interaction.
• Promote agility, through increased abstraction and loose coupling.
• Speed implementation turn-around, through configuration versus coding

The goal of dynamic resolution is to avoid defining end-points anywhere statically. The responsibility of carrying and managing this knowledge, which is specific to the interaction, is frequently given to the consumer. That is, the consumer statically binds to the service endpoint/s that is consumes. If the responsibility be lifted from the consumer (or providers) itself, and given to an intermediate layer, such as the ESB, the byproduct are mechanisms for coping with change and dealing with infrastructural complexity. While the concept may appear to be trivial, its contribution toward providing a more managed distributed environment (many interacting end-points and data exchanges, etc) is significant.

The key challenge to a real world dynamic resolution implementation, is achieving the dynamic (i.e. must not static) characteristic. The ESB guidance provides this capability by providing an extensible resolver framework. The framework can be exposed or extended in anyway that is seen fit. The resolution functionality can easily be consumed in-band directly (i.e. without going out of process) or remotely through a WCF service. The point is, the framework is very extensible and flexible.

Out of the box, five resolver implementations are provided. An overview of these can be found by reviewing the ESBProcessor/Resolver section of the machine.config.

<ESBProcessor>
<Resolver>
  <add key=”UDDI”  value=”Microsoft.Practices.ESB.Resolver.UDDI” />
  <add key=”WSMEX” value=”Microsoft.Practices.ESB.Resolver.WSMEX” />
  <add key=”XPATH” value=”Microsoft.Practices.ESB.Resolver.XPATH” />
  <add key=”STATIC” value=”Microsoft.Practices.ESB.Resolver.STATIC” />
  <add key=”BRE”  value=”Microsoft.Practices.ESB.Resolver.BRE” />
</Resolver>
…

The bridging between the resolver framework and BizTalk Server is achieved through the ESBReceiveXML pipeline. The ESBReceiveXML pipeline is what makes doing transformation, endpoint resolution and validation truly dynamic. The pipeline offers a set of runtime configurable properties (see Figure 1: ESBReceiveXML Pipeline Properties).

• EndPoint – a directive for the resolution framework.
• MapName – the transform to be applied to the message.
• Validate

Note: The ESBReceiveXML functionality is also provided by the more powerful ItineraryReceiveXML pipeline. Further discussion of the ItineraryReceiveXML pipeline will be covered in a future post on Itinerary Processing.

The following snippet is a sample endpoint property configuration, for doing outbound file delivery using the STATIC resolver.

STATIC:\\TransportType=;
TransportLocation=FILE://C:\Projects\Microsoft.Practices.ESB\Source\Samples\DynamicResolution\Test\Filedrop\OUt\%MessageID%.xml;
Action=;
EndpointConfig=;
JaxRpcResponse=false;
MessageExchangePattern=;
TargetNamespace=;
TransformType=;

Note from the above EndPoint configuration, that the following context properties are resolved and associated with the message as a result.

<MessageInfo>
<ContextInfo PropertiesCount=”26″>
  <Property Name=”PortName” Value=”DynamicResolution” />
  <Property Name=”InboundTransportLocation” Value=”C:\Projects\Microsoft.Practices.ESB\Source\Samples\DynamicResolution\Test\Filedrop\in\*.xml” />
  <Property Name=”ReceiveInstanceID” Value=”{953F22D3-EE1A-4B67-ADC1-46FAB6F4562B}” />
  <Property Name=”ReceiveLocationName” Value=”DynamicResolution_FILE” />
  <Property Name=”ReceivePortID” Value=”{FA180F02-2C74-4CB5-AC62-D1DBF928288E}” />
  <Property Name=”ReceivePortName” Value=”DynamicResolution” />
  <Property Name=”InboundTransportType” Value=”FILE” />
  <Property Name=”MessageExchangePattern” Value=”1″ />
  <Property Name=”OutboundTransportLocation” Value=”FILE://C:\Projects\Microsoft.Practices.ESB\Source\Samples\DynamicResolution\Test\Filedrop\OUt\%MessageID%.xml” />
  <Property Name=”MessageType” Value=”http://globalbank.esb.dynamicresolution.com/northamericanservices/#OrderDoc” />
  <Property Name=”OutboundTransportType” Value=”FILE” />
</ContextInfo>
</MessageInfo>

As shown in the above snippet, the ESBReceiveXML pipeline promotes the necessary properties to facilitate a dynamic send port to pickup (subscribe) and deliver the message.

Now that the necessary resolution components have been summarised, the following steps trhough the sequence of activities involved in setting up.

1. Create and build off your assemblies with the necessary BizTalk artefacts—there will be message schemas and optionally maps.
2. Deploy assemblies to a (new or existing) BizTalk application.
3. Define a new receive port and receive location. Depending on the requirements of the consumer, this may be a one-way or solicit-response flavoured port.
4. Configure the receive location to use ESBReceiveXML pipeline. Define its EndPoint, MapName (optional) and Validate (optional) properties.
5. Ensure that the necessary configuration/resources have been deployed, based on the resolver configuration you have defined. For example if you have defined an EndPoint of “BRE:\\policy=GetCanadaEndPoint;version=;useMsg=;” a working version of the GetCanadaEndPoint rule policy must be deployed the Business Rules Engine.
6. Define a dynamic send port. The flavour of receive location defined in step 3 (above) will determine the type (i.e. one way or solicit response) of send port selected here. Based on the resolver you have selected, and end-point metadata that has been provided selected properties will be promoted into the messages context. Depending on the requirements of the consumer, this may be a one-way or solicit-response flavoured port.

Port Relationships

The interaction between receive and send ports here is important to the concepts’ implementation. The dynamic resolution setup walked through here, as the name implies, is very dynamic in nature. Key mechanisms that make this possible include:

• Statically defined receive location,
• The ESBReceiveXML receive pipeline,
• The underlying resolution framework and services,
• Runtime configurable metadata stores (e.g. UDDI, business rules engine, content based resolution, etc),
• Dynamic send ports.

End-point interaction can be performed using the request-and-forward (i.e. one way) or the request-response (i.e. bi-directional) models. The sequencing of the interaction between an inbound request-response receive location and an outbound solicit-response send port is important to the implementation, and for completeness is considered below:

1. Request-response receive adapter through some means (e.g. HTTP, SOAP, WCF) obtains a message,
2. Receive port runtime pushes the request payload through ESBReceiveXML pipeline,
3. ESBReceiveXML promotes the necessary routing properties into the messages context,
4. Dynamic send port subscription fires based on the promoted context properties, and the needed send adapter is resolved
5. Send port runtime pushes the request payload through the PassThruTransmit pipeline,
6. Send port adapter through some means invokes external resource,
7. Send port runtime receipts a response from external resource,
8. The send port solicit-response runtime pushes the response payload through XMLReceive pipeline,
9. The XMLReceive pipeline promotes the necessary routing properties into the response messages’ context,
10. The subscription for the response operation on the original request-response receive location fires,
11. . he request-response receive port runtime pushes the response payload through PassThruTransmit pipeline,
12. . Request-response receive adapter through some means (e.g. HTTP, SOAP, WCF) returns the response message back to the initiating consumer.

Today I came across an interesting compile time error, given a scenario I had never exercised before. I had a vanilla orchestration that was receiving the same message type (same schema different message instance) using two different receive ports. I wanted to correlate the orchestration, so the first receive shape was set to activate with an “Initialising Correlation Set” and the second receive shape was set with a “Following Correlation Set”. This setup produced the following compile time error:

C:\BizTalkApp\Flows\ProcessA.odx(221,13): error X2259: in a sequential convoy the ports must be identical
    C:\BizTalkApp\Flows\ProcessA.odx(215,22): could be ‘TestPortA’
    C:\BizTalkApp\Flows\ProcessA.odx(221,13): or ‘TestPortB’

Awesome. My convoy knowledge is not very deep, so I spent some time with a high quality MSDN article written by Stephen Thomas titled BizTalk Server 2004 Convoy Deep Dive. This helped fill some gaps on the subtle’s of doing sequential convoys.

There seem to be a couple of common options to this error:

1. Don’t define multiple receive ports. The one receive port can be connected to both correlating configured receive shapes. This wasn’t an option in my scenario, as I needed to bind the logical ports to two different physical ports (e.g. HTTP and MSMQ).
2. Don’t intialise the correlation set using a receive shape—use a send shape instead. Thanks to Bruno Spinelli for posting this option up on the wrox forums.

Lately I’ve been having heaps of fun playing with what’s known as the “ESB Guidance” (ESBG)—a community/open source driven initiative to fill the gap Microsoft current have in the SOA/ESB space. At a high level it augments its existing messaging/integration engine, BizTalk Server, by adding extended functionality. The ESB guidance aims to:

• Demonstrate how to implement an ESB pattern using BizTalk
• Outline best practices
• Reduce the amount of “plumbing” clients would have to implement themselves
• Reduce the total cost and effort of an ESB implementation

As of the November 2007 release it contains:

• Architectural Guidance
• Prebuilt Components
• Prebuilt Services
• Sample Applications
• Exception Management Framework and Administration Portal
• Available at http://www.codeplex.com/esb

In its current state it is not a formally supported “product” by Microsoft, and depending on your environment may not be appropriate for a production grade ESB implementation. It does however effectively demonstrate core ESB capabilities using the BizTalk Server product, facilitating exploratory/concept activities using the Microsoft platform.

Prerequisite Software

1. InfoPath and Excel 2003 (should be installed through BizTalk installation procedure) –InfoPath plays a role in the repair and resume portal.
2. A functional BizTalk Server 2006 R2 installation—including optional components BAM, BAM Alerts, and the Business Rule Engine.
3. BizTalk Server 2006 R2 Hotfix KB943871 – add support for new error reporting context properties.
4. Enterprise Library 3.1
5. DebugView – the ESBG is highly instrumented and this utility will render this information.
6. Certificate Services (Windows Server component)
7. UDDI Services (Windows Server component)
8. Dundas Chart for ASP.NET Enterprise

Gotchas

Release and Development Assemblies
If you’ve followed the installation guide and installed from source, your GAC assemblies will have a different public key from the release files, so you won’t be able to install the sample rules from GlobalBank.ESB.Policies.msi. This particular problem will also prevent you from deploying particular examples (e.g. ScatterGather) into BizTalk, which performs a complete dependency check. Types are incompatible between assemblies (to the CLR TypeA from assembly X is completely different from TypeA in assembly Y).
The source for the samples uses the correct key, so you can build and deploy from VS to create the sample app and populate the BRE components. A few of the samples have inter-dependencies. To avoid sample dependency issues, the sequence of sample installation has been outlined below.

UDDI Error 285014
The ESB Guidance uses the Microsoft.Practices.ESB.UDDIPublisher.exe executable to deploy sample endpoint definitions to the UDDI catalogue. With a default IIS 6.0 configuration this tool will fail with the following:
Error 285014: An unexpected error occurred retrieving the Category Key for the TModel name, ‘System.ServiceModel.Security.MessageSecurityException: The HTTP request is unauthorized with client authentication s
cheme ‘Negotiate’. The authentication header received from the server was ‘NTLM,Basic realm=”localhost”‘.
The IIS metabase needs to be tweaked for IIS to support both the Kerberos and NTLM authentication protocols.
http://support.microsoft.com/kb/215383
cd c:\inetpub\adminscripts
cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders “Negotiate,NTLM”
cscript adsutil.vbs get w3svc/WebSite/root/NTAuthenticationProviders

UDDI Error 285023
Depending on how UDDI Services has been configured, you may encounter the following response when running the Microsoft.Practices.ESB.UDDIPublisher.exe executable:
Creating entries…
– adding Default Category for ESB Runtime Resolution
Error creating UDDI entries… Error 285023: An unexpected error occurred creating the new Category, ‘System
.ServiceModel.FaultException`1[uddiorg.api_v2.dispositionReport]:  (Fault Detail is equal to uddiorg.api_v2.
dispositionReport).’, in Uddi.
Review your eventlog for UDDI diagnostics. If you have a UDDIRuntime error log of the UDDI_ERROR_FATALERROR_HTTPSREQUIREDFORPUBLISH category, this relates to an incorrect SSL configuration. A quick solution to this problem would be to disable UDDI’s use of SSL.

Sequential Installation Procedure

1. Install prerequisite software.
2. Install ESB Guidance November 2007.msi.
3. Extract ESBSource.zip to C:\Projects\Microsoft.Practices.ESB\ – some configuration files have dependencies on this absolute location.
4. Create the ESB exception management database.
Execute EsbExceptionDb_CREATE.sql from C:\Projects\Microsoft.Practices.ESB\Source\Exception Handling\SQL\ESB.ExceptionHandling.Database\Create Scripts.

Install ESB Core

5. Navigate to C:\Projects\Microsoft.Practices.ESB\Source\Core\Install\Scripts.
6. Update the “PreProcessingCORE.vbs” script with credentials that will work for your specific BizTalk installation.
7. Run all the scripts in this directory, in sequential order.
8. Update the “ALL.Exceptions” SQL send-port definition to point at the correct database server (i.e. the database created in step 4 above).
9. Make the following changes to the standard BTSNTSvc.exe.config file. Add the following snippet below the opening <configuration> element.

  <configSections>
    <section name=”xlangs” type=”Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess” />
  </configSections>

Add the following snippet above the closing </configuration> element.

  <xlangs>
    <Configuration>
      <AppDomains AssembliesPerDomain=”10″>
        <DefaultSpec SecondsIdleBeforeShutdown=”1200″ SecondsEmptyBeforeShutdown=”1800″/>
        <AppDomainSpecs>
          <AppDomainSpec Name=”Microsoft.Practices.ESB”>
            <BaseSetup>
              <ConfigurationFile>
                C:\Projects\Microsoft.Practices.ESB\Source\Core\Config\
Microsoft.Practices.ESB.PipelineComponents.config
              </ConfigurationFile>
            </BaseSetup>
          </AppDomainSpec>
        </AppDomainSpecs>
        <PatternAssignmentRules>
          <PatternAssignmentRule AssemblyNamePattern=”Microsoft.Practices.ESB.*” AppDomainName=”Microsoft.Practices.ESB” />
        </PatternAssignmentRules>
      </AppDomains>
    </Configuration>
  </xlangs>

12. Restart the BizTalk windows service.
13. Modify the machine.config for the 2.0 runtime, at %WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config, by adding the following snippet directly below the opening <configSections> element.

<sectionGroup name=”ESBProcessor”>
  <section name=”Resolver” type=”System.Configuration.DictionarySectionHandler, System,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  <section name=”AdapterProvider” type=”System.Configuration.DictionarySectionHandler, System,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  <section name=”ItineraryCache”  type=”System.Configuration.DictionarySectionHandler, System,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
  <section name=”Cache” type=”System.Configuration.DictionarySectionHandler, System,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b77a5c561934e089″/>
</sectionGroup>

Add the following snippet immediately above the closing </configuration> element. Be careful in regard to which version of the ESB assemblies you are using—the ESB guidance ships with both development and release versions which have been strong named with different public keys.
To summarise, any assemblies installed through ESB installers (MSI’s) downloaded from Microsoft will GAC release level versions. Release versions are incompatible with development versions due to the difference in strong naming. Development versions (recommended) are only available through the manual procedure of building assemblies from source—that is, pre-built development binaries cannot be downloaded.
If you intend to use the pre-packaged sample source code that demonstrates various ESBG functionality, go with the development version of the assemblies, as all sample source code is bound to the development ESB assemblies and you get debugging symbols (pdb) which can make troubleshooting much easier.

Warning: If you attempt to mix both flavours of assemblies together (e.g. only GAC release quality assemblies but install and run the samples against development versions) this will result in nasty typing (e.g. casting) incompatible problems at runtime.

You can distinguish the flavours of assembly by examining the public key token:
Release: 31bf3856ad364e35
Development (Recommended): c2c8b2b87f54180a

<ESBProcessor>
  <Resolver>
    <add key=”UDDI”  value=”Microsoft.Practices.ESB.Resolver.UDDI,  Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” />
    <add key=”WSMEX” value=”Microsoft.Practices.ESB.Resolver.WSMEX,  Version=1.0.0.0, Culture=neutral,  PublicKeyToken=31bf3856ad364e35” />
    <add key=”XPATH” value=”Microsoft.Practices.ESB.Resolver.XPATH, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” />
    <add key=”STATIC” value=”Microsoft.Practices.ESB.Resolver.STATIC, Version=1.0.0.0, Culture=neutral,  PublicKeyToken=31bf3856ad364e35” />
    <add key=”BRE”  value=”Microsoft.Practices.ESB.Resolver.BRE, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” />
  </Resolver>
  <AdapterProvider>
    <add key=”WCF-WSHttp” value=”Microsoft.Practices.ESB.Adapter.WcfWSHttp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” />
    <add key=”WCF-BasicHttp” value=”Microsoft.Practices.ESB.Adapter.WcfBasicHttp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” />
    <add key=”FTP”  value=”Microsoft.Practices.ESB.Adapter.FTP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” />
    <add key=”FILE”  value=”Microsoft.Practices.ESB.Adapter.FILE, ersion=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” />
    <add key=”MQSeries” value=”Microsoft.Practices.ESB.Adapter.MQSeries, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” />
  </AdapterProvider>
  <ItineraryCache>
    <add key=”timeout” value=”120″ />
  </ItineraryCache>
  <Cache>
    <add key=”UDDI” value=”600″ />
    <add key=”WSMEX” value=”600″ />
  </Cache>
</ESBProcessor>

Install ESB Exception Handling

1. Navigate to C:\Projects\Microsoft.Practices.ESB\Source\Exception Handling\Install\Scripts.
2. Update the “PreProcessingCORE.vbs” script with credentials that will work for your specific BizTalk installation.
3. Run all the scripts in this directory, in sequential order.
Install the ESB UDDI Publishing Windows Service
1. Open the solution C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.UDDI.PublisherService\ESB.UDDI.PublisherService.sln.
2. Edit the App.config, and verify connection strings are correct for the EsbExceptionDb and ESBAdmin databases.
3. Release mode build the solution—two projects, a windows service project and an installer project.
4. Run the MSI generated by the installer project.
5. Start the newly registered windows service (using services.msc).

If you have made it this far you should now have a healthy ESB Guidance rig up & running. I hope to follow up with a series of articles, decomposing how the ESBG can be used/augmented to provide common ESB capabilities.