Free cookie consent management tool by TermsFeed

Autoscale Patterns and Best Practices

The capabilities described on this page are included in Appian's advanced and premium capability tiers. Usage limits may apply.

Overview

Autoscaled processes make it quick to build a workflow that can handle the high-scale needs of your application. To help your processes run smoothly, Appian recommends the following design patterns and best practices.

Keep process variables small

During development, test the size of your process variables with the largest data you expect to handle to ensure you do not hit the size limit of 100 KB.

To help stay under the limit, we recommend building more smaller process models with process variables that store less data, rather than a few complex process models that need larger process variables.

Build separate process models to use unsupported nodes and smart services

You can only use supported nodes and smart services in processes with autoscale enabled.

If you need to use nodes or smart services that aren't supported for autoscale, you'll need to design a separate process model that does not have autoscale enabled to contain that functionality. Then, you can run that process with the Start Process smart service.

These processes should only be started at low throughput. In a single environment, there is a queue for all of the processes started by autoscaled processes.

Processes can be started at a maximum rate of 700 per minute. If more than 700 processes are requested in one minute, they will be put into a queue that can hold a maximum of one million processes. If you try to start a process when the queue is full, the Start Process node will fail.

Keep track of autoscaled processes for later troubleshooting

Appian does not automatically send alerts or notifications for autoscaled process errors. Instead, we recommend using the process's UUID, which is available as the process property pp!instanceUuid, to design a recordkeeping or alerting solution that works best for your application.

For example, you may want to include the UUID in the process name so it's highly visible. You could also write the value to a data source or set up an error flow in the process model to send an email with the UUID from a process without autoscale enabled.

Starting large numbers of autoscaled processes

The best way to start autoscaled processes from an external system is to use a web API and the a!startProcess() function.

Keep in mind that frequent calls might cause high resource usage on the server, so you should use batching with web API calls when possible.

Importing autoscaled processes

If you import an autoscaled process model into an environment without this capability, the import will succeed, but your process model will automatically be set to run without autoscale.

Avoid long-running queries

To help ensure your automated processes are using resources effectively, all nodes time out after 90 seconds. When testing your process models, check for any integration calls to external systems that are taking too long time to complete.

Considerations for using autoscale with existing process models

Your existing process models can be converted to autoscaled processes.

To check your model for compatibility:

  1. Enable autoscale by selecting the Autoscale checkbox in the process model's properties.
  2. From the menu bar, select Tools > Validate. Appian will list any issues that need to be resolved before the model can be successfully published and run with autoscale enabled.

Note:  Be sure to test a converted process model thoroughly before deploying it to a higher environment.

Node behavior changes with autoscale

The following table details the node behavior changes to be aware of when converting an existing process.

Summary Without autoscale enabled With autoscale enabled
Gateways (AND, OR, XOR, and Complex) in swimlanes Gateways always run as the process initiator, even when in a swimlane configured to run as the designer. Gateways use the swimlane configuration but will default to the process initiator when the node is not in a swimlane.
Gateway node reset Gateways are not reset until all incoming flows have been executed. This means an OR gateway with two incoming flows in a looping flow will not execute again until both incoming flows have arrived. The gateway is reset immediately anytime an outgoing flow is executed, allowing any incoming flow to trigger the gateway again.
Implicit flow completion If no flows or events are active after a node completes (a gateway ends with a -None- result or the flow reaches a node with no output flow), the process waits for one hour and is then paused by exception. Flows complete implicitly when a gateway ends with a -None- result or the flow reaches a node with no output flow. This allows all other flows to continue and the process to complete.
Node instance limit A single node can be executed up to 1,000 times per process instance (for example, in a looping flow). By default, nodes can be executed up to 10,000 times per process instance. Contact Appian Support if your use case requires an increased limit.
Process variable size Process variable size is unlimited. Process variable size is restricted to 100 KB.
loggedInUser() When loggedInUser() is called in a node, it is always set to Administrator.

When loggedInUser() is called in a node set to run as initiator, the process initiator is returned (user or service account that kicked off the process).

When a node is set to run as designer, the user that published the model is returned.

At the process level (in expressions like the process name), the initiator is returned.

Process model creator property (pm!creator) The user that published the most recent version of the process model is returned. The user who created the process model object is returned.
CDT versions in expressions Expressions defined in the process model object use the latest version of the CDT available when the process starts. If the CDT changes after the process starts but before the expression evaluates, the older version is used. Expressions defined in the process model object use the latest version of the CDT. If the CDT changes after the process starts but before the expression evaluates, the current version is used.
Casting values to a CDT Values are cast when the process is initiated, and a casting failure will generate an error before the process starts. Values are cast when the containing expression is evaluated, so a casting failure will generate an error after the process has started.

Feedback