Return to Navigation

Integrating Person Data

This section discusses how to:

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.

See Integrating CS Data to HCM Using the HECH Connector.

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.

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.

Example of hiring an employee in HR

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.

CS to HCM Integration

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.

Example of hiring 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.

Example 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

Using Search/Match

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.

Example of adding an admissions applicant in CS using External Search/Match to HCM

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 select Set Up HRMS, then select Install, then select Installation Table.. 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:

  1. Set the Service Configuration in the HCM 9.1 database.

  2. Configure the Gateway in the HCM 9.1 database.

  3. Configure the default local node in the HCM 9.1 database.

  4. Configure the HCM Gateway in the CS 9.0 database.

  5. Configure the CS node in the HCM database.

  6. Configure the default LOCAL node in the CS database.

  7. Configure the HCM node in the CS database.

  8. Update the HCM Gateway nodes in the HCM database.

  9. Update the HCM Gateway nodes in the CS database.

  10. Update the Single Sign-on nodes.

  11. Test Nodes.

Note: The steps detailed in the following tasks demonstrate the setup for HCM 9.1 and CS 9.0 databases.

  1. Setting the Service Configuration in the HCM 9.1 database.

    1. Navigate: select PeopleTools, then select Integration Broker, then select Configuration , then select Service Configuration.

    2. Set Service Namespace = http://xmlns.oracle.com/Enterprise/HCM/services.

    3. Set Schema Namespace = http://xmlns.oracle.com/Enterprise/Tools/schemas.

    4. Set Target Location = http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector.

    5. Set Service System Status = Production.

  2. Configuring the Gateway in the HCM 9.1 database.

    1. Navigate: select PeopleTools, then select Integration Broker, then select Configuration , then select Gateways.

    2. Select Integration Gateway ID = LOCAL.

    3. Set URL = http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector/SPLTHL91.

    4. Click the Load Gateway Connectors button.

      It should load 9 connectors.

    5. Save.

    6. Click the Ping Gateway button. It should be successful and show the status as Active.

  3. Configuring the default local node in the HCM 9.1 database.

    1. Navigate: select PeopleTools, then select Integration Broker, then select Integration Setup, then select Nodes.

    2. Select the default local node.

    3. Set Descr = HCM 9.1 Instance.

    4. Set Authentication Option = Password.

    5. Node Password = PS.

    6. Default User ID = PS.

    7. Click the Connectors tab.

    8. Use gateway LOCAL.

    9. Set Connector Id = PSFTTARGET.

    10. Click the Portal tab.

    11. Set Tools Release = 8.50.xx.

      Note: By pressing the <CTL>+J keys, you should be able to see the tools release string.

    12. Set Application Release = HCM 9.1.

    13. Set Content URI Text = http://machinename:port/psc/SPLTHL91.

    14. Set Portal URI Text = http://machinename:port/psp/SPLTHL91.

    15. Click the WS Security tab.

    16. Set Authentication Token Type = none.

    17. Disable the Encrypted check box.

    18. Save.

  4. Configuring the HCM Gateway in the CS 9.0 database.

    1. Navigate: select PeopleTools, then select Integration Broker, then select Configuration , then select Gateways.

    2. Add a New Value.

    3. Integration Gateway ID = <Gateway Name for HCM 9.1>.

    4. URL = http://machinename:port/PSIGW/PeopleSoftListeningConnector/databasename.

    5. Click the Load Gateway Connectors button.

      It should load 9 connectors.

    6. Save.

    7. Click the Ping Gateway button.

      It should be successful and display an 'Active' status.

  5. Configuring the CS node in the HCM database.

    1. Navigate: select PeopleTools, then select Integration Broker, then select Integration Setup, then select Nodes.

    2. Add Node = <Name of CS 9.0 Node>.

    3. Set Descr = CS 9.0 Instance.

    4. Set Authentication Option = Password.

    5. Node Password = PS.

    6. Default User ID = PS.

    7. Click the Connectors tab.

    8. Set Gateway = LOCAL.

    9. Set Connector ID = PSFTTARGET.

    10. Click the Portal tab.

    11. Set Tools Release = 8.50.xx

      Note: By pressing the <CTL>+J keys, you should be able to see the tools release string.

    12. Set Application Release = CS 9.0.

    13. Set Content URI Text = http://machinename:port/psc/databasename

    14. Set Portal URI Text = http://machinename:port/psp/databasename.

    15. Click the WS Security tab.

    16. Set Authentication Token Type = none.

    17. Disable the Encrypted checkbooks.

    18. Click Save.

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

    1. Navigate: select PeopleTools, then select Integration Broker, then select Integration Setup, then select Nodes.

    2. Select the default local node.

    3. Set Descr = CS 9.0 Instance.

    4. Set Authentication Option = Password.

    5. Node Password = PS.

    6. Default User ID = PS.

    7. Click the Connectors tab.

    8. Select Gateway = <Gateway Name for HCM 9.1>.

      Note: This is not the local gateway.

    9. Set Connector Id = PSFTTARGET.

    10. Click the Portal tab.

    11. Set Tools Release = 8.50.xx.

      Note: By pressing the <CTL>+J keys, you should be able to see the tools release string.

    12. Set Application Release =CS 9.0.

    13. Set Content URI Text = http://machinename:port/psc/databasename

    14. Set Portal URI Text = http://machinename:port /psp/databasename.

    15. Click the WS Security tab.

    16. Set Authentication Token Type = none.

    17. Disable the Encrypted checkbooks.

    18. Click Save.

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

    1. Navigate: select PeopleTools, then select Integration Broker, then select Integration Setup, then select Nodes.

    2. Add Node: <Name of HCM Node>.

    3. Set Descr = HCM 9.1 Instance.

    4. Set Authentication Option = Password.

    5. Node Password = PS.

    6. Default User ID = PS.

    7. Click the Connectors tab.

    8. Gateway ID = <Gateway Name for HCM 9.1>.

      Note: This is not the local gateway.

    9. Set Connector Id = PSFTTARGET.

    10. Click the Portal tab.

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

    12. Set Application Release = HCM 9.1

    13. Set Content URI Text = http://machinename:port/psc/databasename

    14. Set Portal URI Text = http://machinename:port/psp/databasename

    15. Click the WS Security tab.

    16. Set Authentication Token Type = none.

    17. Disable (turn off) the Encrypted checkbooks.

    18. Click Save.

    19. A Node Saved message box appears. Click OK.

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

    1. Navigate: select PeopleTools, then select Integration Broker, then select Configuration , then select Gateways.

    2. Select gateway LOCAL.

    3. Select the Gateway Setup Properties link.

    4. User ID = administrator.

    5. Password = password.

    6. Click OK.

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

    8. Enter the appropriate User ID.

    9. Enter the appropriate Password.

    10. Set the tools release = 8.50.xx.

      Note: by pressing the <CTL>+J keys, you should be able to see the tools release string.

    11. Make sure both the HCM and CS nodes are in the PeopleSoft Nodes tab.

    12. Ping the HCM node.

      It should be successful.

    13. Click Return.

  9. Updating the HCM Gateway nodes in the CS database.

    1. Navigate: select PeopleTools, then select Integration Broker, then select Configuration , then select Gateways.

    2. Select gateway LOCAL.

    3. Select the Gateway Setup Properties link.

    4. User ID = administrator.

    5. Password = password.

    6. Click OK.

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

    8. Enter the appropriate User ID.

    9. Enter the appropriate Password.

    10. Set the tools release = 8.50.xx.

      Note: By pressing the <CTL>+J keys, you should be able to see the tools release string.

    11. Make sure both the HCM and CS nodes are in the PeopleSoft Nodes tab.

    12. Ping the HCM node.

      It should be successful.

    13. Click Return.

  10. Updating the Single Sign-on nodes in both CS and HCM databases.

    Single Sign-on is used in this recommended configuration.

    1. Navigate: select PeopleTools, then select Security, then select Security Objects, then select Single Signon.

    2. Make sure that both the default local node and the other node you will be using are listed.

  11. Testing Nodes.

    Both nodes must be 'pingable' from each database.

    1. Navigate:select PeopleTools, then select Integration Broker, then select Service Operations Monitor , then select Administration, then select Node Status.

      Do this on each database.

    2. For each node name, enter its name and click the Ping Node button.

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

  1. Update security by adding the Service Operation(s) to your primary permission list:

    1. Navigate to select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists.

    2. Select the relevant permission list from the search dialog box.

    3. Select to the Web Services tab.

    4. Enter the corresponding Service(s) for the Service Operation(s) you want to use.

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

    Web Service Access page

  2. Activate Service Operation(s) and Create Routing(s) in CS 9.0:

    1. Navigate to select PeopleTools, then select Integration Broker, then select Integration Setup, then select Service Operations.

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

      PERSON_BASIC_SYNC service operation

    3. Check the Active check box on the General tab.

    4. Make note of the Queue Name field, as you will verify that the PERSON_DATA Queue is in Running status later.

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

      PERSON_BASIC_SYNC routings

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

      PERSON_BASIC_SYNC routing definition

    7. Verify that the Active check box is checked.

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

      PERSON_BASIC_SYNC routing parameters

    9. Enter External Alias = PERSON_BASIC_SYNC.VERSION_4.

    10. Enter Message.Ver into Transform 1 = PERSON_BASIC_SYNC.INTERNAL.

    11. Enter Transform Program = HMTF_TR_OA

    12. Enter Message.Ver out of Transforms = PERSON_BASIC_SYNC.VERSION_4.

    13. Click Save at the bottom of the Parameters page to save the routing.

    14. Click Return at the bottom of the Parameters page to return to the Service Operation setup page.

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

    Integration Broker Routing

  3. Activate Message Queue.

    1. Navigate to select PeopleTools, then select Integration Broker, then select Service Operations Monitor,, then select Administration, then select Queue Status.

    2. Scroll down the page until you find the relevant PERSON_DATA Queue Name.

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

      PERSON_DATA queue status

