I'm writing a service Adapter to use web services hosted by an another vendor (Pega). Changing this service is not an option for me.
When I'm calling a method I get the error :
"Error in deserializing body of request message for operation"
I tried increasing maxStringContentLength and all. Nothing worked.
When examining the response XML I see empty values for few long and int variables I believe this is the reason.
Is there is any fix for this?
This got resolved after removing empty tags from the service end.
No solution found from .Net client end.
I solved this issue by changing format of one of request parameters. Date was passed as a text and service was unable to parse provided date format.
Not sure why service expected date as a string though, but this was out of scope that time.
Related
I'm getting started with UWP and wish to consume an old, heavily used ASMX web service written in VB.Net 2.0.
I have created a service reference to the web service but whatever function I call I always end up with the error
"An exception of type 'System.PlatformNotSupportedException' occurred in mscorlib.ni.dll but was not handled in user code
Additional information: MessageEncoder content type parsing is not supported."
There's no further help than this, not sure if it's because the return type is XML and it's expecting JSON or something, even if that were the case I see nowhere to change this.
Here is the relevant lines that I am using to pull back a simple response, help would be greatly appreciated.
WSSoapClient proxy = new WSSoapClient();
Guid ProviderGUID = Guid.Parse("[REDACTED]");
string ProviderPassword = "[REDACTED]";
objWSEthnicitiesGetReturn result;
result = await proxy.WSEthnicitiesGetAsync(ProviderGUID, ProviderPassword);
I found the issue, while the W/S is using HTTP... during use the endpoint was changed to HTTP. Now while there is a redirect in IIS this caused the lookup to always return a 301 error.
In the reference file for the Service Reference I had to alter the proc GetBindingForEndpoint to include the following lines
result.Security.Transport.ClientCredentialType = System.ServiceModel.HttpClientCredentialType.None;
result.Security.Mode = System.ServiceModel.BasicHttpSecurityMode.Transport;
Whilst bringing the reference into the project .NET had also changed all references to the HTTPS to HTTP so I had to do a search for all instances throughout the project and manually change them all.
All is good now though so thank you for your time guys.
I've added in the service reference an url like this: "https://example.com/cars?wsdl"
Everything works fine, I can access the methods from that soap and compile the project without errors.
When I call a method the endpoint address is https://example.com/cars (I've notice this with the debugger) on this page is only a fault error and every method I call it returns the fault error.
Why the service reference doesn't see the parameter "?wsdl" ?
Thanks!
Your fault message is probably coming from the service itself. The ?wsdl at the end just has information about your service. Put a try catch in the method that you're calling on the service layer.
The problem was solved by using xml request.
http://www.terminally-incoherent.com/blog/2008/05/05/send-a-https-post-request-with-c/
The error seems to be from the service itself.
As strange as this may sound, I've been getting a Bad Request (error 400) response from IIS whenever I post a form that has an invalid date in a datetime field, as if IIS knows it's supposed to be a datetime value and is validating it somehow.
UPDATE (added more information)
It's an ASP.NET / MVC 4.0 website.
All datetime fields in the model are declared as string (for other
reasons), so I don't think it's model validation.
This behavior only occurs in one of the servers, all other machines (developer and servers) are ok.
UPDATE 2 (added more information)
It's seems to be a proxy related issue. When accessing the site locally, it works. When accessing it from another computer, returns bad request.
UPDATE 3 (add more information)
Ruled out the "proxy hypothesis". I enabled request tracing in IIS, this was logged:
ModuleName: ManagedPipelineHandler
Notification: 128
HttpStatus: 400
HttpReason: Bad Request
HttpSubStatus: 0
ErrorCode: 0
Notification: EXECUTE_REQUEST_HANDLER
ErrorCode: A operação foi concluída com êxito. (0x0)
I have two posts:
btnProcessarAutuacao=Processar&IdAutuacao=5000038&DataLimiteIdentificacaoCondutor=31%2F12%2F2013+00%3A00%3A00&DscMensagemErro=Numero+do+auto+de+Infra%C3%A7%C3%A3o+A151515+para+o+Orgao+autuador+100107+j%C3%A1+foi+digitalizado&Placa=GVQ3641&AIT=A151515&CodInfracao=7471&DscInfracao=EXC.VELOC.ALEM+50%25+MAX++++++++&CodOrgaoAutuador=100107&DscOrgaoAutuador=GOVERNO+DO+DISTRITO+FEDERAL&DataEmissao=09%2F01%2F2014&DataInfracao=31%2F12%2F2013&HoraAutuacao=10%3A10%3A00&CodMunicipio=643&DscMunicipio=643&Local1=p_local145&Local2=p_local245&X-Requested-With=XMLHttpRequest
2)
btnProcessarAutuacao=Processar&IdAutuacao=5000038&DataLimiteIdentificacaoCondutor=31%2F12%2F2013+00%3A00%3A00&DscMensagemErro=Numero+do+auto+de+Infra%C3%A7%C3%A3o+A151515+para+o+Orgao+autuador+100107+j%C3%A1+foi+digitalizado&Placa=GVQ3641&AIT=A151515&CodInfracao=7471&DscInfracao=EXC.VELOC.ALEM+50%25+MAX++++++++&CodOrgaoAutuador=100107&DscOrgaoAutuador=GOVERNO+DO+DISTRITO+FEDERAL&DataEmissao=31%2F02%2F2014&DataInfracao=31%2F12%2F2013&HoraAutuacao=10%3A10%3A00&CodMunicipio=643&DscMunicipio=643&Local1=p_local145&Local2=p_local245&X-Requested-With=XMLHttpRequest
The second post sends and invalid date (02/31/2014) for the "DataEmissao" parameter and IIS responds with error 400 (Bad Request). The first post has a valid date for the same parameter, IIS responds with OK (200).
That's the only difference I could find in these requests.
Any clues to what is happening?
Finally got it figured out.
I'm doing custom server-side validation, and whenever some field has an invalid value, I set the response code to 400 (Bad Request) and return a custom error message.
When testing locally, my custom error message goes through. When testing remotely, my custom message is replace with a default IIS error page.
All I had to do was add this to web.config:
<system.webServer>
<httpErrors errorMode="Detailed"></httpErrors>
</system.webServer>
So that my custom response text goes without being replaced by the IIS default message.
Got the answer from here: Custom 400 with message being overwritten.
This isn't strange at all :)
IIS doesn't know what the data-type of the query string parameter is supposed to be, but the application framework does. For example, if this is an ASP.NET web-page, then the ASP.NET runtime could be generating the 400, or, alternatively, a programmer could have implemented a check on the type and manually set the return code to 400.
Without more details (and some code!) it's impossible to say precisely where the 400 is being generated, but it will be along these lines...
I have a simple data model with 3 tables (Account, Contact, and User) with the following relationships:
User -> Account (1 - Many) Account -> Contact (Many - 1)
I am exposing my data via an OData (v3) WCF Data Service, which is consumed by a .NET client that uses the WCF Data Service Client Library. I used the Add Service utility to generate the client proxy code to call the data service.
All methods in the client class uses the class's single DataServiceContext object for calling the web service. i.e.:
DC.WhEntities svcClient = new DC.WhEntities(new Uri(BaseUrl));
What I am having a hard time trying to figure out is why the same query request to the service starts failing after the 6th time. I have literally tried all possible ways to construct a call to the data service:
First approach:
DataServiceQuery<DC.User> users = svcClient.Users.Expand("Accounts");
QueryOperationResponse<DC.User> response = users.Execute() as QueryOperationResponse<DC.User>;
var user = response.FirstOrDefault(u => u.Id == long.Parse(key.ToString()));
Second approach:
string queryString = string.Format("Users({0}L)?$expand=Accounts", key.ToString());
foreach (var user in response) {...}
The last statement in both of the above solution starts failing with a message below after it has executed successfully 6 times in a row:
The response payload is a not a valid response payload. Please make sure that the top level element is a valid Atom element or belongs to 'http://schemas.microsoft.com/ado/2007/08/dataservices' namespace.
**StackTrace:**
at System.Data.Services.Client.Materialization.ODataMaterializer.CreateODataMessageReader(IODataResponseMessage responseMessage, ResponseInfo responseInfo, Boolean projectionQuery, ODataPayloadKind& payloadKind)
at System.Data.Services.Client.Materialization.ODataMaterializer.CreateMaterializerForMessage(IODataResponseMessage responseMessage, ResponseInfo responseInfo, Type materializerType, QueryComponents queryComponents, ProjectionPlan plan, ODataPayloadKind payloadKind)
at System.Data.Services.Client.DataServiceRequest.Materialize(ResponseInfo responseInfo, QueryComponents queryComponents, ProjectionPlan plan, String contentType, IODataResponseMessage message, ODataPayloadKind expectedPayloadKind)
at System.Data.Services.Client.QueryResult.ProcessResult[TElement](ProjectionPlan plan)
at System.Data.Services.Client.DataServiceRequest.Execute[TElement](DataServiceContext context, QueryComponents queryComponents)
When this happens, my WCF Data Service just stopped working and returns a response with
error on line 1 at column 83: Unescaped '<' not allowed in attributes values.
I am not sure if I am missing anything fundamental or if I'm constructing the WCF Data Service Client request incorrectly or if there is something on the WCF Data Service side that doesn't like the same client requesting the same thing more than 6 times.
I've already spent a few days and I meant 3+ days trying to figure this out. I am new to WCF Data Service and I thought I could learn from this tutorial, but so far I got more pain than gain.
I am experiencing similar issue, suddenly my server started (maybe some updates inflicted this, yet the cause is unknown) to return bad responses. If I start my server it works for some time, lets say responds to few requests in a normal manner and then starts to break xml structure of the OData feeds, resulting in <, hexadecimal value 0x3C, is an invalid attribute character. Line 2, position 72. exception.
SOLUTION:
I solved the problem by following this feed
If you have WCF tracing configured, make sure logMessagesAtTransportLevel="false" is turned off, otherwise you will experience this issue.
I tried setting logMessagesAtTransportLevel to false and still got the error.
Then i remembered seeing this issue before when I had an assembly conflict. I went and created a brand new service and this solved my problem even when I had logMessagesAtTransportLevel set to true on my client. This ensured me that the problem was the service.
Although my solution solved my problem, I still don't know the exact issue and I already ran out of time to find it out. However, It is good to see that people are willing to help out and I truly appreciate the effort.
Thanks everyone again for your help.
Qster123.
I am getting this error:
Client found response content type of 'text/html', but expected 'text/xml.
I am adding web reference for live search. When i build the project its Successful. But after that once i enter some text in textbox & enter search button it gives this error. I am Using my local machine & Using .net 2.0 with C#.
Plz help me...
Thanks In Advance...
As Matt said, it's probably an error page coming back.
Either use a proxy like Fiddler or a network sniffer like WireShark to see what the raw response is - that should help you get to the bottom of what's going on.
Generally that error means that the service has sent back an (HTML) error message rather than the XML SOAP response that your client was expecting.
For web services that you control it's really easy to find the problem, because you can invoke the webmethods by hand in your browser. To diagnose it when it's someone else's service is a little trickier. You might be able to trace into the code for your web reference and inspect the text of the response before the exception is thrown.
I have found Fiddler to be highly useful in debugging http client server issues.
It is a proxy that allows you to intercept and even change the content of the request and response.
In your actual code, replace the line:
searchRequest.AppID = "APP ID you generated from ...";
with the actual AppID, which should be a long alpha-numeric sequence.