implementing external search match between cs and hcm

Implementing External Search Match between CS and HCM


November 2010

Including:

Overview of External Search Match for Direct HCM Integration and Integration to HECH

Step-by-Step Configuration and Setup Activities

Troubleshooting Tips and Techniques

PeopleSoft Integration Reference Guide


PeopleSoft Campus Solutions

Copyright 2010 Oracle, Inc. All rights reserved. Printed on Recycled Paper. Printed in the United States of America. Restricted Rights The information contained in this document is proprietary and confidential to PeopleSoft, Inc. Comments on this document can be submitted to Global Support Center. We encourage you provide feedback on this Integration Reference Guide and will ensure that it is updated based on feedback received. When you send information to Oracle, you grant Oracle a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of Oracle. This document is subject to change without notice, and Oracle does not warrant that the material contained in this document is error-free. If you find any problems with this document, please report them to PeopleSoft in writing. This material has not been submitted to any formal Oracle test and is published AS IS. It has not been the subject of rigorous review. Oracle assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by Oracle for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk Information in this book was developed in conjunction with use of the product specified, and is limited in application to those specific hardware and software products and levels. Oracles may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. PeopleSoft, PeopleTools, PS/nVision, PeopleCode, PeopleBooks, PeopleTalk, and Vantive are registered trademarks, and Pure Internet Architecture, Intelligent Context Manager, and The Real-Time Enterprise are trademarks of Oracle. All other company and product names may be trademarks of their respective owners. The information contained herein is subject to change without notice.

Copyright Oracle USA 2010. All rights reserved. Page 3 of 43


TABLE OF CONTENTS

Table of Contents 3

Chapter 1 - Introduction 4 Structure of this Document 4 Related Materials 4

Chapter 2 - Overview 5 Introduction 5 Who Should Read This Guide? 6 Before You Begin 6 Common Terms 6

Chapter 3 - External Search Match Distinct Ownership Model 8 Overview 8 Configuration and Set Up of External Search Match 8 EMPLID Management 10 Person data imported 10 External Search Match Services and Handlers 11

Chapter 4 - External Search Match Integrating with HECH 14 Overview 14 Configuration and Integration to the HECH 14 Search/Match and Fetch for Constituents in HECH 15 EMPLID Management 16 Person Data Searched and Imported 16 External Search Match Services and Message Transformations 23

Chapter 5: Configuring and Administering External Search Match Feature 27 Configure CS 9.0 and HCM 9.0/9.1 Integration Broker Settings 27 Configure External Search Match Services for Distinct Ownership 27 Configure External Search Match Services for HECH 32 Set up External Search Match Functionality 34

APPENDIX A CONFIGURING INTEGRATION BROKER GATEWAYS AND NODES 37

APPENDIX B - INTEGRATION BROKER TROUBLESHOOTING 42

APPENDIX C VALIDATION AND FEEDBACK 43

Customer Validation 43

Field Validation 43

APPENDIX D REVISION HISTORY 43 Authors 43 Revision History 43



CHAPTER 1 - INTRODUCTION

This Integration Guide is a practical guide for functional and technical users, installers, system administrators, and

programmers who implement, maintain, or develop applications for your PeopleSoft system. In this Integration Guide, we

discuss Person bio-demo data integrations between CS and HCM; this includes configuring and troubleshooting a PeopleSoft

Integration Broker environment. In this document, we discuss the functionality of External Search Match, its role in CS HCM integrations, and the necessary configuration steps required for using External Search Match with direct CS HCM integrations and with the Higher Education Constituent Hub (HECH).

Structure of this Document

This Integration Reference Guide provides guidance for the implementation of the Campus Solutions External Search Match

feature for the Direct Integration model for Campus Solutions Separation and for the implementation of the Campus Solutions

External Search Match feature for the Higher Education Constituent Hub (HECH). Keep in mind that Oracle updates this

document as needed so that it reflects the most current feedback we receive from the field. Therefore, the structure, headings,

content, and length of this document are likely to vary with each posted version. To see if the document has been updated since

you last downloaded it, compare the date of your version to the date of the version posted on My Oracle Support.

Related Materials

We recommend that before you read this guide, you read the Campus Solutions-HCM Integration White Paper. It provides an

overall summary of the objectives and various approaches to supporting separate CS and HCM instances.

In addition to this document, several implementation guides have been developed to assist you in understanding and

implementing your CS HCM integrations. These documents and the Campus Solutions-HCM Integration White Paper are posted to My Oracle Support, associated with Feature Pack 4 Documentation ( ID 1259484.1 ).

Implementing Person Bio-Demo Data Integration between CS and HCM on My Oracle Support

Implementing External Search/Match between CS and HCM on My Oracle Support (this document)

Implementing CS Integration with the Higher Education Constituent Hub on My Oracle Support (Note that this document will not be released until late 2010 or early 2011)

Implementing Portal Navigation Aggregation for CS and HCM Integration on My Oracle Support

We recommend that you also read the External Search Match PeopleBooks chapters to have a full understanding of our

External Search Match functionality. Note: Much of the information in this document will eventually be incorporated into

subsequent versions of the Campus Solutions PeopleBooks.

This document is not a general introduction to Integration Broker and we assume that our readers are experienced IT

professionals, with a good understanding of PeopleSofts Internet Architecture. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of system administration, basic Internet

architecture, integration technologies, relational database concepts/SQL, and how to use PeopleSoft applications.

This document is not intended to replace the documentation delivered with the PeopleTools 84x or 8.5x PeopleBooks. We

recommend that before you read this document, you also read the PIA related information in the PeopleTools PeopleBooks to

ensure that you have a well-rounded understanding of our PIA technology. Many of the fundamental concepts related to PIA

are discussed in the following PeopleSoft PeopleBooks:

PeopleSoft Internet Architecture Administration (PeopleTools|Administration Tools|PeopleSoft Internet

Architecture Administration)

Application Designer (Development Tools|Application Designer)

Application Messaging (Integration Tools|Application Messaging)

PeopleCode (Development Tools|PeopleCode Reference)

PeopleSoft Installation and Administration

PeopleSoft Hardware and Software Requirements



CHAPTER 2 - OVERVIEW

This chapter includes the following topics:

Introduction

Who Should Read This Guide?

Before You Begin

Common Terms

Introduction

The Campus Solutions 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. Oracle is supporting a set of integrations and enhanced External Search Match feature that will allow

search match functionality to work, in both directions, between separate CS and HCM instances.

Reference

Data

Transaction

Data

HCM 9.0/9.1 InstanceCS 9.0 Instance

The External Search Match feature extends core search match functionality to allow searches and fetches against an external

system. In Feature Pack 1, the external source was limited to a master data management hub. With Feature Pack 4, you can

define the external source as an instance of HCM 9.0 or 9.1, the Higher Education Constituent Hub (HECH) or any other

external system. This capability is also being delivered in HCM 9.1 so that you can identify CS as a source external to your

HCM instance. With the enhanced capability, you can search internally, externally or across both internal and external

instances.

The primary goal for External Search Match is to provide complete and meaningful lists of potential duplicate IDs in your

entire environment including IDs that reside outside of the CS database.

External Search Match capabilities include

Providing users the most complete and meaningful list of potential duplicate IDs

