Use of Nexel
1. Abstract
Nexel is a hugely powerful tool but it has its limitations, it’s important to understand when it’s appropriate to use Nexel and how best to store the original definition screen.
2. Context
Use of Nexel can be hugely powerful, and in some cases necessary in order to achieve certain outcomes, however there are limits to the number of cells it can process in one go which mean that its use should be carefully considered.
The original definition of Nexel is contained in the screen where it was originally created and saved, because of this it’s important to have a clear strategy for retention of these screens in case changes are to be made later on.
3. Content
Several factors drive the choice between using Nexel versus a data flow or a data reader, it’s important to properly consider the use case so as to select the best option.
3.1 When to Use Nexel
Several factors drive the choice between using Nexel versus a data flow or a data reader, it’s important to properly consider the use case so as to select the best option.
3.1.1 Nexel vs. Dataflows
While Nexel is a powerful tool, its use should generally only be considered where a data flow won’t suffice, after all a Nexel writeback requires creation in a screen, preservation of that screen to be able to modify or recreate the Nexel in future, and potentially recreation in multiple environments if the database itself isn’t being copied.
Where a data flow will suffice it will generally prove to be the best option due to the simplicity of their usage, the fact that anybody reveiewing a procedure can easily see at a glance what a data flow is doing, and the fact that the considerations previously mentioned for Nexel aren’t an issue with a data flow.
There are certain types of functionality however which are only possibly using Nexel:
- Looping procedure (where is necessary to identify the first row available and loop the procedure for any +1 row and keep track of the sequential action)
- Calculation where is needed a column or cell reference. An example is the write back of offset rules
- Use of Nexel only functions (particularly array based functions which can only be used with a Nexel Range)
- Non-daily date calculations using Date cubes (the difference between two date cubes can only be calculated at day level using a data flow, Nexel offers much broader functionality).
3.1.2 Nexel vs. Data Readers
If the need exists to remap hierarchical relationships on the fly as part of a procedure, the two ways in which this can be achieved are using Nexel or by extracting a layout and loading it in via data reader. While data readers are now concurrent in the latest versions of Board, and therefore less of an issue to use as part of ad-hoc functionality, it’s still often going to be preferable to achieve the same outcome using a Nexel layout where possible.
3.1.3 Limitations of Nexel
While being a hugely powerful tool, it’s not without limitations. Nexel calculation:
- Uses a cell-based approach that requires a high amount of resources detriment of performances
- It is based on the layout execution with all the limitations related to a large dataset
3.2 Storing Nexel Definitions
3.2.1 Where to store Nexel
A piece of Nexel is defined as a data view with a Nexel configuration specified, to be able to modify an existing Nexel without recreating it from scratch the original definition must be preserved. In order to ensure this is the case it’s a good idea to clearly indicate which screens are used to hold Nexel and which piece of Nexel each holds, if a system uses a large number of different Nexel write backs (for example a complex planning system) it might be best to devote an entire separate capsule to holding the various Nexel definitions, with one screen per Nexel, if only one or two are used, and if their use is limited to a particular capsule, you might simply store them as screens within that capsule which aren’t accessible by the end user.
3.2.2 Naming
Nexel is defined with and referred to by a unique name, Board does not assign a piece of Nexel an internal ID in the same way as other database objects, so it’s important to ensure that the same piece of Nexel is defined using the same name if it’s modified or recreated in a second environment. Creating a second Nexel with the same name as an existing Nexel will overwrite the pre-existing Nexel with the new definition, no warning will be given when this occurs.
Naming a piece of Nexel
In order to ensure it’s clear what a piece of Nexel does it’s a good idea to ensure that the name given to the Nexel accurately reflects its purpose in as succint a manner as possible, if a system involves a significant number of pieces of Nexel it’s important to ensure they’re all clearly named so as to distinguish them from each other and ensure correct usage.
Naming a Nexel definition screen
When saving the screen where a piece of Nexel is defined the naming will depend on whether you’ve devoted an entire capsule to your Nexel definitions, in which case you might simply name each screen the same as the Nexel itself, however if the screens for the Nexel definitions are simply stored in a capsule with other screens good practice might be to name the screens “NEXEL - <Nexel Name>” so as to group the screens together and clearly indicate what they’re used for. In order to ensure that if a Nexl needs to be modified or recreated in a new environment, the same name is used, it’s a good idea to either include the name of the Nexel in the screen name, or to have a label in the screen specifying the name of the Nexel, this means that the name can simply be copied and pasted when saving the Nexel, eliminating the possibility of a typo being made (if the name the Nexel is saved as differs from the intended name in any way, a new Nexel definition will be saved with the name specified with no warning given, any existing Nexel will not be overwritten and will still retain its previous definition).
Comments
-
Many thanks to @Robert Barkaway for all the insights on this subject!
0