System Health in Novulo

Novulo Contains functionality to check the validity and configuration in the application using System Health.

System Health contains various functionalities. This post will be expanded for all kinds of functionality.

Available now is:

  1. Expression Health, to check expression fields on validity
  2. Data structure health, to check data structure fields on validity
  3. Foreign key checks

Components

The core functionality is in M5018 (System Health) which should be installed in every application. Other components can add functionality.

System Health can be found at:
All Apps > Application maintenance > Settings > System Health.

Best practice

Always check System Health after an appliction update!

System Health: Expression fields health

Expression Fields Health validates all Expression Fields in your appliation.
In addition to M5018 you need M5185 installed.

It will add Expression Fields Health to your menu.

Expression field health checks all expression fields in your application on validity. Faulty expression cause errors in components. Checks include:

  1. Expressions in export definitions and import definitions
  2. Expressions in Data Definitions for REST and CMS
  3. Expressions in Workflow configurations
  4. Expressions in all other components that add expression-based business rules, including Stock replenishment rules or pricing rules

The expression fields are the autocomplete-fields that can be used to enter an expression.

What does it show?

Expression fields health shows all expression fields that are currently invalid. Expression fields are type-checked before they can be stored; invalid options cannot be stored.

So how can they become invalid?

Expression fields can become invalid with application releases when fields are removed or the name is changed. It occurs when removing components from the composition, or when updating components when changing field names (typo’s, correctness) or when re-structuring components. (See for example Why did the field stock_classification move? - #2 by j.batzke ). When this happens, it’s always communicated through Release notes.

When this happens, System Health Expression fields health will help you to show the fields that are not valid. In this example, the field name ‘faxx’ was corrected to ‘fax’, and the expression became invalid. As a result the export definition does no longer work.

How does Expression fields health work?

Expression fields health displays all fields that have an Expression error, on one page, creating your task list to fix all problems in one go.

In the example below, the problem with the ‘faxx’ is also displayed. You can go straight to the page, and fix it.

As you can see, the second row in the screen has a Quickfix.

This is, because this field is linked to the Reference Architecture. Fields that are in the Reference Architecture and have their GUID stored in the expression. This allows them to be fixed automatically using Quickfix.

You must quickfix these fields. They have an interesting aspect:

  1. They do show up in System Health and allow for quickfixing
  2. In the Expression field, nothing strange is seen. Pressing Edit > OK will not throw an error but, won’t fix it either.
  3. Processes like the export engine will throw an error
  4. Editing the field, changing anything that forces a commit will fix the error.

What do quickfixes do?

As soon as an expression has the Reference Architecture linked, from that moment on, field name changes can be processed automatically.

If a record type is available in the reference Architecture, but not yet registered as such in the expression, you see errors like this:

workflowstatevalues:load(302242).value_expression = sales:load(33086) [Incorrectly formatted (including incorrect and incomplete indentifiers)]

In this case, sales is mapped to the reference Architecture, but the link is not stored in the expression. But as the expression is valid, you don’t notice any issues in the application.

When you click quickfix, the expression is changed to:

sales~n_sales#ccafc1e2-d6d2-44d6-9812-215b522abf7a:load(33081)

The GUID here is the link to the reference architecture. From this moment on, if ever the name of the record type “sales” would change, it can be quickfixed.

For this example, we put an x to the sales in the expression so we get this error:

workflowstatevalues:load(302242).value_expression = xsales~n_sales#ccafc1e2-d6d2-44d6-9812-215b522abf7a:load(33081) [Incorrectly formatted (including incorrect and incomplete indentifiers)]

Quickfixing allows to correct this automatically. If it would not have been mapped, it would have required a manual intervention.

Hint: If you want to change a field name in an already-configured application, that’s not in the Reference Architecture yet, apply a two-step approach:

  1. First, add the field to the Reference Archticture and make an update
  2. Run a quickfix
  3. Then, run another update after the field name change and quickfix again

System Health: Data structure fields health

Data Structure Fields Health checks all dropdowns that store a Data type, as coming from the Data Structure plug-in.

Conceptually, it’s similar to the Expression Fields health: it checks if the data is still valid. Also, just like Expression Fields health, can become invalid when application updates change or remove data types.

It can be found at the “Data structure health” menu item. It shows all records with an invalid data structure field.

image

It then shows all Data structure fields. By default, it only shows active fields with errors. By using the checkboxes, you can also see the correct and inactive records.

In this example, the datatype ‘persons_typo’ is wrong. When you go to the page, you see that the form row that should show persons, is blank at (1).

Here, it can be fixed by editing the page and fixing the data type when it still exists. When the data type is removed from the application, you typically need to find an alternative solution, or remove your Data definition, export, import or workflow step, or any other element, that refered to this data type.

image

Quick fixes

When Record types are already mapped to the reference architecture, their GUID is stored. In these cases, name changes can be corrected automatically using Quickfix.

Difference between Data Structure Health and Expression field health

Data Structure Health and Expression field health are closely related. It also occurs often that updates where names are changed, cause errors in both Data structure fields and Expression fields. They are just different types of fields.

In this screenshot:

  1. The Record type at (1) is a Data structure field; errors are shown in Data structure health
  2. The Filter expression and Sort expression at (2) are Expression fields; these errors are shown in Expression fields health

System Health: Foreign Key Check

Another aspect of the System Health Check is the Foreign Key check.
This validates if foreign keys (search links, drop downs) still point to an existing record. Foreign keys which no longer point to an existing record can cause unexpected behaviour of your application.

These errors should never exist.

In real-world applications, we see various scenario’s that cause these validation error and therefore, need action.

Known causes are:

  1. Incomplete manual clean-up of application data
  2. Time-outs or other unwanted process abruption during regular delete processes within the application;
  3. Incorrect use of Cascading Delete Rules within specific components

Incorrect references need to be fixed through data manipulation, typically using the Import engine or workflows. Typically, and depending on the data, there are three ways to solve it

  1. Delete the record with the missing foreign key. This is often the desired route when the record was not correctly deleted during manual clean-up, or when cascading deletes failed;
  2. Unset the reference (give the column a NULL value); this can be needed when the record itself is valid, but an optional field was deleted. (Applies when cascading delete rules are applied incorrectly)
  3. Correct the incorrect reference to a another reference which is valid.

Of course, every type of data manipulation requires good knowledge about the application and data and should be applied carefully!

1 Like

Remark about this part:

Expression fields can become invalid with application releases when fields are removed or the name is changed . It occurs when removing components from the composition, or when updating components when changing field names (typo’s, correctness) or when re-structuring components.

In some cases when you change fields you have to write a data conversion, otherwise you would lose data.