We are implementing a new security package that will be referenced by all of our applications as a central repository for permissions and user account data. This package will sit along side and interface with our LDAP repository. We created a custom Java SSO that all of the applications go through to get the permissions etc. When we invoked a method from PROIV to get the permissions we received the following error.
I am providing the verbiage that one of our Java developers (that solved the issue) provided me in the hopes that if you experience a similar issue then you will have a reference. We gave him a medal for resolving this one
When PROIV loads an SSO jar, it does so in a class loader which is a child of
the application/system class loader. This causes the use of Spring LDAP to
result in a class cast exception from com.sun.jndi.ldap.LdapCtx to
org.springframework.ldap.core.DirContextOperations. This happens because the
Java JNDI classes use the Thread Context Class Loader (TCCL) to load object
factories used as part of a JNDI lookup. Since the Thread Context Class Loader
defaults to the application/system class loader, and the application/system
class loader does not contain the Spring LDAP classes (they are included in the
child class loader), the appropriate Spring object factory is not loaded. The
current solution is to, within the SSO, set the TCCL to the current class
loader (the class loader for the current class) which includes the Spring LDAP
Anyone seen instances where sub-directories are created in the working directory that have the name of core_xxxxx (where xxxxx) is a four or five digit number. The directories themselves are empty. We are running Linux.
This caught me out today as I was using a table variable in my bind. The rounded value was subsequently written back to the open table. Dohhhh.
When using SQL to get a count of record back using the BEGIN, END statements be warned that any numeric variable passed in will be rounded removing any precision after the decimal point after the execution of the statement. Note the SQL will honor the full precision for a variable being passed in.
For example the following policy does have an INV_AMT of 318.01, so the following should return back a #COUNT of 1, however what it also does is change the value of #TEST from 318.01 to 318.00.
#TEST = 318.01
SELECT COUNT(*) INTO :#COUNT FROM INV_PBINV_TBL
WHERE INV_POLICY_ID = '8000255370' AND INV_AMT = :#TEST;
We rolled out a new project today and I thought it may be enlightening to share with you one of the features we used, namely the SQL DYNAMIC feature,
We have a corporate diary that we are using more and more as a workflow engine. One of the requirements of the project was to allow end users to create 'filters' that allowed them to define the selection criteria they wished to employ. It was a good example of the use of the dynamic SQL feature within PROIV. We basically build a SQL statement on the fly from the parameters that are defined by the end user. Simple but effective. To get some additional performance we also introduced a view to join the various Oracle tables that were being referenced. This was purely to increase the speed of the display to the grid. I have attached some screen shots.