Implementation

This chapter describes how to implement Oracle Trading Community Architecture.

This chapter covers the following topics:

• General Implementation
• Feature-Specific Implementation

General Implementation

These general implementation steps apply to setting up TCA for using the Trading Community Manager responsibility:

• Assign responsibilities to users.

• Index customer account data.

• Run migration and upgrade requests as needed.

• Set up business events.

• Set up workflow directory synchronization.

• Optionally define access to the Administration tab.

• Set Trading Community Architecture profile options.

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.

Assigning Responsibilities to Users

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	Menu	Access	Menu Exclusion
Trading Community Manager	TCA Main Menu	Trading Community, Content Access and Integration, Data Quality Management, Setup, Control	None
TCA Data Security Administrator	HZ Security Main Menu	View, create, update, and delete privileges for Data Sharing and Security administration	None

Procedure

Responsibility: System Administrator

See: Users Window, Oracle Applications System Administrator's Guide - Security.

Related Topics

General Implementation

Customer Text Data Creation and Indexing

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.

Program Parameter

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

General Implementation

Running Migration and Upgrade Requests

Run the following program as needed as part of your implementation or upgrade.

Source System - Migrate Party Level Source System References

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:

• HZ_CONTACT_POINTS

• HZ_LOCATIONS

• HZ_ORG_CONTACT_ROLES

• HZ_ORG_CONTACTS

• HZ_PARTIES

• HZ_PARTY_SITES

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

General Implementation

Setting Up Business Events

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.

Business Event Types

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 Process

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

General Implementation

Defining the Business Event Types to Raise

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.

How Oracle E-Business Suite Applications Use TCA 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.

Oracle E-Business Suite Application	Feature That Uses TCA Granular Business Events
Oracle Advanced Collections	Territory assignment
Oracle Partner Management	Channel team assignment
Oracle Sales	Territory assignment
Oracle Shipping	Consolidation of TCA and HRMS locations for shipping activity
Oracle Student System	Workflow notification to administrator on change of address
Oracle Telecommunications Billing Integrator	Publication of information to third party billing systems
Oracle Trading Community Architecture	Workflow Directory synchronization

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.

Specific Situations to Disable Business Events For

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.

  Oracle E-Business Suite Application	Program
  Oracle iStore	Lead Import
  Oracle Marketing	Event Registration Lead Import List Import
  Oracle Order Management	Order Import
  Oracle Payables	Supplier Import
  Oracle Sales	Lead Import
  Oracle Site Management	Retail Site Creation
  Oracle Student System	Admission Import Bulk User Assignment Institution Import ISIR Import
  Oracle Trading Community Architecture	Customer Interface D&B Import Adapter Import Batch to TCA Registry

  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

Setting Up Business Events

Defining How Business Events Are Raised

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.

Preserving Event Information

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.

Event Raising

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.

Event Subscription

Subscribe to business events to perform an action or custom logic when an event is raised.

1. Log on to Oracle Applications using the Workflow Administrator Web Application responsibility.

2. Navigate to Business Events and search for a business event.

3. Click Create Subscription.

4. Enter the action and other parameters as needed.

For more information on subscribing to events, see: Oracle Workflow User's Guide.

Impact and Alternatives of Not Raising Granular Business Events

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.

Oracle E-Business Suite Application	Feature That Uses TCA Granular Business Events	Program
Oracle Advanced Collections	Territory assignment	IEX: Territory Assignment
Oracle Sales	Territory assignment	Assign Territory Access for Total Mode
Oracle Shipping	Consolidation of TCA and HRMS locations for shipping activity	Import Shipping Locations
Oracle Trading Community Architecture	Workflow Directory synchronization	Synchronize WF LOCAL tables

Related Topics

Setting Up Business Events

Setting Up Workflow Directory Synchronization

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.

• Incremental Workflow Directory Synchronization

• Bulk Workflow Directory Synchronization

For more information, see: Setting Up an Oracle Workflow Directory Service, Oracle Workflow Administrator's Guide.

Attribute Mapping for Workflow Roles

Workflow Directory role attributes are mapped with Oracle Trading Community Architecture (TCA) attributes in the Workflow Directory Services synchronization.

Role Mapping for Person 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	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.

Role Mapping for Contacts

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.

Role Mapping for Group Parties

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.

Attribute Mapping for Workflow User Roles

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.

User Role Mapping for Group Parties

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.

User Role Mapping for Person and Contact Parties

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

Incremental Workflow Directory Synchronization

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.

Bulk Workflow Directory Synchronization

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.

Trading Community Architecture Entity to Workflow Directory Mappings

This diagram illustrates how the Workflow Directory Services interact with both their populating views as well as the data that is synchronized with TCA.

Trading Community Architecture Views for Bulk Synchronization with Workflow

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.

Defining Administration Access

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.

Procedure

Responsibility: System Administrator

See: Implementing Function Security, Oracle Applications System Administrator's Guide - Security.

Related Topics

General Implementation

Introduction to Administration

Feature-Specific Implementation

For features in the Trading Community Manager responsibility, you can set up:

• Batch address validation

• Batch duplicate identification

• Bulk Import

• Customer Interface

• Customer Merge

• eLocations Spatial Data Integration

• Party Merge

• Real-time address validation

• Relationship Manager

• Third Party Data Integration

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.

Setting Up Batch Address Validation

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.

Procedure

1. 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.

2. Administer third party or custom adapters by defining address validation adapter configurations. See: Administering Adapters and Configuring Adapters.

