Free cookie consent management tool by TermsFeed EPEx Design Best Practices [EPEx Beta]
EPEx Design Best Practices
This documentation is intended for beta users only. This functionality is not available to most Appian customers, and is not part of the released and supported platform. If you are interested in enrolling in the beta program, please contact your Appian representative.

EPEx design best practices

As you design a process that uses elastic scale, keep the following in mind:

  • 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 200KB. We recommend you implement a pattern where more processes are executed with process variables storing less data, rather than fewer processes with larger process variables.
  • When reading from the database, it is best to batch your queries where possible. This can help ensure your process variables don't hit the 200KB limit.
  • If you need to use functionality that isn't supported in EPEx, you'll need to design a subprocess (without elastic scale enabled) containing that functionality. Remember that subprocesses in this implementation are intended for low throughput.
  • We recommend building observability into your process by using the Write to Data Store Entity Smart Service during development. This smart service can capture what values exist for variables at different points in the process. By writing these values to a database, you can more easily identify any issues in process model configurations.
  • The best way to drive load to the EPEx engine from external systems is to use an Appian Web API and the a!startProcess function. Keep in mind that frequent calls might cause high resource usage on the App Server. This design pattern is constrained by the site resources and will impact other functionality. We recommend batching these Web API calls when possible.

Debugging and monitoring

As you get started building a process intended for elastic scale, you'll want to consider how you'll debug and monitor those processes for optimal development and execution.

If you are building a brand new process model, we recommend that you enable elastic scale before you begin. When elastic scale is enabled, the process modeler shows you which configurations are not supported or ignored when you validate the process model. These validations can help prevent you from developing a process model that relies on unsupported configurations. These validations won't appear if the elastic scale option is disabled.

Tip:  You can enable elastic scale on existing process models as well, but you may notice many validations alerting you to unsupported nodes or configurations.

Currently, only processes with errors will appear in the elastic process activity page of the monitoring view, and monitoring mode is not available for EPEx processes. As you debug your processes, we suggest you disable the elastic scale option so that these executions appear in the process monitoring tab, which captures more information. These details can be helpful to determine which adjustments you need to make. Once you're confident in your process model, re-enable the elastic scale option.

You can find additional information in the Monitor view of your application. The Elastic Process Activity tab shows a lot of the same data as the Process Activity tab, including the 20,000 most recent process executions of the following types:

  • Paused by exception
  • Active
  • Completed with errors

Note:  If a process execution had any errors, you'll see up to 5 errors for each of those processes.

EPEx Design Best Practices

FEEDBACK