Process Instance Version Filter

Introduction

Every Process Instance has a Version Filter. The Version Filter defines the strategy for selecting the versions of Business Objects used during the execution of a Process Instance. The most common type of Version Filter in production is the Timestamp Filter. This type of Version Filter contains a timestamp which is used to find the latest committed version of a Business Object at or before the date and time specified by that timestamp.

In previous Platform versions (Appway 10.0.0 and lower), a new Process Instance was always created with a Timestamp Filter using the current date and time as a timestamp. For example, when starting a Process on August 3, 2020 at 11:30 AM, the Process Instance used a Timestamp Filter with a timestamp pointing at this same date and time.

This way, a Process Instance was executed with the versions of Business Objects being "active" (committed) at the point in time when the Process Instance was started. Changes to Business Objects or Packages after the Process Instance was started had no effect on that Process Instance.

One side-effect of this strategy was that every Process Instance had a Timestamp Filter with a different timestamp. 100 new Process Instances typically used 100 different Timestamp Filters, assuming that Process Instances were not started at the exact same time. This made it very hard for Appway to cache certain information "per Version Filter", since the number of entries in such a cache grew with the number of different Version Filters and, therefore, with the number of active Process Instances.

Current Strategy: Latest Commit Timestamp

Starting with Appway 10.1.0, new Process Instances still get a Timestamp Filter with a timestamp, but this timestamp is no longer the current date and time but, instead, the date and time of the latest commit operation on Business Objects or Packages on that Appway/FNZ Studio system. We say that this Version Filter is "aligned" with a commit timestamp.

For example, when starting a Process on a system where the last commit operation was performed on July 5, 2020 at 3:15 PM, the Process Instance uses a Timestamp Filter with a timestamp pointing at this commit date and time, independent of the current date and time.

The reasoning behind is that there are usually much fewer commit operations (in the range of 1 to 30 per month) on a system compared to new Process Instances (in the range of 30 to 1.5 million per month). In an ideal case with short-living Process Instances, all active Process Instances may use the same 1 to 10 Version Filters. This allows Appway/FNZ Studio to implement more effective caching strategies, especially for information aggregated across multiple Business Objects.

A good example is a cache to remember all properties of a Data Class, including all properties inherited from all parent Data Classes. These properties must be collected by traversing the inheritance hierarchy of a Data Class. Since different Data Classes can have different version histories, the list of properties can be different after every commit. By caching properties "per Version Filter" and using Timestamp Filters configured to use commit timestamps, such a cache can hold the maximum amount of information with a minimum number of cache entries.