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.
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.