X

It's All About the Platform.

Validation of Groovy in Application Composer

Guest Author

Introduction

This blog article outlines the process that occurs when user entered Groovy script is validated, which occurs at the time the Validate button is pressed or the Save and Close button is pressed the Application Composer Groovy edit window.

Background

When a user creates or edits a Groovy script in application composer, the script needs to be validated before it can be saved. Validation consists of three different areas:

  1. Syntax checking
  2. Type checking
  3. Security checking

Syntax Checking

Syntax checking involves validating the names of Groovy keywords, checking code layout structure and validating opening and closing parentheses are matched correctly.

This is achieved by pre-compiling the Groovy script in Java. The failures caught by the compiler are then presented in the Application Composer user interface. When a brace is not terminated correctly the offending line reported by the compiler/validator could be after the last line of code in Application Composer. The actual error is further up the page. Here is an example:

In the above example the if clause defined in line 3 is not terminated with a closing brace. The error message complains that a closing brace is expected in line 12 which doesn't exist.

Type Checking

Groovy has an underlying Type checking feature that informs the compiler of variables and methods created in Groovy script. When the validation process is executed, the compiler is able to validate these variables and methods as well. This validation feature is available in Release 11 in Fusion Applications and maybe new to some, as it was not available previously. More infomation on the underlying Groovy Type checking feature can be found here.

If a variable defined in Groovy script doesn't exist then an error is thrown during the validation process, an example of which is below:

 

 

In the example above, the error is because the type checking element of validation indicates that there is no such variable called nom. The

The warning is because the validation could not find the constructor for the java.util.HashMap class that is referenced in the Groovy script.

Because the compiler is aware of the variable declared in Groovy script it is also able to determine if the variable has been used correctly. Here is an example:


In the example above the Type checking feature of Groovy validation fails because the date field num1 cannot be added to the String variable str as they are incompatible types. This blog article describes this point in more depth.

Security Checking

Security checks during validation only allow classes and methods that are explicitly enabled for execution in Oracle Sales Cloud to execute at run time. A whitelist of available methods and variables are available in the Oracle Sales Cloud Documentation. Furthermore this blog article is an overview of whitelist functionality in Oracle Fusion Applications.

All Groovy script written in Application Composer is considered un-trusted. This means the following:

  1. All underlying Java methods that Groovy functions can call have to be listed as runnable by un-trusted scripts. A check is made against any called method that it exists in the list.
  2. View Objects that can be accessed from a Groovy script have to be explicitly configured for programmatic access in the application. A check is made that only those that have been explicitly allowed for programmatic access are available for access in Application Composer.

Not all the methods in oracle.jbo.ViewObject, for example, are available for execution from within a Groovy script in Application Composer. The getQuery() method is one such example. Left only to the compiler this method would pass validation as it's a valid method. However the security check prevents this method from being executed. Here is the resulting error message:

oracle.jbo.ExprSecurityException 
The method getQuery on class 
example.jedi.fwkext.TestModelViewObjectImpl is not permitted.

The CurrencyVO is an example of a View Object that is not programmatically available in Application Composer. When it is referenced the Application Composer has no knowledge of it and validation fails. Here is what happens:


Further Information

Join the discussion

Comments ( 2 )
  • Ehab Tuesday, October 10, 2017
    Any idea when is the groovy validation will be enabled on HCM modules. Maybe product managers can know this.
  • Oliver Steinmeier Tuesday, October 10, 2017
    Hi Ehab,
    unfortunately I can't comment on possible future availability of features. I would recommend filing an enhancement request with support against the HCM Cloud product you are using and explain the functionality you require (it may not necessarily be implemented the same way as described here).

    Hope this helps,
    Oliver
    Fusion Apps Dev Relations
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.