This chapter covers the following topics:
These general implementation steps apply to setting up TCA for using the Trading Community Manager responsibility:
You can also perform any of the administration steps as part of implementation, for example setting up Data Quality Management. See: Introduction to Administration. To implement specific features in the Trading Community Manager responsibility, see: Feature-Specific Implementation.
Set up individual users of Oracle Trading Community Architecture. Two responsibilities are available for TCA users:
Trading Community Manager: Access to all TCA features, with view-only privileges for Data Sharing and Security (DSS) administration.
TCA Data Security Administrator: Administration privileges for Data Sharing and Security. Assign this responsibility along with Trading Community Manager to users who need to administer DSS.
This table describes the menus and access available to each responsibility.
Responsibility: System Administrator
See: Oracle E-Business Suite Security Guide.
Related Topics
Use the Customer text data creation and indexing program to index customer account information, including account sites, contacts, and contact points. The program creates and updates an interMedia index on the HZ_CUST_ACCT_SITES_ALL table.
You create the index when you run this program for the first time. Schedule the program to periodically run, to ensure that the customer account data is up to date for searches on the index. Base the frequency on your business needs, for example, how often customer data is updated or searched.
Important: Use this parameter only for the first time that you run this program.
Build Compact Index: Specify if you want to build a compact index that does not include contact information for customer accounts and customer account sites.
Related Topics
Run the following program as needed as part of your implementation or upgrade.
Run this program once, when you first implement or upgrade from a release earlier than 11i.HZ.K mini-pack. Run this program only if you used the ORIG_SYSTEM_REFERENCE column before upgrade and want to use source systems after upgrade. See: Source Systems Overview. In the program parameter, specify the batch size, or number of records to process for each commit.
The Source System - Migrate Party Level Source System References program migrates nonunique source IDs, or references, from these party level tables to the HZ_ORIG_SYSTEM_REFERENCES table:
Along with the migrated source IDs, the program assigns a corresponding UNKNOWN source system because the source system is usually not captured for all existing data. In addition, existing source IDs in party level tables are not unique, so multiple party level records can use the same source ID. The UNKNOWN source system allows the same source ID to point to multiple records for all party level tables that are enabled for Source System Management.
Related Topics
Oracle Trading Community Architecture (TCA) provides business events to signal the creation or update of information in the TCA Registry. You can attach your own callout subscriptions to the events to perform additional business logic without modifying TCA.
This infrastructure is based on the Oracle Workflow Business Event System. Several Oracle E-Business Suite products provide additional functionality using the same callout infrastructure.
Oracle Trading Community Architecture provides two types of business events.
Granular Events: These events are raised at physical table or entity level, which is the lowest, most granular level. All TCA granular (V2, or Version 2) API calls raise one such event.
For example, when an organization record is created, the oracle.apps.ar.hz.Organization.create event is raised. Later, if that organization name is modified, a relationship for the organization is created, and two contact points are added, then four separate events are raised:
One oracle.apps.ar.hz.Organization.update event
One oracle.apps.ar.hz.Relationship.create event
Two oracle.apps.ar.hz.ContactPoint.create events
See: Trading Community Architecture Business Object Events, Oracle Trading Community Architecture Technical Implementation Guide.
Business Object Events: These events are raised at the business object level. A business object is a hierarchical collection of physical entities pertaining to a logical business-oriented object. For example, an Organization business object includes the organization's profile information, addresses, contacts, contact points, relationships, and so on.
Business object events include:
Persons Created - oracle.apps.ar.hz.personBO.create
Persons Updated - oracle.apps.ar.hz.personBO.update
Person Customers Created - oracle.apps.ar.hz.CustBO.create
Person Customers Updated - oracle.apps.ar.hz.CustBO.update
Organizations Created - oracle.apps.ar.hz.orgBO.create
Organizations Updated - oracle.apps.ar.hz.orgBO.update
Organizations Customers Created - oracle.apps.ar.hz.orgCustBO.create
Organizations Customers Updated - oracle.apps.ar.hz.orgCustBO.update
Creating any entity within a business object is considered as one update to the business object. Like the example for granular events, when the organization is first created, the oracle.apps.ar.hz.orgBO.create event is raised. However, for the update and additional creation of relationship and contact points, only one business object event is raised: oracle.apps.ar.hz.orgBO.update.
See: Trading Community Architecture Business Object Events, Oracle Trading Community Architecture Technical Implementation Guide.
Business event setup involves:
Setting profile options for the business objects events infrastructure. When setting the profile options, consider the requirements of your installation and the ways in which other Oracle E-Business Suite applications use TCA events.
Profile option for granular events and business object events:
HZ: Raise API Events. See: Defining the Business Event Types to Raise.
Profile options for business object events only:
HZ: Format Business Object Business Events as Bulk. See: Defining How Business Events Are Raised.
HZ: Number of Days to Preserve Business Object Business Event Information. See: Preserving Event Information.
Executing specific Oracle E-Business Suite functions that use TCA granular (V2) business events, even when those events are disabled. See: Schedule Event Raising and Impact and Alternatives of Not Raising Granular Business Events.
Subscribing to business object events. This is done for both granular events and business object events. See: Event Subscription.
For business object events, schedule concurrent programs. See: Events Raising.
Related Topics
Use the HZ: Raise API Events profile option to enable or disable either of the TCA business event types. See: Business Event Types and Profile Options and Profile Option Categories.
Note: You must set this profile option before working with data in order to determine how to capture business events.
Available settings for the profile option are:
All Events Disabled: Neither granular nor business object events are raised.
Only Granular (V2) Events Enabled: Only granular events are raised. Business object events are disabled.
Only Business Object Events Enabled: Only business object events are raised. Granular events are disabled.
All Events Enabled: Both granular and business object events are raised.
Important: Set the HZ: Raise API Events profile option appropriately based on your installation's requirements and the presence of any custom solutions using TCA business events. Enable either or both of the business event types only if you are using the corresponding TCA business events. If not, set the profile option to All Events Disabled, to avoid unnecessary overhead to your system.
Your setting of the HZ: Raise API Events profile option also depends on:
Oracle E-Business Suite applications that use TCA Business Events. See: How Oracle E-Business Suite Applications Use TCA Business Events.
High volume loads of data into the TCA Registry, for which all events should be disabled. See: Specific Situations to Disable Business Events For.
Business events will not be raised even if you set the HZ: Raise API Events profile option to enable events, when either of the following conditions exists:
Business events are disabled.
Business events are enabled but there is no activity.
No enabled subscriptions exist for business events.
Several Oracle E-Business Suite applications leverage the TCA business events infrastructure to provide additional functionality in respective product areas. For these features to properly function, set the HZ: Raise API Events profile option to Only Granular (V2) Events Enabled or All Events Enabled. See: Defining the Business Event Types to Raise.
Oracle E-Business Suite applications do not use business object events. You might need to enable business object events, however, if you have custom integrations with other systems using business object events, a likely scenario in a data hub implementation.
This table lists Oracle E-Business Suite applications and the respective features that leverage TCA granular business events. Refer to product-specific documentation for details on the features and related setup steps.
In some situations, all TCA business events must be disabled, including granular events. See: Specific Situations to Disable Business Events For. You can take alternative actions so that specific Oracle E-Business Suite functions that leverage TCA business events are still performed. See: Impact and Alternatives of Not Raising Granular Business Events.
You should disable all Oracle Trading Community Architecture business events whenever a high volume of records is loaded into the TCA Registry. Set the HZ: Raise API Events profile option to All Events Disabled so that no events are raised. See: Defining the Business Event Types to Raise.
Disable business events for these situations:
Custom code using TCA APIs to load high volume data: Set the profile option to disable all events before you run your custom program to load data. Alternatively, you can code the profile option setting into your custom program, so that events are disabled every time you load data.
Oracle E-Business Suite products loading high volume data: Several E-Business Suite applications load high volume data into TCA. These programs automatically set the profile option to All Events Disabled. After the programs complete, they set the profile option value back to what it was before the run.
This table shows the programs and the corresponding E-Business Suite application.
This table shows programs that can load high volume data into TCA, but do not automatically set the profile option to All Events Disabled.
Important: If you are loading high volume data using these programs, you are strongly recommended to disable the events before running the programs.
Oracle E-Business Suite Application | Program |
---|---|
Oracle Human Resources | Data Pump |
Oracle Transportation | Upload Supplier Ship-from Location |
Related Topics
Granular business events are raised only by V2 API calls.
Business object events can be raised by:
V2 and business object API calls.
TCA Business Objects Events: Raise Events Program
Set the HZ: Format Business Object Business Events as Bulk profile option to Yes to format business object events as bulk events. This profile option does not apply to granular events. TCA tracks and collects business events as they occur but raises them as a group the next time you run the Raise Events concurrent program. This program determines which business objects were created or updated for the time period and raises each of the eight business object events at most only once. For example, the Raise Events program raises a single Organizations Created business event for all Organization business objects created since the last time the programs ran. This is true for all eight business events.
If you set this profile option to No, then each business object API call raises one equivalent business event per business object.
Set this profile option only if you use business object events. It has no default setting.
Use the HZ: Number of Days to Preserve Business Object Business Event Information profile option to determine how long business object business event details will be preserved in the system before being discarded. This determines how long you can call the event-specific object extraction procedure after the business event has been scheduled. If you call the event-specific object extraction procedures after this number of days, then you will trigger an error.
The default for this profile option is 10 days.
To raise business object events, run the following programs:
The TCA Business Objects Events: Generate Infrastructure Packages Program dynamically generates the appropriate underlying infrastructure packages to determine and raise business object events. You must run this program at least once before scheduling the TCA Business Object Events: Raise Events Program.
The TCA Business Object Events: Raise Events Program raises bulk business object events for all events that have been tracked and collected since the last time the program was run. Scheduling this program determines how frequently to raise business object events. You must schedule and run this program periodically even if you raise business object events using business object APIs as they occur. This is particularly important if you use V2 public APIs.
Note: Run this concurrent program only if you use business object events.
TCA Business Object Events: Cleanse Infrastructure Program cleans up the underlying infrastructure of the Business Object Events system. When TCA events are fired, a transactional table stores the data corresponding to that event so that a user subscription can access the data when the event is raised. This program deletes all events that no longer need to be tracked by the system based on the setting in the HZ: Number of Days to Preserve Business Object Events Information profile option.
Subscribe to business events to perform an action or custom logic when an event is raised.
Log on to Oracle Applications using the Workflow Administrator Web Application responsibility.
Navigate to Business Events and search for a business event.
Click Create Subscription.
Enter the action and other parameters as needed.
For more information on subscribing to events, see: Oracle Workflow User's Guide.
Oracle Trading Community Architecture (TCA) granular (V2) business events are not raised when the HZ: Raise API Events profile option is set to All Events Disabled or Only Business Object Events Enabled, either from a manual setting or by programs that load high volume data into TCA. See: Specific Situations to Disable Business Events For.
If TCA granular business events are not raised, then specific Oracle E-Business Suite functions that leverage TCA events are not performed for that data set. See: How Oracle E-Business Suite Applications Use TCA Business Events. To perform specific E-Business Suite functions even when granular events are disabled, run synchronization programs from the corresponding application.
This table shows the applications and the respective features that leverage TCA events, as well as the programs to run if business events are disabled. Refer to product-specific documentation for details on these programs.
Related Topics
As Oracle Trading Community Architecture (TCA) is a source of Oracle Workflow user and role information, the information stored in the TCA tables must be synchronized with the denormalized information in the Workflow local tables. TCA stores information regarding people in the Workflow Directory Services (WFDS) from the TCA data model. The data is kept in synchronization with the actual TCA tables using the Business Event system and internal functionality. The Workflow local synchronization APIs are used to perform this synchronization.
There are two methods of synchronization.
For more information, see: Setting Up an Oracle Workflow Directory Service, Oracle Workflow Administrator's Guide.
Workflow Directory role attributes are mapped with Oracle Trading Community Architecture (TCA) attributes in the Workflow Directory Services synchronization.
Workflow Table: HZ_PARTY_WF_ROLES_V
Related TCA Entity Tables:
HZ_PARTIES
HZ_CONTACT_POINTS
HZ_PERSON_LANGUAGE
This table displays the columns in the related TCA Bulk Synchronization view (HZ_PARTY_WF_ROLES_V).
Column | Person Party |
---|---|
Name | Person Party ID (HZ_PARTY) |
Display Name | Person Party Name |
Description | Person Party Name |
E-mail Address | Person Party Primary E-mail Address |
Notification Preference | From Person Party Primary E-mail Contact Point If there is no e-mail format mentioned for the primary e-mail address or if there is no e-mail address, the notification preference is set to Query. |
Language | Person Party Primary Language |
Territory | From Primary Language |
Fax | Null |
Original System Ref | HZ_PARTY |
Original System Ref ID | Person Party ID |
Status | Person Party Status |
Start Date | NULL |
Expiration Date | NULL |
User Flag | Y |
Note: The Person Party Primary E-mail Address entity is denormalized onto the HZ_PARTIES from HZ_CONTACT_POINTS tables.
For Person Party Status, A is treated as ACTIVE, while any other letter is considered as INACTIVE.
Note: As the role mappings is done for person parties, a user record is simply a role record with user_flag set to Y.
Contacts are Person parties that represent other Person or Organization parties.
Workflow Table: HZ_PARTY_WF_ROLES_V
Related TCA Entity Tables:
HZ_PARTIES
HZ_CONTACT_POINTS
HZ_PERSON_LANGUAGE
This table displays the columns in the related TCA Bulk Synchronization view (HZ_PARTY_WF_ROLES_V).
Column | Contact |
---|---|
Name | Relationship Party ID (HZ_PARTY) |
Display Name | Person Party Name (Subject) |
Description | Relationship Party Name |
E-mail Address | Relationship Party Primary E-mail Address |
Notification Preference | From Relationship Party Primary E-mail Contact Point If there is no e-mail format mentioned for the primary e-mail address or if there is no e-mail address, the notification preference is set to Query. |
Language | Subject Party Primary Language |
Territory | From Primary Language of Subject Party |
Fax | NULL |
Original System Ref | HZ_PARTY |
Original System Ref ID | Relationship Party ID |
Status | Relationship Party Status |
Start Date | Relationship Start Date |
Expiration Date | Relationship End Date |
User Flag | Y |
Note: The Relationship Party Primary E-mail Address entity is denormalized onto the HZ_PARTIES from HZ_CONTACT_POINTS tables.
For Relationship Party Status, A is treated as ACTIVE, while any other letter is considered as INACTIVE.
Note: As the role mappings is done for contacts, a user record is simply a role record with user_flag set to Y.
Workflow Table: HZ_GROUP_WF_ROLES_V
Related TCA Entity Tables:
HZ_PARTIES
HZ_CONTACT_POINTS
HZ_PERSON_LANGUAGE
This table displays the columns in the related TCA Bulk Synchronization view (HZ_GROUP_WF_ROLES_V).
Column | Group Party |
---|---|
Name | Group Party ID (HZ_GROUP) |
Display Name | Group Party Name |
Description | Group Party Mission Statement |
E-mail Address | Group Party Primary E-mail Address |
Notification Preference | From Group Party Primary E-mail Contact Point If there is no e-mail format mentioned for the primary e-mail address or if there is no e-mail address, the notification preference is set to Query. |
Language | Group Party Primary Language |
Territory | From Primary Language |
Fax | NULL |
Original System Ref | HZ_PARTY |
Original System Ref ID | Group Party ID |
Status | Group Party Status |
Start Date | NULL |
Expiration Date | NULL |
User Flag | N |
Note: The Group Party Primary E-mail Address entity is denormalized onto the HZ_PARTIES from HZ_CONTACT_POINTS tables.
For Group Party Status, A is treated as ACTIVE, while any other letter is considered as INACTIVE.
The Workflow (WF) User Roles represent the mappings between Workflow Users and Workflow Roles.
For example, the various persons forming a Group party represent the User Roles for that Group party. Each user in the role receives a separate copy of the notification when Expand Roles is checked on a Workflow Notification.
Note: Workflow Users participate in their own roles. The WF_USER_ROLES table has a record for TCA Person Parties, since they are created with the User Flag set to Y.
Related TCA Entity Tables:
HZ_PARTIES
HZ_RELATIONSHIPS
This table displays the columns in the related TCA Bulk Synchronization view (HZ_GROUP_WF_USER_ROLES_V).
Column | Person Party |
---|---|
User Name | Person Party ID (HZ_PARTY) |
User Orig System | HZ_PARTY |
User Orig System ID | Person Party ID |
Role Name | Relationship Party ID (HZ_GROUP) |
Role Orig System | HZ_GROUP |
Role Orig System ID | Group's Party ID |
Start Date | NULL |
Expiration Date | NULL |
Note: The subject party is a Person and the object party is a Group.
Related TCA Entity Tables: HZ_PARTIES
This table displays the columns in the related TCA Bulk Synchronization view (HZ_PARTY_WF_USER_ROLES_V).
Column | Person Party |
---|---|
User Name | Party ID (HZ_PARTY) |
User Orig System | HZ_PARTY |
User Orig System ID | Party ID |
Role Name | Party ID (HZ_PARTY) |
Role Orig System | HZ_PARTY |
Role Orig System ID | Party ID |
Start Date | Relationship Start Date |
Expiration Date | Relationship End Date |
Oracle Workflow (WF) automatically performs an initial synchronization of the user and role information in all the related originating systems during installation. Subsequently, you must continue synchronizing the user and role information from the source modules with the Workflow local tables.
For Oracle Trading Community Architecture (TCA), a patch automatically synchronizes that information with the information in the Workflow local tables on an incremental basis, using the Workflow local synchronization APIs. For more information on APIs, see: Directory Service APIs, Oracle Workflow API Reference.
Oracle Workflow references user and role information through three views based on the database tables that make up the Workflow Directory repository.
WF_USERS
WF_ROLES
WF_USER_ROLES
These views are based on local tables that are initially loaded by the WF directory's Synchronize WF LOCAL Tables concurrent program. WF_USERS is a view on top of WF_ROLES, which only returns roles that have the User flag set to Y. Users participate in their own roles, so an entry is created as a User Role for each user.
For more information, see: Synchronizing Workflow User and Role Information, in Setting Up an Oracle Workflow Directory Service, Oracle Workflow Administrator's Guide.
Run the Synchronize WF LOCAL Tables program to perform synchronization in bulk. This periodically refreshes the information in the Workflow local tables for Oracle Trading Community Architecture (TCA). Use this concurrent program as an interim method to synchronize the Workflow local tables with the user and role information stored in the TCA tables until TCA performs the synchronization automatically.
The Synchronize Workflow LOCAL Tables request set contains ten instances of the Synchronize WF Local Tables program, one for each originating system. You can use this request set to submit requests for all the originating systems at once.
Note: Each request is defined as a separate stage and the stages will run sequentially because this program is incompatible with itself.
By default, this request set runs once a day to provide a minimal level of synchronization. You can modify the schedule for the request set to perform synchronization more frequently.
For more information, see: Synchronizing Workflow User and Role Information, in Setting Up an Oracle Workflow Directory Service, Oracle Workflow Administrator's Guide.
This diagram illustrates how the Workflow Directory Services interact with both their populating views as well as the data that is synchronized with TCA.
The Workflow views are views on two Workflow tables: WF_LOCAL_ROLES and WF_LOCAL_USER_ROLES. For TCA views, both bulk and incremental synchronizations write to these Workflow tables.
For bulk synchronization, TCA provides four views that populate data to the Workflow tables. The Workflow Directory views then capture the information present in the Workflow local tables.
This diagram illustrates how the four TCA bulk synchronization views are mapped to the Workflow tables.
You can access the Administration tab as a whole, with all available functions, from the Trading Community Manager responsibility and from other Oracle applications. For example, you get the tab in Oracle Customers Online if you have the Oracle Customers Online Superuser responsibility, and in Oracle Customer Data Librarian with the Oracle Customer Data Librarian Superuser responsibility.
To restrict and manage access to the Administration tab, you can assign specific Administration functions to other responsibilities. For example, you can create a Relationships Administrator responsibility with access to administer only relationships.
Responsibility: System Administrator
See: Oracle E-Business Suite Security Guide
Related Topics
Introduction to Administration
For features in the Trading Community Manager responsibility, you can set up:
You can also perform any of the administration steps as part of implementation, for example setting up Data Quality Management. See: Introduction to Administration. For general implementation steps, see: General Implementation.
TCA batch address validation, which validates existing addresses in bulk, uses a central XML open-standards based "black box" that allows integration with third party service providers and custom solutions, through adapters that you or the third party provides.
Callers such as the Address Validation program or the TCA Bulk Import process invoke the black box, which sends and receives the address data to and from the address validation adapters. The adapters validate TCA addresses against the standard addresses in the adapter's associated databases.
If you are using third party address validation services, install and configure their software and adapters according to their instructions.
You can optionally develop your own address validation adapters. See: Creating Address Validation Adapters.
Administer third party or custom adapters by defining address validation adapter configurations. See: Administering Adapters and Configuring Adapters.
Set these profile options:
Related Topics
Batch Address Validation, Oracle Trading Community Architecture User Guide
Feature-Specific Implementation
Batch duplicate identification involves creating batches of potential duplicate parties in the TCA Registry, using Data Quality Management tools. Based on a specified match rule, the process determines duplicate candidates, which can be designated for merge.
Set up Data Quality Management.
Optionally create match rules with the Expanded Duplicate Identification or Bulk Duplicate Identification purpose. You can allow Automerge for the match rule and enter an automatic merge threshold. Any party with a score that exceeds the automatic merge threshold is defaulted in the Duplicate Identification: Batch Review window to be merged. The Automerge program itself does not run.
Optionally set the DQM Match Rule for Batch Duplicate Identification profile option if you want to default a match rule in the Submit Duplicate Identification Batch window. See: Profile Options and Profile Option Categories.
Optionally use the DUP_BATCH_RESTRICTION_LIST Receivables lookup to define the list of attributes that appear in the Submit Duplicate Identification Batch window. You can add any attribute from the HZ_PARTIES table to the list. These attributes are used as restriction criteria for creating duplicate identification batches.
See: Defining Receivables Lookups, Oracle Receivables Implementation Guide.
Related Topics
Batch Duplicate Identification Overview, Oracle Trading Community Architecture User Guide
Feature-Specific Implementation
Data Quality Management Overview
TCA Bulk Import allows for importing batches of data from external sources into the TCA Registry.
Define and map legacy and other source systems to entities in the TCA Registry. Perform this step for all source systems you plan to import from. See: Administering Source Systems.
You can provide the option of resolving duplicates for import:
Batch de-duplication: Resolving duplicates within the interface tables.
Registry de-duplication: Resolving duplicates between the interface tables and the TCA Registry.
Import de-duplication involves Data Quality Management (DQM) bulk duplicate identification. See: Bulk Import De-Duplication Processes.
Administer Data Quality Management.
You must define and designate attributes and transformations for bulk duplicate identification acquisition.
Optionally create match rules for import de-duplication, which must have the Bulk Duplicate Identification purpose.
For match rules you create for Registry de-duplication, allow for Automerge if you want to automatically merge parties with the highest probability of being duplicates.
When you create the match rules, take note of the match and automatic merge thresholds. If a record:
Does not exceed the match threshold, then it is not a duplicate. In Registry de-duplication, the record is inserted as a new party into the TCA Registry.
Reaches or exceeds the match threshold but not the automatic merge threshold, then it is a potential duplicate.
In batch de-duplication, based on the action that the user specifies for duplicates, the record is dealt with in the interface tables, before import.
In Registry de-duplication, the record is inserted as a new party, but is also included in a System Duplicate Identification batch in Oracle Customer Data Librarian for further evaluation. See: System Duplicate Identification, Oracle Customer Data Librarian User Guide.
Reaches or exceeds the automatic merge threshold, then it is inserted as a new party and then automatically merged with its duplicates. This threshold applies only to Registry de-duplication, and only if the match rule is allowed for Automerge.
For providing the option of validating addresses before importing them into the TCA Registry, use or create adapters that can provide address validation services, and define the adapter configurations. See: Configuring Adapters.
For providing the option of applying Data Sharing and Security to the import process:
Set the HZ: Use Data Sharing and Security During Import profile option.
Set these profile options:
See: Profile Options and Profile Option Categories Overview.
Related Topics
Bulk Import Overview, Oracle Trading Community Architecture User Guide
Feature-Specific Implementation
Data Quality Management Overview
The batch and Registry de-duplication are separate processes that run at different times, either with the same or different match rules. For illustration purposes, this diagram describes both de-duplication processes:
TCA Registry attributes are transformed for the staged schema. The attributes to include in the schema, as well as the transformations to use on each attribute, are defined in the Define Attributes and Transformations page.
Also defined are the attribute and transformation combinations to be used for bulk duplicate identification. The staged schema includes B-Tree indexes only for the transformed attributes marked for bulk duplicate identification.
The user specifies a match rule with Bulk Duplicate Identification purpose for the de-duplication.
When the de-duplication process starts, the acquisition and scoring transformations are applied to the attributes in the interface tables, based on the selected match rule.
The transformed interface table records are mapped and loaded into the interface search tables, a set of temporary staged tables with B-Tree indexes.
To find duplicates within the TCA interface tables:
The interface search tables are joined with themselves.
The acquisition match criteria of the same match rule is applied to compare each record against all other records in the same staged table simultaneously.
For example, an acquisition criterion is the D-U-N-S Number attribute with the Exact transformation. All D-U-N-S Numbers, as transformed by the Exact transformation, would be compared against one another.
To find duplicates between the TCA interface tables and the TCA Registry:
The interface search tables are joined with the staged schema. The two sets of staged tables have the same columns. This table shows the mapping between the interface search and staged schema tables:
The acquisition match criteria of the same match rule is applied to compare all records in each interface search table against all records in the staged schema using only B-Tree indexes.
Matched acquisition attribute values determine the most relevant subset of records from the interface search tables to form the work unit.
Using the scoring criteria in the match rule, each record in the work unit is compared to all other work unit records in the same staging table.
A score is calculated for each record in the work unit, and scores for all entities are added together for determining duplicate parties.
The score of each work unit record is compared against the match and automatic merge thresholds defined in the match rule.
Records with scores above the match threshold are selected as potential duplicates and resolved accordingly.
For Registry de-duplication, records with scores that also exceed the automatic merge threshold are automatically merged after import, if the match rule is allowed for Automerge.
Related Topics
Customer Interface lets you import and validate current or historical party and customer account information from other systems into your database.
Although Customer Interface imports both party and customer account information, it does so in a row-by-row manner and is slower than Bulk Import. However, you cannot use Bulk Import to import accounts; it can be used only to import parties. Therefore, for optimal performance, you should import parties using Bulk Import and use Customer Interface to import the associated accounts.
Note: Customer Interface runs independently and does not regard party level information already loaded into your database using Bulk Import. If you plan to use Customer Interface to import accounts that are associated with parties that have already been imported using Bulk Import, you must ensure that the source ID alone is unique across all source systems in the bulk import process. While Bulk Import requires source IDs to be unique only within an identified source system, customer interface does not recognize the source system and therefore requires that the source ID is unique across all sources systems. See:
Bulk Import Overview, Oracle Trading Community Architecture User Guide.
Loading Data into the Interface Tables, Oracle Trading Community Architecture User Guide.
Unique Source IDs for Importing Associated Accounts, Oracle Trading Community Architecture User Guide.
Review the validation rules for each column of the Customer Interface tables. See: Customer Interface Validation Rules, Oracle Trading Community Architecture User Guide.
Perform all required set up steps preceding customer entry to ensure that values exist in your system for the columns of the Customer Interface tables that require predefined values. See: Customer Interface, Oracle Trading Community Architecture Reference Guide.
Write an import program to transfer customer information from an external system.
Validate customer addresses (if you are using US Sales Tax). See: Preparing for Import, Oracle Trading Community Architecture User Guide.
Set these profile options:
HZ: Gather Table Stats
HZ: Import Tax Details Using Customer Interface
HZ: Number of Workers Used by Customer Interface
HZ: Character Value to Indicate NULL During Import
HZ: Date Value (DD-MM-YYYY) to Indicate NULL During Import
HZ: Numeric Value to Indicate NULL During Import
See: .
Related Topics
Feature-Specific Implementation
Merge customer (either individual or organization) accounts that are confirmed as duplicates in the Duplicate Customer Report.
Merge customer (either individual or organization) accounts or customer accounts sites for the same or different customers to transfer site use activity from a customer or site that is no longer active.
Merge an individual customer account with organization customer account, and vice versa.
Generate the Duplicate Customer Report to see a list of all duplicate customers before you initiate the customer merge program. This report tries to match duplicate customer names based on the search criteria that you specify. See: Duplicate Customer Report, Oracle Receivables User Guide.
Complete Auto Invoice processing. This minimizes the number of rows to be merged in the interface tables. The merge process can then run more efficiently.
Generate the Customer Listing report to see detailed information about the customer and site uses. See: Customer Listing Detail and Summary Reports, Oracle Receivables User Guide.
Create a map that shows the site uses you want to merge and the sites you want to maintain. Check that you are merging like site uses (for example, Bill-To's merged with Bill-To's).
Determine whether to inactivate or delete old site use information.
Set these profile options:
AR: Customer Merge Commit Size
HZ: Audit Customer Account Merge
HZ: Location Updatable
HZ: Log Customer Merge
Related Topics
Merging Customers, Oracle Trading Community Architecture User Guide
Feature-Specific Implementation
eLocations Spatial Data Integration allows for retrieving spatial information from Oracle eLocations and storing the longitude and latitude data for addresses in the TCA Registry.
Set up SSL security for the TCA eLocation geocoding service. See Using eLocation Services on Oracle Cloud Infrastructure (OCI) for Oracle Trading Community Architecture (TCA).
Set profile options.
Submit the Locations Spatial Index Rebuild program to create and periodically rebuild the spatial index on the HZ_LOCATIONS table. See: Locations Spatial Index Rebuild.
Related Topics
eLocations Spatial Data Integration, Oracle Trading Community Architecture User Guide
Feature-Specific Implementation
Use the Locations Spatial Index Rebuild program to rebuild the spatial index on the HZ_LOCATIONS table. You should periodically rebuild the spatial index to optimize performance and accuracy for queries on the spatial data in this table.
You can schedule this program to run on a periodic basis. If possible, rebuild the index when users are not querying spatial data because the Locations Spatial Index Rebuild program interferes with user spatial operations.
Note: You cannot run the Locations Spatial Index Rebuild program if the Spatial Information for Locations Batch Update program is running.
If the HZ: Detailed Concurrent Program Output profile option is set to Yes, then you can view a detailed report about the records that the Locations Spatial Index Rebuild program processed.
Related Topics
Setting Up eLocations Spatial Data Integration
Party Merge involves merging parties that are confirmed as duplicates, either from a duplicate identification batch or a manually created merge batch.
Define the Merge Dictionary to determine the entities and procedures that must be processed to merge party entities. You can set up the Merge Dictionary for all Oracle Applications that you use to interact with parties. See: Maintaining the Merge Dictionary.
You can optionally set up any merge procedure registered with the Merge Dictionary to prevent the deletion of records, if your company's business rules require that parties cannot be deleted. To prevent deletion, a merge procedure must call the HZ_PARTY_MERGE. veto_delete procedure. At the end of the merge process, if none of the merge procedures has vetoed the deletion of the merge-from parties, then those party records are deleted.
If you are using Party Merge along with Oracle Credit Management and experiencing bad performance for Party Merge, then create nonunique indexes on the PHONE_ID column of both the AR_CUSTOMER_CALLS_ALL and AR_CUSTOMER_CALL_TOPICS_ALL tables.
Related Topics
Party Merge Overview, Oracle Trading Community Architecture User Guide
Party Merge Deployment Category, Oracle Trading Community Architecture Administration Guide
Feature-Specific Implementation
Real-time address validation validates addresses during address entry. See: Real-Time Address Validation, Oracle Trading Community Architecture User Guide.
You can validate addresses in real time using two distinct repositories:
TCA Geography Hierarchy setup
Third party address validation adapter database
Note: The TCA Geography Hierarchy setup does not validate Address Line 1, Address Line 2, Address Line 3 and Address Line 4.
If validation is performed using both the above repositories, the TCA Geography Hierarchy setup takes precedence for the common attributes set up in the two repositories. For example, if the City attribute is set up in the TCA Geography Hierarchy setup and the Third Party Address Validation Adapter database, then the City in the TCA Geography Hierarchy setup takes precedence.
To get more information, see: Administering Geography Hierarchy.
Real time address validation performed using a third party adapter in the Address CPUI component is based on the settings in the HZ: Enable Real Time Address Validation profile. If the value is set to Yes, you can verify the address during entry. For more information on profile options , see Address Validation Deployment Category. For more information on setting up Adapters, see Adapters.
Real-time address validation can work alongside Flexible Address Formatting (FAF), if both are set up. If you do not need to use validation for a country, then you can set up and use only Flexible Address Formatting. See: Flexible Addresses, Oracle Receivables Implementation Guide. Likewise, you can set up real-time address validation without setting up and using FAF.
Note: Before setting up real-time address validation, verify that valid location data exists from your data sources such as Receivables, a content provider, or manual data entry.
When setting up Flexible Address Formatting and real-time address validation, make sure they are consistent with your Geography Hierarchy setup.
Geography types in your defined country structure must match the address elements in the Flexible Address Formatting address style assigned to that country. For example, if the US country structure has City, State, and Country, then the address style assigned to United States should also have those address elements. See: Defining Country Structures.
Geographies that you define for this country must match any value sets defined for address elements in the address style, if the geography type is mapped to the address element for that style. For example, for the US address style, the State address element is mapped to the State geography type. If this address style has a defined list of states for the State address element, then do not define a different set of states for the State geography type. See: Viewing and Defining Geographies and Managing Validations.
(Recommended but optional) Address elements defined as mandatory in the address style should be mapped for geography validation. For example, if State is defined as a mandatory element in the US address style, then map the State geography type to the HZ_LOCATIONS source table and select the Geography Validation usage. See: Managing Validations.
See: Address Formatting, Oracle Trading Community Architecture User Guide.
Note: Perform these steps for each country that you need to validate addresses for.
Set up the country structure in Geography Hierarchy. This structure determines the available geography types, which corresponds to address elements, for address validation. See: Defining Country Structures.
Define geographies for each geography type in the country structure. Address values are validated against the defined geographies. See: Defining Geographies and Updating Geographies.
Note: If an address has values that you defined as alternate geography names or codes, those values are still valid, but the primary name or code is saved and subsequently displayed to the user.
Select HZ_LOCATIONS as the table to map the country structure against. This initial setup is not for a specific address style, so you see No Style.
Map each geography type in the country structure to the appropriate HZ_LOCATIONS column and select the Geography Validation usage. This mapping and usage assignment determine the address elements that must be entered and valid for the address to be considered valid. See: Managing Validations.
Specify the address, or geography, validation level for the country. See: Managing Validations.
After you set up validations for No Style, and if you have a Flexible Address Formatting address style assigned to this country, then optionally repeat steps 4 and 5 with the FAF address style selected.
Important: If changes are later made to the Flexible Address Formatting address style assigned to this country, then you should make equivalent changes to your mapping and usage assignments for that address style, if defined.
See: Managing Validations.
Set up profile options.
HZ: Address Validation Level for Application - to set different address validation levels by applications, if needed.
HZ: Batch Size for committing records in Geography Name Referencing process.
HZ: Maintain Location History.
HZ: Number of workers for a given Geography Name Referencing request.
HZ: Reference Territory - to set the default territory (country) used to determine the locale for name and address formatting.
HZ: Default Flexible Address Format - to set the default style for address entry when no flexible address format is defined for a country.
HZ: Default Address Style - to set the default format for address display.
Run the Geography Name Referencing process to map addresses in location tables to master reference geographies. See: Geography Name Referencing Process.
Related Topics
Relationship Manager allows users to manage relationships among existing parties in the TCA Registry. Relationship Manager uses the relationship types that you administer. See: Administering Relationships.
You can also set up Data Quality Management (DQM) for the party search in Relationship Manager. DQM provides powerful search functionality, based on a match rule that determines which search criteria are available and how to select and rank the results. You can use a seeded search match rule or create new rules. Relationship Manager's party search uses the rule that is assigned to the HZ: Match Rule for Relationship Manager Search profile option.
If you do not set up DQM, Relationship Manager provides a basic set of search criteria and uses standard search functionality.
Administer Data Quality Management.
Optionally create one or more match rules with the Search purpose.
Assign the match rule that you want to use for the party search to the HZ: Match Rule for Relationship Manager Search profile option. See: Profile Options and Profile Categories.
Related Topics
Searching for Parties and Viewing Results, Oracle Trading Community Architecture User Guide
Data Quality Management Overview
Feature-Specific Implementation
Third Party Data Integration allows for acquiring information from D&B for the TCA Registry. To enable purchase of D&B data, you must integrate with D&B. Without third party data, there is no need to use or administer Third Party Data Integration.
After you set up Third Party Data Integration with D&B, you can optionally administer Source System Management to control how the D&B and user-entered data are used and displayed. See Administering Source System Management.
Important: This Oracle software product includes D&B Data Integration Toolkit software from Dun & Bradstreet, Inc. (D&B). However, you do NOT receive a license to use the D&B software under your agreement with Oracle. The D&B software must be separately licensed from D&B.
To purchase a license to the D&B Data Integration Toolkit software and/or D&B information about businesses, you must have a separate contract with D&B for the Toolkit and/or its Data Rationalization Service, as applicable. Contact your D&B relationship manager to contract for the software or services that meet your data requirements. If you do not have a relationship manager assigned to your company, contact D&B's Global Service Center at (888) 243-4566, e-mail dnb4oracle@dnb.com, or visit http://www.dnb.com. You can also contact D&B for information to interpret credit ratings and other information that D&B provides.
Establish a contract with D&B for its Data Rationalization Service. Contact your D&B relationship manager to contract for the services that meet your data requirements.
D&B provides information that you need to access the D&B database from Third Party Data Integration:
D&B HTTPS URL, which is https://toolkit.dnb.com
D&B user name
D&B password
Tip: You can request multiple user names and passwords if you want to assign different ones to your users, for example, to track D&B transactions by user.
Important: The DNB online purchasing toolkit is not compatible with IBM platform.
Enter the provided D&B URL, user names, and passwords in the configuration for the seeded Dun & Bradstreet adapter. See: Configuring Adapters.
Set the HZ: D&B User Name profile option with the user names that D&B provided, same as what you enter for the adapter.
Contact your information technology department or organization for information about your web server.
Servlet agent URL
If you use a proxy server:
Web server proxy host name
Web server proxy port
Use the information from your information technology organization to set up the profile options listed in this table.
Note: Set the Applications Proxy Port and Applications Server-Side Proxy Host And Domain profile options only if you use a proxy server.
Profile Option | Value |
---|---|
Apps Servlet Agent | Servlet agent URL |
Applications Server-Side Proxy Host And Domain | Web server proxy host name |
Applications Proxy Port | Web server proxy port |
For batch loading D&B data into the Registry:
Set up Bulk Import. See: Setting Up Bulk Import.
Specify a directory object to use that exists in the same environment as your TCA database. Which object you use depends on whether you have migrated to the EBS_SYSTEM schema. If you applied one of the following patches, then you use the EBS_SYSTEM schema:
The Oracle E-Business Suite 12.2.11 Release Update Pack or higher. Refer to My Oracle Support (https://support.oracle.com), Document ID 2758997.1, Oracle E-Business Suite Release 12.2.11 Readme.
The R12.CC_PF.C.Delta.11 Release Update Pack or higher. Refer to My Oracle Support (https://support.oracle.com), Document ID 2788545.1, Applying the R12.CC_PF.C.Delta.11 Release Update Pack.
Patch 31817501:12.2.0. Refer to My Oracle Support (https://support.oracle.com), Document ID 2774309.1, Applying the Oracle E-Business Suite Consolidated Patch for EBS System Schema Migration.
Specify a directory object before running the D&B Import Adapter request set using one of the following methods:
If you use the EBS_SYSTEM schema:
Using the standard directory object EBS_TEMP, copy the D&B flat file to the location identified by this object.
For more information about working with database directory objects after migrating to the EBS_SYSTEM schema, refer to My Oracle Support (https://support.oracle.com), Document 2755875.1, Oracle E-Business Suite Release 12.2 System Schema Migration.
If you do not use the EBS_SYSTEM schema:
Manually create a directory object on the same environment as your TCA database. A directory object is a database object that stores the absolute path of a physical directory on the database node. Name this object HZ_DNB_SOURCE_DIR, and make sure the database server can read and write from the location identified by the directory object.
For example, create the directory object in APPS as follows:
CREATE or replace DIRECTORY HZ_DNB_SOURCE_DIR AS '/emslog/dnb'
If the object is not in APPS, you must also grant access to APPS:
GRANT READ ON DIRECTORY HZ_DNB_SOURCE_DIR TO apps; GRANT WRITE ON DIRECTORY HZ_DNB_SOURCE_DIR TO apps;
Optionally create a request set with the D&B Import Adapter request set and the Import Batch to TCA Registry program. Users can run the new request set to batch load into interface tables and import into TCA Registry in one step.
This table shows the recommended settings for automating D&B batch load import after loading into interface tables.
Import Parameter | Default for D&B Batch Load |
---|---|
Run Batch De-Duplication | No |
Batch De-Duplication Match Rule | None |
Run Address Validation | No |
Run Registry De-Duplication | Yes |
Registry De-Duplication Match Rule | Custom match rule with heavy weights on Address attributes |
Related Topics
Third Party Data Integration Overview, Oracle Trading Community Architecture User Guide
Feature-Specific Implementation
In order to view a map of an address in a pop-up window from the Addresses page within Oracle Customers Online, you must set up Google Maps for use with Oracle Trading Community Architecture. Google requires that you obtain a license to use their maps. Use the links below to obtain a Google Maps JavaScript API Key and Client ID, which you will need later to set up maps for addresses.
After registering with Google, set up the following profile options:
Additional Information: If the Map column is not visible in the Oracle Customers Online Addresses page, then display the Map column using Oracle Application Framework (OAF) personalization.
Related Topics
Addresses, Oracle Customers Online User Guide