Best Practices and Key Considerations for Computed Expressions

This section describes best practices and key considerations when using computed expressions. It also points out efficiencies that can be gained by using computed expressions in a certain way, as well as identifying any risks, constraints, or other limits or within a particular implementation of computed expressions.

◦ An administrator creates computed fields, which display as read-only fields that cannot be edited; however, an administrator may want to allow only certain users or groups to view them. To configure a computed field’s visibility, see “Setting Field Visibility for Types”.

◦ If you create an expression using one or more fields that a user does not have permission to view, the user sees the calculated field value; however, they may be able to extrapolate backwards the value of a field that they do not have permission to view.

◦ In charts and reports, any user can create a computed expression. However, the fields that make up the computed expression must be visible to the user.

◦ The complexity of a computed expression and the following may result in long calculation times and impact the performance of the Windchill RV&S server:

◦ Depending on the number of dynamic computed fields in an item and the complexity of the underlying computed expressions, an item may take a long time to display because all of the computed fields in the item are calculated before viewing.

◦ Querying for items that include state metrics in computed fields may take a long time, for example, querying for items where DaysInState(Submit) > 365. You can improve the performance of the query by configuring the computed field as a static field. Static fields are computed periodically on a schedule and although they may take a long time to calculate initially, they may be indexed as columns in the items table after the calculation. Indexing calculated fields improves query performance.

◦ Do not create computed expressions for types that include vast amounts of items. For example, do not create computed expressions for only one type, such as a Defect type, that potentially includes tens of thousands of items. Instead, include computed expressions for an aggregate type, such as a Project type, that includes maybe 20 to 30 items, but are related to tens of thousands of Defect items.

If an item contains a complex computed expression that needs to be evaluated on the Windchill RV&S Server, editing the item and clicking Apply does not re-calculate and update the new value in the item.