In a BizTalk project I had a problem that I couldn’t use Add Generated Items to consume a webservice and generate the orchestration (plus porttypes and messagetypes in message types in orchestration view), messages and bindings. What I did have was a WSDL file, yet not a so-called single wsdl. For that reason I first had to create a so called .svc file based on the supplied wsdl.
Start the VS command prompt as an administrator and run the following command:
D:\>svcutil k2wservices.wsdl /syncOnly
By using /syncOnly only synchronous methods are generated.
This way you generate the svc file, a webservice interface file and a not implemented service file. In this case I had K2WService.svc, IK2WService.cs and K2WService.cs. If you wanna check out the code, open Visual Studio as an administrator and select File/Open/Web Site. As a gotcha, remember that you can right-click IK2WService in the K2WService.cs file and select Implement Interface. All methods will be created to return a NotImplementedException. Next you can implement the methods you want. Another gotcha: replace [OperationContractAttribute] by [OperationContract] in the service interface file, otherwise it won’t work.
For now let’s assume I did implement one of the methodes of the stub service. Note: You only have to return an empty response without any further implementation, to go to the next step. Create a new application in IIS, specify the correct app pool and reference code files in Visual Studio. If you now browse to the webservice, you get the address of the svc file.
After deploying the website to IIS you can use svcutil again to generate the wsdl and xsd files you want. Use command:
D:\>svcutil /t:metadata http://localhost/K2WService/K2WService.svc
Now you can actually use Add Generated Items in your solution. The recommendation is to create a separate project to add the generated items to. I used Stadgenoot.WRV.VrijgevenWoning.ServiceReference in solution Stadgenoot.WRV.VrijgevenWoning. While using BizTalk Add Generated Items select the second option and then browse and select all the *.wsdl and *.xsd files generated. Now your artefacts are actually created. The last step is to add a reference to Stadgenoot.WRV.VrijgevenWoning.ServiceReference so that you can use the generated porttype and multi-part messagetype in your actual Orchestration project. Note that the xsd file is also left in project Stadgenoot.WRV.VrijgevenWoning.ServiceReference.
Final actions to get it working:
– Remove the dot in all occurrences with .DetailType in K2WService.xsd. So:
<xs:element name=”OpvragenEenheidFaultDetailType” type=”OpvragenEenheidFault.DetailType” />
<xs:element name=”OpvragenEenheidFault.DetailType” type=”OpvragenEenheidFault.DetailType” />
– Change name of body part of all response messages from a name that matches the message name to a name parameter in Orchestration View / Multi-part messagetypes. That way you can solve interface hiding (partname=messagename) issues
– Last issue:
After importing the binding file, I kept getting the following error message:
There was a failure executing the response(receive) pipeline:
“WoCo.ALG.Pipelines.CustomXmlReceive, WoCo.ALG.Pipelines, …”
Source: “XML disassembler”
Send Port: “sndK2W.OpvragenEenheid”
Finding the document specification
by message type “http://tempuri.org/IK2WService#OpvragenEenheidResponse” failed.
Verify the schema deployed properly.
When I checked the Action Mapping in the webservice sendport, I saw http://tempuri.org/IK2WService/ was added for all operations. In the end, the simple solution was to remove the action qualifier. So::
<Operation Name=”OpvragenEenheid” Action=”OpvragenEenheid” />
<Operation Name=”OpvragenEenheid” Action=”http://tempuri.org/IK2WService/OpvragenEenheid” />