The Rule Runner plugin allows ad-hoc Beanshell code execution. It is similar to the Debug pages' "Run Rule" feature, but with live syntax checking, simple auto-completion, execution history, and thread safety features.
To run a rule, simply type your code into the source code box and click Run. The rule’s output, whether success or failure, will be added to the Execution results section. Output can be scalar, object, or XML format, each of which render slightly differently.
You may use Rule Library code by selecting them from the dropdown box below the source code entry area. More than one rule library can be selected.
By default, the Run asynchronously feature is enabled. With this feature enabled, each execution will create two background threads: (1) an execution thread to run your Rule and (2) a monitor thread.
The monitor thread is responsible for tracking the progress of the execution thread. It will attempt to kill long-running executions after ten minutes.
With asynchronous execution, any messages logged by the Beanshell script will be returned to the browser, updated every couple seconds. You may also log progress messages and progress percentages using the monitor object, which implements a superset of sailpoint.task.Monitor. These will be relayed in the user interface.
You may also terminate asynchronous execution using the Stop button.
The following checkbox options are available:
-
Include web context variables: If checked, the servlet variables httpRequest and httpResponse, and the IIQ web service context webService are provided to your script. This can be used to debug web session issues. Since this can only run in the context of a web service call, this option is not compatible with asynchronous execution.
-
Include workflow library variables (lint only): If you are writing a workflow library, your code will assume launcher and wfcontext variables exist. This option provides those variables so that those lines don’t cause syntax errors.
-
Ignore type errors that Beanshell allows (lint only): Beanshell provides a superset of Java, allowing some dynamic typing. The Java parser will reject these structures as errors or warnings. This option suppresses those errors.
This project uses Yarn to manage Javascript dependencies. These dependencies are not stored in Git. You will need to install them on first build.
Steps to grab dependencies using Yarn:
-
Install Yarn for your operating system.
-
Check this project out of Git.
-
On a command prompt, navigate to
<project>/ui/js. -
Run
yarn --flatto pull all dependencies.
You will end up with a node_modules directory where Yarn exported all of the dependencies and a bower_components symlinked to somewhere within `node_modules`. Don’t mess with this please.