Integrating Campus Solutions with Human Capital Management

This chapter provides an overview of Campus Solutions-to-Human Capital Management (CS-to-HCM) integration and discusses how to:

• Integrate person data.

• Integrate using External Search/Match.

• Integrate using the higher education constituent hub (HECH).

• Integrate setup data.

See Also

Campus Solutions-HCM Integration White Paper on My Oracle Support, ID 751540.1.http://support.oracle.com

Understanding CS-to-HCM Integration

The CS suite of products has historically resided in a single database instance with HCM. This coupling has enabled CS and HCM to share a person model, a single instance of a person in the system, and student refund processing through HR Payroll. The release of HCM 9.1 requires CS 9.0 and HCM to operate in separate instances. Separation is not mandatory until your institution upgrades to HCM 9.1; however, as of CS 9.0 Feature Pack 4, Oracle delivers the flexible toolset needed to integrate with a separated instance of HCM 9.0 as well as HCM 9.1. Whenever your institution decides to separate, its business processes will determine the proper way to integrate the separate instances; this chapter describes several possible integration approaches. Although the two databases will be separated, your institution still maintains the ability to search for people and maintain a single EmplID across CS and HCM.

Several implementation guides have been developed to assist in the integration effort. You can find them all posted to My Oracle Support.

See Implementing Integration of Setup Data between CS and HCM on My Oracle Support, ID 751540.1

See Implementing Person Bio-Demo Data Integration between CS and HCM on My Oracle Support, ID 751540.1

See Implementing External Search/Match between CS and HCM on My Oracle Support, ID 751540.1

See Implementing CS Integration with the Higher Education Constituent Hub on My Oracle Support, ID 751540.1

See Implementing Portal Navigation aggregation for CS and HCM Integration on My Oracle Support, ID 751540.1

Integrating Person Data

This section provides overviews of person data integration and business processes, and discusses how to:

• Publish and subscribe to person data.

• Review integrated person data.

Understanding Person Data Integration

In CS 9.0 Feature Pack 4, Oracle has 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.

The Implementing Person Bio-Demo Data Integration between CS and HCM guide provides the technical details of person data integration as well as configuration and messaging. It also provides details about subscription handlers and the global subrecords included in person data messaging.

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

See Also

Implementing Person Bio-Demo Data Integration between CS and HCM on My Oracle Support, ID 751540.1.

Understanding the Business Process

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

Campus Solutions supports three models of integration of person data between CS and HCM: Owner/Subscriber, 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.

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.

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.

Note. Oracle recommends that you set the installation option Last Employee ID Assigned field on the Last ID Assigned page to a range that does not cause conflicts in the two systems. The Implementing Person Bio-Demo Data Integration Between CS and HCM guide provides the configuration details for setting the Last Employee ID Assigned field in both systems.

No matter which model your institution uses to integrate CS and HCM, certain person data always passes from HCM 9.0/9.1 to CS 9.0; that list of data is discussed in the “Integrating Setup Data” section later in this chapter.

Note. For institutions choosing the owner-subscriber model, Oracle supports an architecture with CS 9.0 as the system of record (the owner of core person data for adds and updates) and HCM 9.0 or 9.1 as the subscriber. Oracle also recommends that HCM 9.0 or 9.1 become the system of record for setup data. The following sections provide more details on tools used to manage setup data as well as the owner-subscriber approach to managing data in separate database instances. For further information on other methods of using delivered tools to configure your integration, please refer to the Implementing Person Bio-Demo Data Integration Between CS and HCM guide on My Oracle Support.

See Also

Integrating Setup Data

Selecting General Installation Options

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

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

The Implementing Person Bio-Demo Data Integration between CS and HCM guide provides the technical details of moving person data between owner and subscriber.

Reviewing Integrated Person Data

In the owner/subscriber model, the following person bio-demo and other data is synchronized between the systems:

• Names

• Addresses

• Phones

• Email Addresses

• National IDs

• Gender

• Birthdate

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

• EmplID

• Names

• Addresses

• Phones

• Email Addresses

• National IDs

• FERPA Flag

• VA Benefit

The section on the HECH integration model lists the person data that is synchronized between systems.

See Integrating CS Data to HCM Using the HECH Connector.

Integrating Using External Search/Match

This section provides an overview of External Search/Match and discusses how to use External Search/Match to integrate with external systems.

