1 Understanding the Oracle Customer Master Data Management Pre-Built Integration

This chapter provides an overview of the Oracle Customer Master Data Management Integration (Customer MDM pre-built integration) and discusses terminology for the participating applications.

This chapter includes the following sections:

Section 1.2, "High-Level Integration Flows"
Section 1.3, "Core AIA Components"
Section 1.4, "AIA Integration Services"

1.1 Overview

The Customer MDM integration provides an enterprise-level customer master solution for publishing customer data updates from the Oracle Customer Hub (OCH) to the various participating applications.

Note:

The Oracle Customer Hub is also referred to in text and graphics as Siebel Universal Customer Master (UCM).

You have the option to select one or more participating applications when installing the Customer MDM integration. Records are persisted in the local applications and are then synchronized to Oracle Customer Hub in realtime or in periodic, batch-enabled mode so that the participating applications have the most up-to-date definition of the customer and related entities.

The Customer MDM integration also provides a partial flow to a third-party customer-data enrichment provider that cleanses, recognizes, enriches, and protects Oracle Customer Hub contact records.

The flows delivered with this integration are an effort to harness the powerful features as part of a pre-built, integrated solution between the OCH and the participating applications.

For more information about installing the participating applications (integration options), see the Oracle Application Integration Architecture Installation and Upgrade Guide for Pre-Built Integrations available on Oracle Technology Network. This guide is continually updated.

For more information about the integration options, see the specific chapters for each integration option. Each chapter provides details about the supported process flows, integration services, and interfaces pertaining to that option (application).

1.1.1 Terminology

The Customer MDM integration can be thought of as a collection of core services used to synchronize customer (and prospect) entities across the participating applications.

The term customer as referenced throughout this document describes an entity (organization or person) with which the company providing services may have or may enter into a financial relationship.

Table 1-1 lists some definitions that are helpful when reading this guide:

Table 1-1 Terminology

Term	Definition
Party	Siebel CRM: High-level entity that includes persons, accounts, business units, and households. No functional usage of party in Siebel. Oracle E-Business Suite: based on Trading Community Architecture (TCA), a party is defined as any individual or organization with which the implementing organization can do business. A party in Oracle TCA could be a customer, (in case a selling relationship has been established) or vendor, employee, or relationship, all defined by a "Party Type." The same party can have multiple such roles within EBS.
Contact	Siebel CRM: A contact describes an individual (person) with whom a company expects to do business. Contacts can be related to an account (organization customer) or another contact (individual customer). Contacts can be associated to a primary account and additional non-primary accounts. Oracle E-Business Suite: A contact describes a specific relationship between two parties. The relationship between organization and a person party, which is also called an organization contact. Can also define the relationship between a party and an account (role type = contact in hz_cust_acct_roles).
Account	Siebel CRM: An account is an organization (or organization subtype) that can be sold or serviced. An account can be associated to one or many contacts or persons but only one contact can be primary. Oracle E-Business Suite: An account describes the specific attributes of a party that are relevant to the financial relationship among parties. An account in Oracle E-Business Suite cannot exist by itself without a party. An account in EBS can be associated with an individual (person) or a company (organization) but cannot in it and of itself be an individual or organization.
Customer	Siebel CRM: A customer is the account (org customer). Oracle E-Business Suite: A customer is a combination of party and account and represents a person or organization with which the implementing organization has established a financial relationship. All relevant information of the specific financial relationship with a party is modeled in the account layer entities in Oracle, whereas all the base information like name, address information, contact points are modeled in the party layer entities. Siebel account = Oracle E-Business Suite organization party + Oracle E-Business Suite account Siebel contact = Oracle E-Business Suite person party + Oracle E-Business Suite account This integration pack supports the notion of a "customer" in both B2B and B2C environment.

Note:

To standardize terminology, we use the organization and person naming conventions throughout the documentation.

This convention is consistent with the entity terms used in the CustomerPartyEBO as well as the terminology in the Oracle E-Business Suite TCA model, but departs from the terminology used in Siebel CRM and Oracle Customer Hub. The Oracle Customer Hub web services that have been developed to support this integration adopt the organization and person terminology for the service and schema definitions, even though the underlying integration objects being referenced continue to use the legacy terms of account and contact respectively.

Table 1-2 lists the conventions:

Table 1-2 Conventions in this document

Documentation	Siebel CRM	Oracle Customer Hub	Oracle E-Business Suite	AIA CustomerPartyEBO	Oracle BRM	SAP
Organization	Account	Account	Organization	Organization	Account	Account
Person	Contact	Contact	Person	Person	Contact	Account

