Computed Fields

Computed fields bring the ability to define fields on an object whose value is computed from the values of other fields. These other fields may exist on the same object or another related object. These computations will be available in both the application as well as for reporting purposes.

Computed fields are defined in the application user interface. For information about defining a new computed field, see the IBM OpenPages with Watson Administrator's Guide or contact your system administrator for assistance.

Limitations of Computed Fields

  • There is a limitation on the size of the computation attribute value that can be stored by the application. The main attribute of concern is Equation where a complex flattened equation could be very lengthy.

    There is a 20,000 byte limit on the size of the entered text. Note that the application supports multi-byte characters and so this may not be the equivalent of 20,000 characters.

    If more than 20,000 bytes of information are needed for the equation, you must create the calculation in the custom query subject file as described in Creating Calculations.

  • When exploring all the computation possibilities there is one large distinction in what should be done. While it is possible to query up the relationship tree (that is, compute values based on ancestors) it is strongly discouraged.

    The automatic framework generation is set up in such a way as to create joins that are conducive to better performance querying down the relationship tree.

    Note: A query up the tree will result in bad computed field performance as well as place a large strain on the database that can result in the entire application slowing down.
  • Computed fields can sometimes act as building blocks for other computed fields. These are referred to as intermediate computations. Currently the IBM OpenPages® with Watson™ application does not support intermediate calculation definitions through the application user interface. If you want to reference another computed field, you must replicate the equation used in that computed field inside the equation for the current field.

    Example

    For example, if we have a computed field A and define it as A = B * C and we also know C = D + E, we would only create one computed field A in the application where the equation would be B * (D + E). While this approach can be verbose, it is sometimes the simplest.

  • The definitions used in a computed field must be present in the namespace you are using and must be related to the object you are creating the computed field within. It is possible to create a computed field that will validate in the form but will not yield any results due to this limitation.

Design Considerations

Take the following items into account when designing the computed field:

Localization
All computed data types will be localized by the application except for Simple String, which must be localized as part of the computation (equation).
Dependent Computed Fields
A computation that uses another computation as part of its equation is not supported.
Computation Cross Products
When writing a computation that aggregates across multiple object types we commonly run into a problem where some objects are counted multiple times and so you need to account for this.
Handling Null Values
When writing an equation you must take into consideration that if part of the equation evaluates to null and is then used in some other arithmetic operation, the second operation will return null as well. The solution to this problem is the nvl() function which takes two arguments: an expression to evaluate and check if it is null and a value to use in the case it is null. For example: 
average (nvl(Loss Impacts, 0) for Loss Events) * count 
       ( nvl(distinct Loss Impacts for Loss Events, 0))