Understanding External Search/Match Integration

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.

Using External Search/Match to Integrate with External Systems

External Search/Match can search against the HECH, HCM 9.0, or HCM 9.1 to identify potential duplicate person records as well as carry EmplIDs throughout a business process.

See Also

Setting Up External Search/Match

Using External Search/Match

Integrating Using the HECH

This section provides an overview of HECH integration and discusses how to integrate CS data to HCM using the HECH Connector.

Understanding HECH Integration

The HECH is a separately licensed product that manages bidirectional person data messaging and storage at the enterprise level, using broad data governance and data policy rules. When implemented, HECH becomes the single point of truth for person bio-demo data. HECH synchronizes this master data and transfers changes to all systems registered to it, by applying systemwide data validation policies set by your institution. The CS instance then becomes open to inbound information from other systems on campus.

Important! When using the HECH to integrate multiple systems, data is mastered in the hub itself but is actually manipulated and maintained in its “spoke” systems (such as CS). Messaging between the systems and the HECH is asynchronous. Only high-level data stewards can update or access person data within the HECH, for maintenance or troubleshooting purposes.

Oracle delivers the HECH Connector, a utility that assists with HECH integration by providing transformations and data mappings between CS and HECH, using Integration Broker. The HECH Connector contains Higher Ed Extensions for bio-demo data, affiliations, and External Search/Match. The Implementing CS Integration with the Higher Education Constituent Hub guide contains more information about the HECH, HECH Connector, and how to use these tools to manage bidirectional person data messaging.

See Also

Implementing CS Integration with the Higher Education Constituent Hub on My Oracle Support, ID 751540.1.

Setting Up External Search/Match

Integrating CS Data to HCM Using the HECH Connector

The HECH Connector enables CS to integrate core person data to a separated HCM instance, using Integration Broker messaging to communicate with the HECH. The HECH Connector integrates the following data:

• EmplID

• Name

• Address

• Phone

• Email address

• National ID

• VA benefit

• Marital status

• Education level

• Place of Death/Death Certificate Number

• Affiliations (outbound to HECH only)

See Also

Using Constituent Web Services

Integrating Setup Data

This section provides overviews of HCM-to-CS setup data and enterprise integration points (EIPs) for messaging between CS and HCM.

Understanding HCM-to-CS Setup Data

In all integration configurations, some setup data underlies all person transactions. This setup data needs to be synchronized between the HCM instance and CS 9.0. The following list of the data is integrated in one direction, from HCM to CS:

• Address Types

• National ID Types

• Ethnic Groups

• HCM Business Units

• Currency Codes

• Company Codes

• Major Subject Codes

• Country Codes

• State Codes

• Departments

• Holiday Date Schedules

• Job Codes

• Locations

• Name Titles

• Name Types

• Name Prefixes

• Name Royal Prefixes

• Name Royal Suffixes

• Name Suffixes

• Name Formats

• POI Types

• Regulatory Regions

• SetIDs

• TableSet Controls

• U.S. Standard Occupational Codes

• Visa Permit Types

• Visa Permit Documents

Understanding EIPs

Oracle delivers several EIPs to automate the process of synchronizing setup data between CS and HCM; this ensures that the setup data underlying the transactional data remains in sync. Other delivered EIPs enable your institution to integrate data in support of External Search/Match and core business processes. The Feature Pack 4 implementation guides contain detailed information on all delivered EIPs and web services. Note that person data EIPs are designated sync or fullsync. Fullsync EIPs republish all the data in their source records at once. Incremental sync EIPs send real-time sync messages; as soon as you make a change in the database of record, the system triggers the sync and sends only the changed information to the other database.

See Also

PeopleTools PeopleBook: Integration Broker Testing Utilities and Tools

Implementing Integration of Setup Data between CS and HCM on My Oracle Support, ID 751540.1.

Implementing Person Bio-Demo Data Integration between CS and HCM on My Oracle Support, ID 751540.1.

Implementing External Search/Match between CS and HCM on My Oracle Support, ID 751540.1.

Implementing CS Integration with the Higher Education Constituent Hub on My Oracle Support, ID 751540.1.

Implementing Portal Navigation aggregation for CS and HCM Integration on My Oracle Support, ID 751540.1.

Delivered EIPs

The following table lists delivered EIPs that support CS-to-HCM integration.