I have a WCF service based on BizTalk, I'm not sure how it was deployed or generated but as far as I know it was made using the BizTalk wizard for publishing WCF services. The problem is the BizTalk server installation was removed and now the service still here but it doesn't work, when i invoke the URL the service responses an exception: The BizTalk receive location may be disabled. I need to generate a WCF service in order to replace that service. I have one example request and response and the folder with the service, with a lot of stuff, XML, definitions, etc but there are no DLLs. The SVC markup has a reference to a BizTalk logic.
<%# ServiceHost Language="c#" Factory="Microsoft.BizTalk.Adapter.Wcf.Runtime.WSHttpWebServiceHostFactory, Microsoft.BizTalk.Adapter.Wcf.Runtime, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
So here goes my question, does anybody know how to generate a service based on request or response to supplant the service.
If you only have the request and response xml then it's a bit tricky. Even if you manage to recreate the service there is no guarantee that existing service consumers will be able to continue to call the service without any change. However, if you want to have a go, this rough guide will help:
Extract the operation signature from the soap request and response
This should be simple. Just look at the part of the request xml which defines the SOAP body. As an example:
<soap:Body xmlns:m="http://www.bookshop.com/prices">
<m:GetBookPrice>
<param1 xsi:type="xs:string">Metro 2033</param1>
</m:GetBookPrice>
</soap:Body>
This shows that the operation name was called GetBookPrice, and that it takes a string as an argument. Now look at the soap body for the response, for example:
<soap:Body xmlns:m="http://www.bookshop.com/prices">
<m:GetBookPriceResponse>
<return xsi:type="xs:decimal">5.99</return>
</m:GetBookPriceResponse>
</soap:Body>
This tells us that the return type of the operation was decimal:
public decimal GetBookPrice(string bookName);
So now you can recreate the service operation in a vanilla WCF service.
It's possible that the service definition included complex types rather than primitives, in which case you need to infer the types from the request/response xml. If the types are too large, you can try to automatically infer them by:
Infer XSD from XML - you'll need to extract just the request and response types from the request/response files, then run them through xsd.exe, which will try to generate the XSD schemas for your request/response types.
Infer CS from XSD - once you have the XSD files, again use xsd.exe to infer the classes for these files. You can then annotate these classes with the DataContract and DataMember attributes and then you can use them in your service definition.
In conclusion, it's not a task I envy you for - even if you manage to faithfully reconstruct the service and type definitions, you may still find that existing clients cannot call the service based on having missed some optional data which was not present in the request/response files you have.
If you create a client for the service in a blank project using Visual Studio (References > "Add Service Reference") you will get the interface that you need to implement (as well as POCOs for all the parameters).
Then create a new WCF project and use that interface and those classes as your contract.
This way you will honour the existing schema without having to manually interpret it.
Look for WcfServiceDescription.xml file in your service folder, its under \App_Data\Temp folder of your service physical folder (you can check IIS virtual directory where its pointing to find the physical path).
Use this file to publish the service again. Based on the definition in it, make sure, you deploy required assemblies to GAC (e.g. schema or orchestration assemblies) before publishing the service again.
Then you can use BtsWcfServicePublishing.exe tool which you can download from http://www.microsoft.com/en-us/download/details.aspx?id=21973 from command prompt. On this exe pass the WcfServiceDescription.xml file along with its full path
In the end, I used an ashx handler for procesing the request (cambined with the other responses were very helpfull) xml-> generate xsd -> parse and read request. The only problem is the .ashx termination.
Related
I have a WSDL file and using same a proxy service reference and classes for various object gets generated.
The WCF service implemented using the interface from generated file (reference.cs) works well when service is triggered with some soap message using SOAP UI.
Now I have various soap messages and needs to test the service function using unit testting or some console app. For that I need to convert these soap messages to actual .NET object so I can invoke the service function or some part of that function using the object (which normally received to service operation when invoked)
Tried different approaches like TypeConverter, SoapFormatter etc to desearlize the soap message but non helps since the soap message contains lots of namespaces and nested object hierachy.
How one can do it OR can any one give idea , what methods internally convert the soap message to actual object which are parameters of function ??
How I've done in past is actually imported WSDL in SOAPUI, with all its services, and got clean Services with formated SOAP methods, and afterwards its a piece of cake to create models in C#, java or whatever language.
SoapUI
Create empty project,
Add WSDL to empty project (provide path),
Get correct structure of SOAPs (request)đ
create models
The ONLY argument I can see for SOAP WCF over REST (json) wcf is the fact that once my service is created I can add a a reference in visual studio and I get a load of strongly typed classes ready for me and a client class that I can call all my webmethod through. It even sets up the web.config as far as I remember.
However when I expose a REST (json) service I still get a WSDL. So Im wondering is there still a way to build my references automatically?
Not using WCF tools. Unlike with SOAP (which has an established protocol for describing services - WSDL), REST doesn't. WADL is one such protocol, but it isn't too widespread and WCF does not support it. You still get a WSDL, because WCF will describe everything it can from the service. However, the WSDL won't have a <wsdl:port> element, which would describe the REST endpoint, which is why you get the WSDL, but cannot generate a reference to it.
The post at http://blogs.msdn.com/b/carlosfigueira/archive/2012/03/26/mixing-add-service-reference-and-wcf-web-http-a-k-a-rest-endpoint-does-not-work.aspx has a lot more info on this issue.
Very old question, newer answer.
today using openapi (swagger) I can achieve this by using swagger inspector doing samples i can document my rest services as well as create a spec yml/json file allowing for validations and acceptance criteria as well as automated clients for java,python,c#,ruby,javascript and others I'm sure
I would like top elaborate:
Although it is true you cannot get a WSDL add service reference with a JSON REST WCF service, what I do is create two met data hooks:
is the operations returning JSON
is a single XML op returning a class wrapper which includes all the service classes I allow, I call it Discover:
i.e.
public class Discover
{
public Manager Manager {get;}
public Employee Emp {get;}
....
}
[OperationContract]
public Discover DiscoverDTOs()
You can, indirectly. While the client generated by Visual Studio won't work, that client implements an interface, also generated, that you can use like this:
WebChannelFactory<IService> factory = new WebChannelFactory<IService>(new Uri(endpointAddress));
IService proxy = factory.CreateChannel();
int result = proxy.Operation(1, 2, 3);
WebChannelFactory has another overload which accepts a WebHttpBinding, you can configure based on the service configuration, or you can make this configuration manually in your app.config file.
I need to invoke action on a web service, but i have no idea what the request envelope will look like (the services are attached at runtime by users).
Generally I'd like to generate soap envelope programmatically based on wsdl link. With given link get list of operation and such result for specific one:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:webservice.contentinn.com">
<soapenv:Header>
<urn:AuthHeaderElement>
<token></company>
</urn:AuthHeaderElement>
</soapenv:Header>
<soapenv:Body>
<urn:TestMethod>
<id></id>
</urn:TestMethod>
</soapenv:Body>
</soapenv:Envelope>
Anyone have idea how to do that?
Answers to this question suggests a couple of approaches:
SoapUI: This is not really a programmatic approach.
Castle Dynamic Proxy: This is closer to what you sound like you need, but still not quite there.
The example here is probably what you're after:
The DynamicProxy allows you to create the dynamic WCF client at runtime by specifying the WSDL URI of the service. The DynamicProxy does not depend on the precompiled proxy or configuration. The DynamicProxy uses the MetadataResolver to download the metadata from the service and WsdlImporter to create the contract and binding at runtime. The compiled dynamic proxy can be used to invoke the operations on the service using reflection.
The example shows how you can the dynamic proxy to invoke operations that use simple types and complex types. The flow of usage is as following.
Create the ProxyFactory specifying the WSDL URI of the service.
DynamicProxyFactory factory = new DynamicProxyFactory("http://localhost:8080/WcfSamples/DynamicProxy?wsdl");
Browse the endpoints, metadata, contracts etc.
factory.Endpoints factory.Metadata factory.Contracts factory.Bindings
Create DynamicProxy to an endpoint by specifying either the endpoint or contract name.
DynamicProxy proxy = factory.CreateProxy("ISimpleCalculator");
OR
DynamicProxy proxy = factory.CreateProxy(endpoint);
Invoke operations on the DynamicProxy
double result = (dobule)proxy.CallMethod("Add", 1d ,2d);
Close the DynamicProxy
proxy.Close();
To run the example: Compile the solution, run the CalculatorService.exe and then run the CalculatorDynamicClient.exe
There is a Java example here, too.
You'll need to generate a proxy class; that'll generate everything needed for invoking the service's actions.
There are several ways to generate the proxy class
You could add a Service Reference to your project
Run SVCUTIL: svcutil http://someurl?wsdl
Once the proxy class is generated, it'll expose the service's actions as methods. Just invoke the desired method and the SOAP envelope will be generated for you.
I am developing a c# desktop application and using a webservies which is developed in a php application when i try to consume that application. I just add web REference of that web service and try to access throught the following code
WebReference.TestWSDL pdl = new testingApp.WebReference.TestWSDL();
string copy = pdl.verify("testing");
it throws the error when i try to call the method verify. the error is
Possible SOAP version mismatch: Envelope namespace http://schemas.xmlsoap.org/wsdl/ was unexpected. Expecting http://schemas.xmlsoap.org/soap/envelope/.
and the web service link was like
http://171.139.101.12/code/index.php/webservice/wsdl
The error you are encountering is informing you that when you invoke the webservice, you are being given the WSDL (Web Service Definition Language) for the service - this is the metadata that describes the service functions, but cannot actually be used to invoke the service. Usually, you access the WSDL by appending either "?wsdl" or "wsdl" to the service URI.
There are two elements to the webservice you are attempting to consume.
The actual service exists at:
http://171.139.101.12/code/index.php/webservice
The metadata describing it, which Visual Studio via wsdl.exe used to generate a proxy, resides here:
http://171.139.101.12/code/index.php/webservice/wsdl
You need to edit the properties of the Web Reference and update the address appropriately. Alternatively, you can alter the properties of the pdl variable, and change the endpoint in code.
I have two websites, both using .Net framework 3.5. One website is hosting a soap web service and the other is referencing this service.
I'm having some unexpected happenings with my web method signatures. I have a simple method in my web service with a signature such as:
[WebMethod]
public string[] HelloWorld()
{
return new[] { "Hello World" };
}
But when I reference this web service using the 'Add Service Reference' feature in VS2008, with configuration set to "Always generate message contracts" (although when i check the 'reuse types in referenced assemblies', i seem to have the same issue), the signature seems to be changed by the auto generated proxy objects to the following:
HelloWorldResponse HelloWorld(HelloWorldRequest request)
I've tried to look this up on the net, but having trouble finding something that will simply explain to me why this is happening, and whether I can/should try to work around it?
I also have this question:
How does one determine whether they should choose the service reference configuration option to "reuse types in referenced assemblies" and "always generated message contracts"?
The message-contracts option might have this effect; the purpose here being to allow fine-grained control over the underlying request. Ultimately, what you are sending (behind the scenes) is a request payload.
The reuse-types option is more typically used with objects (not things like string[]) - and means that if you have a 100% matching Customer (say) class locally, it can re-use that for the web-service rather than generating a proxy type.
Additionally, note that you aren't actually consuming a WCF service ([WebMethod] is the older web-service style). As such you may have better results with a "Web Reference"; when adding the service, hit "Advanced", then "Add Web Reference...". This uses the older UI and wsdl.exe to generate code intended for [WebMethod] (asmx), rather than WCF (svc).
Of course, rather than hosting a [WebMethod], you could (since the server is also 3.5) host a WCF service; this may make things easier.
A final point of WCF; if you really want the same contract at client and server, you can use either assembly or class sharing to use the very same types at both end. This is not supported for [WebMethod], though.