Configuring the Target Database HCM 9.1

  1. Update security by adding the service operation to the required user’s permission list.

    1. Navigate to select PeopleTools, then select Security, then select Permissions & Roles, then select Permission Lists.

    2. Select the relevant permission list from the search dialog box (primary permission list for the user).

    3. Select the Web Services tab.

    4. Enter the corresponding Service(s) for the Service Operation(s) you want to leverage.

    5. Click the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page.

    6. Click OK to return to the Web Services page.

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

    Web Service Permissions page PERSON_BASIC_SYNC

  2. Activate Service Operation(s) and Create Routing(s) and Subscription Handler in HCM 9.1:

    1. Navigate to select PeopleTools, then select Integration Broker, then select Integration Setup, then select Service Operations.

    2. Select PERSON_BASIC_SYNC from the search dialog box.

    3. Check the Active check box on the General tab.

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

      HCM 9.1 PERSON_BASIC_SYNC service operation

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

      HCM 9.1 PERSON_BASIC_SYNC handlers

      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

      HCM 9.1 SCC_HR_PERSON handler details

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

      HCM 9.1 PERSON_BASIC_SYNC routings

    7. Enter the CS 9.0 Sender Node and an HCM 9.1 Receiver Node on the Routings Definition page of the Routings component.

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

      HCM 9.1 PERSON_BASIC_SYNC routing definitions

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

      HCM 9.1 PERSON_BASIC_SYNC routing parameters

    10. Enter External Alias = PERSON_BASIC_SYNC.VERSION_4.

    11. Enter Message.Ver into Transform 1 = PERSON_BASIC_SYNC.VERSION_4.

    12. Enter Transform Program = HMTF_TR_IA.

    13. Enter Message.Ver out of Transforms = PERSON_BASIC_SYNC.INTERNAL.

    14. Click Save at the bottom of the Parameters page to save the routing.

    15. Click Return at the bottom of the Parameters page to return to the Service Operation setup page.

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

    HCM 9.1 PERSON_BASIC_SYNC routing graphic

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