Standardizing the user experience so that it is similar whether the search is performed in CS or HCM, or against an external system

Enabling Campus Solutions customers to take full advantage of data hub search engines when the Higher Ed or Other External System option is selected.

Triggering both Internal HCM and External Search /Match at the same time with combined search results

Displaying search results composing from the external system whether the constituent has an EMPLID or not

Allowing users to import a record directly from the search results page into Campus Solutions when the match found does not have an existing PeopleSoft EMPLID



Providing a generic solution that can be integrated with any external system solution. Campus Solutions exposes search information through the Constituent Web Service Search and Fetch services.

Who Should Read This Guide?

For users implementing CS HCM integrations using External Search Match, administration refers to the process of implementing and setting up the integration of Campus Solutions and an external system or source using the administrative

features of Integration Broker and External Search Match features.

Typically, administrative users configure and administer the application. An administrative user can be either an Oracle

Consulting Services representative or the designated members of your implementation team who are familiar with Integration

Broker and your organizations business process requirements. This guide assumes at least that level of knowledge and describes how to implement PeopleSoft External Search Match for the two models of integration Distinct Ownership, and integration to the Higher Education Constituent Hub.

Before You Begin

Before you can setup, administer or use the PeopleSoft Campus Solutions External Search Match Integration, you must install

the external system or source and then set up \ configure the Integration Broker between the two applications for your

organization.

Some examples of the configuration tasks that they must perform for your Campus Solutions Instance Separation/Integrations

include:

Configuring the PeopleSoft CS and HCM installation and feature options tables.

Setting up the integration gateway and integration nodes within the Integration Broker system.

Activating services, service operations, and routings within the Integration Broker system.

Defining roles and permissions for your user profiles

Refer to Chapter 5: Configuring and Administering PeopleSoft Campus Solutions External Search Match Feature for detailed

information regarding the steps required to configure Campus Solutions 9.0 and HCM 9.0/9.1 Integration Broker settings, the

steps required to configure the External Search Match services and the functional setup within the Campus Solutions and HCM

products to define the External System and the External Search Match options used.

Common Terms

This table provides definitions for some of the common terms that are used in this guide.

Term Definition

SCC_SM_SEARCH External Search Match Web Service originally delivered in FP1 used for

Searching for people with the criteria specific in the search parameters and search

rule.

SCC_SM_FETCH External Search Match Web Service originally delivered in FP1 used for

Fetching/Importing person data

LOVs Seibel construct ( List of Values)

CWS Constituent Web Services designed to facilitate integration of the PeopleSoft CS



Term Definition

system with external systems. The services that comprise CWS can be divided

into two categories: the Sync services and the Search Match services.

Oracle Siebel Higher Education

Constituent Hub

Data Hub that allows institutions to capture, standardize and correct constituent

names and addresses, identify and merge duplicate records, enrich constituent

profiles, enforce compliance and risk policies, and distribute a best version record

to all subscribing systems

PBS The PERSON_BASIC_SYNC service used to facilitate core person data

integration.



CHAPTER 3 - EXTERNAL SEARCH MATCH DISTINCT OWNERSHIP MODEL

Overview

A key objective of the Distinct Ownership model of CS HCM integration is to provide Higher Education customers a data governance policy on campus that enforces strict separation of student and employee data and transactions.

Oracle plans to deliver integration that will support functionality equivalent to what is available in the existing combined

products. The Instance Separation initiative is a phased project and while not all of these requirements are completely realized

in the projects first phase, the guiding objectives are:

Assign one EMPLID per individual through time and across CS and HCM

Prevent duplicates

Synchronize core biographic data

Maintain distinct populations so that the respective CS and HRMS departments maintain control of the data for their population

Minimize impact on existing business processes.

Users of the Campus Solutions existing Search/Match feature are familiar with its ability to identify possible duplicate entries

in the Campus Solutions system based on criteria and parameters set by the institution. A user enters data to create a new

Person either in the Search/Match component or in the Add Person component with the Search/Match triggered at Save time.

When a possible duplicate or duplicates are identified, the records are displayed. If one of these records is identified as a match,

the user simply carries or fetches that persons data into the component or transaction.

External Search/Match, a feature first delivered in Campus Solutions Feature Pack 1, has been expanded and enhanced for the

Distinct Ownership model for Campus Solutions and HCM integration. The extension enables search match process flows

between separate instances of Campus Solutions and HCM. Customers can add and update core person data in either database,

and the search will be performed across both applications. Upon examination of the integrated results, if the user elects to

import a person record, then a single EMPLID is assigned in both instances via External Search/Match. This searching and

fetching is accomplished through the External Search Match web services and an External Search Match API within HCM.

Once the person data exists in both HCM and Campus Solutions databases no further synchronization of person data takes

place.

Configuration and Set Up of External Search Match

Implementing External Search Match requires setting an external system as the target of your search/match. This is

accomplished within Integration Broker, where the gateways and nodes for the Distinct Ownership CS/HCM database pair

need to be configured as well as setting up the services, SCC_SM_SEARCH and SCC_SM_FETCH, and handlers and

routings. In addition, you will need to define the External Core Data Integration system within both the CS and HCM

systems and also define the External Search/Match options. Refer to Chapter 5 below, Configuring and Administering PeopleSoft Campus Solutions External Search Match Feature for additional detailed information.



General Scenario of Search and Fetch Operation

Employee / Applicant External Search Match within Separate HCM instance

Serv

ices

HC

M E

xt

Searc

h M

atc

h

AP

I

Cam

pus

Adm

inis

trato

r

within

separa

te

CS

insta

nce

HR

MS

Adm

inis

trato

r

with s

epara

te

HC

M insta

nce

HR Hires a

new Employee

with unique

EMPLID

Campus

begins to

process a

person as an

Applicant

Administrator

uses traditional

Search/Match

parameters and

runs search

match on this

person

Search Request

gets published

from CS

HCM db

handler listens

to request

Searches HCM

db with passed

Search

Parameters

Fetches results

to form Search

Response

Search

Response gets

published

Administrator

reviews

results in

Integrated

Search

Results page

Administrator

decides to

Import person

via EMPLID

Fetch Request

service gets

published

Constituent

record via

EMPLID is

fetched.

Fetch

Response

service gets

published

Person is saved

in CS with same

EMPLID as that

in HRMS.

Fetch

Response

structure

populated

Figure 1 General Scenario of Search and Fetch Operation

1. HCM Admin creates a person as an employee with Workforce Administrator component with unique EMPLID.

2. CS Administrator has Applicant information but wants to determine first if the person exists in the MS system.

3. CS Administrator uses traditional Search/Match parameters and results codes and invokes External Search match against HCM database.

4. HCM API logic determines External Search/Match is active.

5. Constituent Management logic triggers the Search Request and populates it with the search data entered (First Name, Last Name, Gender and Date of birth).

6. HCM External System receives the Search Request and performs the search.

7. HCM External System finds matching candidates.

8. HCM External System populates the Search Response message with the matching candidates.

9. The Search Response is published to CS.

10. Constituent Management logic displays the search results in the Integrated Search Results page.

11. CS Administrator determines person in HCM is the same person

12. Person is Imported from HCM system



EMPLID Management

EMPLID is the unique identifier of individuals on campus. In a combined CS/HCM instance, both Campus Solutions and

