Understanding Customer Data Hub Integration

This chapter discusses:

• Customer data management.

• Customer data hub integration.

• Integration architecture.

• Data synchronization and data mapping.

• Full data synchronization.

• Incremental data synchronization.

• Data quality management.

• Data merge.

Understanding Customer Data Management and the Customer Data Hub

Customer Data Management provides a single, accurate, complete and up-to-date view of the Customer throughout the enterprise.

A Customer Data Management solution performs various functions:

• Customer data throughout the enterprise is consolidated into a single master database.

• Customer data is kept synchronized between the master database and other individual application systems to maintain a consistent enterprise view of the Customer.

• Data is routinely cleansed and enriched in the master database, and then distributed to the individual application systems.

• Master data is leveraged to improve customer centric business processes and to achieve more accurate reporting and analytics.

The Customer Data Hub (CDH) and supporting products available in Oracle’s E-Business Suite constitute Oracle’s Customer Data Management solution.

The Oracle Trading Community Architecture (TCA) is the data model and infrastructure used to physically consolidate customer data into a master database. This customer data can be managed or new data can be created using the Oracle Customers Online application.

The Oracle Customer Data Librarian application is used to cleanse and standardize the master data. It provides process-oriented tools to identify and resolve existing duplicate data and also to prevent the introduction of duplicates into the system.

The Oracle Customer Data Spoke provides tools to integrate spoke applications like PeopleSoft CRM with the Customer Data Hub, and share master customer data across the enterprise in real time.

This document provides details on the CDH integration with PeopleSoft CRM.

References

Before implementing the CRM/CDH integration you should familiarize yourself with the following:

• The PeopleSoft Enterprise CRM 9.1 Application Fundamentals PeopleBook contains essential information describing the setup and design of the PeopleSoft CRM system. This book contains important topics that apply to many or all PeopleSoft applications across the PeopleSoft CRM product line.

• The PeopleSoft Enterprise CRM 9.1 Business Object Management PeopleBook discusses how to create and manage customer and worker business objects in PeopleSoft CRM.

• The Oracle Customer Data Librarian Implementation Guide describes how to implement Oracle Customer Data Librarian. As part of implementing Oracle Customer Data Librarian, you must also complete all the implementation steps for Oracle Customers Online.

• The Oracle Customer Data Librarian User Guide describes how to use Oracle Customer Data Librarian to establish and maintain the quality of the Trading Community Architecture Registry, focusing on consolidation, cleanliness, and completeness. Oracle Customer Data Librarian has all of the features in Oracle Customers Online, and is also part of the Oracle Customer Data Management product family.

• The Oracle Customers Online Implementation Guide describes how to implement Oracle Customers Online.

• The Oracle Customers Online User Guide describes how to use Oracle Customers Online to view, create, and maintain your customer information. Oracle Customers Online is based on Oracle Trading Community Architecture data model and functionality, and is also part of the Oracle Customer Data Management product family.

• The Oracle Trading Community Architecture Technical Implementation Guide explains how to use the public Oracle Trading Community Architecture application programming interfaces (APIs) and develop callouts based on Oracle Workflow Business Events System (BES). For each API, this guide provides a description of the API, the PL/SQL procedure, and the Java method, as well as a table of the parameter descriptions and validations. For each BES callout, this guide provides the name of the logical entity, its description, and the ID parameter name. Also included are setup instructions and sample code.

• The Oracle Trading Community Architecture Administration Guide describes how to administer and implement Oracle Trading Community Architecture (TCA). You set up, control, and manage functionality that affects data in the TCA Registry. It also describes how to set up and use Resource Manager to manage resources.

• The Oracle Trading Community Architecture Reference Guide contains seeded relationship types, seeded Data Quality Management data, Dun and Bradstreet data elements, Bulk Import interface table fields and validations, and a comprehensive glossary. This guide supplements the documentation for Oracle Trading Community Architecture and all products in the Oracle Customer Data Management family.

• The Oracle Trading Community Architecture User Guide describes the Oracle Trading Community Architecture (TCA) and how to use features from the Trading Community Manager responsibility to create, update, enrich, and cleanse the data in the TCA Registry. It also describes how to use Resource Manager to define and manage resources.

Understanding Customer Data Hub Integration

Oracle Customer Data Hub (CDH) provides a single source of customer data for use across multiple systems where users create and maintain customer data. The CDH is the center of a hub-and-spoke architecture in which disparate systems independently synchronize customer data with the CDH.

The Customer Data Hub was developed to consolidate an organization’s party-related data from a heterogeneous application into a single repository. Information is shared between external applications (known by the CDH as source, or spoke, systems) and the CDH, providing a consistent view of party-related data across an organization’s many business applications. Any number of source systems may become the “spokes” of a CDH solution, meaning that they are a provider and/or consumer of the hub’s data.

The following diagram illustrates the hub and spoke architecture of the Oracle CDH:

Hub and spoke architecture of Oracle Customer Data Hub

The Peoplesoft CRM integration with Oracle CDH provides your organization with customer data management functionality that includes:

• Data synchronization ensures that the PeopleSoft system has the most current customer data available and that updates made by PeopleSoft users are uploaded to the master data repository.

• Smart searches use matching rules and fuzzy search logic to help users locate existing customer records.

• Online duplicate identification and prevention uses matching rules and fuzzy logic to synchronously check for duplicate records in Oracle CDH when a user creates a new customer record in the PeopleSoft system.

• Merge requests enable users to notify the Oracle CDH data librarian of potential duplicate records.

Understanding Integration Architecture

The PeopleSoft CRM to CDH integration is made up of various integration components, each playing a unique role:

• As with other types of integrations involving PeopleSoft CRM, the PeopleSoft Integration Broker handles inbound and outbound messaging and acts as the integration gateway. It supports asynchronous as well as synchronous messages, as employed in this integration.

• The JMS or Java Messaging Service server serves as a standards-based Message Queuing system and guarantees delivery of the asynchronous messages that are exchanged between CRM and CDH.

