Understanding Sun Master Index Processing (Repository)

Understanding Master Index Operational Processes (Repository)

Master index applications created by Sun Master Index use a custom Java API library to transform and route data into and out of the master index database. In order to customize the way the Java methods transform the data, it is helpful to understand the logic of the primary processing functions and how messages are typically processed through the master index system.

The following topics describe and illustrate the processing flow of messages to and from the master index application, providing background information to help design and create custom processing rules for your implementation.

Learning About Master Index Message Processing (Repository)

This section provides a summary of how inbound and outbound messages can be processed in a master index application. A master index application cross-references records stored in various computer systems of an organization and identifies records that might represent or do represent the same object. The master index application uses Java CAPS components to connect to and share data with these external systems. The following topics provide information about inbound and outbound message processing.

Figure 1 illustrates the flow of information through a master index application that includes a JMS Topic to which updates to the index are published.

Figure 1 Master Index Processing Flow

Diagram shows the flow of information through a master
index system.

Master Index Inbound Message Processing (Repository)

An inbound message refers to the transmission of data from external systems to the master index database. These messages can be sent into the database through a number of Services. Inbound messages can be stored in journal files and tracked in the log files. The steps below describe how inbound messages are processed.

Messages are created in an external system, and the enveloped message is transmitted to the Enterprise Service Bus through that system’s eWay.
The Enterprise Service Bus identifies the message and the appropriate Service to which the message should be sent. The message is then routed to the appropriate Service for processing.
The message is modified into the appropriate format for the master index database, and validations are performed against the data elements of the message to ensure accurate delivery. The message is validated using the Java code in the Service’s Collaboration and other information stored in the master index configuration files.
If the message was successfully transmitted to the database, the appropriate changes to the database are processed.
After the master index application processes the message, an enterprise-wide universal identifier (EUID) is returned (for either a new or updated record). That EUID can be sent back out through a different Service to the external system. Alternatively, the entire updated message can be published using the outbound OTD (see Master Index Outbound Message Processing (Repository)).

Figure 2 below illustrates the flow of a message inbound to an Sun Master Index application.

Figure 2 Inbound Message Processing Data Flow

Diagram shows the flow of information when an inbound
message is processed.

About Inbound Messages

The format of inbound messages is defined by the inbound OTD, located in the client project for each external system. The inbound messages can either conform to the required format for the master index application or they can be mapped to the correct format in the Collaboration. The required format depends on how the object structure of the master index application is defined (in the Object Definition file in the master index project).

In addition to the objects and fields defined in the Object Definition file, you can include standard master index application fields. For example, you must include the system and local ID fields and you can also include transaction information, such as the date and time of the transaction, the transaction type, user ID, and so on. If you want to use transaction information from the source systems, be sure to include the fields in the OTD.

Transaction fields include the following:

MessageId
EventTypeCode
UserId
AssigningSystem
Source
Department
TerminalId
DateOfEvent
TimeOfEvent

If you do not send these fields into the master index application, default values are used (for example, the date and time fields default to the date and time the transaction is processed by the master index application). The inbound OTD also includes the standard Java methods marshal, unmarshal, marshalToString, unmarshalFromString, marshalToBytes, unmarshalFromBytes, and reset. For information about the default OTD for Sun Master Patient Index, see Understanding Sun Master Patient Index Configuration.

Master Index Outbound Message Processing (Repository)

An outbound message refers to the transmission of data from the master index database to any external system. Messages can be transmitted from the master index application in two ways. The first way is by transmitting the output of executeMatch (an EUID). This is described inMaster Index Inbound Message Processing (Repository) and is only used for messages received from external systems.

The second way is by publishing updates from the master index application to a JMS Topic, which allows you to publish complete, updated single best records (SBRs) to any system subscribing to that topic. When updates are made to the database from either external systems or the Enterprise Data Manager, the master index application generates outbound messages in the format of the outbound OTD.

Note –

A Sun master index application only publishes the outbound message to JMS Topics and not to JMS Queues.

This section describes how the second type of outbound message is processed. A JMS Topic must be defined in the Connectivity Maps for the master index server project and the appropriate client projects for this type of processing to occur.

When a message is received from an external system or data is entered through the Enterprise Data Manager (EDM), the master index application processes the information and generates an XML message, which is then sent to the JMS Topic that is configured to publish messages from the master index application.
Messages published by the JMS Topic are processed through a Service whose Collaboration uses the master index outbound OTD. This Service modifies the message into the appropriate format.
The Enterprise Service Bus identifies the message and the external systems to which it should be sent and then routes the message for processing by an external system eWay.

Note –
Outbound messages are stored and tracked in the Enterprise Service Bus journal and log files.

Figure 3 below illustrates the flow of data for a message outbound from a master index application.

Figure 3 Outbound Message Processing Data Flow

Diagram shows the flow of information for message sent
out from the master index application.

About Outbound Messages

