Вы находитесь на странице: 1из 9

TCA AND CDH

TRADING COMMUNITY ARCHITECTURE (TCA)


• TCA is the customer master in Oracle, it enables you to capture your company’s
relationships with real world entities, their locations, relationships between them,
contacts and their entities including their phone/fax/cell numbers/email, etc.
• You can define reciprocal and non reciprocal relationships between parties and
accounts
• In Release 12, the TCA has been enhanced to incorporate suppliers into TCA. So if a
company has a buying and selling relationship with an entity, that can be defined the
TCA as a single entity (customer and supplier) and this enables you to do things like
AR/AP netting, helps with better reporting, also helps with maintenance, etc.
• The Key entities of the TCA are –
– Parties – the highest level in the TCA – Parties are global in nature and are not Org Specific
– Party Relationships – This can be reciprocal and non reciprocal, used to relate parties (example – if
companies merge or if companies gets acquired)
– Customer Accounts – These are entities that belong to a party. Customer Accounts are specific to an
Organization. Example is if Cisco is a Party – we can setup Cisco US, Cisco Canada, Cisco India as
customer accounts that belong to Party “Cisco”
– Locations – These are addresses for parties and accounts
– Contacts – Contact for customers
– Contact Points – These are the phone, fax, email, etc.
– Site Uses – Like Ship to, Bill To, etc.
TCA DATA DATA MODEL
• TCA DATA MODEL
– Main tables in the TCA Schema are
– HZ_PARTIES : Stores information about parties.
– HZ_ORGANIZATION_PROFILES : Stores details information about credit rating, financial statistics, socio-
economic and corporate linkage information.
– HZ_CUST_ACCOUNTS : Stores information about the relationship, if a party becomes a customer. Basically stores
information about customer accounts.
– HZ_CUST_ACCT_SITES_ALL : Stores information about customer sites. One customer can have more then multiple sites.
– HZ_CUST_SITE_USES_ALL : Stores information about site uses or business purpose. A Single customer site can have
multiple sites uses such as Bill To or Ship To.
– HZ_CUST_ACCT_RELATE_ALL : Stores information about relationships between customer accounts.
– HZ_CUST_ACCOUNT_ROLES : Stores information about the roles that parties perform in customer accounts.
– HZ_CUSTOMER_PROFILES : Stores credit information for a customer account and customer account sites.
– HZ_CUST_PROFILE_AMTS : Stores profile amount limits for every currency defined for a customer account or customer
account site profile.
– HZ_CUST_PROF_CLASS_AMTS :Stores customer profile class amount limits for currency.
– HZ_CUST_PROFILE_CLASSES : Stores standard credit profile classes.
– HZ_CONTACT_POINTS : Stores electronic methods of communicating with entities such as parties, party site. Each record
in this table represents s different means of contacting an entity. HZ_PARTIES_SITES : Stores information about parties
and locations. Because there is a many-to-many relationship between parties and locations.
– HZ_PARTIES_SITE_USES : Stores information about the party site uses and business purposes. A party site can have
multiple site uses such as ‘bill to’ or ‘ship to’ and each site is stores as a record in this table.
– HZ_LOCATIONS : Stores information about the locations, namely, address information
TCA APIs
API NAME PACKAGE USED BASE TABLES
• CREATE ORGANIZATION API HZ_PARTY_V2PUB HZ_PARTIES,
HZ_ORGANIZATION_PROF
ILES
HZ_PARTIES
• CREATE PERSON API HZ_PARTY_V2PUB HZ_PERSON_PROFILES
• CREATE ORG CONTACT API HZ_PARTY_CONTACT_V2PUB HZ_ORG_CONTACTS and
HZ_RELATIONSHIPS
• CREATE ORG CONTACT HZ_LOCATION_V2PUB
HZ_LOCATIONS
ROLE API
HZ_PARTY_V2PUB HZ_PARTY_SITES
• CREATE LOCATION API HZ_PARTY_SITE_USES
• CREATE PARTY SITE API HZ_PARTY_SITE_V2PUB HZ_CONTACT_POINTS
• CREATE PARTY SITE USE API HZ_PARTY_SITE_USE_V2PUB HZ_RELATIONSHIP_TYPE
S
• CREATE CONTACT POINT API HZ_CONTACT_POINT_V2PUB
HZ_RELATIONSHIPS
• CREATE RELATIONSHIP TYPE HZ_RELATIONSHIP_TYPE_V2P HZ_CUST_ACCOUNTS,
API UB HZ_CUSTOMER_PROFILE
• CREATE RELATIONSHIP API S
• CREATE CUSTOMER HZ_RELATIONSHIP_V2PUB HZ_CUST_ACCT_SITES
ACCOUNT API HZ_CUST_ACCOUNT_V2PUB HZ_CUST_SITE_USES
HZ_CUSTOMER_PROFILE
• CREATE CUSTOMER HZ_CUST_ACCOUNT_SITE_V2
PUB S
ACCOUNT SITE API
HZ_CUST_ACCOUNT_SITE_V2
• CREATE CUSTOMER PUB
ACCOUNT SITE USE API HZ_CUSTOMER_PROFILE_V2P
• CREATE CUSTOMER UB
PROFILE API
CDH Overview
DEFINITION OF CDH
• Oracle Customer Hub is a customer data integration (CDI) solution that enables
organizations to centralize information from heterogeneous systems, creating a single view
of customer information that can be leveraged across all functional departments and
analytical systems. In our case the heterogeneous systems will be MAPEX Mainframe
system.