1.2 High-Level Integration Flows

Figure 1-1 illustrates the flows across the participating applications. Customers have the flexibility to select participating applications based on your business needs.

Figure 1-1 Oracle Customer MDM high-level integration flows

This image is described in surrounding text

At a high-level, the Customer MDM integration supports these process flows using the AIA architectural framework:

Match and fetch organizations or persons between OCH and the participating applications.
Synchronization of organizations or persons from OCH to the participating applications and from the participating applications to OCH.
Merge flows from OCH to the participating applications.
Customer-data enrichment flow, which is a partial flow from OCH to any third-party data enrichment application.

1.2.1 Match and Fetch Organizations or Persons

The match functionality enables users to enter a complete or partial customer record in a source application and send the record to the Oracle Customer Hub so that matching logic can be executed against the records in OCH. Oracle Customer Hub returns a list of potential match candidates that are presented to the source application prior to a customer record being committed to the source application database. The match customer service invokes the fuzzy-matching capabilities of Oracle Customer Hub so that an all-inclusive list of candidates is returned. The fuzzy-matching service either supplements or replaces a normal search query executed against the local database to locate a particular customer account or contact.

The fetch process enables users to select a specific record from the list of candidates returned by Oracle Customer Hub in the match process and send a fetch back to Oracle Customer Hub to retrieve and return the full customer profile of the selected record. Oracle Customer Hub returns the latest information for that customer record which either creates a new record in the source application or updates an existing record in the source application.

The process flows for match and fetch are described here:

For match and fetch between OCH and Siebel CRM, see Chapter 3, "Oracle Customer Master Data Management Integration Option for Siebel CRM".
For match and fetch between OCH and Oracle E-Business Suite, see Chapter 4, "Oracle Customer Master Data Management Integration Option for Oracle E-Business Suite".

1.2.2 Synchronizing Organizations or Persons

These flows enable you to synchronize new or updated records from a particular source to one or many target systems. The source can be the Oracle Customer Hub application that invokes the synchronization process to create or update records in the participating applications, or the source can be one of the participating applications that invoke the synchronization process to create or update records in Oracle Customer Hub. The synchronization represents a single service to perform a create or an update call depending on the existence of the customer in the source and target applications.

These integration flows can be triggered manually or as part of an automated process, and are leveraged as part of the match/fetch process.

The synchronization flows for organization and persons are described here:

For synchronization flows from OCH to the participating applications, see Chapter 2, "Oracle Customer Master Data Management Integration Base Pack".
For Siebel CRM for synchronization flows from Siebel CRM to OCH, see Chapter 3, "Oracle Customer Master Data Management Integration Option for Siebel CRM".
For Oracle E-Business Suite for synchronization flows from Oracle E-Business Suite to OCH, see Chapter 4, "Oracle Customer Master Data Management Integration Option for Oracle E-Business Suite".
For synchronization flows from Oracle BRM to OCH, see Chapter 5, "Oracle Customer Master Data Management Integration Option for Oracle Communications BRM".

1.2.3 Merge Flow

A core feature in Oracle Customer Hub is the ability for a data steward to merge customer records. When the data steward merges duplicate account or contact records based on data quality and data cleansing functionality applied to the records, OCH publishes a merge message, which contains the survivor record (to be updated) and the victim record (to be deleted). This merge by data steward invokes functionality in OCH to perform merge of customer victim record(s) into customer surviving record and update the OCH cross-referencing information and source history tables. The merge messages must include the victim record and the surviving record profile.

Merging account or contact records in OCH can be triggered manually or automatically.

The merge customer request published by OCH is conditionally or optionally adopted by the subscribing applications. While most applications typically subscribe to a merge message from OCH, not all subscribing applications may have the ability to implement the merge of survivor and victims records. Without this ability to implement an application merge, there is a significant risk that records remain out of sync. This risk may amount to updates to victim records in applications that do not subscribe to the merge message and may cause updates to victim records in OCH.

By default, the Customer MDM integration merges the customer data in Siebel when a merge is published by the Oracle Customer Hub; however, you can turn off this default behavior should you have a business need when interoperating with applications that do not support a merge process.

To turn off merge publishing by Oracle Customer Hub, set the process property EnablePubSub to False for the UCM Process Merge Request workflow.

For more information about the workflow, see the Siebel Book Shelf: Siebel Business Process Framework: Workflow Guide.

The merge flows from OCH to the participating applications are described in Chapter 2, "Oracle Customer Master Data Management Integration Base Pack".

