Skip Navigation Links | |
Exit Print View | |
Developing Oracle Java CAPS Master Indexes (Repository) Java CAPS Documentation |
Developing Oracle Java CAPS Master Indexes (Repository)
Oracle Java CAPS Master Index Overview
About Oracle Java CAPS Master Index
Oracle Java CAPS Master Index Features
Master Index Repository Components
Match Engine Configuration Files
Outbound Object Type Definition (OTD)
Learning about the Master Index Runtime Environment
Functions of the Runtime Environment
Features of the Runtime Environment
Master Index Runtime Components
Object Persistence Service (OPS)
Objects in an Enterprise Record
Working with Project Components
Copying, Cutting, and Pasting Files
Master Index Development Process Overview (Repository)
The Master Index Framework and the Runtime Environment (Repository)
Before You Begin Developing a Master Index (Repository)
Preliminary Data Analysis for a Master Index (Repository)
Planning a Master Index Project (Repository)
Master Index Project Initiation Checklist (Repository)
Creating a Master Index Application (Repository)
Step 1: Create a Project and Start the Wizard (Repository)
Step 2: Name the Master Index Application (Repository)
To Name the Master Index Application
Step 3: Define Source Systems (Repository)
Step 4: Define the Deployment Environment (Repository)
To Define the Deployment Environment
Step 5: Define Parent and Child Objects (Repository)
Creating Objects from a Template
Deleting an Object from the Structure
Step 6: Define the Fields for Each Object (Repository)
Step 7: Generate the Project Files (Repository)
To Generate the Configuration Files
Step 8: Review the Configuration Files (Repository)
Master Index Wizard Field Properties and Name Restrictions (Repository)
Master Index Wizard Field Name Restrictions (Repository)
Master Index Wizard General Field Properties (Repository)
Master Index Wizard EDM Field Properties (Repository)
Custom Plug-ins for Master Index Custom Transaction Processing (Repository)
Master Index Update Policy Plug-ins (Repository)
Master Index Field Validation Plug-ins (Repository)
Master Index Field Masking Plug-ins (Repository)
Master Index Match Processing Logic Plug-ins (Repository)
Custom Match Processing Logic Methods
Custom Match Processing Logic Plug-in Requirements
Custom Match Processing Configuration (Repository)
Master Index Custom Plug-in Exception Processing (Repository)
Custom Plug-Ins for Master Index Custom Components (Repository)
Master Index Survivor Calculator Plug-ins (Repository)
Master Index Query Builder Plug-ins (Repository)
Master Index Block Picker Plug-ins (Repository)
Master Index Pass Controller Plug-ins (Repository)
Match Engine Plug-ins (Repository)
Standardization Engine Plug-ins (Repository)
Phonetic Encoders Plug-ins for a Master Index (Repository)
Implementing Master Index Custom Plug-ins (Repository)
Creating Master Index Custom Plug-ins (Repository)
Building Master Index Custom Plug-ins (Repository)
Generating the Master Index Application (Repository)
To Generate the Application for the First Time
Master Index Database Scripts and Design (Repository)
Master Index Database Scripts (Repository)
Master Index Database Requirements (Repository)
Database Platform Requirements
Master Index Database Structure (Repository)
Designing the Master Index Database (Repository)
Designing for Performance Optimization
Creating the Master Index Database (Repository)
Step 1: Analyze the Master Index Database Requirements (Repository)
Step 2: Create a Master Index Database and User (Repository)
Step 3: Define Master Index Database Indexes (Repository)
Step 4: Define Master Index External Systems (Repository)
Master Index Database Table Description for sbyn_systems (Repository)
Step 5: Define Master Index Code Lists (Repository)
To Customize Common Table Data for Oracle
To Customize Common Table Data for SQL Server
Step 6: Define Master Index User Code Lists (Repository)
Master Index Database Table Description for sbyn_user_code (Repository)
Step 7: Create Custom Master Index Database Scripts (Repository)
Step 8: Create the Master Index Database Structure (Repository)
To Create the Database Structure
Step 9: Specify a Starting EUID for a Master Index (Repository)
Deleting Master Index Database Tables (Repository)
To Delete Database Tables (Repository)
Defining a Database Connection Pool Through the Application Server
Step 1: Add the Oracle Driver to the Application Server
Step 2: Create the JDBC Connection Pools
To Create the JDBC Connection Pools
You can add custom processing to the master index application using the Custom Plug-ins module of a Oracle Java CAPS Master Index project. This ability allows you to tailor how messages are processed by the master index application. Plug-ins can be used to customize field validations, update policies, match processing logic, and record retrieval, and to create custom components for the master index application, such as custom phonetic encoders, block pickers, or query builders. You can create as many classes as you need to carry out the custom processes.
The following sections describe custom plug-ins that define custom processing. These are explained more fully in Understanding Oracle Java CAPS Master Index Configuration Options (Repository).
Master Index Update Policy Plug-ins (Repository) – Define custom processing logic to perform against the resulting record of a transaction before it is stored in the database.
Master Index Field Validation Plug-ins (Repository) – Define validations to perform against specific fields, such as checking the local ID length and format.
Master Index Field Masking Plug-ins (Repository) – Define how the values for sensitive fields are hidden on the EDM from users who do not have permission to view them.
Master Index Match Processing Logic Plug-ins (Repository) – Define custom logic based on predefined decision points for how records are matched during a transaction.
Master Index Custom Plug-in Exception Processing (Repository) – Define how exceptions are handled by the custom plug-ins you create.
For the primary transactions performed by the master index application, you can define additional custom processing to perform against the record that results from a transaction. The policies you define are invoked by the Update Manager and are applied to the resulting records after they are processed by the survivor calculator. The modifications made to a record by an update policy determine how the record is stored in the database. By creating custom plug-ins, you can create additional Java classes to support the update policies you define.
Update policies are specified in the UpdatePolicy section of the Best Record file, and there are several different types. Each policy modifies an enterprise object (class com.stc.eindex.objects.EnterpriseObject) and must implement com.stc.eindex.update.UpdatePolicy, which contains one method, applyUpdatePolicy. The syntax is as follows:
public EnterpriseObject applyUpdatePolicy(EnterpriseObject before, EnterpriseObject after)
This method throws two exceptions: com.stc.eindex.master.UserException and com.stc.eindex.objects.exception.ObjectException.
The enterprise merge policy defines additional processing to perform after two enterprise objects are merged. The processing defined in this policy acts against the surviving record of the merge. In the EnterpriseMergePolicy element in the Best Record file, enter the fully qualified name of this custom plug-in.
The enterprise unmerge policy defines additional processing to perform after an unmerge transaction occurs. The processing defined in this policy acts against the surviving record of the merge transaction that was unmerged. In the EnterpriseUnmergePolicy element of the Best Record file, enter the fully qualified name of this custom plug-in.
The enterprise update policy defines additional processing to perform after a record is updated. In the EnterpriseUpdatePolicy element of the Best Record file, enter the fully qualified name of this custom plug-in.
The enterprise create policy defines additional processing to perform after a new record is inserted into the master index database. In the EnterpriseCreatePolicy element of the Best Record file, enter the fully qualified name of this custom plug-in.
The system merge policy defines additional processing to perform after two system objects are merged. The processing defined in this file acts against the surviving enterprise record of the merge (and not the system record). In the SystemMergePolicy element of the Best Record file, enter the fully qualified name of this custom plug-in.
The system unmerge policy defines additional processing to perform after system objects are unmerged. The processing defined in this file acts against the surviving enterprise record of the system merge transaction that was unmerged. In the SystemUnmergePolicy element in the Best Record file, enter the fully qualified name of this custom plug-in.
The undo assumed match policy defines additional processing to perform after an assumed match transaction is reversed. In the UndoAssumeMatchPolicy element in the Best Record file, enter the fully qualified name of this custom plug-in.
You can define validations to be performed against certain fields before information is entered into the master index database. Once you create the custom plug-ins containing the validation logic, enter the name of the plug-in in the Field Validation file. Follow these guidelines when implementing custom field validators.
The custom validation classes must implement com.stc.eindex.objects.validation.ObjectValidator.
The exception thrown is com.stc.eindex.objects.validation.exception.ValidationException.
One default field validator, validate-local-id, is provided to validate system and local ID fields before processing data into the database. This is described in Understanding Oracle Java CAPS Master Index Configuration Options (Repository).
There might be instances where you want to mask certain data in records from general users of the Enterprise Data Manager and only allow access by administrators. To do this, you can create a custom plug-in that displays asterisks (or other symbols) in place of the field values on the EDM. Once you define the custom plug-in, specify the name of the custom plug-in Java class in the object-sensitive-plug-in-class element of the Enterprise Data Manager file).
You can implement custom plug-ins that customize the way the execute match methods process data into the master index application. When a record is entered into the master index system, match processing is performed by calling one of the following “execute match” functions from the MasterController class.
executeMatch
executeMatchUpdate
executeMatchDupRecalc
executeMatchUpdateDupRecalc
executeMatchGui (this method is only called by the EDM)
These methods contain standard logic for processing records through the master index database, weighting incoming records against existing records, and then using those weights to determine whether to insert a new record or update an existing record. In addition to configuring the match processing logic in the Threshold file, you can customize certain aspects of the processing logic using custom plug-ins that contain functions found in the ExecuteMatchLogics class.
There are five decision branches where custom logic can be inserted. At specific points in match processing, the execute match methods look for the value of the methods listed below. For more information about the methods, see the Javadocs for the master index. These methods are contained in the ExecuteMatchLogics class in the package com.stc.eindex.master. For information about where the decision points are reached in the processing logic and how to change the logic, see Understanding Oracle Java CAPS Master Index Processing (Repository). The following methods specify the custom logic.
bypassMatching - Indicates whether to perform the match process on incoming records or to bypass the match process.
disallowAdd - Indicates whether an incoming message can be inserted as a new record.
disallowUpdate - Indicates whether an incoming record can update an existing record.
rejectAssumedMatch - Indicates whether to accept or reject an assumed match of two records.
rejectUpdate - Indicates whether to accept or reject an update to an existing record.
The custom plug-ins you create to define custom execute match logic must extend the ExecuteMatchLogics class. In addition, the following classes must be imported into the custom plug-in.
com.stc.eindex.objects.SystemObject
com.stc.eindex.objects.EnterpriseObject
com.stc.eindex.objects.exception.ObjectException
com.stc.eindex.master.ExecuteMatchLogics
com.stc.eindex.master.CustomizationException
If you create a custom plug-in that defines custom processing logic for the execute match methods, you must specify those custom plug-ins in the Threshold file in the master index project. If you create a plug-in for customizing logic in the execute match methods used by the back-end, such as by Collaborations or Business Processes, specify the name of that class in the logic-class element. If you create a plug-in for the EDM, specify the name of that class in the logic-class-gui element. For example:
<logic-class>com.stc.eindex.user.CustomCollaboration</logic-class> <logic-class-gui>com.stc.eindex.user.CustomEDM</logic-class-gui>
For more information about the Threshold file, see Understanding Oracle Java CAPS Master Index Configuration Options (Repository).
If a custom plug-in throws an exception of the class ObjectException or SystemObjectException, multiple stack traces are logged in the server log file, which can make operational management tasks more difficult. For cases where you do not want stack traces to be logged, configure your custom plug-ins to throw exceptions of the class UserException or one of its derived classes (DataModifiedException or ValidationException). This is useful for user errors on the Enterprise Data Manager (EDM). When one of these exceptions is thrown, no stack trace is entered in the log file but an error message still appears on the EDM.
For more information about these exception classes, see the Javadocs for Oracle Java CAPS Master Index.