Link records based on expression strings

Credits to @m.gechev. Original is KB1670

Record Link Field

Since revision 115202, the Expression tools plugin provides a UI element in the architect that can be used to create a link to another record in the application.

This field is of numeric type and in a sense, it is an autocomplete element - just like search links. However, compared to search links, it can be configured to accept records of any type, whereas the search link can contain only one data type defined in the architect. This functionality allows making records like the ApplicationLogs much more lightweight.

Before the introduction of this Record link field, if one wanted to add a link between record X and Application logs, they would have to create a search link on the application logs. The same applies for record Y and any other record type that needs linking.

This process is now much easier with the usage of the Record link field. In combination with the DataStructure DataType field (which is mandatory for the usage of the Record link field), one record link field can contain any record type.

Dependencies

Data structure plugin is needed for the DataStructure DataType field.

Configuration

DataStructure DataType field

The configuration for this doesn’t really matter, as long as it’s valid. The field needs to be filled in with a valid Novulo record datatype string.

The Record Link field

  • Has only one configuration item: “Data type field”, which is used to provide a reference to a DataStructure DataType field.
  • The value of the record link field is the ID of the record to which the link should be made.

Example Configuration and Usage

In the architect, in my test model, I have the following on the application logs:

  • Both fields are not editable - the idea is to set these via Process (example will follow)
  • DataStructure datatype field with the following configuration:
  • Record link field with the following Plugin configuration:

Additionally, I created a function on the application logs, which implements an AliasDataFunction provided by the plugin (will become relevant). This allows for a more optimized way to create grids on such linked records to easily find which Application logs (in this case) belong to my record:

This is the AliasDataFunction to implement:
a95368a34a3d26c567e196a55e9ac522e627f1f1

  • Parameter: my current record
  • Return value: boolean
  • Under the hood, an expression string is built and evaluated which finds the combination of DataType and recordId that match the current record

Configuration:

55edf3e54e4f0c780d63c846bd482bf163b382d3

I use the RecordLink field to create a link between the application logs and a test record, “WhoAmI”. On the WhoAmI record I have:

  • A process to create an application log which is linked to my current WhoAmI record
  • A grid with application logs that are linked to the current WhoAmI record
    • The filter for the application logs grid uses the AliasDataFunction which was implemented above. It is used like this:

    • 697f0bcf14dac54f64b1f1cec4d70c4cd3e1a1bf

    • ParentContext returns the current record, which is the parameter for the function

Creating Record Links

To create a link between the ApplicationLogs and another record, one way (and the intended supported usage of this combination of plugin items) is as follows:

In a process, I have the parameter record (in my case it is the trigger) which I want to create a link to.
Using expression tools EvaluateExpression plugin action, I retrieve the DataType of the record to link (this is the input for the DataStructure DataType field)

Then I create my application log:

  • The DataStructure DataType is the evaluate expression .resulttype from the return values
  • The record link field gets the Id of the record to link (in my case, I can use trigger.id)

@Joeri @Joram @HibaalZoobe this would make a lot of concepts much cleaner!

@j.batzke great improvement, love to see this ‘morphing’ feature. Two questions:

  • What are your experiences on performance compared to searchlinks?
  • Are there (future) plans to replace a growing amount of search links on core concepts such as applogs and Activities?

Hey David, thanks for your question.

  • I have no personal experience with the performance of this feature, I am just the messenger :slight_smile: @m.gechev built it and @Stefan has implemented already. They probably have an answer.
  • As far as I know, there are no plans yet except for the gradual implementation for application logs. N_Activities might be a good suggestion for future

Hi David,

  • What are your experiences on performance compared to searchlinks?

I don’t think you can really compare performance between the two. Searchlinks - load Number of records of the configured type and you select one.

The record link field is simply a numeri field, used in combination with a Data structure field, in order to build up a reference to a record - You won’t get an option to select a record yourself - well you can enter the Data Type and ID of the record you want to link manually, but you will not see a Dropdown with possible results for records matching the configured datatype.

The record link field was developed with the idea that it is a non-editable field, that you can set from a process.
The goal is to actually replace all the (insert a big number here) of searchlinks on records like Application logs - there you have a search link PER possible record that can be linked to an Application log.
Well using the record link field - you can actually remove ALL these searchlinks and use a single RecordLink field instead, which can point to any registered data type

I think the statement above somewhat answers both of your points ? - you can use the record link field instead of search links, but who/when/if/should would convert all existing search links on the App logs for example, is something i do not know.

Greetings,
Miroslav

This development was actually launched with a performance case related to Application Logs, in an application with 20k+ log entries per day, 10M+ log entries and 50+ columns.

Having 2 columns for all references, means you only need one index on two columns to make it searchable.

With 50 columns, you need 50 indexes.

  1. When developers forgot the index, it easily caused 30 second queries
  2. Unfiltered, indexes took 500MB per column
  3. Even filtered, the insert statements consumed quite some SQL CPU to review all 50 indexes, even though only 1 applied
  4. Additionally, the Application log page started to load slow as evaluating 50+ search link visibility conditions added up to 500ms.

This new set-up solves all these four issues.

Read this if you want to use the plugin to filter records: