The topics listed here provide conceptual information about standard processing logic for a master index application, the flow of data through a master index application, the database structure, and the dynamic Java API.
Note that Java CAPS includes two versions of Sun Master Index. Sun Master Index (Repository) is installed in the Java CAPS repository and provides all the functionality of previous versions in the new Java CAPS environment. Sun Master Index is a service-enabled version of the master index that is installed directly into NetBeans. It includes all of the features of Sun Master Index (Repository) plus several new features, like data als
nalysis, data cleansing, data loading, and an improved Data Manager GUI. Both products are components of the Sun Master Data Management (MDM) Suite. This document relates to Sun Master Index (Repository) only.
Several topics provide information and instructions for implementing and using a Repository-based master index application. For a complete list of topics related to working with Sun Master Index (Repository), see Related Topics in Developing Sun Master Indexes (Repository).
Sun Master Index provides a flexible framework that allows you to create matching and indexing applications called enterprise-wide master index applications. It is an application building tool to help you design, configure, and create a master index application that will uniquely identify and cross-reference the business objects stored in your system databases. Business objects can be any type of entity for which you store information, such as customers, patients, vendors, businesses, inventory, and so on.
When you create a master index application, custom database scripts and a custom Java API are automatically generated based on the information you specify in the wizard and the configuration files. Both the database scripts and API are derived from the object structure you define. For example, if you create a master index application with an Address object, the database scripts will define a table named SBYN_ADDRESS and one named SBYN_ADDRESSSBR. The Java API will include a class named AddressObject that includes “get” methods for each field you defined for the Address object.
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.
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.
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.
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.
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.
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.
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.
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.
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. |
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
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> |
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)).
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.
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 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.
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.
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.
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.
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).
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.
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.
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)).
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The following topics provide information about the master index database, including descriptions of each table and a sample entity relationship diagram. All information in these topics pertains to the default version of the database. Your implementation might vary depending on the customization made to the Object Definition and to the scripts used to create the master index database.
The master index database stores information about the entities being indexed, such as people or businesses. The database stores records from local systems in their original form and also stores a record for each object that is considered to be the single best record (SBR).
The structure of the database tables that store object information is dependent on the information specified in the Object Definition file created by the wizard. Sun Master Index generates a script to create the tables and fields in the database based on the information in the Object Definition file. If you update the Object Definition file, regenerating the application updates the database scripts accordingly. This allows you to define the database as you define the object structure.
While most of the structures created in the database are based on information in the Object Definition file, some of the tables, such as sbyn_seq_table and sbyn_common_detail, are standard for all implementations. The database includes tables that store information about the objects defined for the master index application as well as tables that store common maintenance information, transactional information, and external system information. The database includes the tables listed in Table 2.
Table 2 Master Index Database Tables
The tables in the following topics describe each column in the default database tables.
The columns are identical for Oracle and SQL Server databases, but the data types differ in some cases. Table 3 lists the data type differences, and the differences are noted in the Data Type column for each table in this section.
Table 3 Oracle and SQL Server Data Type Differences
Oracle Data Type |
SQL Server Data Type |
---|---|
BLOB |
Varbinary(MAX) |
DATE |
DateTime |
INTEGER |
Int |
LONG |
Varchar(MAX) |
NUMBER |
Numeric |
TIMESTAMP |
DateTime |
VARCHAR2 |
Varchar |
This table stores the parent object in each system record received by the master index application. It is linked to the tables that store each child object in the system record by the object_nameid column (where object_name is the name of the parent object). This table contains the columns listed below regardless of the design of the object structure, and also contains a column for each field you defined for the parent object in the Object Definition file. Columns to store standardized or phonetic versions of certain fields are automatically added when you specify certain match types in the wizard.
The differences in data types between Oracle and SQL Server are noted in Table 4. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 4 SBYN_OBJECT_NAME Table Description
Column Name |
Data Type |
Column Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The system code for the system record. |
|
VARCHAR2(25) Varchar(25) |
A local identification code assigned by the specified system. |
|
OBJECT_NAMEID |
VARCHAR2(20) Varchar(20) |
A unique ID for the parent object in a system record. This is named according to the parent object. For example, if the parent object is “Company”, the name of this column is “companyid”; if the parent object is “Person”, the name of this column is “personid”. |
FIELD_NAME |
Varies |
The name of each field in the parent object. A database column is created for each field, and the data type depends on the type specified in the Object Definition file. |
This table stores the parent object of the SBR for each enterprise object in the master index database. It is linked to the tables that store each child object in the SBR by the object_nameid column (where object_name is the name of the parent object). This table contains the columns listed below regardless of the design of the object structure, and also contains a column for each field defined for the parent object in the Object Definition file. In addition, columns to store standardized or phonetic versions of certain fields are automatically added when you specify certain match types in the wizard.
The differences in data types between Oracle and SQL Server are noted in Table 5. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 5 SBYN_OBJECT_NAMESBR Table Description
Column Name |
Data Type |
Column Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The enterprise unique identifier assigned by the master index application. |
|
OBJECT_NAMEID |
VARCHAR2(20) Varchar(20) |
A unique ID for the parent object in a system record. This is named according to the parent object. For example, if the parent object is “Company”, the name of this column is “companyid”; if the parent object is “Person”, the name of this column is “personid”. |
FIELD_NAME |
Varies |
The name of each field in the parent object. A database column is created for each field, and the data type depends on the type specified in the Object Definition file. |
The sbyn_child_object tables (where child_object is the name of a child object in the object structure) store information about the child objects associated with a system record in the master index application. All tables storing child object information for system records contain the columns listed below. The remaining columns are defined by the fields you specify for each child object in the object structure, including any standardized or phonetic fields.
The differences in data types between Oracle and SQL Server are noted in Table 6. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 6 SBYN_CHILD_OBJECT and SBYN_CHILD_OBJECTSBR Table Description
Column Name |
Data Type |
Column Description |
---|---|---|
OBJECT_NAMEID |
VARCHAR2(20) Varchar(20) |
The unique ID for the parent object associated with the child object in the system record. |
CHILD_OBJECTID |
VARCHAR2(20) Varchar(20) |
The unique ID for each record in the table. This column cannot be null. |
FIELD_NAME |
Varies |
The name of each field in the child object. A database column is created for each field, and the data type depends on the type specified in the Object Definition file. |
The sbyn_child_objectsbr tables (where child_object is the name of a child object in the object structure) store information about the child objects associated with an SBR in the master index application. All tables storing child object information for SBRs contain the columns listed below. The remaining columns are defined by the fields you specify for each child object in the Object Definition file, including any standardized or phonetic fields.
The differences in data types between Oracle and SQL Server are noted in Table 7. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 7 SBYN_CHILD_OBJECT and SBYN_CHILD_OBJECTSBR Table Description
Column Name |
Data Type |
Column Description |
---|---|---|
OBJECT_NAMEID |
VARCHAR2(20) Varchar(20) |
The unique ID for the parent object associated with the child object in the SBR. |
CHILD_OBJECTID |
VARCHAR2(20) Varchar(20) |
The unique ID for each record in the table. This column cannot be null. |
FIELD_NAME |
Varies |
The name of each field in the child object. A database column is created for each field, and the data type depends on the type specified in the Object Definition file. |
This table stores information about the applications used in the master index system. The differences in data types between Oracle and SQL Server are noted in Table 8. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 8 SBYN_APPL Table Description
Column Name |
Data Type |
Description |
---|---|---|
NUMBER(10) Numeric(10, 0) |
The unique sequence number code for the listed application. |
|
VARCHAR2(8) Varchar(8) |
A unique code for the application. |
|
VARCHAR2(30) Varchar(30) |
A brief description of the application. |
|
CHAR(1) |
An indicator of whether the current entry can be modified. If the value of this column is “Y”, the entry cannot be modified. |
|
DATE datetime |
The date the application entry was created. |
|
VARCHAR2(20) Varchar(20) |
The logon ID of the user who created the application entry. |
This table maintains a record of each assumed match transaction that occurs in the master index application, allowing you to review these transactions and, if necessary, reverse an assumed match. This table can grow quite large over time and might require periodic archiving. The differences in data types between Oracle and SQL Server are noted in Table 9. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 9 SBYN_ASSUMEDMATCH Table Description
Column Name |
Data Type |
Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The unique ID for the assumed match transaction. |
|
VARCHAR2(20) Varchar(20) |
The EUID into which the incoming record was merged. |
|
VARCHAR2(20) Varchar(20) |
The system code for the source system (that is, the system from which the incoming record originated). |
|
VARCHAR2(25) Varchar(25) |
The local ID of the record in the source system. |
|
VARCHAR2(20) Varchar(20) |
The matching weight between the incoming record and the EUID record into which it was merged. |
|
VARCHAR2(20) Varchar(20) |
The transaction number associated with the assumed match. |
This table maintains a log of each instance in which any of the master index database tables are accessed through the EDM. This includes each time a record appears on a search results page, a comparison page, the View/Edit page, and so on. This log is only maintained if the EDM is configured for it. This table can grow very large over time and might require periodic archiving. The differences in data types between Oracle and SQL Server are noted in Table 10. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 10 SBYN_AUDIT Table Description
Column Name |
Data Type |
Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The unique identification code for the audit record. This column cannot be null. |
|
VARCHAR2(20) Varchar(20) |
The name of the parent object as defined in the Object Definition file. |
|
VARCHAR2(15) Varchar(15) |
The EUID whose information was accessed during an EDM transaction. |
|
VARCHAR2(15) Varchar(15) |
The second EUID whose information was accessed during an EDM transaction. A second EUID appears when viewing information about merge and unmerge transactions, comparisons, and so on. |
|
VARCHAR2(32) Varchar(32) |
The type of transaction that caused the audit record to be written. This column cannot be null. |
|
VARCHAR2(120) Varchar(120) |
A brief description of the transaction that caused the audit record to be written. |
|
DATE datetime |
The date the transaction that created the audit record was performed. This column cannot be null. |
|
VARCHAR2(20) Varchar(20) |
The user ID of the person who performed the transaction that caused the audit log. This column cannot be null. |
This table stores the processing codes and descriptions for all of the common maintenance data elements. This is the detail table for sbyn_common_header. Each data element in sbyn_common_detail is associated with a data type in sbyn_common_header by the common_header_id column. None of the columns in this table can be null. The differences in data types between Oracle and SQL Server are noted in Table 11. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 11 SBYN_COMMON_DETAIL Table Description
Column Name |
Data Type |
Description |
---|---|---|
NUMBER(10) numeric(10, 0) |
The unique identification code of the common table data element. |
|
NUMBER(10) numeric(10, 0) |
The unique identification code of the common table data type associated with the data element (as stored in the common_header_id column of the sbyn_common_header table). |
|
VARCHAR2(20) Varchar(20) |
The processing code for the common table data element. |
|
VARCHAR2(50) Varchar(50) |
A description of the common table data element. |
|
CHAR(1) |
An indicator of whether the common table data element can be modified. |
|
DATE datetime |
The date the data element record was created. |
|
VARCHAR2(20) Varchar(20) |
The user ID of the person who created the data element record. |
This table stores a description of each type of common maintenance data and is the header table for sbyn_common_detail. Together, these tables store the processing codes and drop-down menu descriptions for each common table data type. For a person index, common table data types might include Religion, Language, Marital Status, and so on. For a business index, common table data types might include Address Type, Phone Type, and so on. None of the columns in this table can be null.
The differences in data types between Oracle and SQL Server are noted in Table 12. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 12 SBYN_COMMON_HEADER Table Description
Column Name |
Data Type |
Description |
---|---|---|
VARCHAR2(10) Varchar(10) |
The unique identification code of the common table data type. |
|
VARCHAR2(10) Varchar(10) |
The application ID from sbyn_appl that corresponds to the application for which the common table data type is used. |
|
VARCHAR2(8) Varchar(8) |
A unique processing code for the common table data type. |
|
VARCHAR2(50) Varchar(50) |
A description of the common table data type. |
|
CHAR(1) |
An indicator of whether an entry in the table is read-only (if this column is set to “Y”, the entry is read-only). |
|
NUMBER(10) numeric(10, 0) |
The maximum number of characters allowed in the code column for the common table data type. |
|
VARCHAR2(3) Varchar(3) |
This column is not currently used. |
|
DATE datetime |
The date the common table data type record was created. |
|
VARCHAR2(20) Varchar(20) |
The user ID of the person who created the common table data type record. |
This table stores a list of all the system and local ID pairs assigned to the enterprise records in the database, along with the associated EUID for each pair. This table is linked to sbyn_systemobject by the systemcode and lid columns, and is linked to sbyn_systemsbr by the euid column. This table maintains links between the SBR and its associated system objects. None of the columns in this table can be null.
The differences in data types between Oracle and SQL Server are noted in Table 13. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 13 SBYN_ENTERPRISE Table Description
Column Name |
Data Type |
Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The processing code of the system associated with the local ID. |
|
VARCHAR2(25) Varchar(25) |
The local ID associated with the system and EUID. |
|
VARCHAR2(20) Varchar(20) |
The EUID associated with the local ID and system. |
This table maintains a record of each merge transaction that occurs in the master index application, both through the EDM and from external systems. It also records any unmerges that occur. The differences in data types between Oracle and SQL Server are noted in Table 14. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 14 SBYN_MERGE Table Description
Column Name |
Data Type |
Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The unique, sequential identification code of merge record. This column cannot be null. |
|
VARCHAR2(20) Varchar(20) |
The EUID of the record that was retained after the merge transaction. This column cannot be null. |
|
VARCHAR2(20) Varchar(20) |
The EUID of the record that was not retained after the merge transaction. |
|
VARCHAR2(20) Varchar(20) |
The transaction number associated with the merge transaction. This column cannot be null. |
|
VARCHAR2(20) Varchar(20) |
The transaction number associated with the unmerge transaction. |
This table stores information about the fields that are locked for updates in the SBRs. It stores the EUID of the SBR, the ePath to the field, and the current locked value of the field. The differences in data types between Oracle and SQL Server are noted in Table 15. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 15 SBYN_OVERWRITE Table Description
Column Name |
Data Type |
Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The EUID of an SBR containing fields for which the overwrite lock is set. |
|
VARCHAR2(200) Varchar(20) |
The ePath to a field that is locked in an SBR from the EDM. |
|
VARCHAR2(20) Varchar(20) |
The data type of a field that is locked in an SBR. |
|
NUMBER(38) numeric(38, 0) |
The data that is locked for overwrite in an integer field. |
|
NUMBER(38) numeric(38, 0) |
The data that is locked for overwrite in a boolean field. |
|
VARCHAR2(200) Varchar(200) |
The data that is locked for overwrite in a string field. |
|
CHAR(2) |
The data that is locked for overwrite in a byte field. |
|
LONG varchar(MAX) |
The data that is locked for overwrite in a long integer field. |
|
DATE datetime |
The data that is locked for overwrite in a date field. |
|
NUMBER(38,4) numeric(38, 4) |
The data that is locked for overwrite in a floating decimal field. |
|
DATE datetime |
The data that is locked for overwrite in a timestamp field. |
This table maintains a list of all records that are potential duplicates of one another. It also maintains a record of whether a potential duplicate pair has been resolved or permanently resolved. The differences in data types between Oracle and SQL Server are noted in Table 16. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 16 SBYN_POTENTIALDUPLICATES Table Description
This table controls and maintains a record of the sequential identification numbers used in various tables in the database, ensuring that each number is unique and assigned in order. Several of the ID numbers maintained in this table are determined by the object structure. The numbers are assigned sequentially, but are cached in chunks of 1000 numbers for optimization (so the application does not need to query the sbyn_seq_table table for each transaction). The chunk size for the EUID sequence is configurable. If the server is reset before all allocated numbers are used, the unused numbers are discarded and never used, and numbering is restarted at the beginning of the next 1000-number chunk.
The differences in data types between Oracle and SQL Server are noted in Table 17. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 17 SBYN_SEQ_TABLE Table Description
Column Name |
Data Type |
Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The name of the object for which the sequential ID is stored. |
|
NUMBER(38) numeric(38, 0) |
The current value of the sequence. The next record will be assigned the current value plus one. |
The default sequence numbers are listed in Table 18.
Table 18 Default Sequence Numbers
Sequence Name |
Description |
---|---|
The sequence number that determines how EUIDs are assigned to new records. The chunk size for the EUID sequence number is configurable in the Threshold file. |
|
The sequence number assigned each potential duplicate transaction record in sbyn_potentialduplicates (column name “potentialduplicateid”). |
|
The sequence number assigned to each transaction in the master index application. This number is stored in sbyn_transaction (column name “transactionnumber”). |
|
The sequence number assigned to each assumed match transaction record in sbyn_assumedmatch (column name “assumedmatchid”). |
|
The sequence number assigned to each audit log record in sbyn_audit (column name “audit_id”). |
|
The sequence number assigned to each merge transaction in sbyn_merge (column name “merge_id”). |
|
The sequence number assigned to each application listed in sbyn_appl (column name “appl_id”) |
|
The sequence number assigned to each common table data type listed in sbyn_common_header (column name “common_header_id”). |
|
The sequence number assigned to each common table data element listed in sbyn_common_detail (column name “common_detail_id”). |
|
Each parent and child object system record table is assigned a sequential ID. The column names are named after the object (for example, sbyn_address has a sequential column named “addressid”). The parent object ID is included in each child object table. |
|
Each parent and child object SBR table is assigned a sequential ID. The column names are named after the object (for example, sbyn_addresssbr has a sequential column named “addressid”). The parent object ID is included in each child object SBR table. |
This table stores information about the system records in the database, including their local ID and source system pairs. It also stores transactional information, such as the create or update date and function. The differences in data types between Oracle and SQL Server are noted in Table 19. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 19 SBYN_SYSTEMOBJECT Table Description
This table stores information about each system integrated into the master index environment, including the system’s processing code and name, a brief description, the format of the local IDs, and whether any of the system information should be masked. The differences in data types between Oracle and SQL Server are noted in Table 20. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 20 SBYN_SYSTEMS Table Description
This table stores transactional information about the system records for the SBR, such as the create or update date and function. The sbyn_systemsbr table is indirectly linked to the sbyn_systemobjects table through sbyn_enterprise. The differences in data types between Oracle and SQL Server are noted in Table 21. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 21 SBYN_SYSTEMSBR Table Description
This table stores a history of changes made to each record in the master index application, allowing you to view a transaction history and to undo certain actions, such as merging two object records. The differences in data types between Oracle and SQL Server are noted in Table 22. The Oracle type is on the first line and the SQL Server type is on the second. This table also includes one column that has a different name for Oracle and for SQL Server.
Table 22 SBYN_TRANSACTION Table Description
Column Name |
Data Type |
Description |
---|---|---|
VARCHAR2(20) Varchar(20) |
The unique number of the transaction. |
|
VARCHAR2(25) Varchar(25) |
This column is reserved for future use. |
|
VARCHAR2(25) Varchar(25) |
The local ID of the second system record involved in the transaction. |
|
VARCHAR2(20) Varchar(20) |
This column is reserved for future use. |
|
VARCHAR2(20) Varchar(20) |
The EUID of the second object record involved in the transaction. |
|
OPERATION (SQL Server) |
VARCHAR2(20) Varchar(20) |
The type of transaction that occurred, such as update, add, merge, and so on. |
VARCHAR2(30) Varchar(30) |
The logon ID of the user who performed the transaction. |
|
TIMESTAMP datetime |
The date and time the transaction occurred. |
|
BLOB varbinary(MAX) |
A list of the changes that occurred to system records as a result of the transaction. |
|
VARCHAR2(20) Varchar(20) |
The processing code of the source system in which the transaction originated. |
|
VARCHAR2(25) Varchar(25) |
The local ID of the system record involved in the transaction. |
|
VARCHAR2(20) Varchar(20) |
The EUID of the enterprise record involved in the transaction. |
This table is similar to the sbyn_common_header and sbyn_common_detail tables in that it stores processing codes and drop-down list values. This table is used when the value of one field is dependent on the value of another. For example, if you store credit card information, you could list each credit card type and specify a required format for the credit card number field. The data stored in this table includes the processing code, a brief description, and the format of the dependent fields.
The differences in data types between Oracle and SQL Server are noted in Table 23. The Oracle type is on the first line, and the SQL Server type is on the second.
Table 23 SBYN_USER_CODE Table Description
The diagrams on the following pages illustrate the table structure and relationships for a sample Oracle database designed for storing information about companies. The diagrams display attributes for each database column, such as the field name, data type, whether the field can be null, and primary keys. They also show directional relationships between tables and the keys by which the tables are related. This diagram is very similar to SQL Server, with the exception of a few column name changes and some different data types as noted in the tables above.
Sun Master Index provides several Java classes and methods to use to transform and process data in a master index project. The master index API is specifically designed to help you maintain the integrity of the data in the database by providing specific methods for updating, adding, and merging records in the database.
The following topics provide information about the master index API and describe the dynamic API:
Sun Master Index provides a set of static API classes that can be used with any object structure and any Sun master index application. Sun Master Index also generates several dynamic API classes that are specific to the object structure of each master index application. The dynamic classes contain similar methods, but the number and names of methods change depending on the object structure. In addition, several methods are generated in an OTD for use in external system Collaborations and another set of methods is generated for use within an Business Process. For detailed information about the static classes and methods, see the Javadocs.
The following topics provide additional information about the different types of Java classes:
Static classes provide the methods you need to perform basic data cleansing functions against incoming data, such as performing searches, reviewing potential duplicates, adding and updating records, and merging and unmerging records. The primary class containing these functions is the MasterController class, which includes the executeMatch method. Several classes support the MasterController class by defining additional objects and functions. Documentation for the static methods is provided in Javadoc format. The static classes are listed and described in the Javadocs provided with Sun Master Index.
When you generate a master index project, several dynamic methods are created that are specific to the object structure defined for the master index application. This includes classes that define each object in the object structure and that allow you to work with the data in each object. If the object structure is modified, regenerating the project updates the dynamic methods for the new structure.
When you generate a master index project, a method OTD is created that contains Java methods to help you define how records are processed into the master index database from external systems. Like the dynamic object classes, these methods are based on the object structure. They rely on the dynamic object classes to create the objects in the master index application and to define and retrieve field values for those objects. Regenerating the master index application updates the methods to reflect any changes to the object structure.
When you generate a master index project, several methods are listed under the method OTD folder that are designed for use within a Business Process. These methods are a subset of the master index API that can be used to query a master index database using a web-based interface. As with the dynamic OTD methods, the Business Process methods are also based on the defined object structure. Regenerating a project updates these methods to reflect any changes to the object structure.
Several dynamic classes are generated for each master index application for use in Collaborations. One class is created for each parent and child object defined in the object structure.
The following topics list and describe the dynamic object classes:
A Java class is created to represent the parent object defined in the object definition of the master index application. The methods in this class provide the ability to create a parent object and to set or retrieve the field values for that object.
The name of the parent object class is the same as the name of each parent object, with the word “Object” appended. For example, if the parent object in your object structure is “Person”, the name of the parent class is “PersonObject”. The methods in this class include a constructor method for the parent object, and get and set methods for each field defined for the parent object. Most methods are named based on the name of the parent object and the fields and child objects defined for that object. In the following methods described for the parent object, ObjectName indicates the name of the parent object, Child indicates the name of a child object, and Field indicates the name of a field defined for the parent object.
class ObjectNameObject |
This is the user-defined object name class for the parent object. You can instantiate this class to create a new instance of the parent object class.
new ObjectNameObject()
None.
An instance of the parent object.
ObjectException
This method associates a new child object with the parent object. The new child object is of the type specified in the method name. For example, to associate a new address object with a parent object, call addAddress.
void addChild(ChildObject child)
The type of object passed as a parameter depends on the child object to associate with the parent object. For example, the syntax for associating an address object is as follows:
void addAddress(AddressObject address) |
Name |
Type |
Description |
---|---|---|
child |
ChildObject |
A child object to associate with the parent object. The name and type of the parameter is specified by the child object name. |
None.
ObjectException
This method associates a new child object with the parent object. The object node passed as the parameter defines the child object type.
void addSecondaryObject(ObjectNode obj) |
Name |
Type |
Description |
---|---|---|
obj |
ObjectNode |
An ObjectNode representing the child object to associate with the parent object. |
None.
SystemObjectException
This method copies the structure and field values of the specified object node.
ObjectNode copy() |
None.
A copy of the object node.
ObjectException
This method removes a child object associated with the parent object (in the memory copy of the object). The object node passed in as the parameter defines the child object type. Use this method to remove a child object before it has been committed to the database. This method is similar to ObjectNode.removeChild. Use ObjectNode.deleteChild to remove the child object permanently from the database.
void dropSecondaryObject(ObjectNode obj) |
Name |
Type |
Description |
---|---|---|
obj |
ObjectNode |
An ObjectNode representing the child object to drop from the parent object. |
None.
SystemObjectException
This method retrieves the unique identification code (primary key) of the object, as assigned by the master index application.
String getObjectNameId() |
None.
A string containing the unique ID of the parent object.
ObjectException
This method retrieves all child objects associated with the parent object that are of the type specified in the method name. For example, to retrieve all address objects associated with a parent object, call getAddress.
Collection getChild() |
None.
A collection of child objects of the type specified in the method name.
None.
This method retrieves the value of the field specified in the method name. Each getter method is named according to the fields defined for the parent object. For example, if the parent object contains a field named FirstName, the getter method for this field is named getFirstName.
String getField() |
The syntax for the getter methods depends on the type of data specified for the field in the object structure. For example, the getter method for a date field would have the following syntax:
Date getField |
None.
The value of the specified field. The type of data returned depends on the data type defined in the object definition.
ObjectException
This method retrieves a list of the names of all child object types defined for the object structure.
ArrayList getChildTags() |
None.
An array of child object names.
None.
This method retrieves the metadata for the parent object.
AttributeMetaData getMetaData() |
None.
An AttributeMetaData object containing the parent object’s metadata.
None.
This method retrieves all child objects that are associated with the parent object and are of the specified type.
Collection getSecondaryObject(String type) |
Name |
Type |
Description |
---|---|---|
type |
String |
The child type of the objects to retrieve. |
A collection of child objects of the specified type.
SystemObjectException
This method retrieves the value of the “add flag” for the parent object. The add flag indicates whether the object will be added.
String isAdded() |
None.
A Boolean value indicating whether the add flag is set to true or false.
ObjectException
This method retrieves the value of the “remove flag” for the parent object. The remove flag indicates whether the object will be removed.
String isRemoved() |
None.
A Boolean value indicating whether the remove flag is set to true or false.
ObjectException
This method retrieves the value of the “update flag” for the parent object. The update flag indicates whether the object will be updated.
String isUpdated() |
None.
A Boolean value indicating whether the update flag is set to true or false.
ObjectException
This method sets the value of the ObjectNameId field in the parent object.
void setObjectNameId(Object value) |
Name |
Type |
Description |
---|---|---|
value |
Object |
An object containing the value of the ObjectNameId field. |
None.
ObjectException
This method sets the value of the field specified in the method name. Each setter method is named according to the fields defined for the parent object. For example, if the parent object contains a field named “DateOfBirth”, the setter method for this field is named setDateOfBirth. A setter method is created for each field in the parent object, including any fields containing standardized or phonetic data.
void setField(Object value) |
Name |
Type |
Description |
---|---|---|
value |
Object |
An object containing the value of the field specified by the method name. |
None.
ObjectException
This method sets the “add flag” of the parent object. The add flag indicates whether the object will be added.
void setAddFlag(boolean flag) |
Name |
Type |
Description |
---|---|---|
flag |
Boolean |
An indicator of whether the add flag is set to true or false. |
None.
None.
This method sets the “remove flag” of the parent object. The remove flag indicates whether the object will be removed.
void setRemoveFlag(boolean e) |
Name |
Type |
Description |
---|---|---|
e |
Boolean |
An indicator of whether the remove flag is set to true or false. |
None.
None.
This method sets the “update flag” of the parent object. The update flag indicates whether the object will be updated.
void setUpdateFlag(boolean flag) |
Name |
Type |
Description |
---|---|---|
flag |
Boolean |
An indicator of whether the update flag is set to true or false. |
None.
None.
This method copies the structure of the specified object node.
ObjectNode structCopy() |
None.
A copy of the structure of the object node.
ObjectException
One Java class is created for each child object defined in the object definition of the master index application. If the object definition contains three child objects, three child object classes are created. The methods in these classes provide the ability to create the child objects and to set or retrieve the field values for those objects.
The name of each child object class is the same as the name of the child object, with the word “Object” appended. For example, if a child object in your object structure is named “Address”, the name of the corresponding child class is AddressObject. The methods in these classes include a constructor method for the child object, and get and set methods for each field defined for the child object. Most methods are named based on the name of the child object and the fields defined for that object. In the methods listed below, Child indicates the name of the child object and Field indicates the name of each field defined for that object.
class ChildObject |
This method represents the child object class. This class can be instantiated to create a new instance of a child object class.
new ChildObject() |
None.
An instance of the child object.
ObjectException
This method copies the structure and field values of the specified object node.
ObjectNode copy() |
None.
A copy of the object node.
ObjectException
This method retrieves the unique identification code (primary key) of the object, as assigned by the master index application.
String getChildId() |
None.
A string containing the unique ID of the child object.
ObjectException
This method retrieves the value of the field specified in the method name. Each getter method is named according to the fields defined for the child object. For example, if the child object contains a field named “TelephoneNumber”, the getter method for this field is named getTelephoneNumber. A getter method is created for each field in the object, including fields that store standardized or phonetic data.
String getField() |
The syntax for the getter methods depends on the type of data specified for the field in the object structure. For example, the getter method for a date field would have the following syntax:
Date getField |
None.
The value of the specified field. The type of data returned depends on the data type defined in the object definition.
ObjectException
This method retrieves the metadata for the child object.
AttributeMetaData getMetaData() |
None.
An AttributeMetaData object containing the child object’s metadata.
None.
This method retrieves the name of the parent object of the child object.
String getParentTag() |
None.
A string containing the name of the parent object.
None.
This method sets the value of the ChildId field in the child object.
void setChildId(Object value) |
Name |
Type |
Description |
---|---|---|
value |
Object |
An object containing the value of the ChildId field. |
None.
ObjectException
This method sets the value of the field specified in the method name. Each setter method is named according to the fields defined for the parent object. For example, if the parent object contains a field named “CompanyName”, the setter method for this field is named setCompanyName.
void setField(Object value) |
Name |
Type |
Description |
---|---|---|
value |
Object |
An object containing the value of the field specified by the method name. |
None.
ObjectException
This method copies the structure of the specified object node.
ObjectNode structCopy() |
None.
A copy of the structure of the object node.
ObjectException
A set of Java methods are created in an OTD for use in the master index Collaborations. These methods wrap static Java API methods, allowing them to work with the dynamic object classes. Many OTD methods return objects of the dynamic object type, or they use these objects as parameters. In the following methods described for the OTD methods, ObjectName indicates the name of the parent object.
The following topics list and describe the dynamic OTD methods.
This method changes the status of a deactivated enterprise object back to active.
void activateEnterpriseRecord(String euid) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object to activate. |
None.
RemoteException
ProcessingException
UserException
This method changes the status of a deactivated system object back to active.
void activateSystemRecord(String systemCode, String localId) |
Name |
Type |
Description |
---|---|---|
systemCode |
String |
The processing code of the system associated with the system record to be activated. |
localID |
String |
The local identifier associated with the system record to be activated. |
None.
RemoteException
ProcessingException
UserException
This method adds the system object to the enterprise object associated with the specified EUID.
void addSystemRecord(String euid, SystemObjectBean systemObject) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object to which you want to add the system object. |
systemObject |
SystemObjectBean |
The Bean for the system object to be added to the enterprise object. |
None.
RemoteException
ProcessingException
UserException
This method changes the status of an active enterprise object to inactive.
void deactivateEnterpriseRecord(String euid) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object to deactivate. |
None.
RemoteException
ProcessingException
UserException
This method changes the status of an active system object to inactive.
void deactivateSystemRecord(String systemCode, String localId) |
Name |
Type |
Description |
---|---|---|
systemCode |
String |
The system code of the system object to deactivate. |
localid |
String |
The local ID of the system object to deactivate. |
None.
RemoteException
ProcessingException
UserException
executeMatch is one of two methods you can call to process an incoming system object based on the configuration defined for the Manager Service and associated runtime components (the second method is executeMatchUpdate). This process searches for possible matches in the database and contains the logic to add a new record or update existing records in the database. One of the two execute match methods should be used for inserting or updating a record in the database.
The following runtime components configure executeMatch.
The Query Builder defines the blocking queries used for matching.
The Threshold file (master.xml) specifies which blocking query to use and specifies matching parameters, including duplicate and match thresholds.
The pass controller and block picker classes specify how the blocking query is executed.
If executeMatch determines that an existing system record will be updated by the incoming record, it replaces the entire existing record with the information in the new record. This could result in loss of data; for example, if the incoming record does not include all address information, existing address information could be lost. To avoid this, use the executeMatchUpdate method instead.
MatchColResult executeMatch(SystemObjectBean systemObject) |
Name |
Type |
Description |
---|---|---|
systemObject |
SystemObjectBean |
The Bean for the system object to be added to or updated in the enterprise object. |
A match result object containing the results of the matching process.
RemoteException
ProcessingException
UserException
Like executeMatch, executeMatchUpdate processes the system object based on the configuration defined for the Manager Service and associated runtime components. It is configured by the same runtime components as executeMatch. One of these two execute match methods should be used for inserting or updating a record in the database.
The primary difference between these two methods is that when executeMatchUpdate finds that an incoming record matches an existing record, only the changed data is updated. With executeMatch, the entire existing record is replaced by the incoming record. The executeMatchUpdate method differs from executeMatch in the following ways:
If a partial record is received, executeMatchUpdate only updates fields whose values are different in the incoming record. Unless the clearFieldIndicator field is used, empty or null fields in the incoming record do not update existing values.
The clearFieldIndicator field can be used to null out specific fields.
Child objects in the existing record are not deleted if they are not present in the incoming record.
Child objects in the existing record are updated if the same key field value is found in both the incoming and existing records.
To allow a child object to be removed from the parent object when using executeMatchUpdate, a new “delete” method is added to each child object bean.
MatchColResult executeMatchUpdate(SystemObjectbean systemObject) |
Name |
Type |
Description |
---|---|---|
systemObject |
SystemObjectBean |
The Bean for the system object to be added to or updated in the enterprise object. |
A match result object containing the results of the matching process.
RemoteException
ProcessingException
UserException
This method obtains a handle to the MasterController class, providing access to all of the methods of that class. For more information about the available methods in this class, see the Javadoc provided with Sun Master Index.
MasterController findMasterController() |
None.
A handle to the com.stc.eindex.ejb.master.MasterController class.
None.
This method returns the enterprise object associated with the specified EUID.
EnterpriseObjectName getEnterpriseRecordByEUID(String euid) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object you want to retrieve. |
An enterprise object associated with the specified EUID or null if the enterprise object is not found.
RemoteException
ProcessingException
UserException
This method returns the enterprise object associated with the specified system code and local ID pair.
EnterpriseObjectName getEnterpriseRecordByLID(String system, String localid) |
Name |
Type |
Description |
---|---|---|
system |
String |
The system code of a system associated with the enterprise object to find. |
localid |
String |
A local ID associated with the specified system. |
An enterprise object or null if the enterprise object is not found.
RemoteException
ProcessingException
UserException
This method returns the EUID of the enterprise object associated with the specified system code and local ID.
String getEUID(String system, String localid) |
Name |
Type |
Description |
---|---|---|
system |
String |
A known system code for the enterprise object. |
localid |
String |
The local ID corresponding with the given system. |
A string containing an EUID or null if the EUID is not found.
RemoteException
ProcessingException
UserException
This method retrieves the local ID and system pairs associated with the given EUID.
SystemObjectNamePK[] getLIDs(String euid) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object whose local ID and system pairs you want to retrieve. |
An array of system object keys (SystemObjectNamePK objects) or null if no results are found.
RemoteException
ProcessingException
UserException
This method retrieves the local ID and system pairs that are of the specified status and that are associated with the given EUID.
SystemObjectNamePK[] getLIDsByStatus(String euid, String status) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object whose local ID and system pairs to retrieve. |
status |
String |
The status of the local ID and system pairs you want to retrieve. |
An array of system object keys (SystemObjectNamePK objects) or null if no system object keys are found.
RemoteException
ProcessingException
UserException
This method retrieves the single best record (SBR) associated with the specified EUID.
SBRObjectName getSBR(String euid) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object whose SBR you want to retrieve. |
An SBR object or null if no SBR associated with the specified EUID is found.
RemoteException
ProcessingException
UserException
This method retrieves the system object associated with the given system code and local ID pair.
SystemObjectName getSystemRecord(String system, String localid) |
Name |
Type |
Description |
---|---|---|
system |
String |
The system code of the system object to retrieve. |
localid |
String |
The local ID of the system object to retrieve. |
A system object containing the results of the search or null if no system objects are found.
RemoteException
ProcessingException
UserException
This method returns the active system objects associated with the specified EUID.
SystemObjectName[] getSystemRecordsByEUID(String euid) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object whose system objects you want to retrieve. |
An array of system objects associated with the specified EUID.
RemoteException
ProcessingException
UserException
This method returns the system objects of the specified status that are associated with the given EUID.
SystemObjectName[] getSystemRecordsByEUIDStatus(String euid, String status) |
Name |
Type |
Description |
---|---|---|
euid |
String |
The EUID of the enterprise object whose system objects you want to retrieve. |
status |
String |
The status of the system objects you want to retrieve. |
An array of system objects associated with the specified EUID and status, or null if no system objects are found.
RemoteException
ProcessingException
UserException
This method first looks up the EUID associated with the specified source system and source local ID. It then retrieves the local ID and system pairs of the specified status that are associated with that EUID and are from the specified destination system. Note that both systems must be of the specified status or an error will occur.
SystemObjectNamePK[] lookupLIDs(String sourceSystem, String sourceLID, String destSystem, String status) |
Name |
Type |
Description |
---|---|---|
sourceSystem |
String |
The system code of the known system and local ID pair. |
sourceLID |
String |
The local ID of the known system and local ID pair. |
destSystem |
String |
The system of origin for the local ID and system pairs you want to retrieve. |
status |
String |
The status of the local ID and system pairs to retrieve. |
An array of system object keys (SystemObjectNamePK objects).
RemoteException
ProcessingException
UserException
This method merges two enterprise objects, specified by their EUIDs.
MergeObjectNameResult mergeEnterpriseRecord(String fromEUID, String toEUID, boolean calculateOnly) |
Name |
Type |
Description |
---|---|---|
fromEUID |
String |
The EUID of the enterprise object that will not survive the merge. |
toEUID |
String |
The EUID of the enterprise object that will survive the merge. |
calculateOnly |
boolean |
An indicator of whether to commit changes to the database or to simply compute the merge results. Specify false to commit the changes. |
A merge result object containing the results of the merge.
RemoteException
ProcessingException
UserException
This method merges two system objects, specified by their local IDs, from the specified system. The system objects can belong to a single enterprise object or to two different enterprise objects.
MergeObjectNameResult mergeSystemRecord(String sourceSystem, String sourceLID, String destLID, boolean calculateOnly) |
Name |
Type |
Description |
---|---|---|
sourceSystem |
String |
The processing code of the system to which the two system objects belong. |
sourceLID |
String |
The local ID of the system object that will not survive the merge. |
destLID |
String |
The local ID of the system object that will survive the merge. |
calculateOnly |
boolean |
An indicator of whether to commit changes to the database or to simply compute the merge results. Specify false to commit the changes. |
A merge result object containing the results of the merge.
RemoteException
ProcessingException
UserException
This method performs a blocking query against the database using the blocking query specified in the Threshold file and the criteria contained in the specified object bean.
SearchObjectNameResult searchBlock(ObjectNameBean searchCriteria) |
Name |
Type |
Description |
---|---|---|
searchCriteria |
ObjectNameBean |
The search criteria for the blocking query. |
The results of the search.
RemoteException
ProcessingException
UserException
This method performs an exact match search using the criteria specified in the object bean. Only records that exactly match the search criteria are returned in the search results object.
SearchObjectNameResult searchExact(ObjectNameBean searchCriteria) |
Name |
Type |
Description |
---|---|---|
searchCriteria |
ObjectNameBean |
The search criteria for the exact match search. |
The results of the search stored in a SearchObjectNameResult object.
RemoteException
ProcessingException
UserException
This method performs a search using phonetic values for some of the criteria specified in the object bean. This type of search allows for typographical errors and misspellings.
SearchObjectNameResult searchPhonetic(ObjectNameBean searchCriteria) |
Name |
Type |
Description |
---|---|---|
searchCriteria |
ObjectNameBean |
The search criteria for the phonetic search. |
The results of the search.
RemoteException
ProcessingException
UserException
This method transfers a system record from one enterprise record to another enterprise record.
void transferSystemRecord(String toEUID, String systemCode, String localID) |
Name |
Type |
Description |
---|---|---|
toEUID |
String |
The EUID of the enterprise record to which the system record will be transferred. |
systemCode |
String |
The processing code of the system record to transfer. |
localID |
String |
The local ID of the system record to transfer. |
None.
RemoteException
ProcessingException
UserException
This method updates the fields in an existing enterprise object with the values specified in the fields the enterprise object passed in as a parameter. When updating an enterprise object, attempting to change a field that is not updateable will cause an exception. This method does not update the SBR; the survivor calculator updates the SBR once the changes are made to the associated system records.
void updateEnterpriseRecord(EnterpriseObjectName enterpriseObject) |
Name |
Type |
Description |
---|---|---|
enterpriseObject |
EnterpriseObjectName |
The enterprise object containing the values that will update the existing enterprise object. |
None.
RemoteException
ProcessingException
UserException
This method updates the existing system object in the database with the given system object.
void updateSystemRecord(SystemObjectName systemObject) |
Name |
Type |
Description |
---|---|---|
systemObject |
SystemObjectName |
The system object to be updated to the enterprise object. Note – In the method OTD, “Object” in the parameter name is changed to the name of the parent object. For example, if the parent object is “Person”, the name of this parameter will appear as “systemPerson”. |
None.
RemoteException
ProcessingException
UserException
A set of Java methods are created in the master index application for use in Business Processes. These methods include a subset of the dynamic OTD methods, which are documented above. Many of these methods return objects of the dynamic object type or they use these objects as parameters. In the descriptions for these methods, ObjectName indicates the name of the parent object.
The following methods are available for Business Processes. They are described in the previous section, Dynamic Master Index OTD Methods (Repository).
Helper classes include objects that can be passed as parameters to an OTD method or a Business Process method. They also include the methods that you can access through the systemObjectName variable in client Collaborations or Business Processes (where ObjectName is the name of a parent object. The helper classes include:
In order to run executeMatch or executeMatchUpdate in a Java Collaboration or Business Process, you must define a variable of the class type SystemObjectName, where ObjectName is the name of a parent object. This class is passed as a parameter to the execute match methods. The class contains a constructor method and several get and set methods for system fields. It also includes one field that specifies the value of the clear field character (for more information, see ClearFieldIndicator Field). In the methods described in this section, ObjectName indicates the name of the parent object, Child indicates the name of a child object, and Field indicates the name of a field defined for the parent object.
class SystemObjectName |
The following methods are inherited from java.lang.Object.
equals
hashcode
notify
notifyAll
toString
wait()
wait(long arg)
wait(long timeout, int nanos)
The ClearFieldIndicator field allows you to specify whether to treat a field in the parent object as null when performing an update from an external system. When an update is performed in the master index application, empty fields typically do not overwrite the value of an existing field. You can specify to nullify a field that already has an existing value in the master index application by entering an indicator in that field. This indicator is specified by the ClearFieldIndicator field. By default, the ClearFieldIndicator field is set to double-quotes (“”), so if a field is set to double-quotes, that field will be blanked out. If you do not want to use this feature, set the clear field indicator to null.
This method is the user-defined system class for the parent object. You can instantiate this class to create a new instance of the system class.
new SystemObjectName() |
None.
An instance of the SystemObjectName class.
ObjectException
This method retrieves the value of the ClearFieldIndicator field.
Object getClearFieldIndicator() |
None.
An object containing the value of the ClearFieldIndicator field.
None.
This method retrieves the value of the specified system field. There are getter methods for the following fields: LocalId, SystemCode, Status, CreateDateTime, CreateFunction, and CreateUser.
String getField() |
or
Date getField() |
None.
The value of the specified field. The type of value returned depends on the field from which the value was retrieved.
ObjectException
This method retrieves the parent object Java Bean for the system record.
ObjectNameBean getObjectName() |
None.
A Java Bean containing the parent object.
None.
This method sets the value of the clear field character (in the ClearFieldIndicator field). By default, this is set to double quotes (“”).
void setClearFieldIndicator(String value) |
Name |
Type |
Description |
---|---|---|
value |
String |
The value that should be entered into a field to indicate that any existing values should be replaced with null. |
None.
None.
This method sets the value of the specified system field. There are setter methods for the following fields: LocalId, SystemCode, Status, CreateDateTime, CreateFunction, and CreateUser.
void setField(value) |
Name |
Type |
Description |
---|---|---|
value |
varies |
The value to set in the specified field. The type of value depends on the field into which the value is being set. |
None.
ObjectException
This method sets the parent object Java Bean for the system record.
void setObjectName(ObjectNameBean object) |
Name |
Type |
Description |
---|---|---|
object |
ObjectNameBean |
The Java Bean for the parent object. |
None.
ObjectException
A Java Bean is created to represent each parent object defined in the object definition of the master index application. The methods in these classes provide the ability to create a parent object Bean and to set or retrieve the field values for that object Bean.
The name of each parent object Bean class is the same as the name of each parent object, with the word “Bean” appended. For example, if a parent object in your object structure is “Person”, the name of the associated parent Bean class is “PersonBean”. The methods in this class include a constructor method for the parent object Bean, and get and set methods for each field defined for the parent object. Most methods are named based on the name of the parent object and the fields and child objects defined for that object. In the methods described in this section, ObjectName indicates the name of the parent object, Child indicates the name of a child object, and Field indicates the name of a field defined for the parent object.
final class ObjectNameBean |
The following methods are inherited from java.lang.Object.
equals
hashcode
notify
notifyAll
toString
wait()
wait(long arg)
wait(long timeout, int nanos)
This method is the user-defined object Bean class. You can instantiate this class to create a new instance of the parent object Bean class.
new ObjectNameBean() |
None.
An instance of the parent object Bean.
ObjectException
This method returns the total number of child objects contained in a system object. The type of child object is specified by the method name (such as Phone or Address).
int countChild() |
None.
An integer indicating the number of child objects in a collection.
None.
This method returns a count of the total number of child objects belonging to a system object.
int countChildren() |
None.
An integer representing the total number of child objects.
None.
This method returns a count of the total number of child objects of a specific type that belong to a system object.
int countChildren(String type) |
Name |
Type |
Description |
---|---|---|
type |
String |
The type of child object to count, such as Phone or Address. |
An integer representing the total number of child objects of the specified type.
None.
This method removes the specified child object from the system object. The type of child object to remove is specified by the name of the method, and the specific child object to remove is specified by its unique identification code assigned by the master index application.
void deleteChild(String ChildId) |
Name |
Type |
Description |
---|---|---|
ChildId |
String |
The unique identification code of the child object to delete. |
None.
ObjectException
This method retrieves an array of child object Beans. Each getter method is named according to the child objects defined for the parent object. For example, if the parent object contains a child object named “Address”, the getter method for this field is named getAddress. A getter method is created for each child object in the parent object.
ChildBean[] getChild() |
None.
An array of Java Beans containing the type of child objects specified by the method name.
None.
This method retrieves a child object Bean based on its index in a list of child objects. Each getter method is named according to the child objects defined for the parent object. For example, if the parent object contains a child object named “Address”, the getter method for this field is named getAddress. A getter method is created for each child object in the parent object.
ChildBean getChild(int i) |
Name |
Type |
Description |
---|---|---|
i |
int |
The index of the child object to retrieve from a list of child objects. |
A Java Bean containing the child object specified by the index value. The method name indicates the type of child object returned.
ObjectException
This method retrieves the value of the field specified in the method name. Each getter method is named according to the fields defined for the parent object. For example, if the parent object contains a field named “FirstName”, the getter method for this field is named getFirstName.
String getField() |
The syntax for the getter methods depends on the type of data specified for the field in the object structure. For example, the getter method for a date field would have the following syntax:
Date getField |
None.
The value of the specified field. The type of data returned depends on the data type defined in the object definition.
ObjectException
This method retrieves the unique identification code (primary key) of the object, as assigned by the master index application.
String getObjectNameId() |
None.
A string containing the unique ID of the parent object.
ObjectException
This method adds a child object to the system object.
void setChild(int index, ChildBean child) |
Name |
Type |
Description |
---|---|---|
index |
integer |
The index number for the new child object. |
child |
ChildBean |
The Java Bean containing the child object to add. |
None.
None.
This method adds an array of child objects of one type to the system object.
void setChild(ChildBean[] children) |
Name |
Type |
Description |
---|---|---|
children |
ChildBean[] |
The array of child objects to add. |
None.
None.
This method sets the value of the field specified in the method name. Each setter method is named according to the fields defined for the parent object. For example, if the parent object contains a field named “DateOfBirth”, the setter method for this field is named setDateOfBirth. A setter method is created for each field in the parent object, including any fields containing standardized or phonetic data.
void setField(value) |
Name |
Type |
Description |
---|---|---|
value |
varies |
The value of the field specified by the method name. The type of value depends on the field being populated. |
None.
ObjectException
This method sets the value of the ObjectNameId field in the parent object.
This ID is set internally by the master index application. Do not set this field manually.
void setObjectNameId(String value) |
Name |
Type |
Description |
---|---|---|
value |
String |
The value of the ObjectNameId field. |
None.
ObjectException
A Java Bean is created to represent each child object defined in the object definition of the master index application. The methods in these classes provide the ability to create a child object Bean and to set or retrieve the field values for that object Bean.
The name of each child object Bean class is the same as the name of each child object, with the word “Bean” appended. For example, if a child object in your object structure is named “Address”, the name of the corresponding child class is AddressBean. The methods in this class include a constructor method for the child object Bean, and get and set methods for each field defined for the child object. Most methods have dynamic names based on the name of the child object and the fields defined for that object. In the following methods, Child indicates the name of a child object and Field indicates the name of a field defined for the child object.
final class ChildBean |
The following methods are inherited from java.lang.Object.
equals
hashcode
notify
notifyAll
toString
wait()
wait(long arg)
wait(long timeout, int nanos)
This method is the user-defined object Bean class. You can instantiate this class to create a new instance of the child object Bean class.
new ChildBean() |
None.
An instance of the child object Bean.
ObjectException
This method removes the child object from the object being processed. This is used with the executeMatchUpdate function to update a system object by deleting one of the child objects from the object being processed.
void delete() |
None.
None.
ObjectException
This method retrieves the value of the field specified in the method name. Each getter method is named according to the fields defined for the child object. For example, if the child object contains a field named “ZipCode”, the getter method for this field is named getZipCode.
String getField() |
The syntax for the getter methods depends on the type of data specified for the field in the object structure. For example, the getter method for a date field would have the following syntax:
Date getField |
None.
The value of the specified field. The type of data returned depends on the data type defined in the object definition.
ObjectException
This method retrieves the unique identification code (primary key) of the object, as assigned by the master index application.
String getChildId() |
None.
A string containing the unique ID of the child object.
ObjectException
This method sets the value of the field specified in the method name. Each setter method is named according to the fields defined for the child object. For example, if the child object contains a field named “Address”, the setter method for this field is named setAddress. A setter method is created for each field in the child object, including any fields containing standardized or phonetic data.
void setField(value) |
Name |
Type |
Description |
---|---|---|
value |
varies |
The value of the field specified by the method name. The type of value depends on the data type of the field being populated. |
None.
ObjectException
This method sets the value of the ChildId field in the child object.
This ID is set internally by the master index application. Do not set this field manually.
void setChildId(String value) |
Name |
Type |
Description |
---|---|---|
value |
String |
The value of the ChildId field. |
None.
ObjectException
This class represents an enterprise object involved in a merge. This is the enterprise object whose EUID was kept in the final merge result record. A DestinationEO object is used when unmerging two enterprise objects.
class DestinationEO |
This method retrieves the surviving enterprise object from a merge transaction in order to allow the records to be unmerged.
EnterpriseObjectName getEnterpriseObjectName() |
where ObjectName is the name of the parent object.
None.
The surviving enterprise object from a merge transaction.
ObjectException
This class represents the results of a search. A SearchObjectNameResult object (where ObjectName is the name of the parent object) is returned as a result of a call to searchBlock, searchExact, or searchPhonetic.searchBlock
class SearchObjectNameResult |
This method retrieves the EUID of a search result record.
String getEUID() |
None.
A string containing an EUID.
None.
This method retrieves the weight that indicates how closely a search result record matched the search criteria.
Float getComparisonScore() |
None.
A comparison weight.
None.
This method retrieves an object bean for a search result record.
ObjectNameBean getObjectName() |
where ObjectName is the name of the parent object.
None.
An object bean.
None.
This class represents an enterprise object involved in a merge. This is the enterprise object whose EUID was not kept in the final merge result record. A SourceEO object is used when unmerging two enterprise objects.
class SourceEO |
This method retrieves the non-surviving enterprise object from a merge transaction in order to allow the records to be unmerged.
EnterpriseObjectName getEnterpriseObjectName() |
where ObjectName is the name of the parent object.
None.
The non-surviving enterprise object from a merge transaction.
None.
This class represents the primary keys in a system object, which include the processing code for the originating system and the local ID of the object in that system. The class is named for the primary object. For example, if the primary object is named “Person”, this class is named SystemPersonPK. If the primary object is named “Company”, this class is named SystemCompanyPK. The methods in these classes provide the ability to create an instance of the class and to retrieve the system processing code and the local ID.
class SystemObjectNamePK |
where ObjectName is the name of the parent object.
This method is the user-defined system primary key object. This object contains a system code and a local ID. Use this constructor method to create a new instance of a system primary key object.
new SystemObjectNamePK() |
where ObjectName is the name of the parent object.
None.
An instance of the system primary key object.
None.
This method retrieves the local identifier from a system primary key object.
String getLocalId() |
None.
A string containing a local identifier.
None.
This method retrieves the system’s processing code from a system primary key object.
String getSystemCode() |
None.
A string containing the processing code for a system.
None.
You can select a Match Type for each field defined in the Sun Master Index wizard. Each match type defines a different type of standardization, normalization, phonetic encoding, and matching logic in the Match Field file. The following topics describe each match type and how each affects the logic in the Match Field file.
For each field that will be used for matching in the master index application, you can select a match type in the wizard. When you select a match type for a field, Sun Master Index automatically adds that field to the match string in the Match Field file and, in many cases, generates additional fields in the object definition that are not visible on the wizard. These fields are used for searching and matching and they should not be modified.
If new fields are generated, they are automatically incorporated into the configuration files and the database script that creates the master index tables. These fields store standardized, normalized, or phonetic versions of the field, depending on the type of matching you choose. In addition, these fields are assigned a match type in the match string in the Match Field file. They might also be defined for standardization in the Match Field file, in which case they will also be assigned a standardization type.
The match types specified in the Match Field file for the fields in the match string are not always the same as the match types you specify in the wizard. Information about match types is provided in the following sections. For more information, see Understanding the Sun Match Engine.
The Sun Master Index wizard match types fall into four primary categories.
The actual standardization and match types entered into the Match Field file vary for each match type you select in the wizard. The match and standardization types for each type of field are listed in the following descriptions. The match types entered into the Match Field file correspond to the match types defined in the match configuration file, MatchConfigFile.cfg.
The Person match types include PersonLastName and PersonFirstName. These match types are used to normalize and phonetically encode name fields for person matching. For each field with one of these match types, the wizard adds two fields to the object structure for phonetic and standardized versions. If you specify a field with a person match type for blocking in the wizard, the phonetic version of the name is automatically added to the blocking query. The following fields are created when you specify one of the Person match types for a field (field_name refers to the name of the field specified for Person matching).
field_name_Std – This field contains the normalized version of the name.
field_name_Phon – This field contains the phonetic version of the name.
The corresponding standardization and match types in the Match Field file are listed in Table 24.
Table 24 Person Name Standardization and Match Types
eView Wizard Match Type |
Match Field File Standardization Type |
Match Field File Match Type |
---|---|---|
PersonLastName |
PersonName |
LastName |
PersonFirstName |
PersonName |
FirstName |
The BusinessName match type is designed to help parse, normalize, and phonetically encode a business name. BusinessName matching adds several fields to the object structure and to the match string. If you specify a business name field for blocking, each parsed business name field is added to the blocking query. The corresponding standardization type in the Match Field file for all fields selected for BusinessName matching is also BusinessName. The actual match type assigned to each field varies depending on the type of information in each field.
Table 25 lists the fields created when you select the BusinessName match type for a field along with their corresponding match types in the Match Field file (field_name refers to the name of the field selected for BusinessName matching).
Only specify this type of matching for one business name field; otherwise, the wizard will create duplicate entries in the object structure. If more than one field contains the business name, you can add those fields to the standardization structure in the Match Field file after the wizard creates the configuration files.
Field Name |
Description |
Added to the Match String? |
Match Field File Match Type |
---|---|---|---|
field_name_Name |
The parsed and normalized version of the business name. |
Yes |
PrimaryName |
field_name_NamePhon |
The phonetic version of the business name. |
No | |
field_name_OrgType |
The parsed organization type of the business name. |
Yes |
OrgTypeKeyword |
field_name_AssocType |
The association type for the business. |
Yes |
AssocTypeKeyword |
field_name_Industry |
The name of the industry for the business. |
Yes |
IndustryTypeKeyword |
field_name_Sector |
The name of the industry sector (industries are a subset of sectors). |
Yes |
IndustrySectorList |
field_name_Alias |
An alias for the business name. |
No | |
field_name_Url |
The business’ web site URL. |
Yes |
Url |
The Address match type is designed to help parse, normalize, and phonetically encode an address for matching or standardizing address information. Address matching adds several fields to the object structure and to the match string. If you specify an address field for blocking, the parsed fields are added to the blocking query. The corresponding standardization type for fields selected for Address matching is Address. The actual match type assigned to each field varies depending on the type of information in each field.
The fields created when you select the Address match type for a field are listed below along with their corresponding match types in the Match Field file (field_name refers to the name of the field selected for Address matching).
Only specify this type of matching for one street address field; otherwise, the wizard will create duplicate entries in the object structure. If more than one field contains the street address, you can define the additional fields in the standardization structure in the Match Field file after the wizard creates the configuration files.
Field Name |
Description |
Added to Match String? |
Match Field File Match Type |
---|---|---|---|
field_name_HouseNo |
The parsed street number of the address. |
Yes |
HouseNumber |
field_name_StDir |
The parsed and normalized street direction of the address. |
Yes |
StreetDir |
field_name_StName |
The parsed and normalized street name of the address. |
Yes |
StreetName |
field_name_StPhon |
The phonetic version of the street name. |
No | |
field_name_StType |
The parsed and normalized street type of the address, such as Boulevard, Street, Drive, and so on. |
Yes |
StreetType |
If you want to search on street addresses but do not want to use these fields for matching, select the Address match type for only one street address field in the wizard. When the wizard is complete, you can remove the address fields from the match string in the Match Field file.
Several additional match types are defined in the wizard for the Sun Match Engine. These match types are used to indicate matching on a string, date, or number fields other than those described above or to indicate matching on a field that contains a single character (such as the gender field, which might accept “F” for female or “M” for male). These match types do not define standardization for the specified field and do not add any fields to the object structure. If you specify one of these match types for a field in the wizard, the field is added to the match string with a match type of String, Date, Number, or Char.