WCF rest client - Post timeout - wcf

I am newbie to WCF rest. I have two operation contracts, a POST and GET Method.
In my client, i use HttpWebRequest and try to access the operation contract.
Whenever i access the POST method operation contract i get a timeout error.
But when i try accessing the POST method after a successful GET method, everything works fine.
Is it necessary, that i should use GET method call subsequent to a POST method call?
What wrong am i doing here?

Doing a GET before a POST is not necessary. Your error might not actually be a POST timeout but rather bad data going to the server and the server failing on deserialization.
Is it possible that the GET is setting up some data on the client that travels back to the server? If this is the case then, is it possible for that data that the GET sets to be the data that when unset, makes the POST fail on the server?
The best way to find out is to set tracing on your server. Look here for good examples of WCF tracing.
UPDATE: Another possibility is that your GET code is initializing something on the server side that your POST call is missing. Perhaps a DB connection?

Related

Long calculation in a wcf restful service

I have a WCF restful service and it works correctly, the problem is that the service expose a method "Calculate" and it may take several minutes to complete the calculation, and since REST is a stateless method, I'm running out of ideas !
should I maintain the session ?
how can I do a callback ?
10 minutes waiting for a response in a website is not convenient, but I have to find a solution.
PS: the service MUST be restful, and I cant reduce the calculation time.
I asked about your clients because if they were .Net only, you could implement the async programming model, but since they aren't...
You can do something like in this post - WCF Rest Asynchronous Calling Methods
Basically your method will spawn an additional thread to do the actual calculation work, and return some sort of token to the calling client immediately in the main thread. The client can then use this token in a polling method to check if the calculation is complete.
You can create a one-way WebMethod to submit the intial calculation request. Inside your calculation code, you need to update a database table or similiar with progress, either percentage or completion.
You will then need to create an additional 'Polling' method that you can use to check the status, using the previous table.
When your calculation method marks it as complete, you can then call a final 'GetResults' method which will do just that.
We do something similiar for large file imports that are submitted via web services and it works very well.
Some info;
http://msdn.microsoft.com/en-us/library/system.web.services.protocols.soapdocumentmethodattribute.oneway(v=vs.71).aspx

Getting Null Back from Method Call

Ok, let me first state some facts:
This is a web service that has been working. There are several .svc endpoints all of which worked. Right now though there's one that is not, meaning I can make method calls to it when I consume the service through another project but I keep getting null back as a result.
The code for the methods in this service that continually sends back null HAS NOT CHANGED
I did mess around with the endpoint configuration pointing it to a couple different servers. I tried the original server it was pointed to also. No matter what I can update the service fine but even if I set it back to the old endpoint path, I still get null back from my unit tests when testing calls to this service. The unit tests are running in the project that's consuming the service of course
I've checked the app.config and web.config for the service itself. As far as I can see everything looks fine...but again I'm new to WCF
I know this is pretty general but I'm looking for some guidance on where to start looking to see why I'm getting null back all of a sudden. The stored proc behind these methods have not changed. Again these method calls were working at some point in time in the past week but now it isn't.
This is very general, but a few things to try...
Try updating your service reference to ensure you have the most recent version of your proxy objects
Have you tried debugging inside your service and seeing if the expected return value is being returned from the service prior to the client getting it?
Do you catch all exceptions in the service and then return a result object or do you let exceptions fall through? If you let them fall through, the WCF channel might be getting faulted.
Try using Fiddler and seeing if the endpoints you think should be getting called are and if the response object is indeed null.
Use an old-school trick and write the result to a file on the server just before you return to the client. This will help you know whether or not it is a server-to-client serialization issue. You may even need to write to file right as the service gets the call to make sure your client is connecting.
What you really need to do is start by debugging inside your service and stepping through the code there. Make absolutely certain the SPROC is returning what you expect and then there isn't an environmental bug introduced.
When you have weird problems with WCF, the fist thing to do it configure WCF tracing. It's a very powerful tool. You can even see the content of messages.
Here is the official doc on this: Configuring WCF Tracing

How do I follow a WCF request from start to finish?

I have a WCF service defined, it accepts JSON and maps that JSON to an object at which point I can then begin debugging code.
Sometimes, the object fails to create. Most recently my service had a BodyStyle of Wrapped but should have been Bare. In this case I would have liked to watch the request come in and see what happens to it as it gets mapped from JSON to POCO and then onto the service so I can watch for errors.
I'd also like to see what happends with the response where I have also had issues in the past.
What is the best way of seeing what is going on in WCF when it is (kind of) out of my control? What kind of logging/tracing can I use and can I see errors/exceptions being thrown by WCF?
Thanks
Scott
I don't know much but svctraceviewer might help in case you haven't heard about it already.
Arnis gives a good suggestion. I'd also suggest using Fiddler to trace WCF traffic assuming you are using a HTTP end point. I've used fiddler to troubleshoot WCF issues so it might be helpful to you as well.