HCM draw from the Last Employee ID Assigned field on the Installation table, managed on the Last ID Assigned page of the

Installation Table component (Set Up HRMS>Install>Installation Table). As individuals are added, the counter auto-

increments, ensuring that each individual has a unique EMPLID and no EMPLID is assigned more than once.

With the Distinct Ownership model, it is particularly important to ensure that EMPLIDs remain unique. Both systems will

have their own EMPLID counter that auto-increment as individuals are added. We recommend creating a business process

where Campus EMPLIDs contain one range of number and HCM EMPLIDs contain a separate range. This can be

accomplished by either dividing the range of numbers in half or by prefixing the EMPLIDs with an alpha string of characters

(HCM00001) to indicate the origin of the EMPLID.

In the event that two person records with the same EMPLID but for different individuals are identified in separate databases

during a search, an error message will be displayed indicating that the EMPLID is already in use. You will need to change one

of the EMPLIDs in order to import person data from one system into another.

Person data imported

The functionality of the External Search Match web services, SCC_SM_SEARCH and SCC_SM_FETCH, in the Distinct

Ownership model is identical to that delivered in Feature Pack 1. The Search operation is based on the long-standing search

parameters and search rules used in original search match utility. The Fetch operation of the Search/Match service imports the

following core bio-demo data to create/populate the new record in the searching system. The data elements returned in the

Fetch response message are displayed below.

SCC_SM_FETCH_RESP

SCC_SM_PRSN_VW

SM_TYPE

SCC_UID

EMPLID

SCC_SCORE

BIRTHDATE

BIRTHPLACE

BIRTHCOUNTRY

BIRTHSTATE

DT_OF_DEATH

SCC_SM_EMAIL_I

SCC_SM_PHONE_I

SCC_SM_NID_I

SCC_SM_NAME_TYP

SCC_SM_ADR_TYPE

SCC_SM_PDE_I

SM_TYPE

SCC_UID

EMPLID

EFFDT

MAR_STATUS

MAR_STATUS_DT

SEX

HIGHEST_EDUC_LVL

FT_STUDENT

LANG_CD

ALTER_EMPLID

SCC_SM_PERS_SA



SM_TYPE

SCC_UID

EMPLID

VA_BENEFIT

CAMPUS_ID

DEATH_CERTIF_NBR

FERPA

PLACE_OF_DEATH

SCC_SM_PRSN_USA

SM_TYPE

SCC_UID

EMPLID

EFFDT

US_WORK_ELIGIBILTY

MILITARY_STATUS

CITIZEN_PROOF1

CITIZEN_PROOF2

MEDICARE_ENTLD_DT

External Search Match Services and Handlers

External Search Match Services Used

External Search Match services are identical to the services provided in Feature Pack 1.

SCC_SM_SERVICE o Messages: Outbound SCC_SM_SERVICE_REQ

Inbound SCC_SM_SERVICE_RESP

SCC_SM_FETCH o Messages: Outbound SCC_SM_FETCH_REQ

Inbound SCC_SM_FETCH_RESP

External Search Match Handler Used

A dedicated set of handlers to address External Search Match integration for the Distinct Ownership model were

created to process the SCC_SM_SEARCH (Search request/response) and SCC_SM_FETCH (Fetch

request/response). The handlers will reside in the Subscriber database (HCM db), the handler will receive the

Search Request Service parse it and, in turn, invoke an Internal S/M against the HCM db. The handler will take the

search results to construct the Search Response Service and send it back to CS. Likewise, the Fetch Request

Response structure also gets processed on the HCM database. Upon receiving the results, the S/M API will invoke

the PBS handler to IMPORT the person into CS. In addition, if the system is configured for the HCM database to

also invoke External Search Match against the CS database, the handler is also installed in the CS database.

Application Package:

SCC_HR_INTEGRATION:Request_Handler

ProcessFetchRequest ProcessSearchRequest



Search Request Response

Search Request Response

Ext

erna

l S/M

API

HCM

Log

icCS A

dmin

Use

r

Create Person

Press SAVE or

SEARCH

Use External

Search/Match?

Search

Request

populated w/

Search data

YES

Use Internal

HCM Search/

Match?

NO

Search Requst

Message

Parsed

Internal HCM

S/M invoked

Search Results

Processed to

form Search

Response

Search

Response

Message

populated and

published

Yes

Return to

Search

Display

Details on

Integrated

Search Page

NO

Figure 2 Search Request Response



Fetch Request and Response

Fetch Request and Response

HC

M L

og

icE

xte

rna

l S

/M A

PI

CS

Ad

min

Us

er Admin presses

Detail link on

Integrate

Results page

User has access

privileges to view

results

Trigger Fetch

Request

populated with

EMPLID

Displays Details

inside Integrated

Search Results

page

Review Details

Press

RETURN

button

Admin

Presses

IMPORT

button

You are not

authorized for this

page

NO

YES

Fetch Request

Parsing

Personal Data

fetched for the

EMPLID

Fetch Response

structure simulated

and fed back to

Campus Solutions

External HCM

Integrated?

PBS Handler

invoked to Create

a person in CS.YES

NOTrigger Fetch

Request

populated with

EMPLID

Fetch Request

Parsing

Personal Data

fetched for the

EMPLID

Fetch Response

structure simulated

and fed back to

Campus Solutions

Constituent

Inbound Handler

Activated to create

a person in CS

Figure 3 Fetch Request and Response



CHAPTER 4 - EXTERNAL SEARCH MATCH INTEGRATING WITH HECH

Overview

The Higher Education Constituent Hub (HECH) is a master data management (MDM) solution for Oracle Higher Education

customers delivered in 2009. It takes the Person data input at the multiple points of entry/ update at your institution, federates

the multiple identities under a single universal ID, and publishes that data back out to your various systems under rules of data

governance defined by your institution and implemented within the HECH. In addition, the HECH provides data cleansing

capabilities such as standardizing address information, as well as duplicate record management and merging, privacy

management and other data quality services.

Of key importance in this integration model is that HECH becomes the single source of truth for core bio-demo data, which is

then shared, based on data governance rules. It publishes updates to subscribing systems, enabling a consistent person record

across all campus systems that need the data. The HECH is based on the Seibel UCM Master Data Management product that

has been tailored to the Higher Education industry with the addition of specific attributes such as support for Affiliations and

Effective dating.

The HECH is a separately licensed product and is not delivered as an inherent part of the CS-HCM integration solution set.

However, as part of the CS-HCM instance separation project Oracle plans to deliver a set of capabilities that we are calling the

HECH Connector. This connector provides out-of-the-box transformations, logic and web services that allow for significantly

faster and easier integration between Campus Solutions and the HECH. Institutions that anticipate a need for enterprise-wide

integration of multiple sources of Person data entry and maintenance are encouraged to find out more about the HECH on

Oracle.com.

Configuration and Integration to the HECH

HECH is intended as an enterprise MDM solution, and it is assumed that deployment is the result of a larger architectural

decision at your institution to centralize Person data management. Integration with the HECH requires the most complex

preparation and set up, primarily because HECH is a separate product, developed on the Siebel technology platform with a

different data model and set of services than those used in CS and HCM.

The Campus Solutions HECH Connector provides services, transformations and mappings between Campus Solutions and the