• Pre-built BPEL or Business Process Execution Language processes are delivered to handle the integration flows between CRM and CDH. These processes execute on the BPEL Server.

• Finally OWB or Oracle Warehouse Builder is used as the Extract, Transform, and Load (ETL) tool to extract and move data from CRM into CDH during Full Sync.

This diagram illustrates how the integration components interact between PeopleSoft CRM and CDH:

Integration between PeopleSoft CRM and CDH

Understanding Data Synchronization and Data Mapping

This section provides an overview of CRM / CDH data synchronization and discusses data mapping.

One of the main goals of the Customer Data Hub is to consolidate customer data from all spoke applications.

Full Sync capability is provided so that customer data from PeopleSoft CRM can be extracted in bulk and then imported into CDH by a batch process. Full Sync is particularly useful when all customer data from CRM is to be moved into CDH for the first time in a new implementation.

See Full Data Synchronization

The Incremental Sync capability of the PeopleSoft CRM to CDH integration ensures that whenever customer data is added to or updated on one system, it is immediately synchronized to the other system. Thus, Incremental Sync is a bidirectional data sync mechanism that seeks to keep both the systems in sync at all times.

See Incremental Data Synchronization

Understanding CRM to CDH Data Mapping

The Business Object Relationship Model (BORM) is a flexible data model that serves as the foundation on which all PeopleSoft CRM applications are built. The BORM provides a configurable means to define and capture relationships about customers, suppliers, partners, contacts and any other objects (people, organizations, or database objects) that are meaningful to our customers, the deploying organizations.

The CDM is built on top of the BORM to provide common APIs for the various CRM applications such as PeopleSoft Field Service, Support, Sales, HelpDesk and Marketing to retrieve and update common core data. In CDM, every entity is considered a Business Object (BO). A BO can be one of the following types:

• Organization

  ABC Corporation

• Individual

  John Smith

• Database Object

  Checking Account

This information is captured in the PS_BO record. Each BO can play one or more roles and can participate in one or more relationships. Roles and relationships are captured in PS_BO_ROLE and PS_BO_REL, respectively.

Oracle Customers Online (OCO) is based on the TCA (Trading Community Architecture) data model and functionality. The TCA is the foundation of customer information used across the E-Business Suite including CDH as common business data to provide a unified view of the people, organizations, places, and relationships. In TCA, every entity is known as a Party. A Party can be one of the following types:

• Organization

  Oracle Corporation

• Person

  Jane Doe

• Group

  World Wide Web Consortium

• Relationship

  Jane Doe, a contact at Oracle Corporation

This information is maintained in the HZ_PARTIES record. Each Party can play one or more roles (defined in Party Usage functionality in R12 - HZ_PARTY_USG_ASSIGNMENTS) and can participate in one or more relationships (maintained in HZ_RELATIONSHIPS and other tables).

Source System Management

Source System Management (SSM) functionality enables implementing organizations to store the customer entity mappings between records in the CDH and those in disparate source systems. SSM provides the ability to maintain mappings between CDH and any external source system including enterprise, legacy, and enrichment source systems, all of which integrate with CDH. The source system (OS) as well as the record ID (OSR) of the entity in the source system is mapped to the Registry ID of the TCA record, such as the party or contact point. Source System setups must be established for all external systems interacting with the Customer Data Hub. This entails creating the source system record in the SSM administration console, and mapping the entities between a particular source system and the Customer Data Hub. All entities of a customer within the CDH that are mapped to external systems are tracked through Source System Management. Examples of such entities include parties, locations, and contacts.

Mapping CDM BO Types and Role Types

This table summarizes CDM BO Types and Role Types that are synchronized with CDH. This information is equivalent to the Party layer information in TCA.

Mapping CDM Roles

CDM captures and stores customer information in PS_BC, PS_BC_SOLDTO_OPT, PS_BC_BILLTO_OPT, and PS_BC_SHIPTO_OPT. This information, known as BC (Business Contact) is equivalent to the Account layer in TCA.

To support the integration of account layer information, the following CDM roles are synchronized with the TCA:

Mapping CDM Relationships

In CDM, two roles are linked together to form a relationship. For example, a Company Contact Relationship is made up of the Company Role (2) and the Contact Role (8).

This table lists the CDM Relationships that are synchronized with CDH:

Mapping CDM Tables

The following CDM tables are synchronized with CDH:

Understanding Full Data Synchronization

A full-sync integration process is provided to initially load data from CRM to CDH. You would run a full-sync integration when implementing the CDH in an existing PeopleSoft CRM installation.

Full-sync integration uses these existing technologies:

• Oracle Warehouse Builder (OWB).

• Oracle Bulk Import.

• PeopleSoft Data Import.

Understanding the Full Sync Process

This diagram illustrates the full sync publish process:

Full sync publish process

The full sync process involves the following processes:

• CRM to CDH - Data Mapping

  Data is mapped between the CRM CDM and CDH TCA.

• Enterprise Customer Full-Sync Publish AE (Application Engine) Process

  This AE process extracts data from CDM Objects and loads them into one or multiple Staging Tables.

• Oracle Warehouse builder ETL Process

  Using the Oracle Warehouse Builder ETL process you deploy the ETL scripts and use the ETL tools to extract the source information and transform the values to adhere to the data requirements of the interface tables.

• Oracle CDH Bulk Import Process

  Once the data has been loaded into the interface tables, you send the batch for import. This is done using the UIs in CDH Data Librarian. As each batch in the interface tables is selected for import and moved into staging tables for processing, the data is matched against the MOSR mapping tables to determine if the record is an explicit update or insert. From the staging tables the data is sent through the appropriate TCA validations to maintain data integrity of all information being loaded and sent to Data Quality Management (DQM) for duplicate identification as requested by the user. Records that pass validation are moved into the appropriate TCA tables and records that fail are sent to the Errors Table.

Data Mapping

