Designing a calculation

Know what objects the calculation applies to

A calculation can run for all or selected objects of an object type.

If a calculation is run for only selected objects, the applicability and input field conditions on the calculation define the selection criteria.

Part of testing a calculation is to verify that the applicability and input field conditions are defined correctly.

Know the calculation result

Know what you want the calculation to achieve.

Know whether the calculation is started by a workflow

Calculation type (automatic or manual) determines whether a calculation can be started with a run a calculation action in a workflow.

Understand the operations in a calculation

Understand the operations in a calculation.

Use input fields and variables in a calculation. It makes the calculations modular and easier to debug.

Add comments to the expression.

Follow good programming practices.

Study the Loss Event calculation to see how the result of one set field operation can be used in subsequent operations.

Understand the calculation expression

Understand the possibilities available in the calculation expressions. For more information, see Expressions in GRC Calculations.

Understand how a calculation can cascade to other calculations

Each calculation is independent, but the result of one calculation can cause a cascade effect to other calculations.

Cascading calculations are allowed across different objects, but not on the same object.

The following example illustrates how this works:

1. A change is made to Input Field A that is used in Calculation A, which sets Set Field A to a value.
2. Set Field A is an input field that is used in Calculation B. When Set Field A changes, Calculation B runs. Calculation B sets Set Field B to a value.
3. Set Field B is an input field that is used in Calculation C and Calculation D. When Set Field B changes, Calculation C and Calculation D run. Calculation C sets Set Field C to a value. Calculation D sets Set Field D to a value.
4. The calculation can continue this pattern.

Understand how the design of the calculation can affect performance

A calculation automates object field assignments while it creates or updates objects, or after end user operations that run asynchronously. As a result, a simple object field update might trigger hundreds of subsequent object updates behind the scenes, causing a reduction in overall system performance.

Use the following techniques to manage the performance of calculations:

• Reduce the number of objects to be recalculated.

  At the end of a user operation, the calculation determines whether any other objects are impacted by the change. To determine whether other objects are impacted, OpenPages® looks up the related object reference in reverse order. The more objects that are identified, the more performance is affected. When you have ancestor or descendant references, the reverse lookup might identify hundreds of objects. Consider the following techniques:

  • Use the Applicability condition to limit the number of objects to be recalculated.
  • When setting up an operation on an input field in a related object, apply Filter By conditions to a Related Object Field.
  • When setting up an operation on an input field in a related object, where the Relationship Type is Direct Parent, enable Primary Parent Only.
• Understand the impact of chaining calculations.

  You can define calculations so that they can depend on other calculations recursively and the calculation can identify all the impacted objects and recalculate values in sequence. However, the performance impact to the overall system of such a chain of calculations can be substantial.

  The following sequence of events is an example of a chain of calculations:

  1. You have a calculation that updates an Action Item.
  2. The update to the Action Item causes a calculation to update the Issue Status of the parent Issue.
  3. The Issue Status is used to classify the parent Control object.
  4. The Classification of the Control is used to calculate the Audit Inherent Risk Rating of the parent Risk.
  5. The Audit Inherent Risk Rating of the Risk is aggregated on the parent Process.

  While you are developing a calculation, do the following:

  • Monitor the "In queue" count column on the calculations administrative page.
  • Update an object as a test.
  • Refresh the calculations page periodically to see the impact of the object update.

  If you see a spike on the "In queue" count on some calculations, analyze the chain relation and optimize the calculation definitions.

• Understand how the automatic update of workflow assignees can slow performance.

  When a workflow assignee definition is set to an object field and that field is updated on the object, the workflow assignee is updated automatically. The automatic assignee update uses the same engine as calculations do. The asynchronous processing shares the queue to manage the recalculation of object fields and workflow fields. As the queue grows, both calculations and workflow auto updates get slower.

• Set the cache size high enough to keep workflows in the on-memory cache.

  Often there are many active workflows that spread across multiple versions of workflow definitions. OpenPages tries to read workflow definitions to find impacted workflows. If the workflows are not available in the on-memory cache, OpenPages gets the workflow definitions from the database.

  Set the registry setting Platform > Workflow Implementations > OpenPages > Expired Process Definition Cache Size to a positive integer value. To avoid degraded performance, do not set this value lower than the default value of 200.

• Terminate workflows that are no longer in use because they can take up resources. Unused workflows are especially common in a development environment.

• Don't use calculations with custom triggers on the same object.

  It is technically possible to use calculations and custom triggers on the same object. However, this practice can cause multiple calls to the database for a single user operation, and debugging custom trigger code can be difficult. Most tasks can be accomplished with calculations or workflows. For example, you can use a calculation for auto field assignment instead of custom triggers.

• Tune the calculation configuration registry settings.

  There are several registry settings that you can use to control the performance of calculations.

  • If you increase the value of Platform > Calculation > OP > Concurrent Calculation Jobs to increase throughput of asynchronous processing of the calculations, it might limit computation resources for other user activities on the OpenPages system.

  • You can set Platform > Calculation > OP > Always Recalculate on the Object Save to true during the development phase of a calculation to easily see the calculation result after the calculation definition update. However, it results in redundant recalculation in a production system where the calculation definition is not changed frequently.
  • If you increase the value of Platform > Calculation > OP > Task View Timeout for Queued Object, it can have an impact on performance. When an object is opened in Task View, OpenPages displays a waiting icon for each object field with calculations in the queue. This icon is displayed until the results become available or the number of minutes specified in Task View Timeout for Queued Object have elapsed. While the waiting icon is displayed, OpenPages keeps using the server-side resources to monitor the progress of the calculation. The larger the value of this setting, the more it can impact the overall performance of your OpenPages system.

Keep it simple

Calculations that have many operations that have complex expressions can impact performance. Avoid making a calculation overly complicated. Keep the expressions as short and simple as possible.