Problem with WCF client calling one-way operation

I have run into a problem when calling web service on a SAP PI bus from my WCF client.
The operation is defined as one-way, and the method on my proxy operation contract is decorated accordingly when the service reference is added.
However, the service client gets an exception when calling the according operation:
The one-way operation returned a non-null message with Action=''
Using SoapUI, the method on the bus can be called successfully, and it returns a SOAP envelope with an empty body. The bus people told me, this is according to the SOAP specs:
(SOAP specs, chapter 4.7.9, One-way operations):
There are differing interpretations of how HTTP is to be used when performing one-way operations.
R2714 For one-way operations, an INSTANCE MUST NOT return a HTTP response that contains an envelope. Specifically, the HTTP response entity-body must be empty.
R2750 A CONSUMER MUST ignore an envelope carried in a HTTP response message in a one-way operation.
R2727 For one-way operations, a CONSUMER MUST NOT interpret a successful HTTP response status code (i.e., 2xx) to mean the message is valid or that the receiver would process it.
So it seems, my WCF client doesn't comply with R2750.
I have found out that when I force the operation contract on the proxy to be IsOneWay = false, everything works.
Is there anything wrong with the way WCF handles one way operations or do I do something wrong (more likely)?
Is there anything else I should do, it just doesn't seem right to override the generated WCF proxy client.
Thanks for any suggestions.
It looks like SAP PI incorrectly sends an empty SOAP envelope and .NET incorrectly interprets that envelope.
Some options from this thread:
alter the generated proxy and remove OneWay=true (or add OneWay=false) to the method definition
catch the Protocol Violation in an exception handler and ignore it
use a 2.0 style webreference to call the service
apply SAP patch Note 1459995 - Soap Sender Adapter HTTP 202 and add &responsecode202=true to the url
The first and last options both worked for me. Further discussion on this sap.com thread.
I would take a look at this article as well by Gerben van Loon here. One way operation might not really be one way according to the standards.
Check this SAP thread out for the complete discussion:
http://scn.sap.com/thread/1627368
#Brian Low has answered this question correctly and very thoroughly (is should get marked as the answer).
I would also like to add that this is a known error in which the SOAP Adapter does not comply with the aforementioned WS-I Basic Profile 1.1 (R2750) and WCF does not comply with (R2750). The result... Hours of wasted time and teeth gnashing....
I believe that this particular problem can be fixed by adding the following attribute declaration to the operation in the client porxy:
[WebInvoke(BodyStyle = WebMessageBodyStyle.Wrapped)]
Without seeing what the signature of the method looks like, my best guess is that your method defined to return something other than "void". Since the operation is one-way, the method can only be defined using "void" (has no return). Anything else, and the operation is NOT one-way.

View underlying SOAP message using vb.net

I have a VB.NET web service that calls a third party web service. How can I view the SOAP message generated by .NET before it is sent to the third party web service and how can I see the SOAP response before it is serialized by .NET.
When creating a standalone EXE, I see the Reference.vb file that is automatically generated, but don't see a similar file when my project is a web service. I have found lots of C# code to do this, but none in VB.NET.
Edit - Fiddler and TCP loggers are great, but will not work for my purposes. I need to be able to access the raw SOAP messages from within the application so I can log them or modify them. I need to do more than just see the messages going back and forth.
You can use fiddler or a tcp sniffer to filter and identify all outgoing and incoming traffic on your host.
This is if you want to see the xml request and response.
How about using an extension to allow you to examine the SOAP message?
Accessing Raw SOAP Messages in ASP.NET Web Services
http://msdn.microsoft.com/en-us/magazine/cc188761.aspx
I was trying to do the same thing and this seems to work for me:
Dim message As String = OperationContext.Current.RequestContext.RequestMessage.ToString()
I didn't think it would be that easy since most of the time ToString() returns the name of the class, but I tried it out and low and behold.
I know you asked this back in January so if since then you've figured out a better way let me know.
Please note that if you're catching the exception in a class that implements IErrorHandler then you have to perform this operation from within the ProvideFault() method instead of the HandleError() method because the context is closed before it gets to call the HandleError() method.
Hope this helps.