Master Index Primary Function Processing Logic (Repository)
The primary functions of a master index application can be performed from the Enterprise Data Manager or can be called from the Collaborations in the master index project. Whether potential duplicates are evaluated after a call to any of these functions is dependent on the update mode settings. Potential duplicates are only processed against the single best record (SBR) and not the system records. These functions are all located in the MasterController class, and are fully described in the Sun Master Index Javadocs. In the following diagrams, significant fields for potential duplicate processing include fields defined for matching and fields included in the blocking query used for matching. In all of the methods described below, an entry is made in the transaction history table (sbyn_transaction).
The following topics describe the logic for each primary master index function:
activateEnterpriseObject
This method reactivates an enterprise record. The EDM calls this method when you select an EUID and then click Activate EUID=EUID_number, (where EUID_number is the EUID of the enterprise record to reactivate). Since all potential duplicates were deleted when the EUID was originally deactivated, potential duplicates are always recalculated, regardless of the update mode. Figure 7 illustrates the processing steps.
Figure 7 activateEnterpriseObject Processing
activateSystemObject
This method reactivates a system record. The EDM calls this method when you select a system from the enterprise record tree and then click Activate system-ID (where system is the system code and ID is the local ID number for the system record to reactivate). If the update mode is set to “pessimistic”, the application checks whether any key fields were updated in the SBR. If key fields were updated, potential duplicates are recalculated for the enterprise record. Figure 8 illustrates the processing steps.
Figure 8 activateSystemObject Processing
addSystemObject
This method adds a system record to an enterprise record. The EDM calls this method when you add a system record to an existing enterprise record. If the update mode is set to “pessimistic”, the application checks whether any key fields were updated in the SBR. If key fields were updated and the update mode is set to pessimistic, potential duplicates are recalculated for the enterprise record. Figure 9 illustrates the processing steps.
Figure 9 addSystemObject Processing
createEnterpriseObject
There are two createEnterpriseObject methods, both of which add a new enterprise record to the database and bypass any potential duplicate processing. One method takes only one system record as a parameter and the other takes an array of system records. These methods cannot be called from the EDM and are designed for use in Collaborations.
deactivateEnterpriseObject
This method deactivates an enterprise record specified by its EUID. The EDM calls this method when you select an enterprise record and then click Deactivate EUID=EUID_number (where EUID_number is the EUID of the enterprise record to deactivate). When an enterprise record is deactivated, all potential duplicate listings for that record are deleted.
deactivateSystemObject
This method deactivates a system record in an enterprise record. The EDM calls this method when you select a system from the enterprise record tree and then click Deactivate system-ID (where system is the system code and ID is the local ID number for the system record to deactivate). If the enterprise record containing this system record has no active system records remaining, the enterprise record is deactivated and all potential duplicate listings are deleted. (Note that if the system record is reactivated, then the enterprise record is recreated.) If the enterprise record has active system records after the transaction and the update mode is set to “pessimistic”, the application checks whether any key fields were updated in the SBR. If key fields were updated, potential duplicates are recalculated for the enterprise record. Figure 10 illustrates the processing steps.
Figure 10 deactivateSystemObject Processing
deleteSystemObject
Unlike deactivateSystemObject, this method permanently removes a system record from an enterprise record. This method cannot be called from the EDM. If the enterprise record containing the deleted system record has no active system records remaining, the enterprise record is deactivated (even if the enterprise record does have deactivated system records). If the enterprise record has no remaining system records after the system object is deleted, the enterprise record is also deleted. In both cases, any potential duplicate listings for that enterprise record are removed. If the enterprise record has active system records after the transaction and the update mode is set to “pessimistic”, the application checks whether any key fields were updated in the SBR. If key fields were updated, potential duplicates are recalculated for the enterprise record. Figure 11 illustrates the processing steps.
Figure 11 deleteSystemObject Processing
mergeEnterpriseObject
There are four mergeEnterpriseObject methods that merge two enterprise records (see the Javadocs for more information about each). The EDM calls a merge method twice during a merge transaction. When you first click the EUID Merge arrow, the method is called with the calculateOnly parameter set to true in order to display the merge result record for you to view. When you confirm the merge, the EDM calls this method with the calculateOnly parameter set to false in order to commit the changes to the database and recalculate potential duplicates if needed. The method called by the EDM checks the SBRs of the records involved in the merge against their corresponding SBRs in the database. If the SBRs differ, the merge is not performed since that means the records were changed by someone else during the merge process.
When this method is called with calculateOnly set to false, the application changes the status of the merged enterprise record to merged and deletes all potential duplicate listings for the merged enterprise record. If the update mode is set to pessimistic, the application checks whether any key fields were updated in the SBR of the surviving enterprise record. If key fields were updated, potential duplicates are recalculated for the enterprise record. Figure 12 illustrates the processing steps, and includes the check for SBR differences, which only occurs in two of the merge methods.
Figure 12 mergeEnterpriseObject Processing
mergeSystemObject
There are four methods that merge two system records that are either from the same enterprise record or from two different enterprise records (for more information about each method, see the Javadocs provided with Sun Master Index). The system records must originate from the same external system. The EDM calls this method twice during a system record merge transaction. When you first click the LID Merge arrow, the method is called with the calculateOnly parameter set to true in order to display the merge result record for you to view. When you confirm the merge, the EDM calls this method with the calculateOnly parameter set to false in order to commit the changes to the database and recalculate potential duplicates if needed. Two of the merge methods compare the SBRs of the records with their corresponding SBRs in the database to ensure that no updates were made to the records before finalizing the merge.
When this method is called with calculateOnly set to “false”, the application changes the status of the merged system record to “merged”. If the system records were merged within the same enterprise record and the update mode is set to “pessimistic”, the application checks whether any key fields were updated in the SBR. If key fields were updated, potential duplicates are recalculated for the enterprise record.
If the system records originated from two different enterprise records and the enterprise record that contained the unkept the system record no longer has any active system records but does contain inactive system records, that enterprise record is deactivated and all associated potential duplicate listings are deleted. (Note that if the system records are unmerged, the enterprise record is reactivated.) If the enterprise record that contained the unkept system record no longer has any system records, that enterprise record is deleted along with any potential duplicate listings.
If both enterprise records are still active and the update mode is set to pessimistic, the application checks whether any key fields were updated in the SBR for each enterprise record. If key fields were updated, potential duplicates are recalculated for each enterprise record. Figure 13 illustrates the processing steps, and includes the check for SBR differences, which only occurs in two of the merge methods.
Figure 13 mergeSystemObject Processing
transferSystemObject
This method transfers a system record from one enterprise record to another. This method is not called from the EDM. If the enterprise record from which the system record was transferred no longer has any active system records (but still contains deactivated system records), that enterprise record is deactivated and any associated potential duplicate listings are removed. If the enterprise record from which the system record was transferred no longer has any system records, that enterprise record is deleted along with all associated potential duplicate listings. If both enterprise records are still active and the update mode is set to pessimistic, the application checks whether any key fields were updated in the SBR for each enterprise record. If key fields were updated, potential duplicates are recalculated for each enterprise record. Figure 14 illustrates the processing steps.
Figure 14 transferSystemObject Processing
undoAssumedMatch
This method reverses an assumed match made by the master index application, using the information from the system record that created the assumed match to create a new enterprise record. The EDM calls this method when you confirm the transaction after selecting Undo Assumed Match. Potential duplicates are calculated for the new record regardless of the update mode. If the update mode is set to pessimistic, the application checks whether any key fields were updated in the SBR of the original enterprise record. If key fields were updated, potential duplicates are recalculated for the enterprise record. Figure 15 illustrates the processing steps.
Figure 15 undoAssumedMatch Processing
unmergeEnterpriseObject
There are two methods that unmerge two enterprise records that were previously merged. One method unmerges the record without checking to make sure the SBR of the active record was not changed by another process before finalizing the merge and one method performs the SBR check (see the Javadocs provided with Sun Master Index for more information). The EDM calls this method twice during an unmerge transaction. When you first click Unmerge, the method is called with the calculateOnly parameter set to true in order to display the unmerge result records for you to view. When you confirm the unmerge, the EDM calls this method with the calculateOnly parameter set to false in order to commit the changes to the database and recalculate potential duplicates.
When this method is called with calculateOnly set to false, the application changes the status of the merged enterprise record back to active and recalculates potential duplicate listings for the record. If the update mode is set to “pessimistic”, the application checks whether any key fields were updated in the SBR of the enterprise record that was still active after the merge. If key fields were updated, potential duplicates are recalculated for that enterprise record. Figure 16 illustrates the processing steps and includes the check for SBR updates.
Figure 16 unmergeEnterpriseObject Processing
unmergeSystemObject
There are two methods that unmerge two system records that had previously been merged. One method unmerges the record without checking to make sure the SBR of the active record was not changed by another process before finalizing the merge and one method performs the SBR check (see the Javadocs provided with Sun Master Index for more information). The EDM calls this method twice during a system record unmerge transaction. When you first click Unmerge, the method is called with the calculateOnly parameter set to true in order to display the unmerge result record for you to view. When you confirm the unmerge, the EDM calls this method with the calculateOnly parameter set to false in order to commit the changes to the database and recalculate potential duplicates if needed.
When this method is called with calculateOnly set to false, the application changes the status of the merged system record back to active. If the source enterprise record (the record that contained the merge result system record after the merge) has more than one active system record after the unmerge and the update mode is set to pessimistic, the application checks whether any key fields were updated in that record. If key fields were updated, potential duplicates are recalculated for the source enterprise record.
If the source enterprise record has only one active system, potential duplicate processing is performed regardless of the update mode and of whether there were any changes to key fields. If the update mode is set to pessimistic, the application checks whether any key fields were updated in the SBR for destination enterprise record. If key fields were updated, potential duplicates are recalculated for each enterprise record. Figure 17 illustrates the processing steps, assuming the system record unmerge involves two enterprise records and including the check for SBR updates.
Figure 17 unmergeSystemObject Processing
updateEnterpriseDupRecalc
This method updates the database to reflect new values for an enterprise record. It processes records in the same manner as updateEnterpriseObject, but provides an override flag for the update mode that allows you to defer potential duplicate processing. The EDM does not call this method. If the enterprise record is deactivated during the update, potential duplicates are deleted for that record. If the enterprise record was changed during the transaction but is still active and the performPessimistic parameter is set to true, the application checks whether any key fields were updated in the SBR of the enterprise record. If key fields were updated, potential duplicates are recalculated. Figure 18 illustrates the processing steps.
Figure 18 updateEnterpriseDupRecalc Processing
updateEnterpriseObject
This method updates the database to reflect new values for an enterprise record, and is called from the EDM when you commit changes to an existing record. If the enterprise record is deactivated during the update, potential duplicates are deleted for that record. If the enterprise record is still active, was changed during the transaction, and the update mode is set to pessimistic, the application checks whether any key fields were updated in the SBR of the enterprise record. If key fields were updated, potential duplicates are recalculated. Figure 19 illustrates the processing steps.
Figure 19 updateEnterpriseObject Processing
updateSystemObject
There are two methods that update the database to reflect new values for a system record. One method updates the record without checking that there were no concurrent changes to the record, and the other method compares the SBR of the associated enterprise object in the transaction with that in the database to be sure there were no concurrent changes (see the Javadocs for more information). The EDM calls the method that checks for SBR changes when you commit changes to an existing system record.
If the enterprise record is deactivated during the update, potential duplicates are deleted for that record. If the enterprise record was changed during the transaction, the enterprise record is still active, and the update mode is set to pessimistic, the application checks whether any key fields were updated in the SBR of the enterprise record. If key fields were updated, potential duplicates are recalculated. Figure 20 illustrates the processing steps and includes the check for SBR changes though it only occurs with one of the methods.
Figure 20 updateSystemObject Processing
- © 2010, Oracle Corporation and/or its affiliates