BizTalk comes with a couple of tools for automating and simplifying the publication of Web-Service and WCF based services.
The problem with both these tools is that once the service has been published, there’s no easy way to make changes to the service definition without re-configuring all the properties of the Service, a time-consuming and manual procedure.
Fortunately, there is a way to initialise the wizards with the contents of a previously saved set of Service configuration file. These configuration files are conveniently created by the Wizard just before you publish the definition, and are saved into a “temp” directory under your Web/Wcf Service application root directory.
For the Web Services Publishing Wizard, the command line syntax is:
For the WCF Services Publishing Wizard, the syntax is:
Both of these tools can be found in the BizTalk installation directory, such as “C:\Program File(x86)\Microsoft BizTalk Server 2010\”
Great, if long, post on integration between BizTalk and SAP.
With SAP being one of the better known, and widely adopted ERP systems, there are a lot of opportunities for integration experts who can “bridge the gap” between SAP and Microsoft technologies.
I recently ran into an intermittent problem where we were receiving the following exception:
System.InvalidOperationException: There were not enough free threads in the ThreadPool to complete the operation.
in conjunction with a stack trace indicating we were well and truly down in the WCF ServiceModel code base. This resulted in numerous suspended messages, and a messy Event Log.
A little investigation showed that it occurred due to a bulk update of the source system, which propagated a whole bunch of messages (around 1000 in a 5 minute period), via WCF, to a web service on the destination system. This resulted in a flood of messages from BizTalk to the WCF Send Adapter, which happily allocates each message to be sent to the back of it’s own processing queue. Each pending message gets allocated a work item thread.
The destination system only exposed a ASMX-style web service, so we were restricted to using basicHttpBinding. Windows, and by inference, BizTalk, limits the default number of outbound HTTP connections to 2. So were were pumping a whole lot of messages to WCF, as quickly as BizTalk could, but WCF could only dispose of, at maximum, 2 at a time. Within a short amount of time, the process thread pool is exhausted, and errors resultant.
My solution was two-fold:
Increase the ‘maxconnections’ property for outbound Http connections.
This can either be applied at the machine level, or at the app config level. I chose to avoid unwanted side effects by only modifying the BTSNTSvc64.exe.config, adding the following snippet within the <configuration></configuration> root:
<system.net> <connectionManagement> <add address="http://name.of.server.here" maxconnection="12" /> </connectionManagement> </system.net>
Again, I took the conservative option, and only altered the maxconnection property for those intended for that specific server. I dislike side-effects…
Increase the maximum number of threads allocated to the Host Instance
Fortunately, the BizTalk architecture was set up in such a way that this specific application had it’s own set of Host Instances. This allowed me to increase the number of Maximum Engine Threads, without too much risk of starving other applications and processes on the server.
This is done within the Host Settings Dashboard, accessed by right-clicking on the BizTalk Group and selecting ‘Settings…” (sorry, BizTalk 2010+ only, folks). You get a screen similar to the one below:
So, I doubled the number of threads, which in conjunction with the increased throughput, above, should ensure we don’t run into this issue again.
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.
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.