My eyes – they bleed!

Came across this “little” map today

I can’t help wondering on the temperament of the developer who patiently connected every single one of those elements to a functoid. The mind boggles!

Unexpected use of keyword: ‘task’

I am currently using BizTalk 2010 as the integration hub between a number of systems, including Microsoft Dynamics CRM Online. The XLANG/s Orchestration compiler will complain with the following:

Unexpected use of keyword: ‘task’

One of the core entities in CRM is the ‘Task’, a sub-type of an Activity in the Sales process. However, we run into a problem in BizTalk when working with the schemas generated out of CRM, as ‘Task’ is also a reserved word in XLANG/s.

My solution was to create a ‘taskInternal’ schema alongside the generated ‘task’ schema. I set the Data Structure Type of taskInternal to the complex type ‘task’, to avoid redundant data types. Now we can build and compile our Orchestration just fine, as ‘taskInternal’ is not a reserved word.

Finally, we need a pair of very simple maps, from taskInternal->task and from task->taskInternal. These are applied on our physical Send Port, in the Outbound Maps and Inbound Maps sections respectively. Without this Inbound/Outbound mapping, we are not sending the correct Xml message types to/from CRM.

Note, there are another couple of reserved words that you might want to take a similar approach with, for example, ‘operator’ and ‘request’ are both reserved in XLANG/s.

CRM Online web services – (407) Proxy Authentication Required

I am currently in the process of integrating several back-end systems with Microsoft Dynamics CRM Online, utilising BizTalk as the integration hub platform.

WCF, and specifically the “Consume Adapter Service” within Visual Studio, abstracts the creation of CRM Schemas to the point that the process is just like any other WCF service.

However, I came to a screeching halt when trying to test the creation of any Entity within CRM Online. The ISA Server was complaining, resulting in the following exception being thrown:

System.Net.WebException: The remote server returned an error: (407) Proxy Authentication Required.

None of the inbuilt authentication settings within the WCF-Custom Transport Properties window were any help (trust me, I tried ‘em all), the Adapter appears to ignore any Proxy Authentication settings.

The solution is to instruct WCF, at the Windows Process level, to use the default Windows proxy settings. This is done by adding the following section into your BTSNTSvc.exe.config file:

  <system.net>
    <defaultProxy useDefaultCredentials="true">
      <proxy usesystemdefault="True" />
    </defaultProxy>
  </system.net>

This is, however, a less-than-ideal solution, as it applies a blanket setting to all BizTalk Host Instances on the server.
Note: If you are in a 64-bit environment, and using a 64-bit Host Instance, you need to make the change in the BTNTSvc64.exe.config file instead.

Post build task to add .Net component to GAC

Occasionally I’ll need to write a helper .Net function to fill the gap where standard BizTalk functionality is not flexible enough.  This is usually often enough that I follow a pattern of having a “.Helpers” assembly associated with every BizTalk application I develop.

These Helper assemblies compile and can be referenced by other projects in the solution just fine, but when the application is later deployed, or exported as an MSI package, we usually find one of the following occurs:

• A referenced DLL is missing from the GAC (easily fixed),
• An older, stale, version of the Helper dll is exported in the packaged MSI, due to subsequent versions of the Helper not having been updated in the BizTalk metabase

The following Post-build Event Command Line will ensure the Helper DLL is successfully added to the GAC on the local machine, then update the BizTalk application to include the latest binary copy of the DLL in its resource manifest:

"%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.0A\Bin\gacutil.exe" /i $(TargetPath)
btstask.exe AddResource -Application:{BizTalk Application Name} -Type:System.BizTalk:Assembly -Overwrite -Source:$(TargetPath)

Be sure to remember to replace the {BizTalk Application Name} token with the relevant Application Name, and change the “Run the post-build event” drop-down option to “When the build updates the project output”

Edit: For 32-bit BizTalk environments, replace %ProgramFiles(x86)% with %ProgramFiles%

Edit 2: When working with BizTalk 2010 (and later), the gacutil executable will be found in a different location.  This is due to the Framework 4.0 GAC being both structured and located differently to earlier versions.  The compatible version of gacutil.exe can now be found at:

"%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\gacutil.exe"

Calling helper methods from the Business Rules Engine

Here’s a trick that usually gets people new to BizTalk.

The Business Rule Engine has the ability to call (public) static methods on any .Net class, without needing to assert an instance of the class first. However, when you execute your policy, nothing is returned into the policy, and your rules will not work as expected.

The problem is that, by default, the BRE will not execute the static method, unless a specific registry setting is set.  This keeps the default behaviour backwards compatible with the original BTS2004 release of the BRE.

