LCA Configuration

The LCA framework allows you to execute custom tasks on different events in an object life cycle.

Life Cycle Actions in Business Model

Life Cycle Actions are defined as a map between the action name and the action list in the lifecycleActions section of the configuration file.

An action can be specified in the following ways:

Current tenant action is specified by its name.
Shared action managed by Reltio is specified with a Reltio/prefix.

lifecycleActions

Example configuration:

"lifecycleActions": {
    "rawDataBeforeCleanse": [
      "FirstAction",
      "SecondAction",
      "Reltio/CommonAction",
      "Lambda/BinaryJSON/LambdaAction"
    ],
    "afterSave": [
      "AfterSaveAction"
    ]
}

In this configuration, rawDataBeforeCleanse and afterSave are action hooks which specify list of actions to be performed. A hook can contain either a list of simple actions or a list of action groups with a filter. If an action group has a filter, it will only be executed for entities that satisfy the specified filter condition. For more information, see Conditional Execution of LCA.

Life Cycle Actions in a list are executed sequentially, the next action gets the result of the previous actions as input.

Configuration Inheritance

Life Cycle Actions configuration is inherited from a parent object. Hooks that are specified only in one of the objects are taken as is. For hooks that are specified in both objects, actions from the parent object are added before actions for the current object. For example, assume that Party has lists of actions for beforeDelete and beforeSave, and Individual (which is inherited from Party) has lists of actions for beforeSave and afterSave. In this case, the resulting Individual has the following lists of actions:

beforeDelete (all from the configuration of Party)
beforeSave (a list of actions from Party, then a list of actions from the configuration of Individual)
afterSave (all from the configuration of Individual)

A customer Life Cycle Actions configuration object always overrides an object in different metadata configuration layers. For example, if you specify Life Cycle Actions for Party inside L1 and L3, only the final configuration from L3 is used.

Note: When you clone a profile, the Life Cycle Action (LCA) is not initiated. The LCA is executed only if you make any modifications to the cloned profile.

Configuration Scenarios

One of the most common uses of an LCA is to interrupt the normal processing of an entity, read its current values, and then write additional data to it either before the save or after the save. A good approach is to treat the LCA as a source. The LCA has exclusive ownership and control of a crosswalk within the entity. The values contributed into the entity by the LCA through the crosswalk are then easily managed against other values in the entity using Survivorship Rules.

Important: When the LCA writes a set of data back into the entity, it MUST explicitly mention the source to use - presumably the source that was assigned to this LCA per the best practice described above. Otherwise, if a reference to the source is omitted, the values being written are associated with ALL crosswalks that already exist in the source.

Support for Distributed Logging

Starting with 2016.1, the Reltio Platform components use log4j SocketAppender to log data in distributed storage with dynamic configuration from S3 configuration files. Reltio Platform components support distributed logging configuration using the S3 configuration file instead of editing log4j.dita files on every component directly.

LCA Execution Timeout

To ensure that custom LCA codes don’t affect Reltio’s performance, we’re timing out LCAs that take more than 100 milliseconds to run. This affects all new tenants provisioned after the 2023.2 release.

You’ll now see a message/alert in Reltio, when an LCA you created exceeds the threshold. The default timeout for Lambda and native LCAs is 100 milliseconds.

Unify and manage your data