I have a two part question:

Currently we don't have access to our production configuration so I can't verify some of the anticipated behaviour of our application using the simulator. Our solution will interface with AES using the CTI conector provided through DD.

When a call initially arrives to our application we execute a CTICallinfo node to retrieve the ANI, DNIS and UCID.

Question Part #1:

How can we determine from our application that the request to the AES was successful? Should we place the CTICallinfo node in a Try Catch bpock to capture any issues with the application retrieving call infomation form the AES?

Question Part #2

The solution will use H323 signaling protocol. In the event the request to the CTI connector to request call information from the AES fails can our application get the ANI, DNIS and UCID from the initial HTTP request to our application? Is the ANI, DNIS, and UCID sent as HTTP parameters? If the information is part of the initial application HTTP request how can we access this information from the application? Is there a node that will retrieve the HTTP parameters and make them available to the application?

Thanks

By default, the application will perform the CTICallInfo request and will populate your cticallinfo variable for you when the call arrives. If this fails, it will throw a runtime exception that you should catch in your approot. If you want to manually peform this call let me know and I can give you details, however manually performing it is not recommended unless you have a reason to do it.

The ANI,DNIS and UCID will be populated in your session variable when the application starts up. You don't have to do any steps.

Neil

Thanks for the details. The Dev Guide Doc gives the impression we need to follow the aproach we implmented or at least that is how we understood he appraoch.

Just to confirm my understanding the cticallinfo variable will be set at call start so no need to execute our appraoch.

Question: We simply need to add a cath to the approot
that would tell us that the CTI connector
had an issue?

Question: Can you provide the exception that we would
receive for this failure?

Question: Is this a unique exception that when it is
caught we can be sure it is related to the CTI
connector failing to get cticallinfo?

Question: If we receive this exception can the
application retrieve the calll info from
anywhere else? Ex: Intial url parameters,
or will the application not be able to resolve
the ANI, DNIS and UCID if the AES
interface fails.

Q1 - Yes, catch error.runtime. However, error.runtime is a common error, so once you catch it, you might want to check your cticallinfo to see if it has a valid callid (greater then 0). If it doesn't then you know something went wrong with it.

Q2 - see Q1

Q3 - see Q1

Q4 - You can check the session variable. It's going to depend on why the failure occurred, but just because CTI failed, doesn't mean the Session won't have the data.

Neil

Thank You for the details. I thought about the exception scenario a little more last night and want to clear up one thought I had. Since our app is installed on a WebSphere Application Server (WAS) and the CTI connector is also installed on the WAS why would the applicaiton not received an excepption on the WAS where the connector is running to get the callino data from the AES? Why is the CTI connector exception received at the browser on te MPP, and not at the WAS layer?

Q4 - Additional detail. If the CTI connector throws an
exception. and th callid length is <=0 an the
ANI, DNIS, and CALLID be retrieved from anywhere
else under that failure condition?

Thanks for your time and help

The browser is invoking the app and expecting a successful response. If the CTICallInfo fails, then the response back to the browser indicates a runtime error which causes the browser to then execute the catch code (error.runtime) that is contained in the app root. Note that approot is like a global node. If you didn't supply your own error.runtime handler in approot, then the MPP will use the default error handler it has internally which will play a message indicating a problem (unless you have tweaked the MPP's default handler).

The reasons for the CTIC not to gather the callinfo are varied and don't necessarily have a significance on what is passed in the session. You could lose the connection the CTIC has to the AES, you could have improper CTIC settings, the CTIC may not have an observer on the given line. Those are all isolated to issues the CTIC may have which has no impact on what is passed in to the session. Your best bet is to always fall back on session data and if you find both CTIC and session data don't have any information it's a safe bet there is something wrong at the telephony level.

To confirm my understanding:
My application begins with the the following flow:

AppRoot -> DataNode->AnnounceNode .. etc etc

At application start on the WebSphere Application Server (WAS) if there is an exception while the AES is retrieving the cticallinfo the exception will be thrown before the DataNode listed above is executed. This exception will be caught by the Catch "error.runtime" I define in the RootApp. The RootApp will then submit to the RTExcep.flow file defined in the app. The RTExcep.flow will look at the cticallinfo.ucid field to determine that the length of the ucid is <=0 which would indicate that AES was not able to retrieve the cticallinfo.

The RTExcep.flow would then want to access the session.ani, session,dnis, and session.ucid and then process the call as normal.

Q1: Is my understanding describd above accurate?

Q2: When the AES attempts to retrieve the cticallifno
and fails causing the "error.runtime" exception
I assume the AES will not attempt to retrieve this
information again for this call. I want to be sure
there is not a loop conition when control
returns to the RTExcep.flow from he RootApp.

Note: We will set a control flag in the RTEcep.flow
to identify that the first instance of the "error.runime"
exception was previously caught, and subsequent
"error.runtime" exceptions will result
in a blind transfer.


Q3: Under the AES exception being discussed the
complex varaible "session" is the correct place to
retrieve the call info if the AES access fails?

Thanks

Q1. yes

Q2. No retry, so no loop condition

Q3. yes