New Trigger administration and deployment in OpenPages GRC 7.2
Brian Laskey 270003US2W Comments (2) Visits (8808)
As a follow up to my prior post talking about what is new
Multiple Trigger Configuration Files
Prior to 7.2, all custom triggers were defined using the centralized _tri
As before any change to the contents of the xml configuration files, or the setting will only go into effect when your OpenPages services are restarted. At startup the trigger definitions are loaded from the file in the order specified in the Trigger Configuration Files setting. You can view the triggers that have been loaded and in what order from the log files ending in *-startup.log under your <OpenPages Home>/aurora/logs directory.
Separate Standard and Custom Solutions jars
One of the difficulties faced when administering an OpenPages environment was with the task of coordinating the deployment of multiple solutions into a single OpenPages system. All custom class files used for triggers and other extensions were placed in the jar file 'openpages-ext.jar' under <OpenPages Home>/aurora/lib. This problem was compounded by the fact that the standard OpenPages Solutions modules also deployed their trigger files within this jar, which required some work to merge everytime a new trigger class was deployed.
In 7.2 the standard solutions classes are now deployed in a separate jar, the new open
There is an additional feature I will mention here, though it is beyond the scope of this article, that is the Configurable Lifecycle which is a new framework consisting of several new standard triggers and new capability in the Trigger configuration file. In addition the core OpenPages application UI can now display certain 'stages' and 'transitions' based on the Lifecycle trigger definition to the user which allow for automating very simple business processes around GRC Objects such as an approval of an Incident. The Lifecycle is an extension to the current Trigger framework but does not change anything else for existing trigger implementations, in addition any custom triggers can continue to coexist with the Lifecycle triggers if defined although it may matter what the sequence of triggers in your system which can be controlled by the order of the trigger definition in the configuration files as well as the order of the listing of tiles in the new setting.
For more information about Lifecycles see the New
Enforcing Certain Triggers Run Sequentially
Finally a behind the scenes capability has been exposed in the trigger configuration to better handle cases where multiple triggers are fired for different objects but there needs to be some coordination between them. For example if you have a Risk Assessment where the status is updated to be Approved when all children Risks are Approved. If you used the Bulk Update feature for example to update the Risks under the Risk Assessment then even if the triggers fired, the updates to each individual Risk is happening asynchronously and in some cases the result will be that the Risk Assessment was ever updated to 'Approved' due to not all the Risks being approved when any of them were being updated simultaneously. It is now possible to control this behavior and enforce that specific triggers via their Event Handler definition are run serially rather than in parallel to process them one at a time.
To enforce this behavior you will need to modify your GRC Trigger definitions in the trigger configuration files containing the triggers in question. Under the <eventHandler> element for the trigger with a handler that you want to behave sequentially you will add a new attribute called excl
The downside for this is that it constrains the performance somewhat of the bulk update capability in Grid Views (or any other parallel operation for that particular type of event). For more details on this feature please refer to the Trigger Developers Guide.