Slicing is a mechanism to compute many variants of the same dashboard and let end-users interact with the resulting sliced dashboard through a search-like navigation. For example, through slicing, it is possible to create a product inspector which consolidates - for every product - all the KPIs and linecharts of interest.
The following script provides a simplistic variant of such a dashboard:
table Products[pid] = with [| as Product, as Color, as Price |] [| "pants", "blue", 25 |] [| "shirt", "white", 15 |] [| "socks", "green", 5|] table Slices[slice] = slice by pid title: Products.Product show table "My Products" a1c3 slices: Slice with Products.Product Products.Color Products.Price
In the above script, the creation of
Slices[slice] takes one option
Product.Product and a key
by pid. The option is the title, or name, of the slice. Slice names become part of the dashboard user interface, as the slice selector offers the possibility to select slices displayed through their names. The option is the group of the slice, in a process highly similar to the group tables detailed in a previous section. Finally, the
table tile gets sliced through the tile option
slices: slice. Note that we can reference
slice instead of
Products.slice, because the table used for the
show table is not ambiguous.
Slicing is a mechanism that impacts only tiles and only when specified at the tile level. When a tile is sliced, its input table (found as the common table among all its input vectors) gets partitioned across every single slice. The resulting tile is computed separately for each slice. Finally, the slice selector allows you to pick which slice gets displayed in the dashboard itself.
Slices can be defined at most once in an Envision script.
by behaves like it does for any aggregator, the only limitation being that the number of slices is limited to 200,000. In particular, it is possible to use multiple vectors through the usual syntax
by [expr1, expr2, expr3].
The creation of the table
Slices accepts an optional
subtitle to specify a label (the first argument is the name, see above). The label can be used to enrich the slice selector as illustrated by:
table Products = with [| as Product, as Color, as Price |] [| "pants", "blue", 25 |] [| "shirt", "pink", 15 |] [| "shirt", "white", 15 |] [| "socks", "green", 5|] table Slices[slice] = slice by Products.Product \ title: Products.Product \ subtitle: join(Products.Color; ", ") by Products.Product sort Products.Color show table "My Products" a1c3 slices: Slice with Products.Product Products.Color Products.Price
In the script above, the second argument
join(Products.Color; ", ") .. is the concatenation of the color values. Indeed, unlike the previous example, the
shirt slice has two elements instead of one as we are grouping by
Products.Product (while we were previously leveraging the autogenerated dimension
Pid of the
by Products.Products is required in the script above, but this requirement is somewhat accidental. As the table
Products appears on the left side of the assignment,
into Products is added by default to any aggregation that does not specify its
by on the right. However, in this case, the target table for the text concatenation is not the
Products table by the
Slices table itself. This quirk would also be eliminated by the future syntax (cf. roadmap above).
Advanced remarks: Envision, and its implementation by Lokad, is geared toward batch processing where scripts are run fast, from minutes (for the big ones) down to a few seconds (for the small ones). Once the execution of a script is complete, our goal is to maintain a latency under 500ms to display even very large dashboards over typical internet connections. However, our goal is not to run a script (even a small one) in milliseconds. Indeed, guaranteeing low latencies while supporting a language having the level of expressiveness of Envision is a devilishly difficult problem. The slicing mechanism can be seen as a way to cheat with latencies. Instead of being able to compute a small dashboard very fast (while enforcing plenty of restrictions on the computations themselves), Lokad precomputes up to a large number of dashboards (with no particular restrictions on the computations), and then serves the pre-computed results very fast. Under the hood, each slice remains stored on the server-side and only gets pushed to the client browser when the slice is effectively visited.