OVERVIEW OF CDH
• Oracle CDH is a full featured application addressing customer data integration requirements
• This includes the Trading Community Architecture (TCA) (API’s, Web Services, etc.), User
Interface (Oracle Customer Online, Oracle Data Librarian), Out of the Box integration for
third party enrichment, standard interface to Dun and Bradstreet (D&B), and address
validation (third part tools like Trillium and First logic can be used for this)
• Facilitates a single system of truth for all customer data which can be maintained and can
be synchronized to all systems that are subscribed to the CDH
• The CDH serves as a master for Customer Data
• The integration with all connected systems happens via web services using the
Publish/Subscribe approach
CDH MAIN SETUPS
• Setting up De-Duplication
– Run the DQM Staging program to create the staged schema.
– Periodically run the DQM Synchronization program to update the staged schema.
– Compile all match rules that we plan to use.
– To create match rules to be used for Auto merge in System Duplicate Identification batch
creation, we must define the match rules as allowed for Auto merge.
• Setting up Import process
– We can Load source files of data into the import interface tables.
– We can Transfer batches of data from the interface tables into the TCA Registry.
• Setting up Party Maintenance
– Set up CDH for the search of organizations and person to maintain.
– We can manage the available levels and reasons.
• Business Rules – We can define multiple business rules and logic to check for
duplicate records and for smart search to help users find existing records.
• Setting up Profile Options
– There are many profile options that need to be setup based on the implementation.
• Data Sharing and Security (DSS): We can control the access privileges of users to create, update,
or delete customer data.
• Third Party Data Integration: Using this we can Integrate Oracle Customer Data Librarian with D&B
so that users can access D&B information to enrich customer information.
• Source System Management: We can set up for mappings between external source systems and
customer data. We can control how source system and user-entered data are displayed, created, and
overwritten.
• Setting up Smart Search
CDH ARCHITECTURE
• Oracle's Trading Community Architecture (TCA) provides the basis for the Customer
Data Hub. TCA is made up of two core elements: the database schema and the
enabling infrastructure.
• The TCA database schema is the repository for all party related data (a party may
be an organization, a person, a buying compant, a contact, a supplier, a partner, or
any other person or organization with which you do business), including profile
characteristics of a party (who/what they are), what their association/relationship with
other parties is, where they are located, what the locations are used for, how to get in
touch with them, how they are classified and more.
• CDH APPLICATION LAYER
– Oracle Customer Online
– Oracle Customer Data Librarian
– Oracle Data Quality Management (DQM)
Integration of CDH with Third Party
• Source Management Rules have to be setup
• Bulk Import functionality has to be setup

INITIAL POPULATION of CDH


• Take snapshot of customer data form source system
• Extract data from source system using ETL Tool
• Import customer data into TCA interface tables
• Run the Bulk Import process
• Run the Oracle Data Librarian to cleanse and de dup the data
• Enrich the data
• Generate TCA records

SUBSEQUENT LOAD OF CUSTOMER DATA


• The same process above has to be followed with certain changes
– Address validation is optional for existing data
– Bulk Import de-duplication is optional
– Auto Merge can be run to merge duplicate data
CDH Integration with Oracle EBS

• The Oracle EBS to CDH integration is made up of various integration components,


each playing a unique role:
– The Integration Broker handles inbound and outbound messaging and acts as
the integration gateway. It supports asynchronous as well as synchronous
messages, as employed in the 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 Oracle EBS and CDH.
– There are Pre-built BPEL processes which are delivered to handle the integration
flows between Oracle EBS and CDH. These processes execute on the BPEL
Server.
– Oracle Warehouse Builder is used as the Extract, Transform, and Load (ETL)
tool to extract and move data from Oracle EBS into CDH during the Sync
Process

Вам также может понравиться