HECH; while it is not a turn-key solution it does significantly reduce the effort required to integrate the two systems prior to its

release.

The CS HECH Connector does not provide enhanced integration capability for HCM. It is delivered and supported as part of

Campus Solutions. Institutions wishing to integrate their HCM instance to the HECH will need to work with internal staff or

external service providers to create the appropriate services and transformations. Because of the similarities in Person data

objects and business processes between CS and HCM, the CS HECH Connector might be used as a design pattern for HCM-

HECH integration, but each institution will need to analyze that possibility based on individual requirements and goals.

Integration Flows between CS and HECH Applications

CS-to-HECH

Search/Match Flow

o Constituent Search and Match call from CS to HECH

Fetch Flow

o Constituent Fetch call from CS to HECH

Synchronization Flows

o Constituent Create call from CS to HECH

o Constituent Update call from CS to HECH

HECH-to CS

Publish Flows



o Constituent Create Publish call from HECH to CS

o Constituent Update Publish call from HECH to CS

Search/Match and Fetch for Constituents in HECH

Figure 4 Search/Match and Fetch for Constituents in HECH

The Search Match and Fetch process allows the user to search for constituents in the HECH and then either fetch the detailed

person information for additional review or import the constituent data directly into Campus Solutions. Both Search Match and

Fetch services are synchronous services. The External Search Match process is similar to the standard Search Match utility in

that once a user saves the person information for an ID, if External Search Match is enabled, the Constituent Web Services will

invoke the External Search Match operation with a request containing the Search Match parameters and rules associated with

the component data.

However, note that the fields Usage, Start Position, and Number of Characters in the Search Match rules will be ignored while

transforming the message into the HECH payload, as these fields have no mappings within HECH Search Match. HECH has

Fuzzy Match logic for partial matches.

The following steps explain the general flow of Search Match and Fetch operations

Search/Match:

1. User enters the person data in Campus Solutions component and clicks on the save button to save the component.

2. Upon invoking Save, the CWS will invoke the external Search Match (SCC_SM_SERVICE_SYNC) with the request containing Search Match parameters associated to the component and the component data.

3. Search Match request transformation app engine (SCC_SM_REQ) will transform the PeopleSoft rowset based message in to HECH Search Match payload.

4. HECH processes the request payload and sends the results found as a response. 5. Search Match response transformation app engine (SCC_SM_RES) will transform the HECH payload into

PeopleSoft rowset based message.

6. Results will be shown to the user in the Integrated Search Results page along with internal Search Match results if the Internal Search is selected as active.



7. User clicks on the Details link that corresponds to one of the external Search Match records after reviewing the basic information in the Integrated Search Results page.

Fetch:

8. CWS will invoke the Fetch service operation (SCC_SM_FETCH_SYNC) with the selected UID that is associated to the record.

9. Fetch request transformation app engine will transform the PeopleSoft rowset based message into a HECH payload

10. HECH process the request and returns the complete person details as a response 11. Fetch response transformation app engine will transform the HECH payload into PeopleSoft rowset based

message.

12. User reviews results displayed in the Details page. 13. User click on the button that corresponds to one of external Search Match records after reviewing the basic

information in the results page

14. A new person record will be created in campus solution and newly created EMPLID will be published to HECH through CWS outbound service operation. HECH will store the newly created EMPLID under external

constituent Ids of the constituent record

Deliverables:

Local to HECH routings for Search-Match and Fetch operations

Request and Response app engines for Search-Match and Fetch operations

EMPLID Management

The role of an MDM solution is to bring together all the information about a person across an enterprise and federate those

multiple identities into a single source of truth record. In the context of the HECH, the true unique identifier is the Universal

User ID (UUID) that defines the federated person record in the HECH hub and not, as has been customary, the EMPLID.

The HECH UUID is part of the Constituent Web Services message structure and is stored in Campus Solutions for cross-

referencing and accessing person records for updates in HECH. However, it is recognized that many institutions using Campus

Solutions and HCM have built significant processes around the use of EMPLID as the unique identifier.

In the initial release of Feature Pack 4, a Person created in one database, for example, HCM will be published to the HECH,

including the EMPLID. When adding a new Person in Campus Solutions, the user will search against the HECH. If a

corresponding record already exists, the user fetches that record into CS and creates a new Person record and hence a new CS

EMPLID for that individual. This new CS EMPLID is then published back to the HECH for federation into the larger HECH

Person record.

Campus Solutions is currently investigating the capability to retrieve an existing externally created EMPLID as part of the

Fetch and Import process. Additional information will be released as it becomes available.

Person Data Searched and Imported

An essential aspect of Person integration is ensuring that the data elements associated with Person information are

synchronized across the instances. Unlike the direct integration configuration, where data structures are identical, integration

to the HECH requires mapping to its structure. HECH has a similar structure called List of Values, but does not contain all the

data elements provided with CS or HCM. The Campus Solutions HECH Connector provides a mapping from the Campus

Solutions set up data values to the HECH LOVs.

The functionality of the External Search Match web services, SCC_SM_SEARCH and SCC_SM_FETCH, in the HECH model

is identical to that delivered in Feature Pack 1 for the data hub. The Search operation is based on the long-standing search

parameters and search rules used in the original search match utility. The Fetch operation of the Search/Match service imports

the following core bio-demo data to create/populate the new record in the searching system. The transformation layer maps the

CS data values to the HECH LOVs.



Note that the fields Usage, Start Position, and Number of Characters in the Search Match rules will be ignored while

transforming the message into the HECH payload as these fields have no mappings within HECH Search Match. HECH has

Fuzzy Match logic for partial matches.

Field/Attribute Mappings

PeopleSoft CS Fields HECH Integration Components HECH IC Fields Attributes

./SCC_CM_PERSON_I ListOfSwiPerson

./EMPLID Contact Id

./SCC_UID Contact PartyUId

Primary Name ID

Primary Student ID

Contact Constituent Type

/BIRTHDATE Contact BirthDate

./BIRTHPLACE

./BIRTHCOUNTRY

./BIRTHSTATE

Contact Primary Address

Contact Primary Contact Phone

Contact Primary Contact E-mail

Contact Primary Affiliation

Contact Ethnic Group Code

Contact Primary Ethnic Code (FK)

Contact Class Year

./DT_OF_DEATH Contact DeceasedDate

./SCC_PER_ADDR_I

EMPLID UCMHEConstituentAddress Id

./ADDRESS_TYPE UCMHEConstituentAddress HEAddressType

./EFFDT UCMHEConstituentAddress EffectiveStartDate

./EFF_STATUS UCMHEConstituentAddress Active Flag

./COUNTRY UCMHEConstituentAddress Country

./ADDRESS1 UCMHEConstituentAddress StreetAddress



./ADDRESS2 UCMHEConstituentAddress StreetAddress2



./CITY UCMHEConstituentAddress City

./NUM1

./NUM2

./HOUSE_TYPE

./ADDR_FIELD1

./ADDR_FIELD2

./ADDR_FIELD3

./COUNTY UCMHEConstituentAddress County

./STATE UCMHEConstituentAddress State

./POSTAL UCMHEConstituentAddress PostalCode

./GEO_CODE

./IN_CITY_LIMIT

./ADDRESS1_AC

./ADDRESS2_AC

./ADDRESS3_AC

./CITY_AC

