Integrating Person Data
This section discusses how to:
Understand person data integration.
Review integrated person data.
Understand the business process.
Understand external Search/ Match integration.
Use external Search/Match to integrate with external systems.
Configure the Last Employee ID Assigned number.
Publish and subscribe to person data.
Configure web services for person data.
Understand Person Data FullSync and Sync Service Operations and Handlers.
In CS 9.0 Feature Pack 4, Oracle delivered the tools that provide for an integration of person data directly between the CS and HCM systems. The suite of person attributes is transferred primarily by the PERSON_BASIC_SYNC message. The data that comprises the message includes the core person data historically contained in PERSON_BASIC_SYNC, plus CS extension data (such as FERPA) contained in the PERSON_SA message and global subrecords. Ethnicity and diversity information are also part of the integrated person data set. Subscription handlers enable inbound person additions and updates in both CS and HCM. PERSON_BASIC_SYNC can also subscribe to incoming person data from an external source.
As delivered, direct integration between CS and HCM requires only the use of Integration Broker to enable and orchestrate the integration. No additional integration mechanism is required.
CS also subscribes to the WORKFORCE_SYNC message to bring job data (still mastered in HCM) into CS for those CS processes that require it (such as assigning an instructor to a class).
In general, the following key person bio-demo and other data are synchronized between the systems. The delivered integrations include data fields for country localizations and other personal attributes which may or may not be used in your implementation.
Names
Addresses
Phones
Email Addresses
National IDs
Gender
Birth date
Date of Death
Marital Status
FERPA Flag
Disability
Ethnicity/Diversity
Citizenship
Passport
Visa/Permits
Job
HR Operator Defaults
User Profiles
In the distinct ownership model, the following person bio-demo data is fetched from one system to the other as part of the External Search/Match process:
EmplID
Names
Addresses
Phones
Email Addresses
National IDs
FERPA Flag
VA Benefit
The section on the Higher Education Constituent Hub (HECH) integration model lists the person data that is synchronized between systems.
In a shared CS-HCM instance, data is available in both systems and updates in either system change a single record. In a CS-to-HCM integrated environment, the person record is physically separated.
In thinking about the flow of person data between separated instances, institutions are no longer bound by the absolute sharing of data conferred by a single shared data model. Instead, they can use the tools described in this documentation to configure the integration to reflect the business needs of the institution. For example, some institutions would prefer to retain, as much as possible, the legacy model in which all person data is shared between CS and HCM; other institutions may want to separate not just their data but their business processes to more closely reflect policies of data ownership between student and human resources administration on campus.
CS supports four models of integration of person data between CS and HCM: Owner/Subscriber, Subscriber-Only, Distinct Ownership, and integration using the Higher Education Constituent Hub.
Owner-Subscriber
In an owner-subscriber integration model, one system is defined as the system of record and the other system subscribes to its person data messages. All EmplIDs exist and are in sync in both databases. For example, if CS is defined as the owner for adding and updating person data, the HCM system subscribes to the person messages; integration setup feeds person data additions and updates to HCM. The end-user experience can be managed via a portal or related content to navigate a combination of CS and HCM menus and pages.
Image: Example of adding an admissions applicant in CS
This workflow depicts the process of adding an Admissions applicant in CS.
Image: Example of hiring an employee in HCM
This workflow depicts the process of hiring an employee in HCM.
Subscriber Only
In a subscriber-only integration model, both systems are defined as system of record and integrations are configured to allow both systems to publish and subscribe to person data messages. All EmplIDs are populated to both systems and are kept in sync.
Image: Example of adding an admissions applicant or employee
This workflow depicts the process of adding an Admissions applicant or employee in the Subscriber-only model.
Distinct Ownership
In a distinct ownership integration model, person data is added and updated in the appropriate CS or HCM system (as determined by the business processes of your institution; for example, employees are added and maintained in HCM). External Search/Match then becomes the method used in each system to ensure that users do not create duplicate records on campus. For example, as an employee is added to HCM, External Search/Match determines whether that new employee is already a student in CS with an EmplID and other bio-demo data housed in the CS system. If so, a "fetch" process can pull that EmplID and person data to HCM, ensuring that the individual retains a single unique ID on campus. Thereafter, each system must be manually updated, with no further integration between them.
Image: Example of hiring an employee in HCM using External Search/Match to CS
This workflow depicts the process of adding an employee in HCM using External Search/Match to CS.
Integration Using HECH
In a HECH integration model, the HECH becomes the owner of all person data, and all other systems on campus subscribe to it. Your institution can use External Search/Match to ensure that users do not create duplicate records in your CS system.
Image: Example of adding an admissions applicant in CS using HECH
This workflow depicts the process of adding an admissions applicant in CS using HECH.
See also:Integrating Using the HECH.
In a single-instance environment, users add persons in their respective application (HCM or CS). In an integrated, separate-instance environment using the distinct ownership model, users who want to maintain a single EmplID must use External Search/Match in each system to ensure the creation of unique person records. Initially, users use positive External Search/Match results to locate and add person data from the external system (such as a CS user searching against HCM); subsequently, person updates must be done manually in both instances to avoid becoming out of sync.
In both the distinct ownership integration and HECH integration models, External Search/Match is the tool used to ensure that only unique EmplIDs are added to any system. With distinct ownership, people are added in either the CS or HCM system (as appropriate); both systems use External Search/Match to search for possible duplicate records so only unique IDs are shared between the databases. However, both databases must be running in order for External Search/Match to work. With the HECH, External Search/Match can search against that system as it would any external system.
External Search/Match can search against the HECH, HCM 9.0, HCM 9.1, or HCM 9.2 to identify potential duplicate person records as well as carry EmplIDs throughout a business process.
See also:
Setting Up External Search/Match Functionality
Image: Example of adding an admissions applicant in CS using External Search/Match to HCM
This workflow depicts the process of adding an admissions applicant in CS using External Search/Match.
You will need to review and update the Last Employee ID Assigned numbers on your systems to ensure EMPLID values are assigned in proper ranges and to prevent data integrity problems with conflicting EMPLID values being assigned.
In an owner/subscriber configuration, the database instance that is the system of record for personal information is responsible for assigning the next EMPLID value.
In a subscriber-only configuration, both databases assign EMPLID values. Determine the range of EMPLID values that will provide the maximum number of new persons expected to be added to each system over its lifetime. For example, you may anticipate more new persons to be added first to your CS system, therefore set the Last Employee ID Assigned value in the CS instance to a value that will allow for the most growth over time.
This step should be done with careful evaluation of the EMPLID number strategy you have implemented. Consider the following:
Do you have custom EMPLID assignment routines that are used to set the next ID number?
Do your users have established business practices that reserve certain number ranges?
Which system is expected to typically create the most new persons?
To update the Last ID Assigned, navigate to
. This navigation is the same for both CS and all HCM releases.On the Last ID Assigned page, update the Last Employee ID Assigned field to the number desired.
See Integrating Setup DataSelecting General Installation Options
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 9.0 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 9.0 and HCM 9.0/9.1 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 your CS 9.0 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 will 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 9.0 to HCM
Integration Name |
HCM Table |
---|---|
PERSON_BASIC_FULLSYNC.VERSION_4 |
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_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.
This section provides a summary of Person Data FullSync and Sync Service Operations and Handlers, and discusses how to:
Configure Integration Broker Gateway and Nodes.
Configure PERSON_BASIC_SYNC Service.
Configuring the Integration Broker Gateway and Nodes
To configure the Integration Broker Gateways and Nodes in your CS and HCM databases:
Set the Service Configuration in the HCM 9.1 database.
Configure the Gateway in the HCM 9.1 database.
Configure the default local node in the HCM 9.1 database.
Configure the HCM Gateway in the CS 9.0 database.
Configure the CS node in the HCM database.
Configure the default LOCAL node in the CS database.
Configure the HCM node in the CS database.
Update the HCM Gateway nodes in the HCM database.
Update the HCM Gateway nodes in the CS database.
Update the Single Sign-on nodes.
Test Nodes.
Note: The steps detailed in the following tasks demonstrate the setup for HCM 9.1 and CS 9.0 databases.
Setting the Service Configuration in the HCM 9.1 database.
Navigate:
Set Service Namespace = http://xmlns.oracle.com/Enterprise/HCM/services.
Set Schema Namespace = http://xmlns.oracle.com/Enterprise/Tools/schemas.
Set Target Location = http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector.
Set Service System Status = Production.
Configuring the Gateway in the HCM 9.1 database.
Navigate:
Select Integration Gateway ID = LOCAL.
Set URL = http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector/SPLTHL91.
Click the Load Gateway Connectors button.
It should load 9 connectors.
Save.
Click the Ping Gateway button. It should be successful and show the status as Active.
Configuring the default local node in the HCM 9.1 database.
Navigate:
Select the default local node.
Set Descr = HCM 9.1 Instance.
Set Authentication Option = Password.
Node Password = PS.
Default User ID = PS.
Click the Connectors tab.
Use gateway LOCAL.
Set Connector Id = PSFTTARGET.
Click the Portal tab.
Set Tools Release = 8.50.xx.
Note: By pressing the <CTL>+J keys, you should be able to see the tools release string.
Set Application Release = HCM 9.1.
Set Content URI Text = http://machinename:port/psc/SPLTHL91.
Set Portal URI Text = http://machinename:port/psp/SPLTHL91.
Click the WS Security tab.
Set Authentication Token Type = none.
Disable the Encrypted check box.
Save.
Configuring the HCM Gateway in the CS 9.0 database.
Navigate:
Add a New Value.
Integration Gateway ID = <Gateway Name for HCM 9.1>.
URL = http://machinename:port/PSIGW/PeopleSoftListeningConnector/databasename.
Click the Load Gateway Connectors button.
It should load 9 connectors.
Save.
Click the Ping Gateway button.
It should be successful and display an 'Active' status.
Configuring the CS node in the HCM database.
Navigate:
Add Node = <Name of CS 9.0 Node>.
Set Descr = CS 9.0 Instance.
Set Authentication Option = Password.
Node Password = PS.
Default User ID = PS.
Click the Connectors tab.
Set Gateway = LOCAL.
Set Connector ID = PSFTTARGET.
Click the Portal tab.
Set Tools Release = 8.50.xx
Note: By pressing the <CTL>+J keys, you should be able to see the tools release string.
Set Application Release = CS 9.0.
Set Content URI Text = http://machinename:port/psc/databasename
Set Portal URI Text = http://machinename:port/psp/databasename.
Click the WS Security tab.
Set Authentication Token Type = none.
Disable the Encrypted checkbooks.
Click Save.
Configuring the default LOCAL node in the CS database.
Note: The gateway used by this node is the HCM gateway. The node passwords must be consistent between the CS database and the HCM database.
Navigate:
Select the default local node.
Set Descr = CS 9.0 Instance.
Set Authentication Option = Password.
Node Password = PS.
Default User ID = PS.
Click the Connectors tab.
Select Gateway = <Gateway Name for HCM 9.1>.
Note: This is not the local gateway.
Set Connector Id = PSFTTARGET.
Click the Portal tab.
Set Tools Release = 8.50.xx.
Note: By pressing the <CTL>+J keys, you should be able to see the tools release string.
Set Application Release =CS 9.0.
Set Content URI Text = http://machinename:port/psc/databasename
Set Portal URI Text = http://machinename:port /psp/databasename.
Click the WS Security tab.
Set Authentication Token Type = none.
Disable the Encrypted checkbooks.
Click Save.
Configuring the HCM node in the CS database.
Note: Each node is defined twice – once in each database. They should all use the same gateway.
Navigate:
Add Node: <Name of HCM Node>.
Set Descr = HCM 9.1 Instance.
Set Authentication Option = Password.
Node Password = PS.
Default User ID = PS.
Click the Connectors tab.
Gateway ID = <Gateway Name for HCM 9.1>.
Note: This is not the local gateway.
Set Connector Id = PSFTTARGET.
Click the Portal tab.
Set Tools Release = 8.50.xx.
Note: By pressing the <CTL>+J keys in the HCM database PIA, you should be able to see the tools release string.
Set Application Release = HCM 9.1
Set Content URI Text = http://machinename:port/psc/databasename
Set Portal URI Text = http://machinename:port/psp/databasename
Click the WS Security tab.
Set Authentication Token Type = none.
Disable (turn off) the Encrypted checkbooks.
Click Save.
A Node Saved message box appears. Click OK.
Updating the HCM Gateway nodes in the HCM database.
Both CS and HCM database nodes should point to the same Gateway. The specific Gateway should also have both Nodes listed in the Gateway Advanced Properties.
Navigate:
Select gateway LOCAL.
Select the Gateway Setup Properties link.
User ID = administrator.
Password = password.
Click OK.
In the 'Gateway Default App. Server' frame, Set the App Server URL = ' //machinename:port.
Note: Your port must match that specified in your HCM application server.
Enter the appropriate User ID.
Enter the appropriate Password.
Set the tools release = 8.50.xx.
Note: by pressing the <CTL>+J keys, you should be able to see the tools release string.
Make sure both the HCM and CS nodes are in the PeopleSoft Nodes tab.
Ping the HCM node.
It should be successful.
Click Return.
Updating the HCM Gateway nodes in the CS database.
Navigate:
Select gateway LOCAL.
Select the Gateway Setup Properties link.
User ID = administrator.
Password = password.
Click OK.
In the Gateway Default App. Server' frame, Set the App Server URL = //machinename:port.
Note: Your port must match that specified in your HCM application server.
Enter the appropriate User ID.
Enter the appropriate Password.
Set the tools release = 8.50.xx.
Note: By pressing the <CTL>+J keys, you should be able to see the tools release string.
Make sure both the HCM and CS nodes are in the PeopleSoft Nodes tab.
Ping the HCM node.
It should be successful.
Click Return.
Updating the Single Sign-on nodes in both CS and HCM databases.
Single Sign-on is used in this recommended configuration.
Navigate:
Make sure that both the default local node and the other node you will be using are listed.
Testing Nodes.
Both nodes must be 'pingable' from each database.
Navigate:
Do this on each database.
For each node name, enter its name and click the Ping Node button.
It should respond with Success.
Configuring the PERSON_BASIC_SYNC Service
The PERSON_BASIC_SYNC service is the primary integration point for syncing core personal data between your CS and HCM systems. The following tasks detail how to configure the PERSON_BASIC_SYNC service to publish from your CS 9.0 system and subscribe in the target HCM 9.0/9.1.
Owner/Subscriber: If you implement the owner/subscriber model, you will configure your PERSON_BASIC_SYNC service to publish from your master CS 9.0 system to your target HCM 9.0/9.1 system.
Subscriber Only: If you implement the subscriber–only model, you will configure the PERSON_BASIC_SYNC service in both your CS 9.0 and HCM 9.0/9.1 systems to publish and subscribe.
Note: The examples of the source and target database configuration tasks are of CS 9.0 (source) and HCM 9.1 (target) on PeopleTools 8.51.03.
Configuring the Source Database CS 9.0
Update security by adding the Service Operation(s) to your primary permission list:
Navigate to
.Select the relevant permission list from the search dialog box.
Select to the Web Services tab.
Enter the corresponding Service(s) for the Service Operation(s) you want to use.
Click the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page by selecting the Full Access option for the Access column.
Image: Web Service Access page
This graphic provides an example of the Web Service Access page for the PERSON_BASIC_SYNC operation.
Activate Service Operation(s) and Create Routing(s) in CS 9.0:
Navigate to
.Select PERSON_BASIC_SYNC from the search dialog box.
Image: PERSON_BASIC_SYNC service operation
This example illustrates the fields and controls on the General page for the PERSON_BASIC_SYNC service operation.
Check the Active check box on the General tab.
Make note of the Queue Name field, as you will verify that the PERSON_DATA Queue is in Running status later.
Click the Routings tab and add a new routing for the Service Operation by entering a value in the Routing Name field and clicking the Add button.
Image: Routings page for PERSON_BASIC_SYNC
This example illustrates the fields and controls on the Routings page for PERSON_BASIC_SYNC.
Enter a Sender Node and a Receiver Node on the Routings Definition page of the Routings component.
Image: Routing Definitions page for PERSON_BASIC_SYNC
This example illustrates the fields and controls on the Routing Definitions page for PERSON_BASIC_SYNC .
Verify that the Active check box is checked.
Click the Parameters tab.
Image: Parameters page for PERSON_BASIC_SYNC routing
This example illustrates the fields and controls on the Parameters page for PERSON_BASIC_SYNC routing.
Enter External Alias = PERSON_BASIC_SYNC.VERSION_4.
Enter Message.Ver into Transform 1 = PERSON_BASIC_SYNC.INTERNAL.
Enter Transform Program = HMTF_TR_OA
Enter Message.Ver out of Transforms = PERSON_BASIC_SYNC.VERSION_4.
Click Save at the bottom of the Parameters page to save the routing.
Click Return at the bottom of the Parameters page to return to the Service Operation setup page.
Click Save at the bottom of any page in the Service Operations component to save the Service Operation.
Image: Integration Broker Routing
This example illustrates Integration Broker outbound request routing for PERSON_BASIC_SYNC.
Activate Message Queue.
Navigate to
.Scroll down the page until you find the relevant PERSON_DATA Queue Name.
Review the queue Status and activate the queue by clicking Run, if needed. The queue status should be set to Running before leaving this page.
Image: Example of PERSON_DATA Queue Status
This example illustrates queue status for PERSON_DATA.
Configuring the Target Database HCM 9.1
Update security by adding the service operation to the required user’s permission list.
Navigate to
.Select the relevant permission list from the search dialog box (primary permission list for the user).
Select the Web Services tab.
Enter the corresponding Service(s) for the Service Operation(s) you want to leverage.
Click the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page.
Click OK to return to the Web Services page.
Click Save to save the updated Permission List.
Image: Web Service Permissions page
This example illustrates the fields and controls on the Web Service Permissions page for the PERSON_BASIC_SYNC service.
Activate Service Operation(s) and Create Routing(s) and Subscription Handler in HCM 9.1:
Navigate to
.Select PERSON_BASIC_SYNC from the search dialog box.
Check the Active check box on the General tab.
Make note of the Queue Name field, as you will verify that the PERSON_DATA Queue is in Running status later.
Image: General page for PERSON_BASIC_SYNC service operation
This example illustrates the fields and controls on the General page for the PERSON_BASIC_SYNC service operation in HCM 9.1.
Click the Handlers tab. Set the SCC_HR_PERSON handler to Active.
Image: Handlers page for PERSON_BASIC_SYNC
This example illustrates the fields and controls on the Handlers page for the PERSON_BASIC_SYNC service operation in HCM 9.1.
Image: Handler Details page for SCC_HR_PERSON
This example illustrates the fields and controls on the Handler Details page for the SCC_HR_PERSON handler in HCM 9.1
Select the Routings tab and add a new routing for the Service Operation by entering a value in the Routing Name field and clicking the Add button.
Image: Routings page for PERSON_BASIC_SYNC service operation
This example illustrates the fields and controls on the Routings page for the PERSON_BASIC_SYNC service operation in HCM 9.1.
Enter the CS 9.0 Sender Node and an HCM 9.1 Receiver Node on the Routings Definition page of the Routings component.
Verify that the Active check box is checked.
Image: Routing Definitions page for PERSON_BASIC_SYNC
This example illustrates the fields and controls on the Routing Definitions page for the PERSON_BASIC_SYNC service operation in HCM 9.1.
Select the Parameters tab.
Image: Parameters page for PERSON_BASIC_SYNC
This example illustrates the fields and controls on the routing Parameters page for the PERSON_BASIC_SYNC service operation in HCM 9.1.
Enter External Alias = PERSON_BASIC_SYNC.VERSION_4.
Enter Message.Ver into Transform 1 = PERSON_BASIC_SYNC.VERSION_4.
Enter Transform Program = HMTF_TR_IA.
Enter Message.Ver out of Transforms = PERSON_BASIC_SYNC.INTERNAL.
Click Save at the bottom of the Parameters page to save the routing.
Click Return at the bottom of the Parameters page to return to the Service Operation setup page.
Click Save at the bottom of any page in the Service Operations component to save the Service Operation.
Image: Integration Broker Routing
This example illustrates Integration Broker inbound request routing for PERSON_BASIC_SYNC.
The following table summarizes the FullSync and Sync Service Operations, and the Subscription Handler that you should use to configure your CS-HCM person bio-demo data integrations.
Service Name |
Queue |
Subscription Handler App Package |
---|---|---|
PERS_POI_FULLSYNC.VERSION_1 |
PERSON_DATA |
PersPoiFullSync PERSPOIFULLSYNC/PersPoiFullSync/OnNotify |
PERS_POI_SYNC.VERSION_1 |
PERSON_DATA |
PersPoiSync PERSPOISYNC/PersPoiSync/OnNotify |
PERSON_BASIC_FULLSYNC.VERSION_4 |
PERSON_DATA |
PersonBasicFullsync PERSON_BASIC_FULLSYNC/PersonBasicFullSync/OnNotify |
PERSON_BASIC_SYNC.VERSION_4 |
PERSON_DATA |
SCC_HR_PERSON SCC_HR_PERSON/PersonBasicSync/OnNotify |
PERSON_DISABILITY_FULLSYNC.VERSION_2 |
PERSON_DATA |
ONNOTIFY PERSON_DISABILITY_FULLSYNC/PersonDisabilityFullsync/OnNotify |
PERSON_DISABILITY_SYNC.VERSION_2 |
PERSON_DATA |
ONNOTIFY PERSON_DISABILITY_SYNC/PersonDisabilitySync/OnNotify |
PERSON_DIVERSITY_FULLSYNC.VER SION_2 |
PERSON_DATA |
PersonDiversityFullSync PERSON_DIVERSITY_FULLSYNC/PersonDiversityFullsync/On Notify |
PERSON_DIVERSITY_SYNC.VERSION_2 |
PERSON_DATA |
PersonDiversitySync PERSON_DIVERSITY_SYNC/PersonDiversitySync/OnNotify |
PERSON_VISA_CITIZEN_FULLSYNC1.VERSION_1 |
PERSON_DATA |
ONNOTIFY PERSON_VISA_CITIZEN_FULLSYNC1/PersonVisaCitizenFullSync1/OnNotify |
PERSON_VISA_CITIZEN_FULLSYNC2.VERSION_1 |
PERSON_DATA |
ONNOTIFY PERSON_VISA_CITIZEN_FULLSYNC2/PersonVisaCitizenFullSync2/OnNotify |
PERSON_VISA_CITIZEN_SYNC.VERSION_2 |
PERSON_DATA |
ONNOTIFY PERSON_VISA_CITIZEN_SYNC/PersonVisaCitizenSync/OnNotify |
WORKFORCE_FULLSYNC.VERSION_3 |
PERSON_DATA |
WorkforceFullSync WORKFORCE_FULLSYNC/WorkforceFullSync/OnNotify |
WORKFORCE_SYNC.VERSION_3 |
PERSON_DATA |
WorkforceSync WORKFORCE_SYNC/WorkforceSync/OnNotify |