To enable calling these methods, add a REG_DWORD key named “StaticSupport“, with a value of “1” to the following registry path:

32-bit Windows

HKEY_LOCAL_MACHINE\Software\Microsoft\BusinessRules\3.0\

64-bit Windows

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\BusinessRules\3.0\

Calling a one-way WCF Service from BizTalk

I recently ran into a real conundrum at the end of a deployment when we discovered that we would be sending messages to a one way (i.e. fire-and-forget) web service using the inbuilt WCF adapters.

Easy!  Just use a one-way Send port with the WCF-BasicHttp binding!  Everything builds and deploys just fine, however, at run time, we started getting the following error messages:

System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.

A little research highlighted that Microsoft does not support sending from BizTalk to one-way Web Services, as BizTalk uses the response acknowledgement to confirm the original message has actually been delivered (remember, BizTalk is all about “Guaranteed Delivery”).  Despite these protestations, sometimes you have to go with “The Customer is Always Right”, even when the customer is actually wrong.

Thanks to a very helpful set of posts by Phillipe, I was able to convince BizTalk to actually send messages, using a “proxy” WCF Service.  The proxy accepts and forwards the Request message, and returns an empty Response message back to BizTalk.

We lose a considerable amount of configuration flexibility, as BizTalk is no longer the sole keeper of end-point information, and there is less visibility if something does go down, but it’s a reasonable workaround for an inbuilt limitation of the standard BizTalk adapters.

Reminder post: How to deploy BAM activity and tracking definitons

So that I don’t have to Google next time I forget what I need to enter for BAM Activity and Tracking:

bm.exe deploy-all -DefinitionFile:"c:\full\path\to\activity-definition.xml"

bttdeploy.exe "c:\full\path\to\TrackingProfile.btt"

Both of these executables can be found in C:\Program Files [(x86)]\Microsoft BizTalk Server 2006\Tracking

Invalid content type for AS2 messages

Recently I ran into an issue with the Http ContentType used when sending messages using the As2EdiSend pipeline.

Using the standard out-of-the-box pipeline, the web content type will be set to “application/EDI-EDIFACT“, regardless of the value supplied in the Party as AS2 Receiver configuration.  If your trading partner is using BizTalk as well, this is not an issue, as BizTalk, and probably some other AS2 servers, do not consider the content type before routing the AS2 payload for further parsing by an EDI interpreter.

However, our trading partner uses a specific AS2 server, Axway, that will only route to the EDI sub-system if the content type is, quite correctly, “application/EDIFACT” (note the small difference).  This is the correct value, according to the RFC (link – see Section 4.2).

Our workaround was to add a custom pipeline component in between the EDI Assembler stage and the AS2 Encoder stage in a custom Pipeline.  This custom component only does one thing, clears the IBaseMessage.BodyPart.ContentType property of the current message stream:

IBaseMessagePart bodyPart = pInMsg.BodyPart;
if ((bodyPart != null))
{
// Override the default content type with the one we want to use
pInMsg.BodyPart.ContentType = "";
}
return pInMsg;

By default, the EDI Assemble stage allocates a default value of “application/EDI-EDIFACT”.  The AS2 Encoder will lookup the appropriate content type to use from the Party configuration, but only if the content type has not been supplied.  As the EDI stage has already allocated a value, this “optional” value is rendered useless.  By “clearing” the default value, we allow the AS2 stage to use the appropriate value

Writing to the event log from a BizTalk Orchestration

Some pointers when utilising DebugView to view debug output from your Orchestration:

• Make sure you write to System.Diagnostics.Trace, rather than System.Diagnostics.Debug
  This ensures that the trace statements will not be compiled out of non-debug builds (unless of course, this is what you want to do!)
• Use a static method on a helper class to provide a wrapper function.  This also makes it easier to provide different levels of debug messages, eg. Debug, Information, Warning, Error
• Finally, ensure the “Capture Global Win32″ flag is set in DebugView.  Without this, you’ll be scratching your head wondering where the messages have gone (speaking from experience)

Get the Instance ID of the current Orchestration

Using the following in an Expression shape will return the Instance Id of the Activating Orchestration instance.

instanceId = Microsoft.XLANGs.Core.Service.RootService.InstanceId;

Where instanceId is of type System.Guid.

Note, this will give you the Instance Id of the Activating Orchestration, not neccessarily the currently executing Orchestration.  This distinction is important in the event of the currently executing Orchestration being called as a sub-orchestration via a Call Orchestration, or Start Orchestration shape.