./REG_REGION

./SCC_NAME_TYPE_I

./EMPLID

./NAME_TYPE

./SCC_ADDR_TYPE_I

./EMPLID

./ADDRESS_TYPE

./SCC_PER_PDE_I

./EMPLID Contact Id

./EFFDT



./MAR_STATUS Contact MaritalStatus

./MAR_STATUS_DT Contact MaritalStatusDate

./SEX Contact M/F

./HIGHEST_EDUC_LVL Contact Degree

./FT_STUDENT

./LANG_CD

./ALTER_EMPLID

./SCC_PER_NID_I

./EMPLID UCMHEConstituentIdentification Id

./COUNTRY UCMHEConstituentIdentification Country

./NATIONAL_ID_TYPE UCMHEConstituentIdentification NationalIDType

./NATIONAL_ID UCMHEConstituentIdentification NationalID

./SSN_KEY_FRA

./PRIMARY_NID UCMHEConstituentIdentification IsPrimaryMVG

./TAX_REF_ID_SGP

UCMHEConstituentIdentification State

UCMHEConstituentIdentification EffectiveStartDate

UCMHEConstituentIdentification EffectiveEndDate

./SCC_PER_PHONE_I

EMPLID Contact_Alternate Phone Id

./PHONE_TYPE Contact_Alternate Phone AlternatePhoneUseType

./COUNTRY_CODE

./PHONE Contact_Alternate Phone AlternatePhone

./EXTENSION

./PREF_PHONE_FLAG Contact_Alternate Phone IsPrimaryMVG

Contact_Alternate Phone EffectiveStartDate

Contact_Alternate Phone EffectiveEndDate

/SCC_PER_EMAIL_I

./EMPLID Contact_Communication Address Id



./E_ADDR_TYPE Contact_Communication Address CommunicationAddressUseType

./EMAIL_ADDR Contact_Communication Address AlternateEmailAddress

./PREF_EMAIL_FLAG Contact_Communication Address IsPrimaryMVG

Contact_Communication Address EffectiveStartDate

Contact_Communication Address EffectiveEndDate

./PERSON_SA

./EMPLID Contact Id

./VA_BENEFIT Contact VABenefits

./CAMPUS_ID

./DEATH_CERTIF_NBR Contact DeathCertNum

./FERPA

./PLACE_OF_DEATH Contact PlaceOfDeath

./SCC_PER_NAME_I

./EMPLID UCMHEConstituentName Id

./NAME_TYPE UCMHEConstituentName NameType

./EFFDT UCMHEConstituentName EffectiveStartDate

UCMHEConstituentName EffectiveEndDate

./EFF_STATUS UCMHEConstituentName Active Flag

./COUNTRY_NM_FORMAT UCMHEConstituentName CountryNameFormat

./NAME

./NAME_INITIALS UCMHEConstituentName M/M

./NAME_PREFIX

./NAME_SUFFIX UCMHEConstituentName Suffix

./NAME_ROYAL_PREFIX UCMHEConstituentName RoyalPrefix

./NAME_ROYAL_SUFFIX UCMHEConstituentName RoyalSuffix

./NAME_TITLE UCMHEConstituentName JobTitle

./LAST_NAME_SRCH UCMHEConstituentName LastName

./FIRST_NAME_SRCH UCMHEConstituentName FirstName

./LAST_NAME UCMHEConstituentName LastName



./FIRST_NAME UCMHEConstituentName FirstName

./MIDDLE_NAME UCMHEConstituentName MiddleName

./SECOND_LAST_NAME UCMHEConstituentName SecondLastName

./SECOND_LAST_SRCH UCMHEConstituentName SecondLastName

./NAME_AC

./PREF_FIRST_NAME UCMHEConstituentName PrefFirstName

./PARTNER_LAST_NAME

./PARTNER_ROY_PREFIX

./LAST_NAME_PREF_NLD

./NAME_DISPLAY

./NAME_FORMAL

./PSCAMA

./LANGUAGE_CD

./AUDIT_ACTN

./BASE_LANGUAGE_CD

./MSG_SEQ_FLG

./PROCESS_INSTANCE

./PUBLISH_RULE_ID

./MSGNODENAME

./SCC_AFL_PERSON

./EMPLID UCMHEConstituentAffiliation Id

./INSTITUTION UCMHEConstituentAffiliation Institution Id

./SCC_AFL_CODE UCMHEConstituentAffiliation AffiliationCode

./START_DT UCMHEConstituentAffiliation EffectiveStartDate

./SCC_AFL_SPONS_DEPT

./END_DT UCMHEConstituentAffiliation EffectiveEndDate

./LASTUPDOPRID UCMHEConstituentAffiliation Updated By

./LASTUPDDTTM UCMHEConstituentAffiliation Updated

./SCC_AFL_PLCD_MTD



./SCC_AFL_RLCD_MTD

./SCC_AFL_STATUS UCMHEConstituentAffiliation Status

./SCC_AFL_STS_DESCR UCMHEConstituentAffiliation StatusDescription

./SCC_AFL_RANK UCMHEConstituentAffiliation AffiliationRank

Domain Value Mappings

Domain value mappings are mapped with the Enterprise Components Application Integration Framework (ECAIF). For

example the Campus Solution address type DORM has to be mapped with Dormitory in HECH while transforming the rowset based message to HECH payload.

Navigation: Enterprise Components > Integration Definitions > Transformation Framework

The following ECAIF value maps are used in the transformation app engines to transform the Campus Solution data values to

HECH values and to transform HECH values to Campus Solutions data. The maps are comprised of two fields, CS_VALUE' and HECH_VALUE which store the Campus Solution data value and HECH value respectively.

CS_VALUE HECH_VALUE

SCC_ADDRESS_TYPE_MAP Address Type Map

SCC_AFFILIATION_STATUS_MAP Affiliation Status Map

SCC_AFFILIATION_TYPE_MAP Affiliation Type Map

SCC_COUNTRY_MAP Country Map

SCC_COUNTRY_RES_MAP Country Map for response

SCC_EMAIL_TYPE_MAP Email Type

SCC_GENDER_MAP Gender Map

SCC_HIGHEST_EDUC_LVL_MAP Highest Education level map

SCC_MARITAL_STATUS_MAP Marital Status Map

SCC_NAME_TYPE_MAP Name Type Map

SCC_NATIONAL_ID_TYPE_MAP National Type Map

SCC_PHONE_TYPE_MAP Phone Type Map

SCC_PREFIX_MAP Prefix Map

SCC_STATE_MAP State Map

SCC_STATE_RES_MAP State Map for Response

SCC_SUFFIX_MAP Suffix Map



External Search Match Services and Message Transformations

From the Campus Solutions side, the integration with the HECH revolves around three main services:

SCC_SM_SEARCH and SCC_SM_FETCH: The business process for the CS HECH add/update Person transactions uses External Search/Match to manage the potential entry of duplicates into Campus Solutions by searching against

the HECH population, and fetching data for records that are deemed to be a match. As such, the use of the External

Search/Match package of services is instrumental to a successful interaction between Campus Solutions and HECH.

CONSTITUENT WEB SERVICE: Constituent Web Services (CWS) was first delivered in Campus Solutions Feature Pack 1 as a way to expose Campus Solutions Person data in a service oriented architecture. The CWS essentially