Data is mapped between the CRM CDM and CDH TCA.

See Understanding CRM to CDH Data Mapping

Full-Sync Publish AE (Application Engine) Process

A series of AE processes extracts, transforms and loads the data from CDM business objects to CRM staging tables adhering to the structure of the TCA interface tables.

Five AE processes, RB_PUB_COMP, RB_PUB_CNTCT, RB_PUB_SITE, RB_PUB_CONS, RB_PUB_PRTNR export CDM data for Company, Contact, Site, Consumer, and Partner respectively with the corresponding Contact Methods.

See Enterprise PeopleTools 8.50 PeopleBook: PeopleSoft Application Engine

Oracle Warehouse Builder ETL Process

The full-sync process uses Oracle Warehouse Builder ETL, (Extraction Transformation & Loading), technology as the middleware for the initial high volume data upload.

Oracle Warehouse Builder (OWB) is a framework for the creation of extraction, transformation, and loading scripts used to populate a data warehouse or operational data store.

OWB understands a diverse set of data sources. It accesses a data source by means of an integrator. An integrator is an OWB component that has been specifically written to access particular type of data sources: relational databases and flat files  OWB also uses the concept of a module, which is a logical grouping of related objects. There are two types of modules: data source and warehouse. Modules contain definitions such as metadata.  The user chooses the integrator that is appropriate for the source, and the integrator accesses the source and imports the metadata that describes it.

See Oracle Warehouse Builder Reference & User Guide

Oracle CDH Bulk Import Process

Oracle Bulk Import is Oracle's data load architecture used to import large volumes of party data into the TCA registry. A set of data to be loaded into the TCA Registry at one time is called a batch. The data in one batch must be from the same data source. The interface tables can store as many batches from different sources as needed, and any number of batches can be actively populating the interface tables at the same time.

The Bulk Import process consists of definition, setup, batch processing, reporting, validating, and purging.

The customer data is extracted from its current location using ETL tools, and the values are transformed to adhere to the data requirements of the interface tables, and to populate the tables with large volumes of information. After information is loaded into one or more of the 11 logical interface tables in batches, one batch per source of data, Batch Import transfers batches of data from the interface tables into the TCA Registry.

Eleven logical interface tables can be populated to provide detail to any of fourteen TCA tables.

TCA provides validations and optional de-duplication to ensure the quality of the imported information. De-duplication identifies and resolves duplicates only within the batch that you are importing from the interface tables. You should purge data from the interface tables after the corresponding batch has been loaded to TCA, to reduce the overall size of the interface tables and improve performance for subsequent batch loads.

See Oracle Trading Community Architecture Technical Implementation Guide

See Oracle Trading Community Architecture Administration Guide

Understanding Incremental Data Synchronization

CRM provides bi-directional integration with the Customer Data Hub (CDH) for all customer data (objects). The business objects that are synchronized are Company, Sites, Partners, Consumers and Contacts. CDH is the single source truth (SST) of customer data. Other PeopleSoft Enterprise systems, such as Supply Chain Management, may also integrate with CDH. Configuration of what systems integrate with CDH and the record mapping will be defined in Source System Management (SSM) in CDH.

This section discusses:

• Outbound Incremental Sync: CRM to CDH

• Inbound Incremental Sync: CDH to CRM

• Syncing data from CRM to SCM

• Coordinating Data Models

Integration Data Formats

During an inbound or outbound integration process, the customer data will be in different formats at different stages of the integration. There are three representations of a Customer in the CRM system that need to be considered in the CRM / CDH Integration:

• When notifications come in to CRM, they start in the form of XML that Integration Broker delivers to an CRM Notification Handler.

• The Notification Handler will then take the XML and put them in to Messaging Data Objects.

  These data objects mirror the structure of the XML, but exist so that applications downstream in the process do not have to do any XML parsing to get at the XML content. They deal with the inbound notification as application classes.

• From there, the data must be adapted in to the BORM classes that they can ultimately be persisted as customer data.

  On the outbound side, the opposite is true. The data starts in BORM objects and must be adapted to the Messaging Data Types. From there, it can be easily converted to XML and sent out as an XML notification.

Outbound Incremental Sync: CRM to CDH

With the CRM to CDH incremental sync, additions or updates to customer data in CRM are sent to CDH via an asynchronous message. CDH processes this message and in turn updates its data in its Trading Community Architecture data model. No response message is sent from CDH to CRM.

CRM to CDH Messaging

Sending a message to CDH to create a new customer or to update an existing customer is implemented as an asynchronous process. BEPL and its Oracle Application adapter are used for invoking a web service on the CDH side.

The CDM message is published through IB and is sent out to JMS for publishing to BPEL. During any save processing of a CDM object, the EIP Adapter application class generates a corresponding notification message and publishes it to a specific JMS topic.

BPEL processes listen to the JMS topic, pick up a message instance, and call the appropriate CDH APIs to update TCA data.

Outbound BPEL Processes: CRM to CDH

The following BPEL processes support outbound integration from CRM to CDH:

• Organization Add (CDM Publish/CDH Subscribe)

• Organization Update (CDM Publish/CDH Subscribe)

• Company Add (CDM Publish/CDH Subscribe)

• Company Update (CDM Publish/CDH Subscribe)

• Person Add (CDM Publish/CDH Subscribe)

• Person Update (CDM Publish/CDH Subscribe)

• Contact Add (CDM Publish/CDH Subscribe)

• Contact Update (CDM Publish/CDH Subscribe)

This diagram illustrates an outbound BPEL process:

Outbound BPEL process

Inbound Incremental Sync: CDH to CRM

In the CDH to CRM incremental sync, additions or updates to customer data in CDH are sent to CRM via an asynchronous message. CRM processes this message by updating its own data and then sends back to CDH an asynchronous message containing the CRM key values of the objects added. Business Object ID or BO_ID is one example of a CDM key. CDH stores the CRM keys it receives in its Source System Management tables.

