General operation of trays

Tray life cycle

The life cycle of tray loading at Athento consists of three fundamental phases: collection, rendering and post-filtering.

1. Procurement phase

The fetching of the data is defined by the process of running the main tray filter from the data providers. Athento makes use of data indexes for performing agile queries, in this case, Elasticsearch, and this can be used instead of the deployed data SQL backend itself, by default, PostgreSQL.

2. Representation phase

Representation is the phase of serialization of the data obtained in the retrieval phase, where, through the use of native queries to the SQL backend itself, fast representations of data coming from the index or from the data backend itself are obtained.

3. Post-filtering phase

The post-filtering phase is achieved by including modification (or filtering) masks so that the represented results can still be altered by Athento and get the tray to present the data with even more detail, or even, removing or adding elements that may be of interest to the end user.

Athento's data providers are SQL or Elasticsearch (agile query index) and the representation, as mentioned above, are achieved with native queries or by iterating the results obtained from the provider in the fetch phase.

Tray representation, mapping

The results mapping based on results iteration establishes a sequential path on the result rows obtained in the retrieval phase to adapt them to the configuration of columns and other parameters of the tray. This mapping mode is recommended for trays with few fetched documents.

The representation by native mapping (use native) is based on the direct query to the SQL backend preparing a direct query to the final representation. This way presents a high efficiency and is recommended for trays with results between 0 and 1000 documents.

Native

To represent each line of the tray, the query asks the DB for all the records, so the query may be affected by performance issues.

Trays with mask

They are used to enrich the filters of the trays, so that additional characteristics of the documents obtained can be displayed. The masks can be: total result-related (mask), so that it can be altered in the total document path, or document-related (hook_mask), which allows to intervene on each individual document. The latter can be cached so that the retrieval phase is instantaneous after the first load.

Ideal tray

The document tray concept, precisely, is similar to that of a physical tray, and that is why it is considered a very useful management element when the number of elements is very limited. For example, "Documents pending approval", "Pending payments", "Invoices to be processed", etc., however, they should not be considered to establish reporting, BI, or data analysis elements, for example, "Total annual invoices", "Change records", "Tasks performed", etc., when these can reach enormous volumes and the cost of loading them is high.