subscribes to the PERSON_BASIC_SYNC message that is published from all relevant HCM and CS Person pages,

enriches it with the attributes of the PERSON_SA record, further enriches it with Affiliations data (also released as

part of Feature Pack 1) and exposes it as a set of service operations. In the CS HECH integration architecture, CWS is

the service by which Campus Solutions Person data is exposed and published to the HECH. For more information on

CWS, please see Feature Pack 1 Documentation on My Oracle Support, associated with ID 844587.1

PERSON_BASIC_SYNC: PERSON_BASIC_SYNC (PBs) has been the primary mechanism within HCM and CS by which Person information has been published to external and internal consumers. Previously, the PBS payload had

been constrained to the core Person data record set. With the CS-HCM Instance Separation project, a new version of

the PBS web service (PERSON_BASIC_SYNC.v4) has been delivered that includes global subrecords as well as the

attributes found on the PERSON_SA record. In addition, new subscription handlers have been delivered that allow

for a broader range of inbound add/update operations on the Person records. In the context of the CS HECH

integration, PBS is used as the inbound handler for data coming from the HECH. The broader existing capabilities of

PBS along with the expanded data set precluded the use of CWS as the inbound mechanism. For example, if CWS

were used, since there is no inbound Affiliations data, CWS would subscribe to the inbound data from the HECH,

stripping out the (non-existent) Affiliations payload before passing it on to the PBS service as part of its normal

transaction. The use of PBS directly (especially with the inclusion of PERSON_SA attributes) removes the additional

overhead of the transform from CWS to PBS.

Search/Match Request Message Transformation:

SCC_SM_REQ- App Engine

Step 01: Transform CWS to HECH

For each rule is mapped to one 'Contact' XML element in HECH request.

Transformation adds one extra 'Contact' XML element with the data in all the rules for fuzzy match.

Fuzzy match 'Contact' element contains the highest match order number. So fuzzy match happens only when all the other rules unable to fetch the results.



Figure 5

Search/Match Response Message Transformation:

SCC_SM_RES:

Step 01: Transform HECH to CWS

CS Search-Match results page can show only one type of child entity. I.e. Only one email.

Search-Match response takes only primary records form the child elements from the HECH payload (ex. Names, email, etc).

If there is no primary element in a list of child elements, then the transformation takes the first row.



Figure 6

Fetch Request Message Transformation:

SCC_FET_REQ:

Step 01: Get the Default local node

Default local node will be added to the payload and it will be used as 'External system id' in HECH

payload.

Step 02: Transform CWS to HECH

Figure 7

Fetch Response Message Transformation:

SCC_FET_RES:



Step 01: Remove SOAP tags

In this step XML payload will be extracted from the SOAP envelope.

Step 02: Add extra data needed for transformation

Add the current date to the payload for transformation in the next steps.

Step 03: Call SCC_HECH_CWS

Call Section: SCC_HECH_CWS (Person to Contact common transformation)

Step 04: Change the tag names

SCC_HECH_CWS app engine transforms the HECH payload into 'SCC_CONSTITUENT_IN_SYNC_DS'

structure.

SCC_CONSTITUENT_IN_SYNC_DS will be transformed to SCC_SM_FETCH_RESP structure. Since

AddPerson in CS does not allow future dated rows while creating the person, all future dated names, and addresses

will be removed from the payload in this step.



CHAPTER 5: CONFIGURING AND ADMINISTERING EXTERNAL SEARCH MATCH

FEATURE

This chapter discusses how to configure and administer External Search Match feature for your system. It provides an

overview of the Integration Broker system and discusses the following topics:

Configure CS 9.0 and HCM 9.0/9.1 Integration Broker Settings.

Configure External Search Match Services.

For Distinct Ownership Model

For HECH Integration Model

Set up External System and External Search Match Options.

Configure CS 9.0 and HCM 9.0/9.1 Integration Broker Settings

Your CS and HCM systems must have appropriate connectivity established before you configure any of the External

Search/Match features.

Please refer to Appendix A of this document for the appropriate steps to configure Integration Broker Gateways and Nodes in

your CS and HCM systems.

Configure External Search Match Services for Distinct Ownership

Perform the following steps to configure and activate the External Search Match service operations. You will configure the

same service operations in both your CS 9.0 and HCM 9.0 systems.

Activate and Configure Services in CS 9.0

1. Activate the Search Service SCC_SM_SERVICE

a. Logon to the Campus Solutions 9.0 Database

b. Navigate to: Integration Broker > Integration Setup > Services SCC_SM_SERVICE

c. Search

d. Click on the link for the Operation.Default Version SCC_SM_SERVICE_SYNC

e. Make sure that the Active check box is checked.

2. Setup the Handler for SCC_SM_SERVICE

a. Click on the Handlers Tab

b. Name = REQUESTHDLR

c. Type = OnRequest

d. Implementation = Application Class

e. Status = Active



f. Click on the Details link

g. Description = Search Request Handler

h. Package Name = SCC_HR_INTEGRATION

i. Path = Request_Handler

j. ClassID = ProcessMatchRequest

k. Method = OnRequest

l. Click OK

3. Setup the Routings for SCC_SM_SERVICE

a. Click on the Routings Tab

b. Enter Outbound Routing

c. Enter the Routing Name i.e. SCC_SM_Request_to_HR

d. Description = Search Request to HR db

e. Sender Node = CS90ESM ( CS 9.0 database name)

f. Receiver Node = HR91ESM (HR 9.1 database name)

g. Log Detail = Header and Detail

h. Save

i. Return

j. Validate that Status is Active and Direction is Outbound within Grid for Routing Name SCC_SM_Request_to_HR

k. Enter Inbound Routing

l. Enter the Routing Name i.e. SCC_SM_Resp_from_HR

m. Description = Search Response from HR db

n. Sender Node = HR91ESM ( HR 9.1 database name)

o. Receiver Node = CS90ESM ( CS 9.0 database name)

p. Log Detail = Header and Detail

q. Save

r. Return

s. Validate that Status is Active and Direction is Inbound within Grid for Routing Name SCC_SM_Resp_from_HR

t. Save

4. Activate the Fetch Service SCC_SM_FETCH

a. Navigate to: Integration Broker > Integration Setup > Services SCC_SM_FETCH

b. Search

c. Click on the link for the Operation.Default Version SCC_SM_FETCH_SYNC



d. Make sure that the Active check box is checked.

5. Setup the Handler for SCC_SM_FETCH



c. Type = OnRequest


e. Status = Active


g. Description = Request Handler



j. ClassID = ProcessFetchRequest


l. Click OK

6. Setup the Routings for SCC_SM_FETCH


b. Define the Outbound Routing

c. Enter the Routing Name i.e. SCC_SM_FETCH_REQ_to_HR

d. Description = Fetch Request to HR db




h. Save

i. Return

j. Validate that Status is Active and Direction is Outbound within Grid for Routing Name SCC_SM_FETCH_REQ_to_HR

k. Define Inbound Routing

l. Enter the Routing Name i.e. SCC_SM_FETCH_RESP_from_HR

m. Description = Fetch Response from HR db




q. Save

r. Return

s. Validate that Status is Active and Direction is Inbound within Grid for



Routing Name SCC_SM_FETCH_RESP_from_HR

t. Save

