Plugins VS Rules/RuleLibraries

Which IIQ version are you inquiring about?

8.4 P1

Please share any images or screenshots, if relevant.

Not relevant

Please share any other relevant files that may be required (for example, logs).

Not relevant

Share all details about your problem, including any error messages you may have received.

Hi,
I’m currently working on refactoring the entire code that’s been previously deployed in our environment in order to make it more efficient, flexible and granular so that it is easier to maintain and scale and reuse.

Whilst I’m at it, I’m working on developing our CI/CD pipeline so that the builds are automated; the code is scanned in our SAST/SCA tool, etc…

I realized that some tools are having issues properly scanning the Beanshell code that’s imbedded in XML so I’m extracting it beforehand but the results are still so so…

That brings me to one big question I’ve been asking myself since a little while now… Ever since version 8.0, we have the possibility to expose classes in Plugins and I’ve been asking myself if using plugins rather than RuleLibraries wouldn’t be “better”?

The way I see it:

  • Since the plugins are compiled rather than interpreted, it might be a bit more efficient.
  • It’ll make the automatic deployments easier
  • It’ll make the SAST/SCA scans easier and more efficient
  • I believe it’ll also make some of the automatic “Fail fast” tests easier to implement
  • It’ll make code in the “rules” easier to follow as you won’t need to put a ruleLibrary in the reference section of the Rules but, rather, import the exposed class just like you’d do for any Java package.
  • On the same note, instead of importing an entire RuleLibrary, you may import a single class or a singe method

I know that using a plugin approach will also require a little bit of overhead since you have to do the manifest files and all so there will be a little bit of overhead but, overall, I believe it’d be much more beneficial than using RuleLibraries especially for “big libraries”

The other thing I can think of is the tokenization that takes place in the <ENV>.target.properties that might be lost but would probably not be a big thing to implement at the Plugin Level.

What are your thoughts? Any Pros or Cons or limitations?

Hi @mobrodeur,

on my advise, everything depends on the complexity of your enviroment. Let me explain better: on IIQ you can have various level of complexity where you can use only the standard funcion or deploy entire library.
Also, plugins are use to implent new funcionality or pages thare arent into the enviroment. So, I don’t see any advantages in convert the libraries into plugins.

That said, if you need a lot of plugins maybe you can evaluate the conversion. But, about the performance, its better invest time on optimize the code on rule\methods, especially on the rules that will be runned thousands of times like aggregations and refresh rules or optimize the JVM. You can save a lot of time of execution using the properly funcion or review the logic of code, respect to use a plugin(and I am not sure that a plugin is more efficient respect rules).

If you a bad code, it will inefficient in every case.

About CI\CD in general, its a little bit difficult respect a standard project because, like you say, in IIQ you have mixed XML-JAVA files and you dont a classic java structure like Maven. On my experience I didnt find a project that it was worth implementing to implent a devops structure because the 90% the code that you can write is more like a script ionstead a real program and following a class-based struncture, most of the time, is inefficient and unuseful.

For example, in this moment I am reviewing the entire code of enviroment, like you, where I lost 2 weeks to understand what the code did. At the end, I undestard to refill a formField value, are called 3 RuleLibraries and 4 fuonctions foreach methods. Beatifull and genial but totally unuseful in IIQ.

At least, evaluate everything, what you need, which is the best way and the cost of maintaince of code. Think if you or another person in one or two years, needs to review your code how would you better understand what the code needs to do.

1 Like

Hi Emanuele,

thank you for your feedback, I really appreciate it! I’ll keep on evaluating the needs to migrate our RuleLibrarire into Plugins (vs keeping them into actual RuleLibraries and just refactor them). I’ll consider the points you mentioned in my evaluation.

Thanks again!

1 Like

PS you can also deploy your code in jar file and put into lib folder, with you have the compiled code and its more maintainable than a plugin

1 Like

Agreed!

