In my SJ, I am using a Invoke activity to update a table. In some cases Incase a JCA exception happens, the details need to be captured. As I undertand you are intending to call business service to update the table from PS which shoul be invoked from SJ. I am not intending to use another PS to just capture the error message. Let me know if I could do this via SJ.
1 person found this helpful
It happened with me as well. When tried logging fault variable defined, it was empty. But when I extracted information by drilling down the xpath structure of fault variable then I was able to get the message.
fn:concat($soapFaultVariableName/Fault/errorCode, $soapFaultVariableName/Fault/Reason, .. so on)
I am just giving snippet above to drill down, you can traverse through xpath editor in variable structure to have correct namespaces and element I wrote above. It was long back when I did this. Hopefully its still same.
When you will see variable structure of defined soapFault in splitJoin catchall, you will observe there are 2 types of Fault structure defined inside. So it might be because we need to give exact xpath of Fault (I convinced myself by thinking something like abstract method of java) which is occurring but I am not sure exactly why this happens.
Thanks Ankit. Let me try this and I'll update.
@Ankit: I tried your soultion but it's not working. I tried with the concat function but the result was empty. Couldn't retrieve any data from fault variable.
I tried with below Xpath, used both faults...
Could you send the xpath with concat funtion. I guess I am missing something.
I am giving you below exact element names which will be there in those 2 fault structures. Just drag and drop these by expanding variable structure for exact xpath and namespaces definition. I am really sorry for not being able to give you exact statement but I have been away from my work system for sometime and don't really have access to my softwares and these things kinda difficult to remember exactly :
Below are the name of elements:
fn:concat($faultVar/.../faultcode, $faultVar/.../faultstring, $faultVar/../code/value, $faultVar/../reason/text)
you can fill these dots with correct xpath when you will drag these into expression builder.
Hope this will help.
I tried it too, and failed.
I tried fn-bea:serialize() and there are just no elements except the parent.
Magically, as soon as I target the request to a intermediary proxy, the fault is fully populated.
I documented it here: http://genericparallel.com/2014/07/split-join-getting-fault-details-in-catchall/
I may try again later, but - are you sure you did not have a call to proxy when you get the fault details?
Vlad Dyuzhev: You are absolutely right. Target service from my split-join is osb proxy itself. Although error handling is in split-join->CatchAll only instead of intermediate proxy service. I think that explains your original theory on going via intermediate proxy as well.
but i am not able to derive a conclusion out of it. Can we say that split-join will require a soapFault in response for catchAll to be able to understand it, no matter target is osb or other system?
If our target service is returning a soapFault in case of error then will a intermediate osb proxy be required? Because only fact so far is that we know that intermediate OSB proxy will wrap any fault into soapFault automatically while replying back and split join is able to understand it.
Conclusion of this thread will surely be helpful for other users in the future.
Which version of OSB are you using? Is it 12c ?
@Ankit: You are correct. In splijoin only the soapFault are being captured. If we are pointing to a proxy, the response is always(success/failure) a soap responce, hence we are able to capture. Capturing other faults is still a mystery here.
I tried your solution wth concat but the result was still nothing. When ever you find time, look into your code and post what exactly is needed to capture non-soap faults.
The issue is not to end a flow properly but to capture faultdetails. In this post we are discussing on capturing non-soap faults.
There are usually 2 different error code paths: exception and faults.
exceptions are thrown on the request path and are not associated with a soap fault. faults correspond to error responses (SOAP Fault for a SOAP service) and are received on the response path.
It is possible that in your use-case, the error happens as an exception on the request path and so no fault response is being receive, which would explain why the SplitJoin soapFaultVar is empty.
One way you could verify this is by using the test console on the target service the splitjoin is invoking by sending the same payload your splitjoin is sending. If the test console is showing a SOAP Fault in the response section, then the error happens on the response path, and the soapFaultVar should have the fault. But if the test console just says the invocation errored and it displays an error message, then the exception happened on the request path and no SOAP fault will be available in the splitjoin.
I think what you say is valid. So in case of exception SplitJoin soapFaultVar is empty. Is there a way to capture fault or splitjoin can only capture soapfaults only. If soapfaults only, then it is a bug and need to contact oracle team for patch.