3. Set these profile options:

   • HZ: Allow Update to Standardized Address

   • HZ: Create Log for Adapters

   • HZ: Default Location Service Adapter

   • HZ: Maintain Location History

   • HZ: Timeout Limit for Address Validation

   See: Profile Options and Profile Option Categories.

   • ECX: Log File Path

     See: Define System Profile Options, Oracle XML Gateway User's Guide.

Related Topics

Batch Address Validation, Oracle Trading Community Architecture User Guide

Adapters Overview

Feature-Specific Implementation

Setting Up Batch Duplicate Identification

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.

Procedure

1. 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.

2. 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.

3. 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

Setting Up Bulk Import

TCA Bulk Import allows for importing batches of data from external sources into the TCA Registry.

Procedure

• 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.

  1. Administer Data Quality Management.

     You must define and designate attributes and transformations for bulk duplicate identification acquisition.

  2. 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:

  1. Administer Data Sharing and Security.

  2. Set the HZ: Use Data Sharing and Security During Import profile option.

• Set these profile options:

  • HZ: Allow Import of Records with Disabled Lookups

  • HZ: Allow Updates of Address Records During Import

  • HZ: Character Value to Indicate NULL During Import

  • HZ: Date Value (DD-MM-YYYY) to Indicate NULL During Import

  • HZ: Error Limit for Import

  • HZ: Import Batch De-Duplication Match Rule

  • HZ: Import Registry De-Duplication Match Rule

  • HZ: Number of Workers for Import

  • HZ: Numeric Value to Indicate NULL During Import

  • HZ: Use HR Security During Import

  • HZ: Validate Flexfields During Import

  • HZ: Work Unit Size for Import

  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

Bulk Import De-Duplication Processes

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:

1. 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.

2. The user specifies a match rule with Bulk Duplicate Identification purpose for the de-duplication.

3. 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.

4. The transformed interface table records are mapped and loaded into the interface search tables, a set of temporary staged tables with B-Tree indexes.

   • HZ_SRCH_PARTIES

   • HZ_SRCH_PSITES

   • HZ_SRCH_CONTACTS

   • HZ_SRCH_CPTS

5. 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:

     Entity	Interface Search Table	Staged Schema Table
     Party	HZ_SRCH_PARTIES	HZ_STAGED_PARTIES
     Address	HZ_SRCH_PSITES	HZ_STAGED_PARTY_SITES
     Contact	HZ_SRCH_CONTACTS	HZ_STAGED_CONTACTS
     Contact Point	HZ_SRCH_CPTS	HZ_STAGED_CONTACT_POINTS

   • 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.

6. Matched acquisition attribute values determine the most relevant subset of records from the interface search tables to form the work unit.

7. 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.

8. A score is calculated for each record in the work unit, and scores for all entities are added together for determining duplicate parties.

9. 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

Setting Up Bulk Import

Bulk Duplicate Identification

Setting Up Customer Interface

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.

Procedure

• 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: Overview of Setting Up, 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: Number of Workers Used by Customer Interface

See: Customer Interface Deployment Category.

Related Topics

Feature-Specific Implementation

Setting Up Customer Merge

Customer Merge lets you:

• 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.

Procedure

• 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

  See: Customer Merge Deployment Category.

Related Topics

Merging Customers, Oracle Trading Community Architecture User Guide

Feature-Specific Implementation

Setting Up eLocations Spatial Data Integration

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.

Procedure

• Set profile options.

  • HZ: Detailed Concurrent Program Output

  • These three profile options are for the HTTP post to eLocations. They determine the URL, proxy host, and proxy port to use.

    • HZ: Spatial Provider URL

    • Applications Server-Side Proxy Host And Domain

    • Applications Proxy Port

  See: Profile Options and Profile Option Categories.

• 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

Locations Spatial Index Rebuild

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

Setting Up Party Merge

Party Merge involves merging parties that are confirmed as duplicates, either from a duplicate identification batch or a manually created merge batch.

Procedure

• Define any custom entities and merge procedures.

• 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

Feature-Specific Implementation

Setting Up Real-Time Address Validation

Real-time address validation validates addresses during address entry. See: Real-Time Address Validation, Oracle Trading Community Architecture User Guide.

Most of the address validation setup involves Geography Hierarchy. See: Administering Geography Hierarchy.

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.

Synchronizing FAF and Geography Mapping

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.

Procedure:

Note: Perform these steps for each country that you need to validate addresses for.

1. 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.

2. 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.

3. 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.

4. 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.

5. Specify the address, or geography, validation level for the country. See: Managing Validations.

6. 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.

7. 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.

8. Run the Geography Name Referencing process to map addresses in location tables to master reference geographies. See: Geography Name Referencing Process.

Related Topics

Geography Hierarchy Overview

Setting Up Relationship Manager

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.

Procedure

1. Administer Data Quality Management.

   Optionally create one or more match rules with the Search purpose.

   • When defining match rule thresholds, remember that a record's score must meet or exceed the match threshold to be displayed in the search results.

   • If you define a match rule set, remember that the superset of all attributes in the set is displayed as search criteria.

2. 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

Setting Up Third Party Data Integration

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.

Procedure

1. 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.

   If you do not have a relationship manager assigned to your company, contact D&B's Global Service Center at [phone], e-mail [e-mail], 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.

2. 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/access/scripts

   • 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.

3. Enter the provided D&B URL, user names, and passwords in the configuration for the seeded Dun & Bradstreet adapter. See: Configuring Adapters.

4. 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.

5. 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

6. 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

   See: Profile Options and Profile Option Categories.

7. For batch loading D&B data into the Registry:

   • Set up Bulk Import. See: Setting Up Bulk Import.

   • 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