I thought/am thinking about that as well. It was, actually, the first thing I considered. The two things that “bugs me” a little about that approach (and it’s really not that big of a deal but still something to consider) are that:

  1. A restart of the Tomcat service (or, at the very least, a reload of the IIQ “site” in Tomcat) is required
  2. We need to make sure to deploy the lib on each servers**

Those things aren’t that big of a deal, especially given we’ll have a proper CI/CD pipeline that will take care to deploy the file(s) and send the restart command/check to ensure integrity across all the nodes.

At this point, both are actually still on the table; I just need to evaluate the pros/cons of using a lib vs a plugin with exposed classes.

** Despite having a CI/CD Pipeline that would take care of the deployment of the files on all the servers, I’ll need to think about the strategy for our DR environment (those servers are shutdown – they are only being booted up automatically for patching purposes and then, re-shutdown.) That’s, actually, another reason why the plugin approach sounded a tad bit more interesting (despite the overhead it may create) since they’re are stored in the database.

Thank you very much for the suggestion though; I appreciate it!

yes, you have to consider everything.
About the first point, tomcat needs 5-20 second to restart, about me its not a big problem. The second point its the most annoying one but if you have a pipeline that doing it, its perfect.

Effectively, deploy one time respect x times its better.

Very important for this decision is “how many times you need deploy a new version”?
I dont know the configuration of you env, but if have 16 servers and you deploy everyweek maybe plugin solution can be advantageous.

You also need to consider whether installing this type of solution will bring you any advantages. I’m not saying your project is useful, but I personally prefer simple things.
WIth iiq plugin for vscode, git and ssb I managed a very complex projects without loosing the control on version\code.

1 Like

I do agree with you that it would be very simple to use the IIQ Plugin for VSCode to automate the deployment!

The CI/CD pipeline; the code scanning and the automatic-deployment is actually a requirement from our governance and compliance team due the audits the company has to go through on an annual basis. Everything needs to be logged with trace and link to a change that went through an approval process, etc…

At the moment, I foresee many deployments (at least twice a month for the next few years) as we have tons of enhancements/additions to do (the current implementation of IIQ is very limited but the business requirements are very large.)

One of my main goal (which is also a requirement from the governance) for all the automation is so that accesses to the Production Servers will be extremely limited and no-one should connect unless there’s an emergency or something that requires access to the server that can’t or isn’t yet automated; everything else should/will be automated.

The Production instance of SailPoint might, as well, become very locked down so that manual changes can’t be performed directly on the prod. instance unless there’s a ticket logged in our system and privileged access are granted temporarily (and logged).

Maybe that context will put a bit of perspective on why I’m leaning towards using plugins VS JAR Libraries.

Each has their own Pros and Cons.

After my vacation, I’ll be performing some tests using Plugins and will evaluate how much overhead they’re creating VS their benefits.

If you’re interested, I can keep you posted on the evolution of the plugin tests and the automation of everything.

We offer a DevOps service container that can do code checks, vulnerability checks, linting, automated testing and even UI testing with the ability to record snapshots of screens for audit purposes. Happy to demo this for you: IIDOps - Instrumental Identity
With regards to beanshell vs plugins you are probably better off just using java classes withing your src folder of your SSB. While you can leverages plugin classes in rules you may run into classloader issues if you are hot deploying. We have also done some presentations on our CI/CD process on Developer Days.

Hi @mobrodeur ,

Probably from the performance perspective and Code scan etc , You can move the code of the Rules in Java Classes , And Just call the methods in Rules .
And in your CI/CD pipeline you can integrate the code scan tools like sonarlint etc whatever you want to use . And Scan the Java Classes .
Let me tell you one thing , it is kinda big project , Probably you can start Using this practice on new implementation and take the old implementation phase wise .
If you are gonna use the Java Classes , You would have to restart the service for every change on these classes . Definitely it is gonna improve performance on long run if you have a large scale implementation.