Is there any drawback to writing a rule in IIQ that creates an object from a Java class and calls a method? Or is it preferrable to write a rule in Beanshell only?
I write all of my rule logic in Java and create unit tests, so it seems inefficient to copy the code over into a rule and adjust the code to make it work in Beanshell.
Any thoughts or experiences anyone can share?
Ask 10 IIQ developers this question and you will get 15 answers 
My personal approach is to always start in Beanshell, but to write java compliant code while doing do. It is much easier to rapidly develop in Beanshell (no compilation needed, no need to redeploy jar files, etc). If I find I’m writing the same code more than once, I move it to a rule library. Once it is stabilized, if it is code that is not likely to be updated in the future and/or code where performance is critical, I will move it to a java class and just invoke that from the rule. I’ll also point out that Beanshell is lacking many of the features of later IIQ supported Java versions, so if you want to use streams for example, you will need to use compiled code.
For unit testing Beanshell code, check out Unit Test SailPoint Rule - Compass
I agree with @markearnest writing the code directly in Beanshell is much more convenient as you do not need to compile every time you make any changes to java. Also if you really want to make your code re-usable you can get this done by creating a ruleLiberary.
I recommend to write standalone java code only if its absolutely necessary.
I concur with the group’s opinion that using BeanShell is the preferred approach, both for deployment , ease of troubleshooting and many more advantages, unless it cannot deliver the required functionality, in which case you may need to write a Java class.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.