Communities
A collaborative platform to connect and grow with like-minded Informaticans across the globe
Product Communities
Connect and collaborate with Informatica experts and champions
Discussions
Have a question? Start a Discussion and get immediate answers you are looking for
User Groups
Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
Get Started
Community Guidelines
Knowledge Center
Troubleshooting documents, product guides, how to videos, best practices, and more
Knowledge Base
One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
Support TV
Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
Documentation
Information library of the latest product documents
Velocity (Best Practices)
Best practices and use cases from the Implementation team
Learn
Rich resources to help you leverage full capabilities of our products
Trainings
Role-based training programs for the best ROI
Certifications
Get certified on Informatica products. Free, Foundation, or Professional
Product Learning Paths
Free and unlimited modules based on your expertise level and journey
Resources
Library of content to help you leverage the best of Informatica products
Tech Tuesdays Webinars
Most popular webinars on product architecture, best practices, and more
Product Availability Matrix
Product Availability Matrix statements of Informatica products
SupportFlash
Monthly support newsletter
Support Documents
Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
Product Lifecycle
End of Life statements of Informatica products
Ideas
Events
Change Request Tracking
Marketplace
English
  • Identity Resolution 10.5 HotFix 2
  • All Products

Table of Contents

Search

  1. Preface
  2. Introduction
  3. SSA-NAME3 Overview
  4. Introduction for Application Programmers
  5. Appendix A: Glossary

Introduction to SSA-NAME3 (EXTN) Service Groups

Introduction to SSA-NAME3 (EXTN) Service Groups

Back Next

The SSA-NAME3 Service Group Environments

The SSA-NAME3 Service Group Environments

Once installed, SSA-NAME3 has a Customization Environment and a Development/Run-time Environment.

The SSA-NAME3 Customization Environment

The customization environment is comprised of five major components:
  • The Country specific Definition files, which contain the default rules for how the name search & matching software operate on data for different populations and different countries.
  • The Customization and Generation modules, which allow the default Definition files to be customized for an organization’s data and applications, and then re-built.
  • The Testing module, which allows a callable SSA-NAME3 module to be tested in a stand-alone manner.
  • The Visual Workshop, which allows the definition files to be customized, generated and tested in a visual environment.
The customization environment is on Windows for all platforms except MVS, where native customization is available. (However, MVS users are encouraged to use Windows as there are certain benefits).
The Country Specific Definition Files are supplied pre-loaded with the basic definitions suitable for a given country. These are called "Fast-start" definition files and are usually used as the basis for any customization work.
There is a minimum amount of customization that must be done to these files and tables before SSANAME3 can be used. See Tips on Customizing an Algorithm section in the
DEFINITION and CUSTOMIZATION GUIDE FOR SSA-NAME3 SERVICE GROUPS
 guide for more details.
In summary, the customizable components within the Country Definition files are:
Algorithms
For a given population of names or addresses, an Algorithm manages the way a name or address within that population is transformed prior to key-building or matching. This is done by selecting the Character-set tables, Edit-lists, Frequency tables, Scaler Frequency tables (optional), Word Stabilization routines and other processes it will use. An Algorithm also controls the type, style and number of keys generated for a name or address.
Character-set tables
These tables control the way individual characters are treated. Examples of treatment are casing, dropping of accents and deletion of non alpha-numeric characters.
Edit-lists
An Edit-list controls the way common words or phrases within a name or address population are transformed or marked. Examples of transformation are replacements for nick-names, abbreviations, synonyms & phrases; deletions for noise, delete or stop words; concatenation or splitting for prefixes and suffixes. Examples of marking are, finding the major word and, classification of data.
Frequency tables
These tables are automatically built from the user’s data and control the way common words within the name or address population are compressed into keys.
Scaler Frequency tables
These tables are optionally built from either the user’s data or the user’s SSA-NAME3 keys. They enhance the Scale value returned in the
NAMESET
 search ranges.
Search Strategies
A Search Strategy controls the way name or address key index is searched and varies according to the needs of the application. A customer search is one search strategy, a pre-insert search is another and a fraud search may be quite different again.
Matching Schemes
A Matching Scheme controls the way two records, usually a search and a file record, are matched. Matching occurs after Searching and can be performed on names, addresses, dates, telephone numbers, codes and other data strings. The goal of a Matching Scheme is to mimic the choice process of a user. The results of Matching are used for filtering, matching or ranking records.
After these Definition files and tables have been customized, they are then generated. If the development environment is on a different platform to the customization environment, the Service Group Data File must be transferred to the target platform. The Data File is plain ASCII text which should be considered when transferring.
A final
Gendll
 step is performed which creates the dll/shared object that can be called from the program.

The SSA-NAME3 Development/Run-time Environment

The development environment is on the platform where the applications which will use SSA-NAME3 are developed. This is often referred to as the target platform as it is the target for the customization work. The development environment is comprised of:
  • The Core modules, which represent the non-modifiable kernel of the software and without which the other components would not work.
  • The Testing module, which allow a callable SSA-NAME3 module to be tested in a stand-alon manner.
  • The API’s, which allow user applications to call SSA-NAME3 Services.
Most major platforms are catered for as targets.
The run-time environment is on the platform where the applications, which will use SSA-NAME3, are executed. The run-time environment is comprised of:
  • The Callable SSA-NAME3 module, which has been prepared in the development environment. No other SSA-NAME3 modules are required in the run-time environment.
User applications communicate with the Callable SSA-NAME3 Service Group via documented API conventions. For on-line applications, it is normal for one copy of the SSA-NAME3 Service Group to be shared by many user transactions. For batch applications, it is more common for the Service Group to be statically linked to the application.
User applications use the SSA-NAME3 Service Group for three main reasons:
  1. To build keys for the name or address population to be searched. The User application calls the SSA-NAME3 Service Group passing it a name or address and indicating which Algorithm it wishes to use. The Service Group passes back one or more keys ("
    Keys Stack
    ") which are to be stored by the application in the user’s database. These keys are either 5-bytes binary or 8-bytes character depending on the DBMS being used. Applications making use of this service are commonly the initial key-load program, and name or address maintenance programs. For example,
  2. To build search strategies for a search name or address. The User search application calls the SSA-NAME3 Service Group passing it the name or address and indicating which Algorithm and Search Strategy it wishes to use. The Service Group passes back an array of key ranges which define the sets of records which are candidates for this name or address search. The User application then does a key sequential access of its SSA-NAME3 key index for the key range or key ranges specified. It returns the name or address and other data from the database which is then used for matching.
  3. To match two records, a search record and a file record. After reading a candidate record in the search, the User application calls the SSA-NAME3 Service Group indicating which Matching Scheme to use and passing it the search name or address, and any other identity data entered, and a file name or address, and the identity data retrieved for the file record. The Service Group compares the two records and passes back a Score between 1 and 100. The User Application may then use the Score to match, filter or rank the records. For example,
0 COMMENTS
We’d like to hear from you!