Application Scripts

Application Scripts (AppScripts) are self contained blocks of code written in Groovy. These scripts can be used to tailor the business logic layer of a TrackVia application when unique needs surrounding record actions arise. AppScripts are created and managed through the integrated Groovy editor within the edit table screen. Order of Operations

Dig Deeper...

AppScripts operate at the table level on record events and are not associated to any views or forms. They can be configured to trigger on the following record events:
  • Before Insert
  • After Insert
  • Before Update
  • After Update
  • Before Delete
  • After Delete
The Before Insert and Before Update events can be used to set values based on additional logic before saving a record. For instance, using an AppScript to set a value based on the input of another value. The After Insert and After Update events can be used to set values after the record has saved and Triggered Fields have executed. These events would also be used to create Child Records. Child records require the parent record to exist in order to set the relationship to the parent record.
AppScripts reference applications, tables, fields and relationships. Administrators can change the name of these resources in TrackVia. The system identifiers for these items are unique and immutable and should be used as constants in the AppScript. For example, a field named Car ID has a system identifier value of 608. A TrackVia administrator changes the name of the field to Vehicle ID. The system identifier value will retain its value of 608. When the system identifier is used as a constant in an AppScript, changing the name of a table, field, or relationship will not impact the AppScript functionality. If multiple applications have tables with the same name, the application name can be passed as an optional final parameter to functions in order to identify which table to use. This ensures that the correct table is being acted upon in the AppScript.
To ensure optimum performance and steadfast security, AppScripts have certain restrictions.
  • AppScripts are executed in a private container.
  • AppScripts do not have access to system resources.
  • AppScripts are allocated a finite amount of execution time.
  • AppScripts cannot reference calculated or auto counter field types.
  • AppScripts are not executed when performing a batch update or delete when more than 1000 records would be effected.
  • AppScripts cannot reference Record IDs.
An AppScript is executed within a single transaction. A transaction is a change or series of changes that are performed within the scope of a single commit statement. A commit statement is the final act of updating data changes to the datastore. Should an operation in an AppScript fail during a transaction, the changes within the transaction may be rolled back to their initial state in order to prevent data corruption. For example, an After Update AppScript loops through its child records and updates a field on each one. If there are 10 child records, and the third child record update fails for any reason, all child records and the parent record will have their values reset to their initial state.