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:
ENTITY_CHANGED
ENTITIES_MERGED (for Classic merge) or ENTITIES_MERGED_ON_THE_FLY (for on the fly scenario)
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.
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.Notify an external program
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.