Problem Consuming WCF Service in BizTalk 2009
I’m posting this one problem I ran into this week so I don’t forget about it. The scenario was as follows:
We had an existing, working WCF service. Most of the operations in the service contract were not using explicit data contracts as input parameters; instead they were just using primitives (such as an operation taking a string as an argument), though data contracts were used for the response messages.
We were trying to consume this service from an orchestration in BizTalk Server 2009 RTM, so we added the reference using the WCF Service Consuming Wizard. This worked fine. All the schemas were correctly imported and new multi-part messages were defined for the input and output messages. Schemas were also created for the inputs and outputs.
The problem came when trying to actually populate the parameters of the input multi-part messages. In this case, this needs to be done by creating the input message with all the arguments using the right schema (which we had) and then assigning that message into the parameters part of the input multi-part message that would be actually sent to the send port.
The error was that the Orchestration Compiler (or Visual Studio) for that matter didn’t seem to recognize the parameters part in the message. Though it would pop up in Intellisense in an expression shape, any attempt to actually assign a value to it would cause an error about the assignment expression being invalid (because it doesn’t recognize the part).
I immediately went back to a BizTalk 2006 R2 installation and, sure enough, I was able to do this in minutes and have it working. So far, I had failed to find anything in the docs, the readme or on searches around the neck, but I was sure it had to be something relatively harmless. Well, just so I can find it easier next time:
The workaround is to import your WCF service metadata into a separate BizTalk 2009 project, then go and change the generated Port Types and Multi-Part Message Types so that they are have public visibility, and then add a reference to the new project from the one containing your orchestration. Then it will compile and work just fine.
Annoying little bug, isn’t it?
That’s ridiculous! especially considering it works just fine in BizTalk 2006 R2. Have we gone backwards?
Have you logged this with the product team?
Any particular reason why you had to import it in a seperate project ?
Ryan: Not yet. I wasn’t part of the CTP program, and frankly, it was an scenario I had not tried till this week anyway. Will see what I can do about reporting it.
Patrick: The reason is… that having it in the same project plain didn’t work. It appears to be a side effect of the new build process (probably artifacts getting compiled in the wrong order, or something like that). So importing it in a separate project was just a means to getting the WCF port/schemas built before the orchestration using them.