This content has been marked as final. Show 9 replies
1.) If the default behaviour of CompositeJavaAction is rethrow, why aia-ora-java comes with 5 return values viz. REPLAY, RETHROW, ABORT, RETRY, MANUAL? To me it looks there is no way by which I can return a value from CompositeJavaAction directly. Has it been like this so that I can extend this class in my custom java action handlerand use that further? Or is there any situation in which CompositeJavaAction will return other than RETHROW?
You are right, the default value is always RETHROW, and in case someone wants to customize the action, they can change the default action.
2.) For remoteFaults I want to allow humanIntervention. How should I do that provided AIA notifications and logging remain unaffected. In other words, if I enable humanIntervention by specifying the explicit fault condition, CompositeJavaAction will never execute and hence no default notification and no logging will occur. How can I enable both?
You can choose only one action at a time to handle the fault. And so if you choose to use java action, then you cannot use humanIntervention @ the same time. If your goal is only to use human Intervention along with the java action, then in FP its already available - if you enable HWF (Human Work Flow) in AIAConfigurationProperties.xml file, then you get the workflow enabled which is a human intervention.
Thanks for your reply but I have few more doubts related to your answers.
You are right, the default value is always RETHROW, and in case someone wants to customize the action, they can change the default action.*
I thought changing the default-action is not recommended at all. AIA Fault Management Behavior When the No. of Instance Retries is Exceeded
Also what about the other values it returns, when they can be used if return values is always RETHROW. Even default-action will not be executed in any case as the return value from the Java action is RETHROW.
And so if you choose to use java action, then you cannot use humanIntervention @ the same time*
This is what I want as I would like that AIA Java action does what it wants to do and then should render the process as recoverable manually.
if you enable HWF (Human Work Flow) in AIAConfigurationProperties.xml file, then you get the workflow enabled which is a human intervention.*
I have tried setting HWF as true in AIAConfigurationProperties.xml. It works. This just adds another task but doesn't give me any operations such as RETRY/RESUBMIT etc there. I'd like that in case a remoteFault is encountered in the process, AIA error handling is done and then it should be humanly recoverable from FMW Console or Worklist, whatever. Is it possible somehow using the HWF option?
Even if you achieve the humanIntervention option using the fault policy, its not recommended to retry from that point using the em since the message should always be resubmitted from the source milestone and not from the middle of the milestone.
The option to resubmit is not yet there in HWF that comes with FP. Depending on the usecase one can extend it further to add Resubmit as another possible action and call the resubmission tool api thats already available with FP.
I have a use-case both for runtime/business faults where I need to provide the humanIntervention. If I just write </humanIntervention> for remote fault in fault policy, AIA error logging and notification will never get triggered. Hence the person will never be informed about the error. Hence I'd like to control that from the CompositeJavaAction as I can see that there is MANUAL return option provided by this.
How should I go ahead to accomplish this?
Shall I write my own custom Java Handler that extends the existing CompositeJavaAction and return the value MANUAL from there?
Is it recommended to extend this CompositeJavaAction? If yes, can you point towards the steps to achieve that?
Yes, for now you can do this minimal thing.
public class NewCompositeJavaAction extends CompositeJavaAction
public String handleFault(IFaultRecoveryContext iCompositeFaultRecoveryContext)
//Based on some logic return the interested DEFAULT ACTION...
That way your changes will be minimal and even if a new version is shipped in future by FP, you should be fairly safe.
I am planning to customise AIA 2.5 Error handling process AIAErrorTaskAdministration process to receive custom action from Human work flow and perform re-submit from AIAErrorTaskAdministration process. I came across JAVA API in the developer's guide that i can use to do this customization.
I want to know if any one tried this in the past had luck to see Re-submission of message working fine. Please let me know.
You can use the following to do resubmission
You can call oracle.apps.aia.core.eh.resubmit.util.AIAEHResubmissionUtil main method with the following arguments
<QUEUE/TOPIC/RESEQUENCER - 1/2/3>
Ex: oracle.apps.aia.core.eh.resubmit.util.AIAEHResubmissionUtil.main("oracle.jdbc.driver.OracleDriver","jdbc:oracle:thin:@testServer:1521:XE","aia", "aia","1","IP_IN_QUEUE","123456","IP_QTAB");
I know your post is one year old but just trying to help people facing the same issue in the future.
I had the same problem: wanting to call the aia java class CompositeJavaAction so the logging into the AIA error topic is done but then I wanted human intervention after so the recovery can be performed manually from the Enterprise Manager.
There is an easier solution in case you just want to use the action you want after executing CompositeJavaAction, which is just commenting the RETHROW returnValue element:
<javaAction className="oracle.apps.aia.core.eh.CompositeJavaAction" defaultAction="ora-human-intervention">
<returnValue value="REPLAY" ref="ora-terminate"/>
<!--returnValue value="RETHROW" ref="ora-rethrow-fault"/-->
<returnValue value="ABORT" ref="ora-terminate"/>
<returnValue value="RETRY" ref="csm-ora-retry"/>
<returnValue value="MANUAL" ref="ora-human-intervention"/>
Since CompositeJavaAction returns always RETHROW, in case it cannot find any returnValue that matches it, the defaultAction will be used.
So we manage to have human intervention after aia logging without any special programming, just modifying the fault policy.