[BAM] PivotTable names must be unique

More a note to self than a serious blog post (haven’t got the time to do screen shots and stuff).

When creating BAM views in Excel, you can copy the initial PivotTable that is generated to create multiple predefined ‘views’. To copy the PivotTable select it (go to the edge until you get a solid arrow cursor) then Copy it (Ctrl+C), select a free cell well below the existing PivotTable and Paste (Ctrl+V). Right-click in the Pivot Table and select Table Options… to give it a name. This Name must be unique across the workbook. Otherwise the PivotTable will not be linked to a cube when exported (although it all seems to work in excel) and your view will be missing from the Aggregations node in the BAM Portal navigation pane.

Using an Interop layer with BizTalk

This is my second project in which I used an Interop layer for calling custom code in BizTalk and it still feels (and smells) good.


The Interop layer is an assembly that isolates the BizTalk specifics from the rest of your code base (I’ve not needed more than a single assembly but I can imagine you might want to split things up in multiple assemblies with bigger and more diverse projects). The BizTalk specific types are only used in this assembly and requirements like [Serializable] are also implemented here (if not supported by underlying code base). Note that I do not use the Interop layer for Pipeline Components: each pipeline component is an ‘interop layer’ on its own – so I do take care not to leak any BizTalk specifics into the general code base.


Some examples of the types of classes I found myself writing in the Interop assembly are:




  • Message Factory classes
    Easily construct new message instances using BizTalk (XLANG) specific types.


  • Content Enrichment classes
    Classes that fetch additional information and return it as Xml (string) for use in maps. See also my post on How to Enrich a Message.


  • Configuration classes
    A serializable class that contains configuration settings in an orchestration; when you want to keep the settings an orchestration works with during its lifetime constant.


  • Collection / Iterator classes
    Classes that represent a collection of (domain) information and can be used inside a Loop shape (MoveNext/Current).


  • Xml Aggregator class
    A serializable class that knows how to generically aggregate multiple Xml documents into a single Xml document (of the same schema).

The fact that the Interop layer shields the rest of you custom code base from BizTalk specifics makes your (non interop/other) code Unit Testable without having to resort to ‘creatative’ injection techniques ;-).


I hope it works just as well for you as it has for me.

Building Reusable Pipeline Components Part 4: Build SourceFileName Component

The Build SourceFileName component builds a value for the %SourceFileName% macro that can be used as part of a Send Port Url thus allowing customization of the file names.


The following class diagram shows the classes for the BuildSourceFileName component:


BuildSourceFileName classes


The BuildSourceFileName class derives from the PipelineComponentWithResourceBase base class and passes a name prefix and an instance to a ResourceManager to its constructor. The override of the ExecuteInternal method concatenates all the literal or context property values into one string and uses the FileAdapterMessageContext class to set the FILE.ReceivedFileName context property of the message. This context property is used as a value for the %SourceFileName% macro.


Both the Load and Save methods are overridden to manage persistence of the configured properties. Three values are maintained for each configured property (Key, Namespace and IsLiteral) and an extra count value to indicate the number of configured properties.


The BuildSourceFileNameBagNames utility class manages the names for each configured property in the persistence bag.


 Download the source code here.

Building Reusable Pipeline Components Part 3: Outbound File Location Component

The Outbound File Location component allows messages to be placed in a sub folder hierarchy based on Context Properties of the Message.


The following class diagram shows the classes for the OutboundFileLocation component:


Outbound File Location classes


The OutboundFileLocation class derives from the PipelineComponentWithResourceBase base class and passes a name prefix and an instance to a ResourceManager to its constructor. The override of the ExecuteInternal method uses the SystemMessageContext class to check the OutboundTransportType. If the FILE adapter is not used, the component does not perform any operation and simply returns the incoming message.


Otherwise the Outbound Transport Location is parsed for a macro (e.g. %SourceFileName%) and the sub path is build retrieving the configured properties values from the current message’s context. Then the base path (configured in the Send Port), the sub path and the macro are combined and assigned to the Outbound Transport Location context property of the message.


Both the Load and Save methods are overridden to manage persistence of the configured properties. Three values are maintained for each configured property (Key, Namespace and IsLiteral) and an extra count value to indicate the number of configured properties.


The OutboundFileLocationBagNames utility class manages the names for each configured property in the persistence bag.


Download the source code here.

Building Reusable Pipeline Components Part 2: Static Message Context Component

A Static Message Context is a Pipeline Component that has one or more Context Properties configured and applies them to each message that travels through the Pipeline.


The following class diagram shows the classes of the Static Message Context component:


Static Message Context classes


The StaticMessageContext class derives from PipelineComponentWithResourceBase base class and passes a name prefix and an instance to a ResourceManager in its constructor. The class also overrides the ExecuteInternal method to apply the configured Context Properties to the message being processed. Applying the configured properties is simply a matter of iterating over the configured properties and writing or promoting them to the message context of the current message being processed.


Both the Load and the Save methods are overridden to manage the configured properties persistence. Four values per configured property are maintained (Key, Namespace, Value and Promote) and an extra count value to indicate the number of configured properties. The StaticMessageContextBagNames utility class manages the names for each configured property in the persistence bag.


Download the source code here.

Building Reusable Pipeline Components Part 1: The base classes