1.2.4 Data Enrichment Flow

Data enrichment represents a spoke service to the CustomerPartyEBO that requests clean or enriched information from third-party data provider services. This third-party provider cleanses, recognizes, enriches, and protects Oracle Customer Hub contact records.

Data enrichment is described in Chapter 8, "Customer Data Enrichment".

1.3 Core AIA Components

These are the core AIA components as part of the Customer MDM integration:

CustomerPartyEBO
QueryCustomerPartyEBM
QueryCustomerPartyResponseEBM
QueryCustomerPartyListEBM
QueryCustomerPartyListResponseEBM
SyncCustomerPartyListEBM
SyncCustomerPartyListResponseEBM
ProcessCustomerPartyListEBM

The core EBO and EBM XSD files can be located by EBO within the $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Core/EBO/parent folder.

The core EBS WSDL files can be located by EBO within the $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/EBO/ parent folder.

For detailed documentation of individual EBOs and EBMs, click the AIA Reference Doc link on EBO and EBM detail pages in the Oracle Enterprise Repository (OER).

For more information about using the OER and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."

EBOs can be extended, for instance, to add new data elements. These extensions are protected and will remain intact after a patch or an upgrade.

For more information, see Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Extensibility."

1.4 AIA Integration Services

These are the AIA integration services:

CustomerPartyEBSV2
CustomerPartyResponseEBSV2
CustomerPartyOrchestrationEBSV2
CustomerPartyOrchestrationReponseEBSV2
ProcessCustomerPartyEBS
CommunicationsCustomerPartyEBSV2
CommunicationsCustomerPartyResponseEBSV2
FetchCustomerPartyEBF
CommsProcessFulfillmentOrderBillingAccountListEBF
CommsProcessBillingAccountListEBF
InterfaceContactToAccountEBF

1.4.1 CustomerPartyEBSV2

The match and fetch flows use some of the same services as the synchronization flows.

The CustomerPartyEBSV2 is implemented as a lightweight Mediator service that exposes all of the enterprise operations that can be performed with a CustomerParty enterprise object. All of the Customer MDM integration flows make use of the operations provided by this enterprise business service.

This service is deployed as part of the MDM installation. A few routing rules are added to route the messages as part of the Oracle BRM option for OCH. These routing rules route the messages from Siebel and OCH to Oracle BRM, as appropriate.

Customer MDM synchronization flows use the SyncCustomerPartyList operation of CustomerPartyEBSV2.

For more information about this EBS, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing Enterprise Business Services" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services."

1.4.2 CustomerPartyResponseEBSV2

The match and fetch flows use some of the same services as the synchronization flows.

The CustomerPartyResponseEBSV2 is implemented as a lightweight Mediator service that exposes all of the enterprise response operations that can be performed with a CustomerParty enterprise object. All of the Customer MDM integration flows make use of the response operations provided by this enterprise business service.

Customer MDM synchronization flows use the SyncCustomerPartyListResponse operation of CustomerPartyResponseEBSV2.

1.4.3 CustomerPartyOrchestrationEBSV2

The CustomerPartyOrchestrationEBSV2 is the front-end interface to the FetchCustomerPartyEBF. AIA guidelines suggest that EBFs be called only by other EBFs or an EBS. These operations are used by this service:

AsyncFetchCustomerParty
FetchCustomerParty

1.4.4 CustomerPartyOrchestrationResponseEBSV2

The CustomerPartyOrchestrationResponseEBSV2 exposes the callback operation, which is invoked by the FetchCustomerPartyEBF after the synchronization has completed. This service routes back to the original caller instance. This service uses AsyncFetchCustomerPartyResponse operation.

1.4.5 ProcessCustomerPartyEBS

This Mediator service routes the ProcessCustomerPartyListEBM to the third-party provider and passes the response EBM back to the Oracle Customer Hub requester.

1.4.6 CommunicationsCustomerPartyEBSV2

The CommunicationsCustomerPartyEBSV2 enterprise business service exposes all of the enterprise operations that can be performed with a CustomerParty enterprise object for Communication industry. The integration uses these operations provided by the CommunicationsCustomerPartyEBSV2:

QueryCustomerPartyList
SyncCustomerPartyList

Figure 1-2 illustrates the relationship of CommunicationsCustomerPartyEBSV2 with the other services in the integration flow:

Figure 1-2 CommunicationsCustomerPartyEBSV2

