Overview of Groovy Scripts

Groovy is a standard, dynamic scripting language for the Java platform. You write Groovy scripts using Application Composer's expression builder, which appears in many places as you modify existing objects or create new custom ones.

Read this chapter to learn about how and where you can use Groovy scripting in Application Composer.

Note: To fully understand all the scripting features available to you in Application Composer, you should also review the Groovy Scripting Reference guide.

In this chapter, you will learn about:

• Where you can use Groovy in your application, along with examples of one or more lines of Groovy code

• How to access view objects using the newView() function, for programmatic access to object data

• How to create global functions, which is code that multiple objects can share

• How to call Web services from your Groovy scripts. You might call a Web service for access to internal or external data, or, for example, to perform a calculation on your data.

• What kind of scripts will you write?

Write Groovy Scripts

You write Groovy scripts using Application Composer's expression builder, which appears in many places throughout Application Composer as you modify existing objects or create new custom ones.

• You will write shorter scripts to provide an expression to calculate a custom formula field's value or to calculate a custom field's default value, for example.

• You may write somewhat longer scripts to define a field-level validation rule or an object-level validation rule, for example.

Additional examples of where you write Groovy scripts in Application Composer are described in "Groovy Scripting: Explained."

To learn more about how to best use the features available in the expression builder when writing scripts, see "Groovy Tips and Techniques" in the Groovy Scripting Reference guide.

Performance Considerations

For optimal performance, always write your Groovy scripts to query and fetch the fewest possible rows from the database. Minimizing the number of queried rows is one of the most important performance best practices you can follow.

Many of the most significant performance impacts you're likely to encounter will be related to code that queries and fetches a large number of rows. This has several implications for application performance and functionality:

• Response time

  Querying and fetching rows are two of the most expensive operations your application will typically perform and can noticeably impact performance. Large result sets magnify the impact of sub-optimal code executed while iterating over a result set.

• Scalability

  Long-running operations tie up limited shared resources such as database connections and shared memory. This might increase response time of other requests because they have to wait for resources to become available.

• Functionality

  If your application attempts to fetch too many rows, then the application will display a warning to the user and will not fetch any more rows. This limits the user's ability to view data in the UI and causes processing errors in scripts that iterate over rows.

To limit the potential performance impacts described above, most view objects have a 500-row Fetch Limit. Design your customizations with the Fetch Limit in mind as an absolute limit, but always strive to limit your queries to the least number of rows possible to satisfy your business requirements.

For example, use view criteria and bind parameters to tailor a view's default query and limit fetch size for view objects. See Finding Objects Using a View Criteria.