Can anyone point me in the right direction with this issue? We have a WCF central router and we want to manipulate the responses passing through the router based on some xpath criteria. Basically we want to remove a lot of the details from some error requests and sub some extra details in. Ideally we would also like to log the error.
I know it is generally better practice to update the web services to do this but in our case this is not possible and needs to be performed on the router if at all possible.
Also it would be great if we could log each request and response but that is likely a different solution to the manipulation of the responses.
Not sure if you have solved this but...
You should be able to use WCF Behaviours to do what you need.
Have a logging behaviour to log the requests and responses and another one to log errors/manipulate responses
We use behaviours to log to app fabric, and we have one (nasty) behaviour which catches all exceptions and returns a valid response with an error message. I personally don't like this 'feature' but you can basically do anything to your requests/responses with behaviours
Related
I am working with Apigee edge lately and am having trouble with a specific implementation. Essentially, the client will request an oauth token from their API through apigee. However, to make calls to our proxy they need an oauth token from us as well. So far my flow goes like this.
Client calls token endpoint on apigees side, a service callout is made to get a token from one of our other proxies (returned as a json object). Then the request passes through and gets the token from the clients API.
Here is where I am having trouble. After the response from the clients API, I want to use the assign message policy to modify the response to include the first token that was grabbed from our other proxy. The problem is the variable seems to be falling out of scope between request/response.
Am I missing something obvious here? I have looked into the PopulateCache policy, but I feel like this may be overkill as I only want the variable to remain in scope for the request/response. Thanks for any clarity you guys can provide! Sorry if my explanation is not very good, I am VERY new to Apigee Edge.
You aren't missing anything obvious. Variables should not fall out of scope between request and response flows. You are right that PopulateCache isn't necessary.
One item that catches people sometimes is how you access the response from the service callout. If you configure the service callout response to be stored in a variable called calloutResponse, then when you access the body to extract information, you'd use calloutResponse.content as the source. If you try to access calloutResponse instead, you might think that the variable had disappeared.
Add more details/trace if that is not the problem, and we can figure out what is going wrong.
I'm developing a WCF SOAP web service based on this schema.
Basically it takes product orders from many clients.
As part of the submit operation the client is allowed to provide a URL where it expects asynchronous status updates on the order and it's line items.
I want to know if anyone has experience with a similar architecture? How did you go about implementing this?
Can i use a dynamic web reference as stated here? I would think this won't work very well in this situation. I'm pretty sure i'll need Chuck Norris to handle all the exceptions that get throw at the presence of any client service that is not identical or slightly different... even if it does pass schema validation.
The best thing i can think of is building the status object, serializing it into the SubmitResponse request soap message xml then sending it off using curl. something like:
curl -d "<my soap message xml>" "http://www.example.com/target"
Any ideas?
Question FOCUS
The problem i'm trying to solve is how to submit status responses to web service urls dynamically without having any prior knowledge of them.
Just started my first WCF rest project and would like some help on what are the best practices for using REST.
I have seen a number of tutorials and there seems to be a number of ways to do things...for example if doing a POST, I have seen some tutorials which are setting HttpStatusCodes (OK/Errors etc), and other tutorials where they are just returning strings which contain result of the operation.
At the end of the day, there are 4 operations and surely there must be a guide that says if you are doing a GET, do it this way, etc and with a POST, do this...
Any help would be appreciated.
JD
UPDDATE
Use ASP.NET Web API.
OK I left the comment REST best practices: dont use WCF REST. Just avoid it like a plague and I feel like I have to explain it.
One of the fundamental flaws of the WCF is that it is concerned only with the Payload. For example Foo and Bar are the payloads here.
[OperationContract]
public Foo Do(Bar bar)
{
...
}
This is one of the tenants of WCF so that no matter what the transport is, we get the payload over to you.
But what it ignore is the context/envelope of the call which in many cases transport specific - so a lot of the context get's lost. In fact, HTTP's power lies in its context not payload and back in the earlier versions of WCF, there was no way to get the client's IP Address in netTcpBinding and WCF team were adamant that they cannot provide it. I cannot find the page now but remember reading the comments and the MS guys just said this is not supported.
Using WCF REST, you lose the flexibility of HTTP in expressing yourself clearly (and they had to budge it later) in terms of:
HTTP Status code
HTTP media types
ETag, ...
The new Web API, Glenn Block is working addresses this issue by encapsulating the payload in the context:
public HttpResponse<Foo> Do(HttpRequest<Bar> bar) // PSEUDOCODE
{
...
}
But to my test this is not perfect and I personally prefer to use frameworks such as Nancy or even plain ASP NET MVC to expose web API.
There are some basic rules when using the different HTTP verbs that come from the HTTP specification
GET: This is a pure read operation. Invocation must not cause state change in the service. The response to a GET may be delivered from cache (local, proxy, etc) depending on caching headers
DELETE: Used to delete a resource
There is sometimes some confusion around PUT and POST - which should be used when? To answer that you have to consider idempotency - whether the operation can be repeated without affecting service state - so for example setting a customer's name to a value can be repeated multiple times without further state change; however, if I am incrementing a customer's bank balance this cannot be safely be repeated without further state change on the service. The first is said to be idempotent the second is not
PUT: Non-delete state changes that are idempotent
POST: Non-delete state changes that are not idempotent
REST embraces HTTP - therefore failures should be communicated using HTTP status codes. 200 for success, 201 for creation and the service should return a URI for the new resource using the HTTP location header, 4xx are failures due to the nature of the client request (so can be fixed by the client changing what they are doing), 5xx are server errors that can only be resolved server side
There's something missing here that needs to be said.
WCF Rest may not be able to provide all functionality of REST protocol, but it is able to facilitate REST protocol for existing WCF services. So if you decide to provide some sort of REST support on top of the current SOAP/Named pipe protocol, it's the way to go if the ROI is low.
Hand rolling full blown REST protocol maybe ideal, but not always economical. In 90% of my projects, REST api is an afterthought. Wcf comes in quite handy in that regard.
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
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.