This is a four part series on building reusable Pipeline Components for BizTalk (2004/2006). The four part series starts of with laying a foundation with a couple of base classes and the other three installments will cover one component each. The following components will be discussed.



  • Static Message Context Component
    A Pipeline Component that can add statically configured properties to a message (context).

  • Outbound File Location Component
    A Pipeline Component that can create sub folders in an Outbound Transport Location based on message (context) properties or literal expressions.

  • Build SourceFileName Component
    A Pipeline Component that can set the value for the %SourceFileName% macro used in Send Ports. This is a convenient way to custom-name the output files.

The Pipeline Components use a collection of configured properties that are configured during design-time in the (BizTalk) Pipeline Designer. Once the Pipeline is deployed no configured properties can be added or removed but the values of the existing properties can be changed.


A quick analysis of the three components shows us that we see 2 common needs here: (1) we can probably make a base class for each Pipeline Component to derive from and (2) all components use (some sort of) configurable Context Properties to build some internal state.


The following class diagram shows the base classes:


base classes


The PipelineComponentBase class provides the initial layer of Pipeline Component functionality. It (partially) implements the IBaseComponent, IComponent and IPersistPropertyBag interfaces most commonly found in Pipeline Components. Note that the base class does not declare any (class) attributes for registering Pipeline Components. These class attributes should be added on the implementation class that (indirectly) derives from the PipelineComponentBase class.


Both the Name and Description properties of the Pipeline Component are abstract: the derived class has to implement them. The class also introduces an abstract ExecuteInternal (template) method that is call from the IComponent.Execute method implementation. This method has the exact same signature as the IComponent.Execute method but is only called if the Enabled property is set to true (default). When Enabled is set to false the incoming message is returned and no operations are performed. This allows you to switch Pipeline Components on and off through configuration – even in production.


The PipelineComponentWithResourceBase class derives from the PipelineComponentBase class and takes an instance of a ResourceManager in its constructor (with an optional name prefix). The ResourceManager instance passed to the constructor can be taken from the Visual Studio generated Settings class. Through a naming convention it looks for resources in the assembly for the Name and Description properties. The class also implements the IComponentUI interface and its Icon property. The implementation of the Icon property fall back to a generic Icon if there is no Component specific Icon resource found.


The naming convention used for the implementation of the Name, Description and Icon properties is: [prefix] + “Component” + PropertyName. For instance a Pipeline Component class that specifies “MyComponent” as prefix would provide the resource key “MyComponentComponentName” with a string value “My Component” to implement the Name property. Note that you must supply the Name and Description property resources. The Icon property resource is optional and defaults to “ComponentIcon”. Use the prefix if you have more than one Pipeline Component in a single assembly.


The ContextPropertyDef class provides a base class for component specific configurable Context Property instances.


I’ve also included the MessageContextBase class in the class diagram. This class provides a basis for implementing Typed Message Context classes like the SystemMessageContext implemented by BizTalk. The Build SourceFileName Component uses the FileAdapterMessageContext (which derives from MessageContextBase) to access the FILE.ReceivedFileName context property.


Download the source code here


 

[BizTalk] How to enrich a message

While working on my first BizTalk 2006 project I came across the need to enrich messages as they were routed through BizTalk. I knew that a Map would be the logical approach because most fields could be copied through directly. Based on some other properties a database lookup should be performed and the resulting data structure is to be added to the destination message. The structure of this data is complex; an hierarchy with multiple, repeating  elements.

After trying all sorts of things covering Database Lookup, and all sorts of Scripting functoids configurations and searching the net, I finally came across this post. http://www.infusionblogs.com/blogs/syd/archive/2006/05/17/480.aspx. It nearly describes the problem I tried to solve and sure enough, within 5 minutes I had a working solution.

I made a custom .NET assembly with a class that has a public method to lookup the extra information based on the source message properties. This method takes several (in my case) string parameters and returns a string that contains the Xml sub structure thats to be included in the destination message. Note that the string returned is the OuterXml of the DocumentElement of the XmlDocument. If you return the OuterXml of the XmlDocument you’ll include a <?xml?> PI and the map doesn’t like that (with good reason).

public class DataLookup
{
public string Lookup(string param1, string param2)
{
XmlDocument xmlDoc = new XmlDocument();

// load xml document…

return xmlDoc.DocumentElement.OuterXml;
}
}

Then I created a map in VS.NET, selected the source and destination schemas and placed two Scripting Functoids on the map-surface. The first scripting functoid has its inputs connected to the required input properties from the source schema and the output is connected to the second scripting functoid and is configured to call out to my .NET assembly. The second scripting functoid is configured as an Xslt call template (code is shown below) and its output connects to the root element in the destination schema where the additional information has to go.

<xsl:template name=”enrich”>
<xsl:param name=”data” />
<xsl:value-of disable-output-escaping=”yes”  select=”$data” />
</xsl:template>

So, during a transformation, the source properties are fed into my custom class’ method, a database lookup is performed and an xml document is created which is returned as a string. This Xml as string is then passed into the xslt named template and injected into the destination message at the specified root element.

Source Properties => (picture of two script functoids)  => Destination Xml

It seems a bit strange that you have to convert Xml into a string (to be converted into Xml again by the Xslt template) in an xml technology-based BizTalk map. But hey, it works…