Setup the External SM Search Service in HCM 9.0 database


a. Logon to the HCM 9.0 Database


c. Search



8. Setup the Handler for SCC_SM_SERVICE



c. Type = OnRequest


e. Status = Active


g. Description = Search Request Handler



j. ClassID = ProcessMatchRequest


l. Click OK

9. Setup the Routings for SCC_SM_SERVICE for HR database


b. Enter Outbound Routing

c. Enter the Routing Name i.e. SCC_SM_Request_to_CS

d. Description = Search Request from CS db




h. Save

i. Return

j. Validate that Status is Active and Direction is Outbound within Grid for Routing Name



SCC_SM_Request_to_CS

k. Enter Inbound Routing

l. Enter the Routing Name i.e. SCC_SM_RESP_From_CS

m. Description = Search Response to CS db




q. Save

r. Return

s. Validate that Status is Active and Direction is Inbound within Grid for Routing Name SCC_SM_RESP_From_CS

t. Save



b. Search



11. Setup the Handler for SCC_SM_FETCH



c. Type = OnRequest


e. Status = Active


g. Description = Request Handler



j. ClassID = ProcessFetchRequest


l. Click OK

12. Setup the Routings for SCC_SM_FETCH


b. Define the Outbound Routing



c. Enter the Routing Name i.e. SCC_SM_FETCH_REQ_to_CS

d. Description = Fetch Request to CS db

e. Sender Node = HR91ESM ( HR 9.1 database name)

f. Receiver Node = CS90ESM (CS 9.0 database name)


h. Save

i. Return

j. Validate that Status is Active and Direction is Outbound within Grid for Routing Name SCC_SM_FETCH_REQ_to_CS

k. Define Inbound Routing

l. Enter the Routing Name i.e. SCC_SM_FETCH_RESP_from_CS

m. Description = Fetch Response from CS db

n. Sender Node = CS90ESM ( CS 9.0 database name)

o. Receiver Node = HR91ESM ( HR 9.1 database name)


q. Save

r. Return

s. Validate that Status is Active and Direction is Inbound within Grid for Routing Name SCC_SM_FETCH_RESP_from_CS

t. Save

Configure External Search Match Services for HECH

Setup the External SM Search Service for the Campus Solutions database


a. Logon to the Campus Solutions 9.0 Database


c. Search



2. Configure and activate the Routings for SCC_SM_SERVICE


b. Click on the Routing Name i.e. SCC_SM_SERVICE from the existing routings



c. Navigate to Connector Properties Tab

d. Set the value for PRIMARY URL property in the Connector Properties Grid. Replace the http://hostname:port/targetwebserviceurl value with the hosted HECH Web Service endpoint url

e. Save

f. Return

g. Select the check box for the Routing Name i.e. SCC_SM_SERVICE from the existing routings

h. Click on Activate Selected Routings button

i. Validate that Status is Active and Direction is Outbound within Grid for Routing Name SCC_SM_SERVICE



b. Search



4. Configure and activate the Routings for SCC_SM_FETCH for CS 9.0

database

a. Click on the Routing Name i.e. SCC_SM_FETCH from the existing routings

b. Navigate to Connector Properties Tab

c. Set the value for PRIMARY URL property in the Connector Properties Grid. Replace the http://hostname:port/targetwebserviceurl value with the hosted HECH Web Service endpoint url

d. Save

e. Return

f. Select the check box for the Routing Name i.e. SCC_SM_FETCH from the existing routings

g. Click on Activate Selected Routings button

h. Validate that Status is Active and Direction is Outbound within Grid for Routing Name SCC_SM_SERVICE

Configure Domain Value Mappings for HECH Integration Model

Domain value mappings are mapped with the PeopleSoft Enterprise Components Application Integration Framework (ECAIF).

For example, the CS address type DORM needs to be mapped with Dormitory in HECH while transforming the rowset based message to HECH payload.



Navigation: Enterprise Components > Integration Definitions > Transformation Framework

The following ECAIF value maps are used in the transformation app engines to transform the Campus Solution data values to

HECH values and to transform HECH values to Campus Solutions data. The maps are comprised of two fields, CS_VALUE' and HECH_VALUE which store the Campus solution data values and HECH values respectively.

CS_VALUE HECH_VALUE

SCC_ADDRESS_TYPE_MAP Address Type Map

SCC_AFFILIATION_STATUS_MAP Affiliation Status Map

SCC_AFFILIATION_TYPE_MAP Affiliation Type Map

SCC_COUNTRY_MAP Country Map

SCC_COUNTRY_RES_MAP Country Map for response

SCC_EMAIL_TYPE_MAP Email Type

SCC_GENDER_MAP Gender Map

SCC_HIGHEST_EDUC_LVL_MAP Highest Education level map

SCC_MARITAL_STATUS_MAP Marital Status Map

SCC_NAME_TYPE_MAP Name Type Map

SCC_NATIONAL_ID_TYPE_MAP National Type Map

SCC_PHONE_TYPE_MAP Phone Type Map

SCC_PREFIX_MAP Prefix Map

SCC_STATE_MAP State Map

SCC_STATE_RES_MAP State Map for Response

SCC_SUFFIX_MAP Suffix Map

Set up External Search Match Functionality

This section details the basic steps required to implement External Search Match functionality

Specify the external system installed for External Core Data Integration

Define the External Search Match options.

Defining the External System

The External System is the source of the external core date. With the evolution of the External Search Match feature to

integrate the Campus Solution product with various external systems, the External Core Data Integration page is used to

indicate IF an external system is integrated and to select specifically WHICH external system is installed. Only one external

system can be integrated with respect to External Search Match.

Navigation: Set Up SACR > Install > External Core Data Integration



Figure 8

The checkbox identifying whether an external system is installed is evaluated upon bio-demo and search/match component

save times to determine whether the system should invoke the standard Search/Match utility or the External Search Match

utility.

The specific external system drop-down field is examined to determine the appropriate branch of the Ext S/M program

interface to invoke.

HCM installed as Third party select to indicate that CS and HCM system are in separate instances and the administrative user has distinguished the HCM system as an External system with direct integration to it. The EXT

S/M API invokes the handler for the HCM system. When implementing External Search/Match for the Direct

Ownership model, you specify the HCM instance as the installed external system within the Campus Solutions system

and then within the HCM instance you would specify that an HCM system is installed as an External system. The

services do not distinguish between CS 9.0, HCM 9.0 or HCM 9.1.

Higher Ed Constituent Hub select to indicate that the administrative user has distinguished the Oracle Higher Ed Constituent Hub (HECH) data hub as the External System with direct integration to it from Campus Solutions. The

Ext S/M API invokes the handler for the HECH system based on this selection.

Other External System Select to indicate that an external system other than an HCM system or HECH data hub has been integrated to CS. This could potentially be another third-party data hub. The Ext S/M API invokes the handler

for the target External System.

More information on this set up can be found in the PeopleSoft Enterprise Campus Community Fundamentals 9.0 PeopleBook

chapter Setting Up External Search/Match.

Defining the External Search Match Options

The External System Search Match Options page is used to configure the system to use the Search/Match utility, the External

Search/Match utility or both when adding a new person or saving an updated bio/demo page.

Navigation: Set Up SACR > System Administration > Utilities > Search/match > Search match with External Sys