CDH to CRM Messaging

The following steps describe an inbound messaging sequence for a consumer object:

1. When a customer is added or updated in CDH, business events are raised and a change message is put onto the Advanced Queue (AQ).

2. A BPEL process subscribes to the queue, transforms it into Customer Schema and sends it to Java Message System (JMS)

3. Peoplesoft Integration Broker (IB) subscribes to the JMS message and invokes the application logic to handle the incoming CDH messages.

4. CRM sends back the newly created BO ID to CDH to be updated in the Source Management System table.

   This key cross-reference information must be maintained so that the two systems will be able to communicate future updates for the newly created BO. In some update cases (such as when a new CM is added or a CM Profile Sequence has changed), key data needs to be passed back to CDH to be updated in the SSM.

This diagram illustrates the inbound integration from CDH to CRM where a consumer is added in CDH and is sent to CRM:

Inbound integration from CDH to CRM

Inbound BPEL Processes

The following BPEL processes support inbound integration from CDH to CRM:

• Organization Add

  An Organization Add will be treated as a Company since TCA has no concept of Site or Partner.

  Note. If SCM is a spoke on the hub and is set up as the master of customer data, CDM expects the Customer ID to be populated. If the Customer ID is not populated, CDM will ignore the add message.

• Organization Update

  The BPEL process checks the Action Flag to determine which TCA record has been modified and extracts it to map to the CDM Customer schema.

  Note. Within CRM, the BO_ROLE table is checked to determine if the update is for a Company, Site, or Partner. If both Company and Partner roles are found, the object will be considered a Company.

• Person Add

  Note. In CDM, a Contact role for a Person will always be created.

• Person Update

• Source System Management Update

  TCA maintains cross-reference information between CDH and other spokes by populating key fields and record names in HZ_ORIG_SYS_REFERENCES table.

  A BPEL process handles the SSM update by calling update_orig_sys_reference API.

  For inbound add messages, CDM will return key fields to TCA to be updated in HZ_ORIG_SYS_REFERENCES for certain tables.

This diagram illustrates the inbound BPEL process:

Inbound BPEL process

Syncing data from CRM to SCM

PeopleSoft Enterprise Supply Chain Management (SCM) can integrate with CDH as well. In this case, CRM and SCM will not directly exchange customer data.

Customers have the option to use incremental sync of customer data between CRM and SCM through CDH or directly between CRM and SCM. For example a customer might implement CDH in phases, first integrate with CRM, and then integrate with SCM, or vice versa.

This section discusses the business scenarios based on whether CRM is integrating with SCM or not.

SCM Integrates with CDH

If SCM integrates with CDH, messages to exchange customer data between CRM and SCM will be inactivated, and messages between SCM and CDH will be activated. Both CRM and SCM need to populate the TCA in the same manner so that a customer entered in either SCM or CRM will have the same attributes populated in the other system in the same way the current EIP functions. Consistency between the two applicationsis maintained for the following attributes:

• SetID

• Customer ID

• Customer Group

• Address Seq Nbr

• Other flex fields

• Determination of single account to use in PS

Note. The process to generate customer IDs in CRM for a new customer will not change. SCM must always be the master for generating the ID.

There are three scenarios for customer ID generation in the CRM/SCM integration:

• Customer created in CRM

  • When a customer is added in CRM, the customer ID is requested from SCM before sending the new customer to CDH. Both the SetID and Cust ID are in the message sent to CDH.

  • When SCM receives the new customer from CDH, it uses the SetID and Cust ID in the message to create the customer, and it sends the same keys to CDH to be stored in SSM.

  • Since SetID and Cust ID are not in TCA, both CRM and SCM should use the same TCA flexible fields to map SetID and Cust ID. CRM will update the RB_INT_CUSTOMER, RB_INT_CUST_AD and RB_INT_CONTACT records, as these will still be used by applications for transaction sync.

• Customer created in SCM

  • Customers added in SCM are sent to CDH and then CDH sends them to CRM. CRM sends IDs for new customers to CDH to be stored in SSM.

  • CRM uses the SetID and Cust ID passed in the flexible fields to create a row in the company record.

  • CRM updates the RB_INT_CUSTOMER, RB_INT_CUST_AD, and RB_INT_CONTACT records, as these will still be used by applications for transaction sync.

• Customer created in a non-PeopleSoft spoke

  • Customers added in CDH are sent to CRM and SCM. In this scenario, the flexible fields mapped to SetID and Cust ID will be blank.

  • CRM does not process the message since SCM is configured to be the master to generate Customer IDs and the message has a blank Cust ID. In this case, CRM will discard the message and will not insert the entry into the error tables.

  • SCM receives the message, creates the new customer and sends the IDs for the new customer to CDH to be stored in SSM. Since SetID and Cust ID are stored in the flexible fields in CDH, this will be considered an update transaction and SCM will send the updates to CDH.

  • In CDH there will be a customer update event for a customer that does not have an entry in SSM for CRM. A customer create message will be sent to CRM, where CRM will create the customer and send back the keys to CDH.

  • Existing transactions (EIPs) between CRM and SCM will not be impacted since the process to generate customers did not change.

SCM does not Integrate with CDH

If the option to incrementally sync customer data between CRM and SCM is selected, the Customer messages between these systems will stay active. In this case, for every customer data add/updates, CRM will send changes to CDH using the new message and to SCM using the existing messages. In other words, there will be no changes to existing functionality between CRM and SCM.

Coordinating Data Models

Since there are some differences in the data models of the two systems that are being integrated; some standard rules and defaults have been set up to resolve the differences.

Understanding Data Quality Management

This section provides an overview of data quality management and discusses:

• Online duplicate prevention

• Match rules

• Smart search

By leveraging Oracle CDH data quality management features, PeopleSoft takes advantage of duplicate prevention and merge, and fuzzy search features, thereby providing a single source of truth for customer data.

