Hi,
well, I can't think of any good reason why you need this at all. I mean, it's a simple stored procedure being called, so nothing special - I was expecting some complicated calculations in Java. But all your custom code does is this: reads a string named callerinput, and calls a function which in turn returns one number (Float type).
How much did your company pay for this?
Anyway, a few things to consider:
1. A connection is created each and every time this is called. And I see they are not closed (what I'm missing is conn.close(), I would proably insert a finally block, and close the connection there). Not nice, eats up resources slowly.
2. A function can be called within a SELECT statement - so unless you have an unsupported version of Oracle, you don't need such "scaffolding".
3. The JDBC URL is "jdbc:oracle:thin:@sdorapsardev01:1521:ardev91", sdorapsardev01 is the server hostname - are you sure it's resolvable all the time? Would be safer to either use FQDN's or IP addresses.
So in my humble opinion, you may want to talk to whoever manages your database and ask him/her the following: create a view that calls this function. Then integrate UCCX the standard way - this would give you safer access, like pooled connections. And also, you'll be able to use the standard DB Read/Get/Release steps.
G.
Attached is the custom file, I only know its not working from testing it, I cannot verify it is even trying to work. The return on a known good account is simply no data or basically a bad response.. My dba's say it is not possible/feasible to determine whether the uccx oracle database user is trying to logon or not..