This section describes helpful tips for expressions that follow Appian best practices.
When you write an expression that can be applied in multiple places around your system, such as one that retrieves information on the most recent meeting event, it is a best practice to create a rule out of it.
An expression rule is a stored expression with a user-defined name, description, definition, and a central location that can be reused within any expression field. They are accessible through the Expression Editor or can be typed into an expression.
See also: Expression Rules, Create Constant, Save Selected Expression As…
Similar to expression rules, instead of defining the same literal value multiple times in your system, such as the number of days until a deadline, define the literal value as a constant.
See also: Constants
In order for an expression to execute and logic to evaluate when the system attempts to derive information at runtime, the initiator must have sufficient user rights.
For example, if an expression is initiated by a user who does not have sufficient rights to access a resource requested by the expression, it will encounter an exception that halts the evaluation.
When creating an expression for a process model, the developer or task owner may require the rights instead.
See also: User Contexts for Expressions in Process
When an expression uses too much memory, it is typically doing one of the following:
This section provides guidance on how to avoid these design patterns.
Large queries are one of the easiest ways to store too much data in local variables. When you query a lot of data and store it in a variable, that data is stored in memory for as long as that variable can be used. For local variables configured to refreshAlways
, these values are stored for the entire evaluation of the a!localVariables()
function. For local variables with any of the other refresh configurations, the values are stored across all evaluations on that interface. See the Interface Evaluation Lifecycle page for more information on how local variables are evaluated.
To avoid memory issues with storing too much data in local variables, always do at least one of the following:
a!queryEntity
, a!queryProcessAnalytics
, a!queryRecordType
, and query rules all support paging using a!pagingInfoa!queryEntity
, a!queryProcessAnalytics
, and a!queryRecordType
support filtering using a!queryFilter and a!queryLogicalExpressionLooping over a large array of data can use a large amount of memory. While a looping function is being evaluated, the results of each iteration are accumulated so they can be returned at the end of the function evaluation. Even if each iteration is only returning a very small value, the overall result can use a lot of memory if the number of iterations is very large.
This problem can be compounded if you have nested looping functions. Memory will be allocated for each looping function iteration across all nested loops and won't be reclaimed until the parent loop is completed.
To avoid memory issues with looping over too many items:
In reality, the result of your expression is just a piece of data, and interfaces are no exception. Interfaces that contain a large number of components or components that contain a large amount of data can cause memory issues when being processed by the system. This is usually more of a problem when the interface contains a dynamic number of components based on a large data set, such as a grid with a dynamic number of rows.
To avoid memory issues with too many components on an interface:
Expressions Best Practices