I'm trying to understand WCF message routing, so I'm trying to recreate a sample passthrough router that I found in order to understand the pieces. The problem is that when I run mine in the debugger, I get the exception:
Multiple headers with name 'VsDebuggerCausalityData' and namespace 'http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink' found.
I've read that this is because I'm debugging all the pieces at the same time, and that the debugger is adding this data on each hop? However, I can debug all the pieces in the original sample I'm working from with no errors, so I'm not sure I believe the explanation I've seen, or I don't understand something yet. Anyone have an explanation how I can debug mine without getting this exception?
Can you check if your machine config has element. You might need to comment this out. (Before any changes to machine config do back it up)
Related
I can access this API/WS through
http://localhost:8080/ode/processes/ProcessManagement?wsdl.
I would like to get the Process Info of a Process through this service and active it.
The serivce has the matching operations getProcessInfo and activate.
With listAllProcesses I get all Processes of a delpoyed package.
For getProcessInfo/activate I need the Process pid.
I get a <ns:pid>, using this gets me a load of Exceptions.
Using the name of the process and other stuff I receive earlier doesn't work either.
The pid is of type QName, perhaps thats the root of the problem.
However I don't now how to typecast here.
(Tried all with the eclipse Web Services Explorer and soapUI)
question: How does a proper request for both Operations look like?
When I try to consume the webservice with axi2 via eclipse, there is a undeclared variable local in the AnySimpleType class. I'm not keen on using the service this way.
But since I'm already writing a Client for the DeploymentService I thought about this approach.
question: How do I properly access the ProcessManagement?
EDIT: I have a simular problem with the DeploymentService and the undeploy Operation.
EDIT2: I figured the Problem with the DeploymentService undeploy out.
I had to get the Packagename as String. Then a made a javax.xml.namespace.QName out of it. Then I used the setPackageName of said undeploy operation.
Answer to question number 1:
soapUI with listAllProcesses returns
<ns:pid>{ode/bpel/unit-test}HelloWorld2-1</ns:pid>
getProcessInfo wants
<pmap:getProcessInfo>
<pid>?</pid>
</pmap:getProcessInfo>
Now I replaced <pid>?</pid> with
<pid xmlns:odetest="http://ode/bpel/unit-test">odetest:HelloWorld2-1</pid>
and it worked like a charm.
I remember that there was an issue with parameter ordering when using the Axis2 generated WSDL. Could you try if building a request against the original WSDL located at http://localhost:8080/ode/deployment/services/ProcessManagement works?
EDIT: Now that I got the question correctly, the problem is that ODE expects the QName to be serialized differently, i.e. in the XML way instead of the Java way. Thus, instead of <ns:pid>{ode/bpel/unit-test}HelloWorld2-1</ns:pid> the correct notation is <ns:pid xmlns:odetest="ode/bpel/unit-test">odetest:HelloWorld2-1</ns:pid>.
In my winrt app, I am trying to update the live tile based on polled URIs. There is currently no update happening and I can't figure out how to troubleshoot. There are numerous scenarios that could be breaking things but i can't seem to find anyway to get insight into potential errors.
The TileUpdateManager seems to be a bit of a black hole that absorbs information but never lets it out.
Does anyone know of how to view errors from the TileUpdateManager?
If it interests anyone, here is my update code:
TileUpdateManager.CreateTileUpdaterForApplication().EnableNotificationQueue(true);
PeriodicUpdateRecurrence recurrence = PeriodicUpdateRecurrence.HalfHour;
List<Uri> urisToPoll = new List<Uri>();
urisToPoll.Add(new Uri(#"http://livetileservice2012.azurewebsites.net/api/liveupdate/1"));
urisToPoll.Add(new Uri(#"http://livetileservice2012.azurewebsites.net/api/liveupdate/2"));
TileUpdateManager.CreateTileUpdaterForApplication().StartPeriodicUpdateBatch(urisToPoll, recurrence);
To expand on Nathan's comment, here are two steps you can take to troubleshoot:
Enter your URI straight into a browser to see the results that are returned, and inspect them for being proper XML. As Nathan points out, your URIs are returning JSON which will be ignored by the tile update manager. As a working example (that I use in Chapter 13 of my HTML/JS book), try http://programmingwin8-js-ch13-hellotiles.azurewebsites.net/Default.cshtml.
If you feel that your URI is returning proper XML, try it in the Push and Periodic Notifications Sample (Scenarios 4 and 5 for tiles and badges). If this works, then the error would be in your app code and not in the service.
Do note that StartPeriodicUpdate[Batch] will send a request to the service right away, rather than waiting for the first interval to pass.
Also, if you think that you might have a problem with the service, it's possible to step through its code using Visual Studio Express for Web running on the localhost, when the app is also running inside Visual Studio Express for Win8 (where localhost is enabled).
.Kraig
I have a problem with WCF. My testing code is pretty simple.
I call a service layer method on my server from my silverlight application and print the result in a textbox.
Everything of this is surrounded by try-catch.
When my service layer method simply returns a constantly defined string there seems to be no problems - however as soon as it calls a more complex method it fails.
While debugging it does not even reach the complex model method; it fails before that inside some auto-generated code from microsoft:
/WuSIQ.jpg
As the error message "NotFound" is not exactly the most helpful or specific you can imagine my trouble googling for hints.
I thought maybe the auto-generated code could only send simple data so I made a temporary string and returned that, but this did not help.
I have already: a client access policy, a service reference added, removed duplicate reference in ServiceReferences.ClientConfig and a ServiceLayer.svc.cs.
I am debugging by running from the main window and my breakpoints are picked up.
Anyone?
I had some errors in the server side method that were quickly found after debugging was fixed.
I fixed this, as I said in comments, setting the project to have "Multiple Startup Projects".
Whenever I had troubles with updating the WCF service methods one of these usually solved it all:
1 Delete all bin and obj folders (specifically selecting re-build might do the same).
2 The servicelayer will not succesfully auto-update (but will work!) unless this:
[ServiceContract(Namespace = "")]
... is set to this:
[ServiceContract(Namespace = "YourServiceLayerName")]
3 Right clicking on the servicereference and selecting "update...".
Sometimes it would stop debugging again, but a forced full re-build would return it to normal.
I hope this helps someone.
I'm working on a site and to help catch errors that we may not hear about, I've created a custom 500 error page.
This page basically records information about the current situation and logs it including the following:
Request.Servervariables("URL")
But, the log seem to actually be providing information about the location of the error.asp file instead of the actual file causing the error. And it doesn't seem to pick up Server.GetLastError().
Any ideas on how to ensure these scripts pick up the errors and deatils about the page causing the error and not the page that is used for 500 errors?
NOTE: When there's an error, the url in the address bar is always the address fo the page causing the error, but the log shows the error handler page 'error.asp'.
I would follow what Dee said, but also be aware that there was something finicky with IIS7 (or 7.5). I can't remember exactly, but you have to do something special to make sure it works on IIS7. Check out this article. IIS7 breaks the server.getlasterror and there is a workaround provided.
Also a cool thing to do is to email yourself those errors. So in your custom 500 asp script just fire off an email with the details. Depends on how critical errors are to your program, but it's good to be in the loop rather than have another log to worry about.
We have a custom exception handling behaviour (implementing IErrorHandler) in our solution which essentially uses Automapper to convert exceptions to faults.
This has been working well since day 1. However we have just noticed while browsing ServiceTraceViewer (looking at server logs - not client) on our shared development server that any faults returned from our services omit the detail element.
Running exactly the same code and configuration on my development machine, the detail element is correctly populated. As I say configuration files (behaviours, bindings) are identical on both machines. Both configurations do specify includeExceptiondetailsInFaults = true.
I've also added a bunch of log statements that seem to indicate that the same code path is followed on both machines with the same values for various things like fault code, fault reason etc.
My dev machine is 2008R2 standard (64bit). The server in question is also 2008R2 Standard (64 bit).
I can post extracts of the code if required, but in the first instance is there anything environmental that could allow for what we're seeing?
Extract from problem file:
<s:Body u:Id="_1">
<s:Fault>
<s:Code>
<s:Value>s:Sender</s:Value>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-NZ">An error occured during the request to the ...</s:Text>
</s:Reason>
</s:Fault>
</s:Body>
Not 100% sure about etiquette here. This is an answer I guess to my specific brand of stupidity. Maybe somebody else will be as stupid, then the answer applies to them...
I was sure I had compared everything (I stated exactly the same code / configuration). But the behaviour configuration file I just gave a quick visual. After another developer approached me I realised that the local files were NOT the same as the server files. Doh!
In fact the server files had one extra line added by a post build step - triggering another custom behaviour which implemented IErrorHandler in addition to the IErrorHandler behaviour we already use for logging etc.
I guess I'm going to open another question now which seeks an answer to the approach on having multiple behaviours implementing the same interface and not polluting eachothers functionality (like returning Faults).