Oracle Fusion — Sandbox (Application Composer — Server Scripts — Groovy Scripting) — Part2

Greetings, Ardent Oracle Enthusiasts!

Within the confines of this blog post, we shall delve into the realms of Validation and scripting within Application Composer. This empowering tool enables us to intricately shape customizations that cater to unique business requirements.

Application Composer stands as a browser-based configuration tool, uniquely empowering business analysts and administrators — beyond just developers — to extend their applications.

Application Composer supports Groovy, a scripting language, for enhancing applications. You can use Groovy scripts in many different contexts, such as:

• Validation rules: These scripts validate the value of a field or an object. For example, you could write a validation rule to ensure that the value of a quantity field is always positive.
• Triggers: These scripts execute automatically when a specific event occurs, such as when a record is created or updated. You could use a trigger to validate the two date fields.
• Object functions: These scripts are reusable functions that can be used in multiple contexts. For example, you can reuse an object function inside a trigger or validation rule.

You can learn more about Groovy scripting in Application Composer by reading the Groovy Scripting Reference guide: Overview of Groovy Scripts (oracle.com).

Here are some additional things to mention about Groovy scripting in Application Composer:

Groovy is a powerful language that can be used to do a lot of things, such as:

• Validate data.
• Automate tasks.
• Create custom functions.
• Integrate with other systems.
• Groovy scripts are easy to write and maintain, and they can be used to enhance any Oracle Fusion application.

Validation Rules:

Validation rules serve as restrictions that you can define for either a field or an object.

These rules encompass expressions or extended scripts that assess and verify fields or objects before permitting their storage. The creation of validation rules takes place within the Server Scripts node for both standard and custom objects.

For scenarios involving a single field, opt for field-level validation.

A field-level validation rule is a constraint applicable to any standard or custom field. This rule operates at runtime when the corresponding field’s value is established, and the user moves away from the field. As the rule executes, the field’s value remains unassigned, acting as a guardian until successful assignment. Employing validation logic at the field level minimizes the overhead of Groovy executions during saving. Utilize this method whenever feasible.

Please note: Dynamic choice lists do not support field-level validation rules.

For instance, consider a custom XX object featuring a Priority field. You can establish a field-level validation rule to ensure the entered number falls between 1 and 5.

The expression or script you construct must yield a Boolean value indicating the validity of the value.

A true return from the rule permits field assignment as long as other field-level rules on the same field also return true.

A false return, however, halts field assignment. The UI visually highlights the invalid field, displaying the configured error message to the user. Despite the assignment failure, the field retains its existing value (possibly null if it was null before). Yet, the web page’s UI component allows users to perceive and rectify their incorrect entry for another attempt.

Note: When validation spans multiple interrelated fields within an object, resort to object-level validation rules. This type of constraint applies to any standard or custom object.

Object-level rules enforce conditions dependent on two or more fields in the object. This ensures consistent enforcement regardless of the sequence in which users assign values. The rule is assessed whenever the framework attempts object validation.

Such validation occurs during tasks like submitting changes in a web form or moving from one row to another.

Note: However, these rules aren’t evaluated when a user saves a record without modifications.

For example, envision a XX object with x and y fields. The latter refers to a dynamic choice list field associated with z objects, where the Type field designates a member. An object-level validation rule can be configured to ensure that a XX with priority 1 or 2 cannot be saved without being assigned to a member.

The expression or script you create must produce a Boolean value indicating the object’s validity:

True rule returns enable object validation, pending other object-level rules returning true.

False rule results, however, prohibit object saving and prompt display of the configured error message to the user.

Let’s understand a simple Groovy Script..

if (JobLevel <= 4) {
return CommissionPercentage < 0.40
}
else {
return CommissionPercentage < 0.60
}

In this case, if JobLevel is less than 4, then commission % would be lesser than 40% else 60%.

Groovy is often used for scripting within applications that support customization and automation. It’s a versatile scripting language that can be used to extend the functionality of an application by adding custom logic and behavior. Here’s a breakdown of the different contexts you’ve mentioned:

Shorter Scripts:

1. Custom Formula Field’s Value: You can use Groovy scripts to calculate and set the value of a custom formula field. This allows you to define complex calculations based on the values of other fields.
2. Custom Field’s Default Value: Groovy scripts can be used to determine the default value for a custom field. This can involve calculations, referencing other objects, or setting default values based on certain conditions.
3. Conditionally Updatable Field: With Groovy, you can make a custom field updatable based on certain conditions. This could involve checking the values of other fields or applying business logic to determine whether the field can be modified.
4. Conditionally Required Field: Similarly, you can use Groovy to enforce the requirement of a custom field based on specific conditions. This is useful when you want to ensure that certain information is provided under certain circumstances.
5. Object Workflow Conditions: Groovy scripts can define the conditions under which an object workflow should be executed. This allows you to trigger specific actions or processes based on the state of the object.

Below screen shot (where you can write shorter groovy scripts)..

Longer Scripts:

1. Field-Level Validation Rule: Groovy scripts can be used to implement validation rules that check the values of fields before they are saved. This helps maintain data integrity and ensures that data meets certain criteria.
2. Object-Level Validation Rule: Similar to field-level validation, you can use Groovy to define more complex validation rules that involve multiple fields or require interactions between different objects.
3. Trigger for Default Processing: Groovy scripts can be used to create triggers that respond to events or actions within the application. These triggers can complement the default behavior of the application by adding custom logic.
4. Utility Code in Global Function: You can define global functions in Groovy that can be used across different parts of the application. These functions can encapsulate common logic, calculations, or operations that are reused in multiple contexts.
5. Object Function for Reusable Behavior: Groovy scripts can also be used to define functions specific to a certain object type. These functions encapsulate behavior that is associated with that object and can be reused whenever needed.

Overall, Groovy scripting provides a flexible way to extend and customize the behavior of applications, making them more tailored to specific business processes and requirements. It’s commonly used in scenarios where standard features don’t cover all the necessary functionality or when you need to automate complex processes.

So, this is where you write all your validation scripts.

For instance, let’s consider a scenario where we have a field named “Business Unit” (BU) within our application. To enhance data integrity and accuracy, we’ve implemented a field-level validation rule specifically for the “Business Unit” field.

def v_bu = BU_c
def v_bu_len = length(v_bu)
def v_err = “Length of BU entered is not correct”
if (v_bu_len < 3)
{
println(“Error:”+v_err)
}

You also have the option to utilize functions and web services.

Triggers are customizable scripts designed to enhance the default processing logic of either standard or custom objects.

These scripts are automatically activated when certain predefined events take place. These events are chosen by you during trigger creation and are often referred to as triggers. Both object-level and field-level triggers can be defined using the Server Scripts node for any standard or custom object. Oracle offers a range of trigger events for selection when setting up your trigger “scripts.” Once the designated event occurs, the corresponding action specified in the trigger definition is automatically executed.

Likewise, object-level triggers yield scripts engineered to activate upon the advent of distinct events. This genre of triggers boasts a broader array of trigger “events” to choose from, encompassing:

1. After Create: Frequently utilized to configure default field values.
2. Before Invalidate: Initiates within the parent object when alterations transpire in child object records.
3. Before Remove: Can preempt deletions through conditional constraints.
4. Before Insert in Database: Aids in verifying the existence of a dependent record or detecting duplicates.
5. Before Update in Database: Sparks prior to the modification of an extant object in the database.
6. Before Delete in Database: Assesses dependent record values, potentially deterring deletions.
7. Before Rollback in Database: Activates during database rollback operations.
8. After Changes Posted to Database: Materializes subsequent to all changes being posted to the database but prior to permanent commitment. Useful for introducing supplementary changes, subsequently preserved within the ongoing transaction.

Field Trigger Example:

def StartDate = StartDate_c;

if (StartDate!=null && StartDate> today())

{

adf.error.raise(null);

}

Error Message -> Start Date should not be greater than today

ref:About Application Composer (oracle.com)