The data cleansing activities performed in the CDH help to identify and remove customer duplicates. PeopleSoft CRM users can also identify duplicates utilizing the CDH integration. CRM application users can first search for customers by using a CDH search mechanism called Smart Search. The search criteria submitted by the user is directly executed on CDH, and a list of closely matching records is presented to the user in the form of search results. This list could contain duplicate records, which could then be earmarked by users and sent to the CDH Data Librarian in a merge evaluation request message.

Online Duplicate Prevention

PeopleSoft CRM leverages the CDH to prevent the introduction of customer duplicates Before a new customer is created by an online user using Quick Create or from a Customer Data Model component, CDH duplicate prevention logic is invoked. The duplicate prevention logic first does a customer search and presents the CRM user with a list of possible duplicates of the new customer being created. The user can either pick a duplicate from the list, or else proceed with creation of the new customer. Duplicate prevention is also implemented in some CRM batch processes like Lead Import and the Financial Account creation EIP.

This diagram illustrates the duplicate prevention process flow:

Duplicate prevention process flow

Duplicate business objects may get introduced into the system from various application pages in CRM. For example a sales user could create a new Customer record while entering an opportunity, without checking if the customer already exists in the system. Also, typographical errors made by users while entering customer information like name and address often lead to creating a customer that already exists and thus introducing a duplicate.

Duplicate Prevention logic is implemented in specific areas of CRM which deal with creation of new Business Objects:

• All Customer Data Model pages that add new Business Objects support duplicate prevention.

• All Quick Create screens that are used by various application transaction pages to quickly create new Business Objects have been enhanced.

• Certain application business flows implement duplicate prevention logic.

Online Duplicate Prevention logic for Customer Data Model components is enforced during the addition of new Business Objects. When a user tries to add a new Business Object, a list of potential duplicate records is displayed to the user before the component page is opened. This is done by invoking the appropriate Match Rule in CDH. Note that there is no duplicate prevention logic enforced when an existing BO is updated from a CDM component page.

The components that support duplicate prevention during Add operations are:

• Company

• Consumer

• Contact

• Site

• Partner

• Partner Contact

Duplication Prevention logic is also enforced in the CRM Quick Create functionality. Quick Creates are a fast and easy way to create a Business Object by providing minimal information. They are normally invoked from application transaction pages, but can also be launched standalone.

Duplicate Prevention on a Quick Create page is triggered when a user tries to save the BO information entered in the page. A list of potential duplicates is displayed to the user based on the results returned by the CDH Match Rule execution. Match Scores are also displayed for each record.

The user can continue creating a new Business Object or can pick an existing BO from the list of potential duplicates. If the user picks an existing BO, then the BO is populated on the originating transaction and any information entered by the user on the Quick Create page is discarded. Quick Creates that create standalone Business Objects, such as Quick Create Consumer, as well as those that create Business Objects with parent-child relationships, such as Quick Create Company with Contact, support duplicate prevention.

Match Rules

To compare PeopleSoft CRM customer records to its own customer records, Oracle CDH relies on match rules that relate equivalent fields. PeopleSoft CRM integration with Oracle CDH is delivered with a set of match rules that must be imported into Oracle CDH during installation. The PeopleSoft system includes pages that show implementers these rules, but any changes to the rules (for example, to accommodate a customized system) must be made in Oracle CDH.

Customers Online contains PeopleSoft data and will be available for the Data Librarian to investigate customers’ data. Additionally, the Data Librarian should have access to the PeopleSoft application to view PeopleSoft specific information that is not available in Customers Online.

Understanding Match Evaluation

This table illustrates an example of a match evaluation:

Understanding the Match Rule Process

The match rule process consists of the following steps:

1. Select an attribute such as State.

2. Establish the Match Rules

   • Transformations

   • Replacement Lists

   • Custom Callouts

3. Establish the weightings and scoring

   • Assign attribute importance

   • Set threshold

4. Calculate score

   • At search

   • At data import

   • At data creation

5. Evaluate duplicates

   Score > Threshold = Possible Duplicate

Understanding Match Rules

Match rules are defined for the following uses:

• Online Duplicate Prevention

  When a user creates a new business object in CRM, these match rules are invoked. Any resulting matches that exceed the match threshold are presented to the user as potential duplicates. The user can then select one of the potential matches or proceed with the creation. If the override threshold is met or exceeded for a potential match, the user is required to use the matching BO and is prevented from creating a new BO. Online duplicate prevention is defined for Company, Partner, Site, and Person (Contact or Consumer) BOs.

• Smart Search and Merge Initiation from Search

  When a user searches for a Company, Partner, Site, Person or Customer, these match rules are invoked. Any results that exceed the match threshold are listed as potential duplicates, and the user can select two or more potential duplicates and submit them to the data librarian for merge evaluation.

• System Duplicate Identification Batch (SDIB) Match Rules

  These match rules are invoked during batch data cleansing. Even if a match exceeding the match threshold occurs, the merge might be prohibited due to PeopleSoft external merge rules.

Duplicate Prevention Match Rules

The following match rules are invoked when creating new business objects in CRM. The resulting matches, exceeding the Match Threshold, are presented to the user as potential duplicates. Where the Override Threshold for any returned result is met or exceeded, the user is required to select the matching BO and is prevented from creating a new BO.

• Company

  This match rule is used to identify duplicates when creating a company either in the CDM component for Company Add or the Quick Create of Company.

  Address attributes displayed on the page will be based on the country selected by the user

  Criteria	Details
  Match Rule Name	ECRM_COMPANY_ADD
  Purpose	Search
  Search Operator	Match All Attributes
  Match Threshold Percentage	80%
  Override Threshold Percentage	100%
  Merge Threshold Percentage	N/A

  Note. Partner duplicate prevention uses the same rule as Company: ECRM_COMPANY_ADD.

• Site

  This match rule is used to identify duplicates when creating a site either in the CDM component for Site Add or the Quick Create of Company with Site.

  Address attributes displayed on the page will be based on the country selected by the use.

  Since this release does not support Energy sites, all sites created will be associated with a company.

  Criteria	Details
  Match Rule Name	ECRM_SITE_ADD
  Purpose	Search
  Search Operator	Match All Attributes
  Match Threshold Percentage	80%
  Override Threshold Percentage	100%
  Merge Threshold Percentage	N/A

• Person

  This match rule can also be used for Quick Create of Contact or Consumer.

  Criteria	Details
  Match Rule Name	ECRM_PERSON_ADD
  Purpose	Search
  Search Operator	Match All Attributes
  Match Threshold Percentage	80%
  Override Threshold Percentage	100%
  Merge Threshold Percentage	N/A

Search Match Rules

Business Object Search criteria is linked to a DQM match rule.

Seeded date is supplied for these search match rules:

• Business Object Search for Company

  Criteria	Details
  Match Rule Name	ECRM_COMPANY_SEARCH
  Purpose	Search
  Search Operator	Match All Attributes
  Match Threshold Percentage	80%
  Override Threshold Percentage	N/A
  Merge Threshold Percentage	N/A

  Partner search uses the same rule as Company Search: ECRM_COMPANY_SEARCH

• Business Object Search for Site

  Criteria	Details
  Match Rule Name	ECRM_SITE_SEARCH
  Purpose	Search
  Search Operator	Match All Attributes
  Match Threshold Percentage	80%
  Override Threshold Percentage	N/A
  Merge Threshold Percentage	N/A

• Business Object Search for Person

  Criteria	Details
  Match Rule Name	ECRM_PERSON_SEARCH
  Purpose	Search
  Search Operator	Match All Attributes
  Match Threshold Percentage	80%
  Override Threshold Percentage	N/A
  Merge Threshold Percentage	N/A

• Business Object Search for Customer (Company, Site, Consumer)

  Criteria	Details
  Match Rule Name	ECRM_CUSTOMER_SEARCH
  Purpose	Search
  Search Operator	Match All Attributes
  Match Threshold Percentage	80%
  Override Threshold Percentage	N/A
  Merge Threshold Percentage	N/A

• Business Object Search for Customer (Company, Site, Consumer) and Person

  Criteria	Details
  Match Rule Name	ECRM_ORG_PER_SEARCH
  Purpose	Search
  Search Operator	Match All Attributes
  Match Threshold Percentage	80%
  Override Threshold Percentage	N/A
  Merge Threshold Percentage	N/A

• Additional match rules

  Search	Match Rule
  BO Search for Consumer with Person	Use the same rule as Person Search ECRM_PERSON_SEARCH
  BO Search for Organization (Company, Partner, Site) with Contact	Use the same rule as Org with Person Search ECRM_ORG_PER_SEARCH.
  BO Search for Consumer with Contact	Use the same rule as Person Search ECRM_PERSON_SEARCH
  BO Search for Organization (Company, Partner) with Site	Use the same rule as Org with Person Search ECRM_ORG_PER_SEARCH
  BO Search for Site/ Contact of a Consumer	Where one search is invoked use can be made of ECRM_ORG_PER_SEARCH. Where two searches are to be invoked use ECRM_COMP_SEARCH and ECRM_PERSON_SEARCH
  BO Search for Site/ Contact of a Company/ Partner	Where one search is invoked use can be made of ECRM_ORG_PER_SEARCH. Where two searches are to be invoked use ECRM_COMP_SEARCH, ECRM_SITE_SEARCH and ECRM_PERSON_SEARCH

System Duplicate Identification Batch (SDIB) Match Rules

In addition to matching on name and address, the following attributes must match for the party to be identified as a duplicate in SDIB:

• SDIB Match Rules for Company

  • The Company’s TIN must be an exact match

  • SetID

  • Party usage = Company

• SDIB Match Rules for Partner

  • The Company’s TIN must be an exact match

  • SetID

  • Party usage = Partner

• SDIB Match Rules for Site

  • Company

  • SetID

  • Party usage = Site

• SDIB Match Rules for Person

  • SetID

  • NID, country and type

Additional match rules prevent duplicates when:

• Importing sales leads.

  • ECRM_SLS_LEAD_IMPORT_COMPANY

  • ECRM_SLS_LEAD_IMPORT_CONSUMER

  • ECRM_SLS_LEAD_IMPORT_CONTACT

• Creating financial accounts

  • ECRM_FIN_ACCT_COMPANY

  • ECRM_FIN_ACCT_PERSON

Smart Search

Smart Search is an advanced search mechanism provided in CDH, that identifies business objects like Customers and Contacts that are similar to the ones submitted in a search criteria, but not necessarily the same. This functionality can be referred to as fuzzy searching, where pre-defined logic contained in Match Rule definitions is used to display records that could potentially match the submitted search criteria.

This diagram illustrates the results of a search for exact matches:

Example of exact match search

This diagram illustrates the results using fuzzy searching:

Example of fuzzy searching

To support this functionality PeopleSoft CRM provides pre-built Match Rules of type Search, which are installed in CDH.

When a user performs a Smart Search, the system displays the matching records and a Match Score for each record. A Match Score is a percentage number which denotes how close a matching record is to what was searched for. For example, a record with a 90% match score is considered a closer match than one with an 80% match score.

All the Business Object Searches that are invoked from transaction pages have been enhanced to utilize the Smart Search mechanism of CDH. When a user performs a search operation with the smart search option turned on, the search is executed against the Hub.

Smart searching is only supported on advanced BO search pages and it is not applicable to basic BO search. When a user first looks up a business object, such as a customer, from a transaction, the basic BO search is used typically. If the search does not return any exact match, the user is then transferred to the Advanced Search page where smart searching is supported and additional search criteria can be entered to find the business object. The user can click the Advanced Search link on the main transactional page to perform advanced BO search. Other types of searches in CRM do not support smart searching.

For example, Customer Data Model component search pages, which use the Configurable Search mechanism have not been Smart Search enabled. Most CRM transaction components like Case, Opportunity, Order, Task and so on employ advanced BO searches and as a result enable smart search. The Customer 360 degree search screen also supports smart searching.

A Smart Search check box is provided on every advanced BO Search screen. This option is visible and defaults to selected if the following conditions are met:

• CDH is installed on the Installation page.

• Smart Search is activated on the CDH Installation page.

• Smart Search is activated on the BO Search Criteria page.

If checked, the CDH Smart Search is triggered on search execution. If unchecked, the search is performed against CRM.

There are some instances when a search is done against CRM even if the Smart Search check box has been selected.

If the Customer Data Hub integration is temporarily unavailable, the search is done against CRM and a message is displayed to notify the user:

Example of Smart Search encountering CDH unavailability

If the CDH Smart Search returns too many records due to a search criteria that is too broad, a message is shown, which suggests that the search should be refined to get meaningful results:

Example of Smart Search producing too many results

The number of results depends on the business object search setup under Set Up CRM, Common Definition, Customer, BO Search, Search Role.

Similarly, a message is displayed if the CDH Smart Search cannot return any search results based on the specified criteria:

Example of Smart Search returning no results

Understanding Data Merge

This section provides an overview of data merges and discusses:

• The merge process.

• The merge impact on a company.

Along with data consolidation and data enrichment, one of the main uses of the Customer Data Hub is data cleansing. Cleansing data means identifying duplicates introduced into the system and then blending duplicate records into a master record. This process is called a Merge. CDH can merge Parties, their relationships, and addresses to maintain clean data.

The CDH Data Librarian is responsible for submitting merge processes. Merge Requests are notifications sent to the Data Librarian by users and by an automated process, requesting potential duplicate parties in the system to be merged. These merge requests sit in the Merge Request Queue of the Data Librarian, awaiting review. PeopleSoft CRM users can also initiate Merge Requests from the Smart Search results. In this release, all Advanced BO search screens in CRM allow sending Merge Requests to CDH. Two or more search result records can be marked as duplicates and submitted to the CDH Data Librarian’s Merge Request Queue. The Data Librarian reviews new Merge Requests and decides whether a merge is warranted. Before submitting a merge process, the Data Librarian chooses which of the parties will be the master record or Survivor, which attributes of the Survivor will be maintained, and which ones will be overwritten by values taken from one of the Non Survivors. On successful completion of the merge, the Non Survivors are inactivated.

De-duplication in CDH ensures that the master Customer record is kept accurate and up-to-date through the blending of attributes from duplicates into the master record. CRM data is also kept accurate as a result of this. Fragmentation of data belonging to the same customer is reduced, and this allows more accurate generation of reports.

Rules for Merging Business Objects

For PeopleSoft CRM data that is synchronized to CDH, certain validations are done to ensure that a merge in CDH would not cause inconsistencies in CRM. When any of these validations fails, the merge is not allowed to go through and error messages are returned. The list of validation rules are:

• Only Parties corresponding to business objects in the same setID can be merged.

• The business objects merged must be the same type.

  For example, a merge between an organization like a customer and an individual like a consumer is not allowed.

• Companies and Partners can be merged with one another.

• Consumers, Contacts, and Partner Contacts can also be merged with one another.

  For example, a person might be a consumer, and the same person might exists as a duplicate as a business contact. These two records could be merged with one of them designated the Survivor.

• Sites can only be merged with other sites provided that they belong to the same Company or Consumer.

• Workers cannot be merged with another worker.

  But a Worker can be merged with other persons like Consumers. The same rule applies to Persons of Interest, Student Admin Consumers, and Sales Users.

Interface for Requesting Merges

If Smart Search presents users with a list of potential duplicate customer, users can select two or more of the potential duplicates from the search results and submit them to the data librarian for merge evaluation. This functionality is available only when the Data Librarian functionality (part of Oracle CDH) is licensed.

The interface for submitting a merge request is the same in search pages that use PeopleSoft CRM configurable search functionality and pages that use BO search functionality.

System Limitations During a Merge

While a merge is in process, roles and relationships are deactivated and the business object is not found in BO Search results.

Data Handling for Merged Business Objects

When two business objects merge:

• The status of the objects remains Active even after a merge request has been sent to the Data Librarian. The Data Librarian processes the request and the necessary updates occur in CDH. Then an AE process is submitted to update the CRM data. At this point the status changes to Merge In Process. Once the merge is complete, the merge-to object is set to Active, and the non-survivors are set to Inactive.

• The names of the merge-from business object become alternate names for the merge-to business object. The merge-from object's primary name is assigned the new name type Merged.

Additional Considerations for Data Merges

The HZ:Default Profile Attributes for Merge Mapping is used to identify whether the Master Party Value or the Most Frequent Value is to be used for profile attributes. For the CRM implementation this must be set to Master Party Value.

The HZ: Default Secondary Profile Attributes for Merge Mapping is used to identify if a conclusive value is not found by the HZ:Default Profile Attributes for Merge Mapping. Set this value to be the same for both CRM and CDH.

National ID matching is based on the CRM primary NID value.

MERGE operator ID must be included in production as this is the ID used to stamp merged BOs. Users should not change the password.

Data that has had business objects replaced will no longer be visible on the merged-from business object.

Understanding the Merge Process

CDH performs a party merge that merges party information such as names, addresses, phones and so on. A CDH event is generated informing spokes of the merge and providing the merge-to and merge-from parties.

The party merge process consists of the following steps:

1. The Data Librarian submits a merge.

   The merge process in CDH completes by consolidating Survivor information and inactivating the non survivors.

2. CDH event notifies the CRM spoke of a merge and identifies the master BO.

   CRM receives information about the merge, such as Survivor, Non Survivor and other data.

   CDH merges party details.

3. CRM reacts by running Merge Handlers in the background. The Merge Handler for CDM merges corresponding records and attributes and rearranges relationships.