For more information about Communications-specific services or flows, see the Oracle Communications Order to Cash Integration Pack for Siebel CRM, Oracle Communications Order and Service Management, and Oracle Communications Billing and Revenue Management Implementation Guide, or the Siebel CRM Integration Pack for Oracle Communications Billing and Revenue Management: Agent Assisted Billing Care Implementation Guide.

1.4.7 CommunicationsCustomerPartyResponseEBSV2

CommunicationsCustomerPartyResponseEBSV2 exposes all of the enterprise response operations that can be performed with a CustomerParty enterprise object. All of the customer management integration flows use the operations provided by this enterprise business service.

Figure 1-3 illustrates the relationship of CommunicationsCustomerPartyResponseEBSV2 with the other services in the integration flow:

Figure 1-3 CommunicationsCustomerPartyResponseEBSV2

1.4.8 FetchCustomerPartyEBF

The FetchCustomerPartyEBF orchestrates the query request to the customer master provider (Oracle Customer Hub) and the subsequent synchronization of that customer to the requesting system (Oracle E-Business Suite and Siebel CRM). This EBF supports both asynchronous and synchronous interaction patterns. The asynchronous pattern is used by Siebel requests with a callback using the CustomerPartyResponse EBS. The synchronous pattern is used by Oracle E-Business Suite for its request and response interaction.

For more information about EBFs, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Constructing Enterprise Business Flows" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding Enterprise Business Services," Enterprise Business Flow Processes.

1.4.9 CommsProcessFulfillmentOrderBillingAccountListEBF

This Enterprise Business Flow (EBF) extracts the CustomerData from OrderEBM. The process loops through every order line and extracts any customer account or billing profile that it encounters.

This service has two operations: The first operation accepts the ProcessFulfillmentOrderBillingAccountListEBM and is used by the process to order data, and the other operation is used by the process to send the response back to the calling process (using the ProcessFulfillmentOrderBillingAccountListEBM).

The transformations include:

ProcessFulfillmentOrderBillingAccountList to ResponseEBM.xsl
ProcessFulfillmentOrderBillingAccountListEBM to ProcessBillingAccountListEBM.xsl

Figure 1-4 illustrates the relationship of CommsProcessFulfillmentOrderBillingAccountListEBF with the other services in the integration flow:

Figure 1-4 CommsProcessFulfillmentOrderBillingAccountListEBF

The CommsProcessFulfillmentOrderBillingAccountListEBF enterprise business flow is implemented as an asynchronous delayed response BPEL process.

1.4.10 CommsProcessBillingAccountListEBF

This EBF service creates or synchronizes all the customer accounts and billing profiles in an appropriate billing system. The Order Processing integration flow invokes this service with a list of Customer Account IDs, Billing Profile IDs, and the Target System ID. When the process is complete, a response is sent back to the order flow confirming that all accounts have been set up in the target billing system, and the order processing can continue.

This service provides two operations. The first operation accepts the ProcessBillingAccountListEBM, and is used by the process to receive the customer data to be synchronized. The other operation is used by the process to send the response back to the calling process (using the SyncCustomerPartyListResponseEBM).

The data area of the message contains one or more customer account IDs. For each account, one or more bill profile IDs must be synchronized to the target billing system. The customer data indicates both the hierarchical and the paying relationships between the accounts.

This service creates or synchronizes one or more customers (identified by ID only) and their billing profiles to a particular target billing system (identified in the EBM header). Therefore, the responsibilities of this service include:

To determine whether the customer already exists and is up to date in the target billing system. If so, it optimizes and does not try to create or synchronize.
If needed, retrieve the customer data from the appropriate Siebel CRM system using the provided IDs.
To optimize, if possible, the number and size of queries back into Siebel CRM for the customer data.
To create or to update the customers and billing profiles in the target billing system, reflecting the customer hierarchy, and paying relationships among the customers.

Figure 1-5 illustrates the relationship of the CommsProcessBillingAccountListEBF with the other services in the integration flow:

Figure 1-5 CommsProcessBillingAccountListEBF

1.4.11 InterfaceContactToAccountEBF

InterfaceContactToAccountEBF is an asynchronous BPEL process, which routes the account message from the CustomerPartyEBSV2 to CommunicationsCustomerPartyEBSV2 when a contact is updated in OCH. This service sends the account details from the payload (one message at a time) to EBS services, which in turn synchronizes it to Oracle BRM. Upon receiving the account list, InterfaceContactToAccountEBF service performs these validations on the accounts:

It checks whether the account is for an update in BRM.
It ensures that the associated contact for the account is the primary contact for the account.

If both these validations pass, CommunicationsCustomerPartyEBSV2 routes the message for further processing.