I have a wsdl generated from XSD using WCSF Blue. I am using the service from a console application client. I am getting the following exception (SOAP?). What’s wrong in the wsdl? How can we correct it?
Header namespace mismatch in member UserCredentials of type RestaurantService.AddRestaurant.
The header namespace found in the description is urn:thinktecture-com:demos:restaurantservice:headerdata:v1.
The element namespace deduced by the formatter is urn:thinktecture-com:demos:restaurantservice:wsdl:v1.
This mismatch can happen if the Namespace specified in XmlElementAttribute or XmlArrayAttribute does not match the namespace specified in the MessageHeaderAttribute or MessageHeaderArrayAttribute or the contract namespace.
WSDL
Header Data
I am planning to use the following approach:
Verify all things mentioned in 400 Bad Request Exception: Simple SOAP WCF service with small data
The service code is generated from wsdl using a tool (WCSF blue). Using the service, when wsdl is generated it is slightly different. So,
Try to create a client using the wsdl obtained by browsing the svc file. Refer the end point address in the config file in this new client. Verify that our client's adress is same as this client's address.
Related
I have several SOAP web services that have the same interface but have different URLs' and namespaces'.
URL 1 http://badservice.com/one has a namespace "one-ns"
URL 2 http://badservice.com/two has a namespace "two-ns"
When I generate a web service client via svcutil from http://badservice.com/one?wsdl, I can only use it for http://badservice.com/one. Once I try to send a request to http://badservice.com/two SOAP service says
namespace mismatch require http://nanopetdbs.driver.maestro.ibtech.com found http://ozkaraslanpetroldbs.driver.maestro.ibtech.com
I can generate clients for each web service URLs at the worst scenario.
I need an idea to prevent code duplication in this case. I have tried altering namespace while sending requests, could not make it.
I need to change the highlighted place of the envelope at the runtime.
No, we can’t specify these values at the runtime. During SOAP communication, this field will be used for addressing the method to be called.
Here is a communication telegram captured by Fiddle.
The SOAPAction field will specify the method to be called.
If these values can be changed at the runtime, the addressing method becomes confusing. This is the meaning of a service contract with its namespace and name properties.
[ServiceContract(Namespace ="http://mycommany.com")]
public interface IService
{
[OperationContract(Name ="Mymethod")]
Int32 Add(Int32 Num1, Int32 Num2);
}
Besides the BasicHttpbinding, some other bindings, such as wshttpbinding using ws-addressing. They use these properties(namespace, name) in Action SOAP header to specify the addressing method.
In summary, It is these attributes that determine the addressing mode at the runtime, so we cannot modify these attributes(namespace, name) at the runtime.
Feel free to let me know if there is anything I can help with.
I have a WCF SOAP Web Service built using svcutil to generate the contract classes. The WSDL has enums and thus the default is to deserialize the XML to an enum class. This works great when the user sends in the correct enum.
<priceType>List</priceType>
<priceType>Net</priceType>
However, if the user enters a bogus value:
<priceType>I love dogs</priceType>
The deserializer throws and exception and they get a SOAP Fault that there was a server error. How could I respond with a better error message that their enum value is invalid?
There is a series of SOAP services which I wish to call (across a series of services), and while the end points are well defined & documented, there is no WSDL data... so I decided to build my own.
In order to do so, I built a test WCF service which matches the known interface of the service I wish to call.
I then saved the WSDL it exposed, changed the base address the WSDL references, created my proxy (with wsdl.exe), added it to a test client project, and can successfully create a proxy and make calls which causes the SOAP service to send the expected response... only this expected response is not picked up by the proxy and returned to the calling code.
When looking at the back and forth traffic... I can clearly see that the service is replying with what I want.
Any suggestions as to how I might troubleshoot this and get the proxy to pickup the data?
Given the replies are effectively identical, I'm forced to look back at the differences between what my client is sending and another sends.
A known working app sends it's XML blob starting with the following:
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
While my client immediately starts with the envelope (without the xml tag, and with one less namespace):
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
The other difference is that the message within the body is prefixed by a namespace in theirs, while mine it is not... though both define this namespace within the tag.
Ala:
<s:Body>
<u:DoSomething xmlns:u="urn:http://some.namespace.org" />
</s:Body>
VS:
<s:Body>
<DoSomething xmlns="urn:http://some.namespace.org" />
</s:Body>
This is not a namespace:
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
It's setting the encoding style for the envelope which, even though it's not required per the SOAP spec, may be required by the specific implementation you're talking to. Do you have enough control over what you're sending from the client to get that put on there?
Other than that, the XML PI is not required and I think you're definitely on the right track looking at the body XML. This is almost always the case of some kind of namespace mismatch somewhere. Are you 100% positive the namespace URIs are identical?
The most likely problem is the VS version using a "default" XML namespace. There are soap parsers that I've worked which don't work correctly when using an un-aliased (default) namespaces. If you know using the u: alias works with the service, your proxy should also generate it even when every tag inside the s:Body element is prefixed with the alias.
I'm trying to administer my BES 5.0 servers using C# and the following URL seems to not only tell me to generate a WSDL for an incorrect namespace (does not exist) but it also generates collisions.
http://docs.blackberry.com/en/developers/deliverables/16633/Generate_the_client_proxy_925487_11.jsp
What is the correct way to set up the WSDL for the BES admin api?
The correct way is the following command, one line, with the FQDN of the server:
wsdl.exe /sharetypes /out:C:\Temp\proxy.cs https://myFQDN/baaws/core/ws?wsdl https://myFQDN/baaws/core/wsutil?wsdl https://myFQDN/baaws/emailexchange/ws?wsdl https://myFQDN/baaws/dispatcher/ws?wsdl
Alternate WSDL for Groupwise: (append) baaws/emailgroupwise/ws?wsdl
Alternat WSDL for LotusNotes: (append) baaws/emaildomino/ws?wsdl
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.