4. CRM inactivates the non-surviving business object and invokes the inactive customer EIP for SCM.

5. For successfully merged business objects, CDM initiates the merge routines for the applications.

Merge Handlers

A Merge Handler is a program in CRM that updates a set of specific database tables in response to a CDH Merge. Several Merge Handlers are provided as out-of-the-box system data.

Handlers are grouped by product area and further organized by the application transactions they are responsible for handling. A single Handler program manages all updates that are required for CDM. Separate Handlers exist to update individual application transactions like Case, Lead, Agreements, Orders and so forth.

Handlers are registered on the Data Hub Merge Registry page. Registered Handlers provided out-of-the-box cannot be modified or inactivated. However, additional handlers can be adding during implementation, to take care of customizations and product extensions that require tables to be updated. Handlers are designed to run in a particular sequence that is specified on the Data Hub Merge Registry page. For example, the application handlers run after the CDM handler. Some of the provided handlers send notifications to a specified role after they finish execution.

CRM Reaction to the Merge

The Merge Handler for CDM is responsible for merging CDM business objects. It performs the following activities:

• The Non-Survivor business object record is inactivated.

  Once inactivated, this business object cannot be updated and cannot be used on transactions.

• The Non Survivor’s name is added to the survivor as an alternate name.

• When CRM data is synched to CDH, not all the attributes of a Business Object are synced. The attributes that are not synced are merged or blended into the Survivor record:

  • Non-blank attributes of the survivor are always retained. This is based on the Primary Merge Rule as defined on the CDH Installation Options page.

  • If the Survivor has a blank attribute, then it gets its value from the corresponding attribute of the Non Survivors. If there are multiple Non Survivors, then the Secondary Merge Rule selected in the CDH Installation Options page is used to decide which of the Non Survivors is used for attribute selection.

• All roles of the Survivor are retained. Unique, active roles of the Non Survivor are added to the Survivor.

  This result may vary depending on the merge rules defined on the CDH Installation Options page.

• All relationships of the Survivor are retained. Relationships of the Non-Survivor may be added to the Survivor depending on the action taken by the Data Librarian during the merge. The non-survivor relationship is end-dated on the non-survivor record which is now in a status of Inactive.

• Contact methods of the Non-Survivor may be added to the Survivor.

  This result may vary depending on the action taken by the Data Librarian during the merge.

Understanding the Merge Impact to a Company

This section provides an example of the merge impact to a company.

In this example, there are two customers – Johnson Inc. and Johnson Cars Inc.

• Johnson Inc. has the Bill To, Ship To and Sold To roles, in addition to the Company role.

  Johnson Cars Inc. has only the Company role

• Tyson Bruno is a contact for Johnson Inc., while Calvin Dobbs is a contact for Johnson Cars Inc.

• The addresses for Johnson Inc. and Johnson Cars Inc. are not the same.

The Data Librarian merges these two companies, making Johnson Cars Inc. the Survivor.

Once the CDM Merge Handler runs successfully, Johnson Inc. is inactivated since it is the Non Survivor. This Company becomes read-only and can no longer be updated. A link is provided for the user to navigate to the Survivor company, which is Johnson Cars Inc.

Example of a non-survivor inactivated after the merge

Click the This Company has been merged to <survivor component name> link to access the company component of the survivor. Note that the survivor component name that appears in the link label is the name of the final merge-to company. For example, if a company named ABC is merged to Company ABD, and Company ABD is later on merged to Company ABE, the link label that appears on the Company - Summary: Summary page of Company ABC (which is now inactivated) becomes This Company has been merged to ABE.

This link is available in the Person component as well with a person-specific link label, for example, This Individual Consumer has been merged to <survivor component name>.

This page shows the survivor of the merge, Johnson Cars Inc.

Example of the survivor and non-survivor names after merge

Johnson Inc., the Non Survivor, has been added as a merged name to Johnson Cars Inc. If a user searches for Johnson Inc., the results will show Johnson Cars. Inc.

Prior to the merge, Johnson Inc. had the these roles:

Example of the Johnson Inc. roles prior to the merge

Johnson Cars Inc. had only the Company and Business Contact (ORG) roles.

After the merge, the Ship To, Sold To, and Bill To roles of Johnson Inc. have been added to Johnson Cars Inc.

Examples of roles for Johnson Cars Inc. after the merge

Tyson Bruno has a contact relationship with Johnson Inc. while Calvin Dobbs has a contact relationship with Johnson Cars. Inc. During the processing of the merge request in the CDH, the Data Librarian elected to append contacts from the non-survivor company to the survivor company. This page shows that both contacts are added to Johnson Cars Inc. record after the merge.

Example of contacts for Johnson Cars Inc. after the merge

After the Merge is complete, you can view the merge history from the Survivor component by clicking the View merge history for <survivor component name> link that is displayed in the Status section of the Company - Summary: Summary page. This link is available in the Person component as well.

Note. If the company you are currently viewing happened to be a survivor company in past merges but it becomes the non-survivor company in the most recent merge and has been inactivated, the link for viewing merging history is renamed to View previous merge history for <non-survivor component name> link.

There are four tabs on the Merge History page: Main, Roles, Relationships, and Contact Methods. You can view detailed information about the merge on these pages.

Example of Main Merge History for Johnson Cars Inc.

The Main tab shows the Merge-From or Non-Survivor business objects that were merged into the Merge-To or Survivor. In this case, Johnson Cars Inc. is the Survivor.

The Roles tab shows the merge history of the roles of the Survivor and Non-Survivor. New Ship To, Bill To and Sold To roles were added to the Johnson Cars Inc. from Johnson Inc.

Example of Roles Merge History for Johnson Cars Inc.

The Relationships tab shows a history of the merged relationships:

Example of Relationships Merge History for Johnson Cars Inc.

The Contact Methods tab shows a history of the merged contact methods:

Example of Contact Methods Merge History for Johnson Cars Inc.

CDH Terminology

The following terms are used in this document: