As we discussed in a previous post, we can make code in different areas of the Application Composer.
However, when will the code we make, actually going to run?
So to answer this lets start with the most common place where scripting is done, Triggers.
Triggers
Triggers are categorized in Object Level Triggers and Field Level Triggers.
Object Level Triggers
-this triggers fire when things happen at the object level.
This are the Types of Object Level Triggers that you can create:
- After Create: Fires when a new instance of an object is created. Use to assign programmatic default values to one or more fields in the object.
- Before Modify: Fires when the end-user first modifies a persistent field in an existing, queried row.
- Before Invalidate: Fires on an existing object when its first persistent field is modified. Fires on a valid parent object when a child row is created, removed, or modified.
- Before Remove: Fires when an attempt is made to delete an object. Returning false stops the row from being deleted and displays the optional trigger error message.
- Before Insert in Database: Fires before a new object is inserted into the database.
- After Insert in Database: Fires after a new object is inserted into the database.
- Before Update in Database: Fires before an existing object is modified in the database.
- After Update in Database: Fires after an existing object is modified in the database.
- Before Delete in Database: Fires before an existing object is deleted from the database.
- After Delete in Database: Fires after an existing object is deleted from the database.
- Before Commit in Database: Fires before the change pending for the current object (insert, update, delete) is made permanent in the current transaction.
- After Commit in Database: Fires after the change pending for the current object (insert, update, delete) is made permanent in the current transaction.
- Before Rollback in Database: Fires before the change pending for the current object (insert, update, delete) is rolled back.
- After Rollback in Database: Fires after the change pending for the current object (insert, update, delete) is rolled back.
Field Triggers
– this triggers execute when a field has its value changed without pressing save button.
Validation Rules
An object-level validation rule is a constraint you can define on any standard or custom object. It is evaluated whenever the framework attempts to validate the object.
This can occur upon submitting changes in a web form, when navigating from one row to another, as well as when changes to an object are saved. Use object-level rules to enforce conditions that depend on two or more fields in the object.
This ensures that regardless of the order in which the user assigns the values, the rule will be consistently enforced
https://docs.oracle.com/cd/E48434_01/fusionapps.1118/e49548/F1071033AN1FBCA.htm
A field-level validation rule is a constraint you can define on any standard or custom field. It is evaluated whenever the corresponding field’s value is set. When the rule executes, the field’s value has not been assigned yet and your rule acts as a gatekeeper to its successful assignment.
source: Oracle Fusion CRM Application Composer Scripting Guide
Custom Button
From Actions and Links you can create your own buttons with code behind them.
As you can imagine the code you write for the button will execute upon clicking the button
However there is 1 case when you will press the button you made but you wont see any results or effects, that is because the code probably needs to commit some actions to the database.
And that happens only after pressing save button
For example if you create a button that will create a copy of an record of a opportunity via pure groovy scripting(by that I mean we don’t use web-services in our code, as web-services autonomic to the database)
So you p[res the button and code to make the copy record executes, but you wont see that copy until you click save button, only then the transactions are pushed to the database and the copy of the record will appear in the UI.
Object Workflow
Object workflow fire when their conditions on the event points are met.
As there are only 2 possibilities create new record and update a record, that is when the code in the conditions will execute.
Required/Updateble Field Condition
The code of this condition executes/is evaluated when the depending field changes its value or when save button is push
It all depends on the logic of the condition code.
Usually if you have a script that cheeks if a field has changed its value, then this will execute only when a depending field is set, and that field actually changes its value.
But if you have a condition that checks for a particular value then this could also execute when save button is press
So all depends on the scrip set on this conditions.
Expression from Default Values on a field
This code will execute when creating the record, as this is the initial value that the field will display.
The code will execute upon record creation even if that field is not displayed on the creation page and only on details.
Expression from the mapping of Lead to Opportunity and Deal Registration to Opportunity conversion.
As its position is in the map used for conversion, this executes the moment we convert Leads to Opportunities or Deal Registrations to Opportunities.
Now lets take an Example on how the above works.
I have used the triggers above on the Opportunity Object.
In the table below you will see the actions done in the UI and the corresponding triggers that fire when those actions are done:
