1 2 Previous Next 17 Replies Latest reply: Aug 19, 2014 3:48 PM by Vlad Dyuzhev RSS

    OSB Split Join Error Handling

    Kartik Kamarajugadda



      I am tyring to capture JCA error's in my split join error handler- catchall. When exception occurs it is going into CatchAll block but there soapFaultVar(say) is always empty.


      I am not able to capture either Error code or error description.


      Please help.

        • 1. Re: OSB Split Join Error Handling
          Kartik Kamarajugadda

          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.

          • 2. Re: OSB Split Join Error Handling
            Ankit kalanoria

            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.




            • 3. Re: OSB Split Join Error Handling
              Kartik Kamarajugadda

              Thanks Ankit. Let me try this and I'll update.

              • 4. Re: OSB Split Join Error Handling
                Kartik Kamarajugadda

                @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...

                fn:concat(data($soapFault/soapenv:Fault/faultcode), data($soapFault/soap:Fault/soap:Detail))


                Could you send the xpath with concat funtion. I guess I am missing something.

                • 5. Re: OSB Split Join Error Handling
                  Ankit kalanoria

                  Hi Kartik,


                  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.




                  • 6. Re: OSB Split Join Error Handling
                    Vlad Dyuzhev

                    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?




                    • 7. Re: OSB Split Join Error Handling
                      Ankit kalanoria

                      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.




                      • 8. Re: OSB Split Join Error Handling


                        Which version of OSB are you using? Is it 12c ?

                        • 9. Re: OSB Split Join Error Handling


                          See if it solves by adding a local reply action attached to the Error Handler?

                          10 Improving Service Performance with Split-Join (12c Release 1 (12.1.3))    ->  see 10.4.2 How to Configure a Reply

                          • 10. Re: OSB Split Join Error Handling
                            Kartik Kamarajugadda

                            @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.


                            Thanks everyone..!!

                            • 12. Re: OSB Split Join Error Handling
                              Kartik Kamarajugadda

                              The issue is not to end a flow properly but to capture faultdetails. In this post we are discussing on capturing non-soap faults.

                              • 13. Re: OSB Split Join Error Handling
                                Dimitri Laloue-Oracle

                                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.

                                • 14. Re: OSB Split Join Error Handling
                                  Kartik Kamarajugadda

                                  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.

                                  1 2 Previous Next