Source System Management maintains references between the TCA Registry and any defined source system, such as a legacy or third party system, that loads data into the Registry. The source ID, or ID of the record in that external system, is mapped to the Registry ID of the TCA record, such as the party or contact point.
For example, you load a record with the ID 12345 from the Gorman system into the TCA Registry. That record is assigned the Registry ID 100 in the TCA Registry. The source ID, 12345, is referenced to Registry ID 100.
Note: By defining source systems, you ensure that when you load data from that system, a mapping record is created to maintain the reference between the source ID and the Registry ID.
Source System Management allows multiple source system references to one Registry ID. Examples of TCA entities that support multiple source references include the Party, Location, and Customer Account entities. The mappings can be between one Registry ID and source IDs from multiple source systems, or, if enabled, between one Registry ID and multiple source IDs from the same source system.
For example, Registry ID 100 is mapped to source ID 12345 from the Gorman system and source ID 99999 from the Elcaro system. If multiple references from the same source is allowed for the entity, Registry ID 100 can be mapped to source IDs 12345 and 67890 from the same Gorman system.
By mapping the IDs from the sources of your customer data to the TCA Registry IDs, your source systems can continue to operate, sending updates to and receiving updates from TCA. This operational mapping between the TCA Registry and multiple source systems allows you to:
Consolidate multiple customer databases, stored in various applications across different platforms, into the TCA Registry.
Create, maintain, share, and leverage an operational, single view of your customer information, or customer hub, across your enterprise.
This example shows how you can implement and use source systems.
You define a source system, for example, Gorman.
You load data from an external system into the TCA Registry, specifying both the source system name and source ID.
For example, you load a record for a party named Joe Smith from Gorman. You specify that the source system name is Gorman and that the source ID, or ID of Joe Smith in Gorman, is 12345.
Note: If you specify only the source ID, the mapping is only inserted for customer account level entities with unique references, with the source system name defaulted to UNKNOWN.
Users of an application that has implemented SSM can specify the source system name and source ID when they create or update records in the TCA Registry. They can also query records in the Registry using the source system name and source ID.
For example, the user enters a record for the party named Joe Smith and specify that the source system is Gorman and the source ID is 12345. Then, the user can query for Joe Smith using 12345 as the source ID and Gorman as the source system name.
You can encounter additional situations, for example:
When a source system is no longer used to provide data to one or more entities, you update the source system definition from Step 1 to indicate that the source system is inactive.
This inactivation prevents additional mapping records from being created for that source system and all TCA entities. Existing mappings to the source system remain active.
For example, you do not want to continue maintaining mappings between the Gorman source system and the TCA Registry for any new loaded data. You inactivate the Gorman system. The mappings between the Joe Smith record in the TCA Registry and the Joe Smith record in Gorman remain untouched.
When a party record is inactivated in the source system, the reference between the source ID and the Registry ID is not affected.
For example, the Joe Smith record in the Gorman system is inactivated. The mapping between Gorman 12345 and Joe Smith's Registry ID remains unchanged.
When a party record is inactivated in the TCA Registry, the reference between the source ID and the Registry ID is not affected. A BES callout for the party record inactivation is raised and applications that subscribe to the event are notified of the inactivation.
For example, the Joe Smith record in the HZ_PARTIES table is inactivated. The mapping between Gorman 12345 and Joe Smith's Registry ID remains unchanged. A BES callout from HZ_PARTIES is raised due to the inactivation, notifying subscribing applications.