When you generate the master index application, an outbound OTD is created, the structure of which is based on the object definition. This OTD is used to publish changes in the master index database to external systems using a JMS Topic. The output of the executeMatch process is an EUID of the new or updated record. You can use this EUID to obtain additional information and configure a Collaboration and Service to output the data, or you can process all updates in the master index application through a JMS Topic using the outbound OTD.

Outbound OTD Structure

The outbound OTD is named after the master index application (for example, OUTCompany or OUTPerson). This OTD contains eight primary nodes: Event, ID, SBR, and the standard Java methods marshal, unmarshal, marshalToString, unmarshalFromString, marshalToBytes, unmarshalFromBytes, and reset. The Event field is populated with the type of transaction that created the outbound message, and the ID field is populated with the unique identification code of that transaction. The SBR node is the portion of the OTD created from the Object Definition file. In the sample, the outbound OTD publishes messages in XML format. Table 1 describes the components of the SBR portion of the outbound OTD.

Table 1 Outbound OTD SBR Nodes


Node	Description
EUID	The EUID of the record that was inserted or modified.
Status	The status of the record.
CreateFunction	The date the record was first created.
CreateUser	The logon ID of the user who created the record.
UpdateSystem	The processing code of the external system from which the updates to an existing record originated.
ChildType	The name of the parent object.
CreateSystem	The processing code of the external system from which the record originated.
UpdateDateTime	The date and time the record was last updated.
CreateDateTime	The date and time the record was created.
UpdateFunction	The type of function that caused the record to be modified.
RevisionNumber	The revision number of the record.
UpdateUser	The logon ID of the user who last updated the record.
SystemObject	The object’s local identifier in a specified system. This field has three sub-fields: LID: The local ID assigned to the person in the system of origin. System: The processing code of the system of origin. Status: The status of the local ID in the enterprise record.
`Object_Name`	The fields in this node are defined by the object structure (as defined in the Object Definition file). It is named by the parent object and contains all fields and child objects defined in the structure. This section varies depending on the customizations made to the object structure.

Outbound Message Trigger Events

When outbound messaging is enabled, the following transactions automatically generate an outbound message that is sent to the JMS Topic (if a JMS Topic has been incorporated into the master index project).

Activating a system record
Activating an enterprise record
Adding a system record
Creating an enterprise record
Deactivating a system record
Deactivating an enterprise record
Merging an enterprise record
Merging a system record
Transferring a system record
Unmerging an enterprise record
Unmerging a system record
Updating an enterprise record
Updating a system record

Sample Outbound Message

The following text is a sample outbound message for a master index application based on a master person index. Your outbound messages might appear differently depending on how you configure the client project connectivity components.

<?xml version="1.0" encoding="UTF-8"?>
<OutMsg Event="UPD" ID="00000000000000044005">
<SBR EUID="1000008001"  Status="active" CreateFunction="Add" ChildType="Person" 
CreateSystem="System" UpdateFunction="Update" RevisionNumber="5" CreateUser="eview" 
UpdateSystem="System" UpdateDateTime="12/16/2003 17:40:44" 
CreateDateTime="12/16/2003 17:36:58" UpdateUser="eview">
<SystemObject SystemCode="CBMC" LID="434900094" Status="active">
</SystemObject>
<Person PersonId="00000000000000017000" PersonCatCode="PT" LastName="WRAND" 
FirstName="ELIZABETH" MiddleName="SU" Suffix="" Title="PHD" DOB="12/12/1972 00:00:00" 
Death="" Gender="F" MStatus="M" SSN="555665555" Race="B" Ethnic="23" Religion="AG" 
Language="ENGL" SpouseName="MARCUS" MotherName="TONIA" MotherMN="FLEMING" 
FatherName="JOSHUA" Maiden="TERI" PobCity="KINGSTON" PobState="" PobCountry="JAMAICA" 
VIPFlag="N" VetStatus="N" FnamePhoneticCode="E421" LnamePhoneticCode="RAN" 
MnamePhoneticCode="S250" MotherMNPhoneticCode="FLANANG" MaidenPhoneticCode="TAR" 
SpousePhoneticCode="M622" MotherPhoneticCode="T500" FatherPhoneticCode="J200" 
DriversLicense="CT111333111" DriversLicenseSt="CT" Dod="" DeathCertificate="" 
Nationality="USA" Citizenship="USA" PensionNo="" PensionExpDate="" RepatriationNo="" 
DistrictOfResidence="" LgaCode="" MilitaryBranch="NONE" MilitaryRank="NONE" 
MilitaryStatus="NONE" StdLastName="WRAND" StdMiddleName="SUSAN">
<Phone PhoneId="00000000000000011001" PhoneType="CC" Phone="9895558768" PhoneExt="">
</Phone>
<Phone PhoneId="00000000000000011000" PhoneType="CH" Phone="9895554687" PhoneExt="">
</Phone>
<Address AddressId="00000000000000011001" AddressType="H" AddressLine1="1220 BLOSSOM 
STREET" AddressLine2="UNIT 12" AddressLine3="" AddressLine4="" City="SHEFFIELD" 
StateCode="CT" PostalCode="09877" PostalCodeExt="" County="CAPEBURR" 
CountryCode="UNST" HouseNumber="1220" StreetDir="" StreetName="BLOSSOM" 
StreetNamePhoneticCode="BLASAN" StreetType="St">
</Address>
</Person>
</SBR>
</OutMsg>

