We have triggers support in ADF 12c! Powerful new feature is available - Entity-Level triggers. Previously it was often confusing if certain use case belongs to validation rule, or it is more generic business logic. Everything was implemented as part of validation rule in the EO. ADF 12c provides cleaner approach by supporting option of Entity-Level triggers, along with regular validation rules. Validation logic can be implemented as part of validation rule, non-validation (but still dependent on data management lifecycle) logic can be implemented as part of new Entity-Level trigger.
ADF 12c EO wizard offers new section - Entity-Level Triggers. Here you can define different triggers, for example - before update, before commit, after insert, before delete, etc.:
This means, you can inject any custom code to be invoked by the framework, during certain event from ADF BC lifecycle.
Wizard allows to select trigger type and define Groovy expression, here you can call any custom method from EO Impl class. However, there is one trick related to expression execution in untrusted mode - I will describe it below (thanks for a hint to Steve Muench):
Custom method is defined in EO Impl class, you can see it here:
If you simply define a trigger and try to test it, you will get an error about not permitted method call:
Trigger expression by default is running in untrusted mode, this means your custom method must be annotated with @AllowUntrustedScriptAccess. If you don't want to annotate, you could change trust mode to trusted for the expression. By default trust mode is set to be untrusted:
Change it to trusted mode:
Trigger should work just fine now. Try to change data and save:
There are two triggers defined - before update and before commit. Both of these triggers are invoked successfully, as you can see from the printed log (right before update and before commit):
ADF 12c EO wizard offers new section - Entity-Level Triggers. Here you can define different triggers, for example - before update, before commit, after insert, before delete, etc.:
This means, you can inject any custom code to be invoked by the framework, during certain event from ADF BC lifecycle.
Wizard allows to select trigger type and define Groovy expression, here you can call any custom method from EO Impl class. However, there is one trick related to expression execution in untrusted mode - I will describe it below (thanks for a hint to Steve Muench):
Custom method is defined in EO Impl class, you can see it here:
If you simply define a trigger and try to test it, you will get an error about not permitted method call:
Trigger expression by default is running in untrusted mode, this means your custom method must be annotated with @AllowUntrustedScriptAccess. If you don't want to annotate, you could change trust mode to trusted for the expression. By default trust mode is set to be untrusted:
Change it to trusted mode:
Trigger should work just fine now. Try to change data and save:
There are two triggers defined - before update and before commit. Both of these triggers are invoked successfully, as you can see from the printed log (right before update and before commit):
Download sample application - ADF12cApp.zip.
This is a great improvement. Thanks for pointing this out.
ReplyDeleteThis new feature is a huge improvement. Jdeveloper gets better and better with every new version. Thanks for the blog post.
ReplyDeleteHi Andrejus ,
ReplyDeleteIs there any way to set this trusted mode once per application instead of changing it per each groovy code snippet.. Thanks.
You can define a custom security policy class that extends oracle.jbo.script.ExprSecurityPolicy then reference that custom policy
ReplyDeletein the ExprSecurityPolicy property of the element in adf-config.xml
for your adf-adfm-config section.