Optimize Business Object Performance

When working with business objects, you might want to tune settings for your business object's fields and functions to optimize performance and enhance your application's user experience.

Override Default Timeout for Groovy Scripts

When you use Groovy code (whether short expressions or multi-line scripts) for business logic, you have the option of overriding the default timeout configured for Groovy processing. You might want to do this if you expect your script's processing time to exceed the default Groovy timeout at runtime.

You can specify your own timeout for Groovy code that calculates a formula field's value or a field's default value. You can also change this setting in business rules when you define field-level or object-level validation rules, field or object triggers, and object functions.

The default timeout for each of these options varies and should work for most scenarios. Consider changing the default timeout only if your script's processing time will overrun the default duration and you run the risk of the connection timing out before your business logic can be executed. If you anticipate a fairly long processing time, you might also want to enable polling to prevent endpoint requests from being terminated because of (say) gateway or browser timeouts.

This table describes the default timeouts predefined for Groovy. To override the default timeout, you use the Timeout Override property, either in a field's Properties pane or in a business rule's editor.
Business Object Functionality Default Timeout (in seconds) To Change the Default Timeout, See:
Calculate a field's default value when using an expression 60 seconds Set a Default Value for a Field
Calculate a field's value using a formula 5 seconds Add a Formula to a Field
Object and field triggers 60 seconds Object Triggers

Field Triggers

Object and field validators 60 seconds Object Validators for Business Objects

Field Validators for Business Objects

Object function 60 seconds Object Functions for Business Objects

Enable Polling for Endpoint Requests

If you run into timeout issues when working with business objects, you might want to enable polling for long-running endpoint requests.

Polling is useful in many contexts involving long-running processes, where you run the risk of breaking the client/server connection because of gateway or browser timeouts. A process can be long running, say, when your application integrates with external services, perhaps through a trigger that makes API calls to an external service. It can also involve endpoint requests that import a large volume of data from a file or from one database (development, staging, or live) to another during your application's lifecycle. Most data-related endpoint requests, including those to create, query, update, and delete business object data, are long-running processes that can benefit from polling.

You can enable polling by adding the vb-poll=true query parameter to an endpoint request URL. Now when the client makes an endpoint request, the server—instead of waiting for the request to complete and then return an HTTP response (status 200 or otherwise)—returns an HTTP response (status 202) with details of a new URL for the client to poll. This allows the server to continue processing the request in the background and the client to poll the new URL as and when it wants to find out if the request is complete and get the response (or error).

To enable polling for long-running endpoint requests:

  1. Add the vb-poll=true query parameter to your endpoint request URL, for example:

    POST https://server.example.com/ic/builder/rt/hrapp/1.0/resources/data/Employee?vb-poll=true

  2. When you receive the HTTP response with status 202, look for the Polling-Location header whose value will be the polling URL.

    The client can poll this URL and check the response, which will either contain the Polling-Location header to indicate that the process is still running, or will be the final response.

    When the long-running process completes, the response remains available for a limited time period, after which it is removed. The process itself is not affected by this, but the result is not available beyond this period—two minutes by default. The client should take this setting into account when determining the frequency of polling requests.

Control Data Caching for Business Objects

When application resources don't include sensitive data, you can define a caching strategy to safely store your business object's data and improve performance. Caching enables data to be retrieved from the browser cache, instead of the business object on the server, thus speeding up subsequent requests for this data.

Data Caching Options

Caching for each business object is controlled by its data caching strategy. You can choose predefined options (Sensitive, Private, or Public Shared) which combine flags used by the Cache-Control HTTP header to meet common caching scenarios. Or, you can use a combination of Cache-Control flags to build a custom caching strategy.

Here's a look at the different caching options in Visual Builder:
  • Sensitive: Indicates that data must never be stored in any cache (private or otherwise). Select this option if your business object contains sensitive data, for example, banking transactions or personally identifiable information, that must not be cached and you want the latest most up-to-date information to be served every time.

    The Sensitive option is a combination of the no-cache, no-store, and must-revalidate flags that guarantee data is never cached. When a request is made for the data, the browser always checks with the server for the latest data.

  • Public Shared: Indicates that data can be cached by the client's browser and other caches (like those from ISPs or other parties) for a specified duration. While this option is the least secure of all the available policies, select this one if your data is not sensitive and is not likely to change often, for example, country codes.

    The Public Shared option is a combination of the public and max-age flags that allow data to be stored in any cache for a maximum length of time.

  • Private: Indicates that data can be cached, but only by the client's browser for a specified duration. Select this option if your data is user-specific, for example, a user's purchase order history that must not be stored in public caches but can stay in the client's browser cache. Remember though that anybody with access to the client would have access to the data as well.

    The Private option is a combination of the private and max-age flags that allow data to be stored only by the client's browser for a maximum length of time.

  • Custom: (For advanced users) Specifies a custom option based on the no-cache, public, or private flags, each of which can be augmented by the no-store, must-revalidate, and max-age flags. Custom settings are not validated; select this option only if you are familiar with the Cache-Control header options and are confident of your choices.

Define a Data Caching Strategy

Configure the Resource Cache Control setting to define a caching strategy that safely stores a business object's data. Because all application data is deemed sensitive, by default, no data is cached.

Whether you cache data between the server and the browser or not at all depends on factors such as whether your data is sensitive, how often it is updated, and so on. Before you decide on a caching strategy, check whether it is safe to cache your data. If it is, decide on an option that makes the most sense for your data and specifies where, and for how long, the data can be cached. See Data Caching Options.

You can apply a different caching strategy for each business object, but be aware that the strategy applies uniformly to all its endpoints.

  1. Select the business object's Endpoints tab.
  2. Expand Resource Cache Control and select a suitable Data caching strategy:
    Option Steps
    Sensitive Select Sensitive if your data is sensitive and must never be cached (for example, banking transactions or personally identifiable information). This option is the default setting that disables caching.
    Public shared
    1. Select Public shared if your data isn't sensitive, is not likely to change often (for example, a list of country code values), and can be cached by the browser as well as other intermediary caches.
    2. In the Max Age field, enter how long the data can be cached. To cache your data for, say, a month, enter 2629746 as the max age in seconds. After this duration, the data will be considered stale and if a user is offline, they will continue to see the stale data.

      If you don't want this behavior, use the Custom option and add must-revalidate in addition to max-age. In this case, after the max-age duration, the data must be re-validated or downloaded again from the origin server.

    Private
    1. Select Private if your data is user-specific (for example, someone's purchase order history that must not be in public caches but can be stored in the client's browser cache).
    2. In the Max Age field, enter how long the data can be cached. To cache your data for, say, 24 hours, enter 89999 as the max age in seconds. After this duration, the data will be considered stale and if a user is offline, they will continue to see the stale data.

      If you don't want this behavior, use the Custom option and add must-revalidate in addition to max-age. In this case, after the max-age duration, the data must be re-validated or downloaded again from the origin server.

    Custom
    1. Select Custom to build your own caching strategy.
    2. Select one or more of the available flags: no-cache, public, private, no-store, must-revalidate, and max-age.
    3. If you chose max-age, enter a value in the Max age field.

    Note:

    Custom settings are not validated. It is your responsibility to ensure the flags you select are valid combinations.
Your caching strategy is applied to data requests at runtime, when your web server adds the Cache-Control header to each endpoint response.

Note:

You can see your caching setting take effect only when an application is staged or published, not when you preview the application during development.