Configuration Best Practices
To realize optimum performance from the Reltio platform, you must follow these best practices.
Reltio platform provides the following configuration best practices across a range of topics and object types. Reltio encourages our customers to work closely with their Customer Success Manager (CSM) and/or Reltio Professional services to gain clarity on these topics and optimize the configuration of their Reltio platform.
| Entity Configuration | |
| Max number of OV rulesets for an entity type: | 10 |
| Max number of match rules for an entity type: | 10 |
| Max number of Reference attributes in a entity: | 20 |
| Max number of Reference attributes from other entities to a single entity record(Not related to Nested Attributes): | 100 |
| Max number of populated attributes in an entity: | 200 |
| Max number of defined attributes in an entity type: | 500 |
| Relationship Configuration | |
| Max number of relationships between any two entity types: | 50 |
| Max number of attributes defined in a relationship type: | 50 |
| Maximum number of relationship types defined between any two entity types: | 50 |
| Relationship attributes must not contain reference attributes. | |
| Crosswalk Configuration | |
| Max number of crosswalks in an entity or relationship: | 200 |
| If a surrogate has been defined, it must be the same for all sources. | |
| Match Rules Configuration | |
| Use Negative match rules sparingly as they are resource intensive. | |
| When creating a match rule on an entity type where a surrogate crosswalk is defined, ensure that the match rules account for all attributes in the surrogate crosswalk to avoid matching issues. | |
| Entity or Relationship Configuration | |
| Max percent of an object’s attributes that must be nested: | 25% |
| Attributes Configuration | |
| Max number of values present in an attribute: | 4 |
| Nested Attributes Configuration | |
| Max number of sub-attributes in a nest: | 50 |
| Nested attributes must not contain reference attributes. (While the configuration will technically support this, it is not a supported use of the information model). | |
| Location Configuration | |
When using a relationship to link a party (for example) to a location
entity type, (for example use of the HasAddress
relationship type), make sure that all attributes like the ADDR
TYPE attribute are held in the relationship type and not in
the location entity. Otherwise you will just keep disconnecting the old
address and connecting to the new address rather than adding one for
each address type. | |
The cleanse configuration must contain the declaration,
"ovOnly": "true" which ensure that only the OV of
the address values will be sent for cleansing. | |
| The configuration for address cleansing must have a AVC Code for Status Mapping. | |
| At least one Address match rule must be defined. | |
All address match rules must include a match on the verification
status ="Verified". | |
| A surrogate key must be defined. | |
| The list of attributes defined in a surrogate crosswalk must be the same that are configured in the match rule. | |
| All the attributes that are used in the match rule must be defined in the surrogate crosswalk, even if the source does not provide the information. Even if the match rule is lenient, with few attributes, the same set of attributes must be used in the surrogate crosswalk. | |
| The survivorship strategy must be defined only for the lowest granular attribute (addressline1), all other attributes must be referring to the source of lowest granular attribute (other crosswalk winner). | |
| Reltio cleanser crosswalk must have the highest source priority. | |
| The cleanse button must be disabled in all UI configurations. | |
| RDM Configuration | |
Max number of lookups created in one POST to an RDM
tenant: | 100 |
| Maximum number of lookup values for all types: | 20,000 |
Delta Detection: Implementations MUST code delta detection and only
POST updates and inserts. | |
| If any attributes in the configuration use RDM, then all must use RDM. Otherwise any attributes not using RDM will be not be able to utilize a drop-down list in the UI. | |
| Every RDM Value set must include a source mapping for source "Reltio". | |
The "rdmConfig": {...} setting in the L3 must be
properly configured in order to link the MDM tenant to the RDM
tenant. | |
| LCA Configuration | |
| Carefully evaluate whether LCAs must be used or are appropriate. LCAs must only be used for short-running operations because they will impact performance. | |
| Ensure that the LCA is not performing data manipulation or calculation of derived data based on a specific source. Such logic must be designed and implemented at the source integration layer. | |
| LCAs must be disabled for the high volume loads if possible. (both initial and incremental). | |
| LCA must not invoke Reltio APIs as this can cause performance degradation and also possibly cause circular references. Reltio Engineering approval must be obtained for any exceptions. | |
| Ensure that the LCA code does not contain memory leaks, exploits, or attempts to work with file system/network and any other slow devices. | |
| Ensure that the LCA code does not contain Reltio classes defined in the LCA framework. | |
| Ensure that the LCA code does not contain any hard coded credentials. | |
| Ensure that the LCA code does not contain any output to a system. All outputs must be written using the logging service. | |
| All LCA Code must be submitted to engineering at least 3 weeks in advance of approval so it can be thoroughly tested via a test harness available on the Reltio repository for all the test cases. Submission to Reltio engineering is done by filing a support ticket with a link to a Bitbucket or git repository that holds the code. The ticket must fully explain the goal and strategy of the LCA. | |
| Submit test-run logs that ensure that the LCA code is executed with the minimum throughput of 1000tps. | |
| Submit test-run logs that ensure the latency due to the LCA call is no more than 10ms. | |
| Submit test-run logs that ensure the LCA code can be run in the multi-threaded environment. | |
| Ensure that the LCA code is well tested using the testing framework available on the Reltio maven repository. | |
| Ensure that the JAR file(s) is compiled and signed with the Life Cycle Handler implementation. | |
| Ensure that necessary filter condition is configured for every LCA (if applicable) in the L3 which will prevent unnecessary calls to the LCA module. | |
| We recommend that the attribute name must never be repeated across the L3 configuration. | |
| Streaming Configuration | |
| Ensure the streaming is disabled in the tenant if the applications it supports do not need streaming. | |
It is recommended to configure only Entity and Reltio URI in the
JMSEventsFilteringFields (physical configuration)
for better performance of the tenant. | |
| Disable the Streaming API before a task affecting large volume of data in the tenant such as Reindex the tenant. | |
| Ensure the streaming is disabled in the tenant if the applications it supports do not need streaming. | |
| UI Related Configuration | |
| Maximum Dashboard facets: | 20 |
| Maximum Pivot facets: | 20 |
| The number of tags displayed on the dashboard cannot exceed the Maximum: | 20 |
| Max number of entities rendered in relationship facet: | 500 |
| Maximum facets on a page: | No Max |
| Maximum Pivot attributes: | No Max |
| Each entity has its own perspective defined (that is, no default perspective). | |
| Each facet has proper labels defined. | |
| All UI extensions have a unique ID (No ID used twice). | |
| Data Loading Configuration | |
| Design data loads so that you do not update the same entity in a parallel thread in a single load (try to load each entity only once). | |
| Load data in appropriately sized batches and threads. | |
| Maximum number of references held within a reference attribute | |
| Maximum number of non-reference relationships between two entities | |
| Maximum number of related entities using non-reference relationships | |