Master Index Inbound Message Processing Logic (Repository)

When records are transmitted to the master index application, one of the “execute match” methods is usually called and a series of processes are performed to ensure that accurate and current data is maintained in the database. The execute match methods include executeMatch, executeMatchUpdate, executeMatchDupRecalc, and executeMatchUpdateDupRecalc. The EDM uses executeMatchGui. For more information about how these methods differ, refer to the Javadocs.

You can define these processes in the Collaboration using the functions defined in the customized method OTD. The steps performed by the standard executeMatch method are outlined below, and the diagrams on the following pages illustrate the message processing flow. The processing steps performed in your environment might vary from this depending on how you customize the Collaboration and Connectivity Map.

The steps outlined below refer to the following parameters in the Threshold file. They are described in Threshold Configuration (Repository) in Understanding Sun Master Index Configuration Options (Repository)).

OneExactMatch parameter
SameSystemMatch parameter
MatchThreshold parameter
DuplicateThreshold parameter
Update mode

Note –
There are several decision points in the match process that can be defined by custom logic using custom plug-ins. These decision points are not listed in the below steps, which describe the default processing logic.Master Index Custom Decision Point Logic (Repository) provides the same steps as below with the decision points included.
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 object. Using the EUID of the existing record, the master index application performs an update of the record’s information in the database.
  - 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 the 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.
  
  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.
  - 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.
    
    Note –
    Exact matching is determined by the OneExactMatch parameter, and the match threshold is defined by the MatchThreshold parameter. For more information about these parameters, see Threshold Configuration (Repository) in Understanding Sun Master Index Configuration Options (Repository).
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.
  - If a local ID is found and same system matching is set to false, it is assumed that the two records represent the same object. Using the EUID of the existing record, the master index application performs an update, following the process described in Step 2 above.
  - If no local ID is found, it is assumed that the two records represent the same object 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 above.
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 and the update mode, see Threshold Configuration (Repository) in Understanding Sun Master Index Configuration Options (Repository)).

The following flow charts provide a visual representation of the processes performed in the default configuration. Figure 4 and Figure 5 represent the primary flow of information. Figure 6 expands on update procedures illustrated in Figure 4 and Figure 5.

Figure 4 Inbound Message Processing

Diagram shows the initial processing steps performed
on an inbound message.

Figure 5 Inbound Message Processing (continued)

Diagram shows the final processing steps performed on
an inbound message.

Figure 6 Record Update Expansion

Diagram shows how updates are processed.

Master Index Custom Decision Point Logic (Repository)

You can customize the way the execute match methods process inbound messages by defining custom plug-ins that include decision-point methods. There are several decision points in the match process that can be defined by custom logic using custom plug-ins. This topic describes the standard inbound processing logic as described in Master Index Inbound Message Processing Logic (Repository), but also includes how the decision-point methods alter the process. If no custom logic is defined, the decisions default to false, and processing is identical to that described in Master Index Inbound Message Processing Logic (Repository).

For more information about the methods and plug-ins, see Master Index Match Processing Logic Plug-ins (Repository) in Developing Sun Master Indexes (Repository). For detailed information about the methods, see the Javadocs provided with Sun Master Index. The methods are contained in the ExecuteMatchLogics class in the package com.stc.eindex.master.

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.
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.
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.
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.
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.
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 above.
  
  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 above.
  
  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 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 Threshold Configuration (Repository) in Understanding Sun Master Index Configuration Options (Repository)).

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

Diagram shows the processing steps performed when activateEnterpriseObject
is called.

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

Diagram shows the processing steps performed when activateSystemObject
is called.

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

Diagram shows the processing steps performed when addSystemObject
is called.

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

Diagram shows the processing steps performed when deactivateSystemObject
is called.

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

Diagram shows the processing steps performed when deleteSystemObject
is called.

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

Diagram shows the processing steps performed when mergeEnterpriseObject
is called.

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

Diagram shows the processing steps performed when mergeSystemObject
is called.

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

Diagram shows the processing steps performed when transferSystemObject
is called.

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

Diagram shows the processing steps performed when undoAssumedMatch
is called.

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

Diagram shows the processing steps performed when unmergeEnterpriseObject
is called.

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

Diagram shows the processing steps performed when unmergeSystemObject
is called.

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

Diagram shows the processing steps performed when updateEnterpriseDupRecalc
is called.

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

Diagram shows the processing steps performed when updateEnterpriseObject
is called.

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

Diagram shows the processing steps performed when updateSystemObject
is called.