Figure 9

Upon identifying that an external system is integrated, the system evaluates the external search match options and determines

whether to perform the search match within the CS database and/or within the external system. If the system determines that

an external search should occur, then it generates the appropriate outbound search request (Scc_Sm_Search) for that external

system. The search request contains all information specified within the search criteria (Search Parameter and Search Rule).

More information on this set up can be found in the PeopleSoft Enterprise Campus Community Fundamentals 9.0 PeopleBook

chapter Setting Up External Search/Match.



Appendix A Configuring Integration Broker Gateways and Nodes

This appendix describes the steps to configure the Integration Broker Gateways and Nodes in your CS and HCM databases.

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

to be modified to match the appropriate CS 9.0 and HCM 9.1 environments. Steps use the following example database names:

i.e. CS90ESM, i.e. HCM91ESM

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

5. Configure the CS node in the HCM 9.1 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 9.1 database

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

10. Update the Single Sigonon nodes.

11. Testing Nodes

1. Setting the Service Configuration in the HCM 9.1 database

a. Navigate: PeopleTools > Integration Broker > Configuration > Service Configuration.

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

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

d. Set Target Location = http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector (URL from HCM database)

e. Set Service System Status = 'Production'.

f. Save

2. Configure the Gateway in the HCM 9.1 database

a. Navigate: PeopleTools > Integration Broker > Configuration > Gateways.

b. Select Integration Gateway ID = 'LOCAL'

c. Set URL = http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector' (URL from HCM database)

d. Click the 'Load Gateway Connectors' button. It should load 9 connectors.

e. Save.

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

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



a. Navigate: PeopleTools > Integration Broker > Integration Setup > Nodes.

b. Select the default local node:

c. Set Descr = 'HCM 9.1 Instance'.

d. Set Authentication Option = 'Password'.

e. Node Password = 'PS'.

f. Default User ID = 'PS'.

g. Click the 'Connectors' tab.

h. Use gateway ' LOCAL'.

i. Set Connector Id = 'PSFTTARGET'.

j. Click the Portal tab.

k. Set Tools Release = '8.50.xx'. (Note: by pressing the +J keys, you should be able to see the tools release string.

l. Set Application Release = 'HCM 9.1'.

m. Set Content URI Text = ' http://machinename:port/psc/HCM91ESM'. (psc for content)

n. Set Portal URI Text = ' http://machinename:port/psp/HCM91ESM'. (psp for portal)

o. Click the WS Security tab.

p. Set Authentication Token Type = 'none'.

q. Disable the 'encrypted' checkbox.

r. Click Save

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

a. Navigate: PeopleTools > Integration Broker > Configuration > Gateways

b. Add a New Value

c. Integration Gateway ID = .

d. URL = http://machinename:port/PSIGW/PeopleSoftListeningConnector/HCM91ESM'

e. Click the 'Load Gateway Connectors' button. It should load 9 connectors.

f. Save.

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

5. Configure the CS node in the HCM database

a. Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes.

b. Add Node =

c. Set Descr = CS 9.0 Instance'.

d. Set Authentication Option = 'Password'.

e. Node Password = 'PS'



f. Default User ID = 'PS'

g. Click the 'Connectors' tab

h. Set Gateway = ' LOCAL'

i. Set Connector ID = 'PSFTTARGET'

j. Click the Portal tab

k. Set Tools Release = '8.50.xx (Note: by pressing the +J keys, you should be able to see the tools release string)

l. Set Application Release = 'CS 9.0'.

m. Set Content URI Text = 'http://machinename:port/psc/CS_databasename'

n. Set Portal URI Text = 'http://machinename:port/psp/CS_databasename'.



q. Disable the 'Encrypted' checkbox.

r. Click Save.

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

a. Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes

b. Select the default local node:

c. Set Descr = CS 9.0 Instance'.

d. Set Authentication Option = 'Password'




h. Select Gateway = (Note: this is not the local gateway.)



k. Set Tools Release = '8.50.xx. (Note: by pressing the +J keys, you should be able to see the tools release string.

l. Set Application Release = 'CS 9.0'.

m. Set Content URI Text = ' http://machinename:port/psc/CS_databasename

n. Set Portal URI Text = ' http://machinename:port /psp/CS_databasename



q. Disable the 'encrypted' checkbox.

r. Click Save.



7. Configure the HCM node in the CS database

[Note that each node is defined twice: once in each database. They should all use the same gateway.]

a. Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes.

b. Add Node:

c. Set Descr = HCM 9.1 Instance'

d. Set Authentication Option = 'Password'




h. Gateway ID = (Note: this is not the local gateway.)



k. Set Tools Release = '8.50.xx'. (Note: by pressing the +J keys in the HCM database PIA, you should be able to see the tools release string.

l. Set Application Release = HCM 9.1

m. Set Content URI Text = ' http://machinename:port/psc/HCM_databasename

n. Set Portal URI Text = ' http://machinename:port/psp/HCM_databasename



q. Disable (turn off) the Encrypted checkbox.

r. Click Save.

s. Node Saved message box. Click OK.

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


b. Select gateway 'LOCAL'.

c. Select the 'Gateway Setup Properties' link.

d. User ID = administrator

e. Password = password

f. Click OK.

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

h. Enter the appropriate User ID



i. Enter the appropriate Password

j. Set the tools release = '8.50.xx'. (Note: by pressing the +J keys, you should be able to see the tools release string.)

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

l. Ping the HCM node. It should be successful.

m. Click return.

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


b. Select gateway 'HCM Gateway'.

c. Select the 'Gateway Setup Properties' link.

d. User ID = administrator

e. Password = password

f. Click OK.

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

h. Enter the appropriate User ID

i. Enter the appropriate Password

j. Set the tools release = '8.50.xx'. (Note: by pressing the +J keys, you should be able to see the tools release string.)

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

l. Ping the HCM node. It should be successful.

m. Ping the CS node. It should be successful.

n. Click return.

10. Update the Single Signon nodes in both CS and HCM databases

Single signon is used in this recommended configuration.

a. Navigate: PeopleTools > Security > Security Objects > Single Signon.

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

a. Navigate: PeopleTools > Integration Broker > Service Operations Monitor > Administration> Node Status. Do this on each database.

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

c. It should respond with 'Success'.



Appendix B - Integration Broker Troubleshooting

This chapter includes some basic troubleshooting techniques and is for reference only.

Error Messages Encountered and Possible Solutions

Message: You do not have security access to complete transaction.

Occurs: When trying to add or search for a person using External Search Match.

Possible Reason:

1. Validate that Domain is active. 2. Validate that Node should be active. 3. Validate that Routings are active 4. Validate that Handler exist 5. Incorrect Gateway URL defined on Message Node.



Appendix C Validation and Feedback

This section documents that real-world validation that this Integration Reference Guide has received.

CUSTOMER VALIDATION

PeopleSoft is working with PeopleSoft customers to get feedback and validation on this document. Lessons learned from these

customer experiences will be posted here.

FIELD VALIDATION

PeopleSoft Consulting has provided feedback and validation on this document. Additional lessons learned from field

experience will be posted here.

Appendix D Revision History

Authors

PeopleSoft Campus Solutions Development Team

Revision History

November 2010 - Created document.

implementing external search match between cs and hcm

Documents