Thanks Wilson,
I tried as you suggested and indeed setting the sage autoinvoke property to false prevents the automatic uncatchable exception.
Only issue is that for a clean solution, would prefer to put the CTI code in initial node of the flow and also in custom code section (override requestBegin).
When I add in the actual CTICallInfo node in the editor, it does properly add in the appropriate code to the executeDataActions of the underlying Java. However, this code as you know executes
after the requestBegin method, for which it is too late.
If I try and extract this code and put it in the requestBegin override method instead so that it populates CTI info right away when needed, it does nothing at all. This is my code in requestBegin:
try {
//{{START:CODEGEN:EXTENSIONPOINT:com.avaya.sce.cti.ui.callInfo
com.avaya.sce.runtime.connectivity.cti.CTIOpFactory.createCallInfoInitialCallOperation(mySession);
//}}END:CODEGEN:EXTENSIONPOINT:com.avaya.sce.cti.ui.callInfo
mySession.getTraceOutput().writeln(ITraceInfo.TRACE_LEVEL_DEBUG, "Successfully retrieved AES Call Info.");
} catch (Throwable t) {
mySession.getTraceOutput().writeln(ITraceInfo.TRACE_LEVEL_DEBUG, "Unable to retrieve AES call Info: " + t.getMessage());
t.printStackTrace();
}
I suspect it is related to the //{{START:CODEGEN:EXTENSIONPOINT:com.avaya.sce.cti.ui.callInfo section which must not be getting evaluated in the requestBegin method. Is there a way to manually overcome this?
Alternatively, I do realize I could create a new node in the flow which only populates the CtiCallInfo variable and then moves onto the next node (which used to be the first), and if I have no other choice I will do this. However trying to keep the solution as clean as possible and so if I can keep this to one node instead that would be preferred.
Thanks.