Unify and manage your data

Show Page Sections

Match events

By default, all Match and Merge events from Reltio APIs are sent to queues or topics as messages in JSON format.

To understand matching and merging in Reltio, it is important to review Match, Merge, and Survivorship together since they are so closely related within the Reltio platform. See Reltio Match, Merge and Survivorship

Headers: tenantId; eventType; sourceObjectUri { "type": <string>, "updatedTime": <timestamp>, "uris": <List<string>> }

Merge entities

These events are generated during merge:

  1. ENTITY_CHANGED
  2. ENTITIES_MERGED (for Classic merge) or ENTITIES_MERGED_ON_THE_FLY (for on the fly scenario)
  3. ENTITY_LOST_MERGE

updatedTime appears only if JMSIncludeMergeTime: true (by default, it's false) is specified in the field, in the streaming configuration. Only type ENTITIES_MERGED is supported. The updatedTime includes the timestamp when the entities were merged.

The URIs include the URIs of all merge participants.

Internally, these event types are supported:

  • ENTITIES_MERGED: This event generates a background automatic process based on match rules. An event is triggered for the winner entity.
  • ENTITIES_MERGED_MANUALLY: This event is created when we manually merge entities.
  • ENTITIES_MERGED_ON_THE_FLY: This event generates an automatic process that merges entities in real time. For more information, see topic Merge-on-the-fly.
Note: When the system sends these event types to the external queue, it always converts the type of the event into ENTITIES_MERGED in the typeFilter property in the Tenant physical configuration streamingConfig-messaging->destinations section. Therefore, even if you indicate ENTITIES_MERGED_MANUALLY, or ENTITIES_MERGED_ON_THE_FLY, the propagated event is ENTITIES_MERGED.

Failed merges

Reltio has two types of match events to represent failed merge attempts due to system-imposed restrictions, for example, when exceeding crosswalk limits. Those events are ENTITIES_MERGE_FAILED and RELATIONS_MERGE_FAILED, and they are generated in case of the following merge errors:
  • OBJECT_TOO_LARGE_TO_SAVE_IT
  • MERGE_REQUEST_REJECTED_DUE_TO_OBJECT_CHANGES
  • MERGE_OF_OBJECTS_DIFFERENT_TYPES
  • FAILED_TO_MERGE_RELATIONS_WITH_THE_SAME_CROSSWALK
  • START_OR_END_ENTITIES_ARE_NOT_MATCHED
  • UNABLE_TO_COMBINE_MERGE_REQUESTS

These events are logged in the Activity Log for visibility and you can send them to external queues for real-time monitoring and corrective action. For more information, see topics Search using Activity Log API and Data streaming at a glance.

Notify an external program

Reltio supports two event types for notifying an external program to consider taking action on the event. These two events can be published to the queue using your match rule. The external program receives the event, get the profiles, and further analyze the event. These two events are:
  • POTENTIAL_LINK_FOUND: This event conveys that two profiles named in the event have characteristics that suggest they're potentially related to each other.
  • AUTO_LINK_FOUND:This event type can be used to strongly suggest that the two profiles are related to each other.

If the external program approves the event, then you can post a request to explicitly define a relationship between the two profiles.

Was this content helpful?