About Me

Anjum Ara I am a technology enthusiast, an ardent reader. My latest interest is virtualization. In my free time, I love understanding child nutrition, child holistic development. I bake, read, paint, and do whatever it takes to improve myself every day.

Saturday, November 15, 2014

ORABPEL-05002

ORABPEL-05002
ERROR:

Message handle error.
error while attempting to process the message "com.collaxa.cube.engine.dispatch.message.instance.ExpirationMessage"; the reported exception is: Fault not handled.
failure to handle a fault thrown from a scope, by any blocks in the scope chain.
This exception occurred because the fault thrown in the BPEL flow was not handled by any fault handlers and reached the top-level scope.
A top-level fault handler should be added to the flow to handle faults not caught from within the flow.

This error contained an exception thrown by the message handler.
Check the exception trace in the log (with logging level set to debug mode).

    at com.collaxa.cube.engine.dispatch.DispatchHelper.handleMessage(DispatchHelper.java:238)
    at com.collaxa.cube.engine.dispatch.BaseDispatchTask.process(BaseDispatchTask.java:89)
    at com.collaxa.cube.engine.dispatch.BaseDispatchTask.run(BaseDispatchTask.java:66)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:909)
    at com.collaxa.cube.engine.dispatch.Dispatcher$ContextCapturingThreadFactory$2.run(Dispatcher.java:933)
    at java.lang.Thread.run(Thread.java:662)

]]

Issue detected:
Unable to reach FCM/ARM through workspace .



 
Solution thought process:

Tried many things like adding protocol handlers to setsvcdomain.cmd  but it was of no use in my case.

I read it on one the threads in Oracle Community that they purged tables and it started.
How I came to conclusion which table should be purged.
If the errror talks about  "cube.engine" then it has something to do with SOA tables. In my environment there were 3 soainfra schemas viz DEV_SOAINFRA , DEV1_SOAINFRA, DRM_SOAINFRA.
I went to each schema and saw the tables and it had 3 tables related to CUBE as shown below


and reach data for all schemas DEV_SOAINFRA, DEV1_SOAINFRA and DRM_SOAINFRA only DEV1_SOAINFRA had data entered for yesterday. Hence I concluded that this is my schema.
-------------
Final Solution:

1. Took a backup of entire schema DEV1_SOAINFRA
2. Truncated data from CUBE_INSTANCE, CUBE_PROCESS_BREAKPOINT, CUBE_SCOPE
Restarted the SOA_SERVER1 managed service and it started without an issue.

Waiting the application users to report any error in case they find due to purging of tables.

ARM/FCM was reachable now




Share:

0 comments: