Custom Decision Point Logic

There are several decision points in the match process that can be defined by custom logic using custom plug-ins. The steps below are identical to those outlined in Inbound Message Processing Logic, but include descriptions of the decision points, which are listed in italic font. If no custom logic is defined, the decisions default to “false”, and processing is identical to that described in Inbound Message Processing Logic.

For more information about the methods and plug-ins, see Master Index Match Processing Logic Plug-ins in Oracle Java CAPS Master Index User’s Guide. For detailed information about the methods, see the Javadocs provided with Oracle Java CAPS Master Index. The methods are contained in the ExecuteMatchLogics class in the package com.sun.mdm.index.master.

1. When a message is received by the master index application, a search is performed for any existing records with the same local ID and system as those contained in the message. This search only includes records with a status of A, meaning only active records are included. If a matching record is found, an existing EUID is returned.

2. If an existing record is found with the same system and local ID as the incoming message, it is assumed that the two records represent the same entity. Using the EUID of the existing record, the master index application performs an update of the record’s information in the database.

   Custom plug-in decision point: If disallowUpdate is set to true, the update is not allowed and a MatchResult object is returned with a result code of 12. If disallowUpdate is set to false and rejectUpdate is set to true, the update is not allowed and a MatchResult object is returned with a result code of 13.

   • If the update does not make any changes to the object’s information, no further processing is required and the existing EUID is returned.

   • If there are changes to the object’s information, the updated record is inserted into database, and the changes are recorded in the sbyn_transaction table.

   • If there are changes to key fields (that is, fields used for matching or for the blocking query) and the update mode is set to pessimistic, potential duplicates are reevaluated for the updated record.

3. If no records are found that match the record’s system and local identifier, a second search is performed using the blocking query. A search is performed on each of the defined query blocks to retrieve a candidate pool of potential matches.

   Custom plug-in decision point: If bypassMatching is set to true, the search steps are bypassed and, if disallowAdd is set to false, a new record is added. If disallowAdd is set to true, the record is not added and a MatchResult object is returned with a result code of 11.

   Each record returned from the search is weighted using the fields defined for matching in the inbound message.

4. After the search is performed, the number of resulting records is calculated.

   • If a record or records are returned from the search with a matching probability weight above the match threshold, the master index application performs exact match processing (see Step 5).

   • If no matching records are found, the inbound message is treated as a new record. A new EUID is generated and a new record is inserted into the database.

5. If records were found within the high match probability range, exact match processing is performed as follows:

   • If only one record is returned from this search with a matching probability that is equal to or greater than the match threshold, additional checking is performed to verify whether the records originated from the same system (see Step 6).

   • If more than one record is returned with a matching probability that is equal to or greater than the match threshold and exact matching is set to false, then the record with the highest matching probability is checked against the incoming message to see if they originated from the same system (see Step 6).

   • If more than one record is returned with a matching probability that is equal to or greater than the match threshold and exact matching is true, a new EUID is generated and a new record is inserted into the database.

     Custom plug-in decision point: If disallowAdd is set to true, the new record is not inserted and a MatchResult object is returned with a result code of 11.

   • If no record is returned from the database search, or if none of the matching records have a weight in the exact match range, a new EUID is generated and a new record is inserted into the database.

     Custom plug-in decision point: If disallowAdd is set to true, the new record is not inserted and a MatchResult object is returned with a result code of 11.

6. When records are checked for same system entries, the master index application tries to retrieve an existing local ID using the system of the new record and the EUID of the record that has the highest match weight.

   • If a local ID is found and same system matching is set to true, a new record is inserted and the two records are considered to be potential duplicates. These records are marked as same system potential duplicates.

     Custom plug-in decision point: If disallowAdd is set to true, the new record is not inserted and a MatchResult object is returned with a result code of 11.

   • If a local ID is found and same system matching is set to false, it is assumed that the two records represent the same entity. Using the EUID of the existing record, the master index application performs an update, following the process described in Step 2 earlier.

     Custom plug-in decision point: If rejectAssumedMatch is set to true and disallowAdd is set to false, a new record is added; if disallowAdd is set to true, the new record is not inserted and a MatchResult object is returned with a result code of 11. If rejectAssumedMatch and disallowUpdate are set to false, the existing record is updated; if disallowUpdate is set to true, the update is not performed and a MatchResult object is returned with a result code of 13.

   • If no local ID is found, it is assumed that the two records represent the same entity and an assumed match occurs. Using the EUID of the existing record, the master index application performs an update, following the process described in Step 2 earlier.

     Custom plug-in decision point: If rejectAssumedMatch is set to true and disallowAdd is set to false, a new record is added; if disallowAdd is set to true, the new record is not inserted and a MatchResult object is returned with a result code of 11. If rejectAssumedMatch and disallowUpdate are set to false, the existing record is updated; if disallowUpdate is set to true, the update is not performed and a MatchResult object is returned with a result code of 13.

7. If a new record is inserted, all records that were returned from the blocking query are weighed against the new record using the matching algorithm. If a record is updated and the update mode is pessimistic, the same occurs for the updated record. If the matching probability weight of a record is greater than or equal to the potential duplicate threshold, the record is flagged as a potential duplicate (for more information about thresholds, see Oracle Java CAPS Master Index Configuration Reference ).