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).
Related
Currently, I am working with SAP Business One SDK. I took some project from another team. This project is a SOAP web service. It has been written in ASPX technology, anyway another team used standard DI API library. This is the main problem with this solution because it causes a lot of problems with memory leaks.
In source code after every operation when DI API is called I try to use Garbage Collector, but unfortunately, it is not enough.
The web service is hosted on IIS and I had to set an option that for some time restart it. I know it is not the best solution, but it works. Obviously, that way generates many problems.
I have a question about it. Does any reasonable solution exist? Or I will have to rewrite source code using DI Server?
I have read a lot about this, I found some articles on the Internet. Please do not put any links in comments, because I am quite sure that I have read them.
Every time you use a DI API object you have to release it. Otherwise, it will stay in memory and it will cause the memory leak you mentioned.
The correct way to release them is to use ReleaseComObject. Remember that if the object is null you will get an exception so check it first.
if (oDocuments != null)
System.Runtime.InteropServices.Marshal.ReleaseComObject(oDocuments);
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>.
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.
We've found a bug in a program that we bought from another company, which doesn't exist any more. The bug is somehow major, we have to figure out at which module/step the error occurs. We know the tracing data which are simply what the end user types into the program. Is it possible to using WCF to realize such debugging? If it is possible, where could man find some examples?
You can enable service tracing on both the service and client ends:
http://msdn.microsoft.com/en-us/library/ms733025.aspx
UPDATE
It's not that hard. You can find simpler examples than that easily.
http://blogs.msdn.com/b/andreal/archive/2009/03/21/wcf-end-to-end-tracing.aspx
Then you can read the logfiles generated by using SvcTraceViewer.exe
http://msdn.microsoft.com/en-us/library/ms732023.aspx
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)