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’

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.

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.

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

"%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"

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\

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.

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

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

• 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)

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.