Publishing and Subscribing to Person Data

In an owner-subscriber integration approach, the following messages move data asynchronously from the owner to the subscriber:

  • PERSON_BASIC_SYNC

  • PERSON_DIVERSITY_SYNC

  • PERSON_VISA_CITIZEN_SYNC

  • PERSON_DISABILITY_SYNC

  • PERS_POI_SYNC

  • PERS_EMERGNCY_CONTACT_SYNC

  • SCC_PERSON_SYNC

The WORKFORCE_SYNC message integrates job data between the two systems; where necessary, from HCM to CS.

Minimum setup information must be available and loaded from your HCM system to your CS system for implementation. This should be completed before any transactional data syncs are performed. The values defined in these setup tables are key to person bio-demo data integrity. Oracle recommends that your setup tables be mastered in the HCM instance.

Incremental Synchronization

Data in the supporting tables in your system of record may change over time after the initial loading of setup, transactional data, and security data. Use incremental sync (Sync) services to send this information from your system of record to your subscribing target system to maintain data integrity.

An incremental sync captures data that was created, added, changed, or deleted in the system of record since the last synchronization. It uses the captured data to overwrite the same data in the subscribing system, thereby refreshing the subscribing system so that both systems have the same data.

After the initial fullsync data loads have completed in your subscribing target system, you may inactivate the associated fullsync services, and then activate the appropriate incremental Sync services to keep your systems updated.

Manual Entry Data Load

You can, if necessary, enter data manually into your CS and HCM systems. However, it would be tedious, time consuming, and possibly introduce typographical errors. Oracle does not recommend this method for most data elements unless required to load a small amount of data.

Transactional Data Loading Sequence

For all owner/subscriber configurations, person transactional information must be available and loaded from your system of record to your subscribing system for implementation. Oracle recommends that CS be the system of record for Person data. Your HCM system should remain the system of record for all HCM Workforce and other HR related transactional data.

Note:

Carefully plan your requirements for the initial load of transaction data for your specific implementation. If you are doing a new install of HCM, you need to load this transaction data as part of your implementation. Customers upgrading to HCM 9.1 or HCM 9.2 from a combined HCM and CS 9.0 database will already have the proper transaction data in place in both systems.

The following table lists the required integration, indicates the type of service recommended, and the order in which you must load transactional table data into your HCM system.

Person Transaction Data Campus Solutions to HCM

Integration Name HCM Table

PERSON_BASIC_FULLSYNC.VERSION_9

PERSON

PERS_DATA_EFFDT

PERS_DATA_USF*

PERS_NID

NAMES

ADDRESSES

EMAIL_ADDRESSES

PERSONAL_PHONE

PERS_SMOKER*

PERSON_BRA*

PERS_DATA_BRA*

PERS_DATA_CAN PERS_DATA_CHE*

PLACE_ORIG_CHE*

PERS_HUKOU_CHN*

PERS_DATA_DEU*

NATIONALITY_GER*

PERS_DATA_ESP*

PERSON_FRA*

PERS_DATA_FRA*

PERS_DATA_IND*

PERS_DATA_ITA*

PERS_DATA_JPN*

PERS_DATA_MEX*

PERS_DATA_USA

PERS_DATA_FPS*

PERSON_SA

PERS_EMERGNCY_CONTACT_FULLSYNC

EMERGENCY_CNTCT

EMERGENCY_PHONE

PERS_POI_FULLSYNC.VERSION_1

PER_POI_TYPE

PER_POI_SCRTY

PER_POI_SCR_DT

PER_POI_TRANS

PERSON_DISABILITY_FULLSYNC.VERSION_2

DISABILITY

ACCOM_REQUEST

DISABILITY_FRA*

DISABILITY_GER*

DISABILITY_CHE*

DISABILITY_ESP*

DISABILITY_BRA*

DISABILITY_NLD*

DISABILITY_NZL*

PERSON_DIVERSITY_FULLSYNC.VERSION_2

DIVERSITY

DIVERS_ETHNIC

DIVERS_RELIGION*

PERSON_VISA_CITIZEN_FULLSYNC1.VERSION_1

CITIZENSHIP

CITIZEN_PSSPRT

PERSON_VISA_CITIZEN_FULLSYNC2.VERSION_1

VISA_PMT_DATA

VISA_PMT_SUPPRT

*Existing CS functionality does not populate these tables. Depending on your use of HCM functionality, the records marked with an asterisk may not have data present at the time the fullsync is published.