Implementing External Search Match Between CS and HCM

Implementing External Search Match between CS and HCM
PeopleSoft Integration Reference Guide

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 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.
TABLE OF CONTENTS
Table of Contents
Chapter 1 - Introduction
Structure of this Document
Related Materials
4
4
4
Chapter 2 - Overview
Introduction
Who Should Read This Guide?
Before You Begin
Common Terms
5
5
6
6
6
Chapter 3 - External Search Match Distinct Ownership Model

Overview
Configuration and Set Up of External Search Match
EMPLID Management
Person data imported
External Search Match Services and Handlers
8
8
8
10
10
11
Chapter 4 - External Search Match Integrating with HECH

Overview
Configuration and Integration to the HECH
Search/Match and Fetch for Constituents in HECH
EMPLID Management
Person Data Searched and Imported
External Search Match Services and Message Transformations
14
14
14
15
16
16
23
Chapter 5: Configuring and Administering External Search Match Feature

Configure CS 9.0 and HCM 9.0/9.1 Integration Broker Settings
Configure External Search Match Services for Distinct Ownership
Configure External Search Match Services for HECH
Set up External Search Match Functionality
27
27
27
32
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

Authors
Revision History
43
43
43
Copyright Oracle USA 2010. All rights reserved.
Page 3 of 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
Page 4 of 43
CHAPTER 2 - OVERVIEW
This chapter includes the following topics:
Introduction
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.
CS 9.0 Instance
HCM 9.0/9.1 Instance
Reference
Data
Transaction
Data
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
Page 5 of 43
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.

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
Page 6 of 43
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.
Page 7 of 43
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.
Page 8 of 43
General Scenario of Search and Fetch Operation
HCM db
handler listens
to request
Search Request
gets published
from CS
Campus
Administrator
within separate
CS instance
HCM Ext
Search Match
API
HR Hires a
new Employee
with unique
EMPLID
Services
HRMS
Administrator
with separate
HCM instance
Employee / Applicant External Search Match within Separate HCM instance
Campus
begins to
process a
person as an
Applicant
Searches HCM
db with passed
Search
Parameters
Administrator
uses traditional
Search/Match
parameters and
runs search
match on this
person
Constituent
record via
EMPLID is
fetched.
Fetch
Response
structure
populated
Search
Response gets
published
Fetch Request
service gets
published
Fetch
Response
service gets
published
Administrator
reviews
results in
Integrated
Search
Results page
Administrator
decides to
Import person
via EMPLID
Fetches results
to form Search
Response
Person is saved
in CS with same
EMPLID as that
in HRMS.
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
Page 9 of 43
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 autoincrements, 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
Page 10 of 43

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
Page 11 of 43
Search Request Response
HCM Logic
External S/M API
CS Admin User
Search Request Response
Return to
Search
Create Person
Press SAVE or
SEARCH
Use External
Search/Match?
NO
Use Internal
HCM Search/
Match?
NO
Display
Details on
Integrated
Search Page
Yes
YES
Search
Request
populated w/
Search data
Search Requst
Message
Parsed
Internal HCM
S/M invoked
Search Results
Processed to
form Search
Response
Search
Response
Message
populated and
published
Figure 2 Search Request Response
Page 12 of 43
Fetch Request and Response
HCM Logic
External S/M API
CS Admin User
Fetch Request and Response

Press
RETURN
button
Admin presses
Detail link on
Integrate
Results page
Review Details
You are not

authorized for this
page
User has access

privileges to view
results
YES
NO
Trigger Fetch
Request
populated with
EMPLID
Displays Details
inside Integrated
Search Results
page
Trigger Fetch
Request
populated with
EMPLID
External HCM
Integrated?
YES
Fetch Request
Parsing
Fetch Request
Parsing
Personal Data
fetched for the
EMPLID
Admin
Presses
IMPORT
button
Fetch Response
structure simulated
and fed back to
Campus Solutions
Personal Data
fetched for the
EMPLID
NO
Constituent
Inbound Handler
Activated to create
a person in CS
PBS Handler
invoked to Create
a person in CS.
Fetch Response
structure simulated
and fed back to
Campus Solutions
Figure 3 Fetch Request and Response
Page 13 of 43
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 HCMHECH 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
Fetch Flow
o
Constituent Search and Match call from CS to HECH

Constituent Fetch call from CS to HECH
Synchronization Flows
o
Constituent Create call from CS to HECH
Constituent Update call from CS to HECH
HECH-to CS
Publish Flows
Page 14 of 43

o
Constituent Create Publish call from HECH to CS
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.
2.
3.
4.
5.
6.
User enters the person data in Campus Solutions component and clicks on the save button to save the
component.
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.
Search Match request transformation app engine (SCC_SM_REQ) will transform the PeopleSoft rowset based
message in to HECH Search Match payload.
HECH processes the request payload and sends the results found as a response.
Search Match response transformation app engine (SCC_SM_RES) will transform the HECH payload into
PeopleSoft rowset based message.
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.
Page 15 of 43

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.
8.
CWS will invoke the Fetch service operation (SCC_SM_FETCH_SYNC) with the selected UID that is
associated to the record.
Fetch request transformation app engine will transform the PeopleSoft rowset based message into a HECH
payload
HECH process the request and returns the complete person details as a response
Fetch response transformation app engine will transform the HECH payload into PeopleSoft rowset based
message.
User reviews results displayed in the Details page.
User click on the button that corresponds to one of external Search Match records after reviewing the basic
information in the results page
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
Fetch:
9.
10.
11.
12.
13.
14.
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 crossreferencing 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.
Page 16 of 43

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
./SCC_CM_PERSON_I
ListOfSwiPerson
./EMPLID
Contact
Id
./SCC_UID
Contact
PartyUId
Attributes
Primary Name ID
Primary Student ID
Contact
Constituent Type
Contact
BirthDate
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
Contact
DeceasedDate
EMPLID
UCMHEConstituentAddress
Id
./ADDRESS_TYPE
HEAddressType
./EFFDT
EffectiveStartDate
./EFF_STATUS
Active Flag
./COUNTRY
Country
./ADDRESS1
StreetAddress
/BIRTHDATE
./BIRTHPLACE
./BIRTHCOUNTRY
./BIRTHSTATE
./DT_OF_DEATH
./SCC_PER_ADDR_I
Page 17 of 43
./ADDRESS2
StreetAddress2
./ADDRESS3
StreetAddress3
./ADDRESS4
StreetAddress4
./CITY
City
./COUNTY
County
./STATE
State
./POSTAL
PostalCode
Contact
Id
./NUM1
./NUM2
./HOUSE_TYPE
./ADDR_FIELD1
./ADDR_FIELD2
./ADDR_FIELD3
./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
./EFFDT
Page 18 of 43
./MAR_STATUS
Contact
MaritalStatus
./MAR_STATUS_DT
Contact
MaritalStatusDate
./SEX
Contact
M/F
./HIGHEST_EDUC_LVL
Contact
Degree
./EMPLID
UCMHEConstituentIdentification
Id
./COUNTRY
Country
./NATIONAL_ID_TYPE
NationalIDType
./NATIONAL_ID
NationalID
./FT_STUDENT
./LANG_CD
./ALTER_EMPLID
./SCC_PER_NID_I
./SSN_KEY_FRA
./PRIMARY_NID
IsPrimaryMVG
./TAX_REF_ID_SGP
State
EffectiveStartDate
EffectiveEndDate
EMPLID
Contact_Alternate Phone
Id
./PHONE_TYPE
AlternatePhoneUseType
AlternatePhone
./SCC_PER_PHONE_I
./COUNTRY_CODE
./PHONE
./EXTENSION
./PREF_PHONE_FLAG
IsPrimaryMVG
EffectiveStartDate
EffectiveEndDate
Contact_Communication Address
Id
/SCC_PER_EMAIL_I
./EMPLID
Page 19 of 43
./E_ADDR_TYPE
CommunicationAddressUseType
./EMAIL_ADDR
AlternateEmailAddress
./PREF_EMAIL_FLAG
IsPrimaryMVG
EffectiveStartDate
EffectiveEndDate
./EMPLID
Contact
Id
./VA_BENEFIT
Contact
VABenefits
Contact
DeathCertNum
Contact
PlaceOfDeath
./EMPLID
UCMHEConstituentName
Id
./NAME_TYPE
NameType
./EFFDT
EffectiveStartDate
EffectiveEndDate
./EFF_STATUS
Active Flag
./COUNTRY_NM_FORMAT
CountryNameFormat
M/M
./NAME_SUFFIX
Suffix
./NAME_ROYAL_PREFIX
RoyalPrefix
./NAME_ROYAL_SUFFIX
RoyalSuffix
./NAME_TITLE
JobTitle
./LAST_NAME_SRCH
LastName
./FIRST_NAME_SRCH
FirstName
./LAST_NAME
LastName
./PERSON_SA
./CAMPUS_ID
./DEATH_CERTIF_NBR
./FERPA
./PLACE_OF_DEATH
./SCC_PER_NAME_I
./NAME
./NAME_INITIALS
./NAME_PREFIX
Page 20 of 43
./FIRST_NAME
FirstName
./MIDDLE_NAME
MiddleName
./SECOND_LAST_NAME
SecondLastName
./SECOND_LAST_SRCH
SecondLastName
PrefFirstName
./EMPLID
UCMHEConstituentAffiliation
Id
./INSTITUTION
Institution Id
./SCC_AFL_CODE
AffiliationCode
./START_DT
EffectiveStartDate
./END_DT
EffectiveEndDate
./LASTUPDOPRID
Updated By
./LASTUPDDTTM
Updated
./NAME_AC
./PREF_FIRST_NAME
./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
./SCC_AFL_SPONS_DEPT
./SCC_AFL_PLCD_MTD
Page 21 of 43
./SCC_AFL_RLCD_MTD
./SCC_AFL_STATUS
Status
./SCC_AFL_STS_DESCR
StatusDescription
./SCC_AFL_RANK
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
SCC_ADDRESS_TYPE_MAP
HECH_VALUE
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
Page 22 of 43
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.
Page 23 of 43
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.
Page 24 of 43
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:
Page 25 of 43
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.
Page 26 of 43
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
Page 27 of 43

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
Page 28 of 43

d. Make sure that the Active check box is checked.
5. Setup the Handler for SCC_SM_FETCH

c. Type = OnRequest
e. Status = Active
f.
g. Description = Request Handler

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

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
Page 29 of 43

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
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
8. Setup the Handler for SCC_SM_SERVICE

c. Type = OnRequest
e. Status = Active
f.
g. Description = Search Request Handler

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

h. Save
i.
Return
j.
Validate that Status is Active and Direction is Outbound within Grid for Routing Name
Page 30 of 43

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

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
11. Setup the Handler for SCC_SM_FETCH

c. Type = OnRequest
e. Status = Active
f.
g. Description = Request Handler

i.
j.
ClassID = ProcessFetchRequest
l.
Click OK
12. Setup the Routings for SCC_SM_FETCH

b. Define the Outbound Routing
Page 31 of 43

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
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
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
Page 32 of 43

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

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
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.
Page 33 of 43

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
SCC_ADDRESS_TYPE_MAP
HECH_VALUE
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
Page 34 of 43
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
Page 35 of 43
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.
Page 36 of 43
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:
<CS9.0 Database Name> i.e. CS90ESM, <HCM9.1 Database Name> 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

Page 37 of 43

a.
Navigate: PeopleTools > Integration Broker > Integration Setup > Nodes.
b. Select the default local node: <Name of HCM 9.1Node>

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 <CTL>+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 = <Gateway Name for HCM 9.1>.
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 = <Name of CS 9.0 Node>

c.
Set Descr = CS 9.0 Instance'.
d. Set Authentication Option = 'Password'.

e.
Node Password = 'PS'
Page 38 of 43

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 <CTL>+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'.
o.

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: <Name of CS 9.0 Node>

c.
Set Descr = CS 9.0 Instance'.
d. Set Authentication Option = 'Password'

e.
f.
g.
h. Select Gateway = <Gateway Name for HCM 9.1> (Note: this is not the local gateway.)
i.
j.
k. Set Tools Release = '8.50.xx. (Note: by pressing the <CTL>+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
o.

q. Disable the 'encrypted' checkbox.
r.
Click Save.
Page 39 of 43
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: <Name of HCM Node>

c.
Set Descr = HCM 9.1 Instance'
d. Set Authentication Option = 'Password'

e.
f.
g.
h. Gateway ID = <Gateway Name for HCM 9.1> (Note: this is not the local gateway.)
i.
j.
k. 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.
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
o.

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.
a.
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
Page 40 of 43

i.
Enter the appropriate Password
j.
Set the tools release = '8.50.xx'. (Note: by pressing the <CTL>+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.

a.
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 <CTL>+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'.
Page 41 of 43
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.
2.
3.
4.
5.
Validate that Domain is active.

Validate that Node should be active.
Validate that Routings are active
Validate that Handler exist
Incorrect Gateway URL defined on Message Node.
Page 42 of 43
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.
Page 43 of 43

Implementing External Search Match Between CS and HCM

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Implementing External Search Match Between CS and HCM

Diunggah oleh

Hak Cipta:

Format Tersedia

Implementing External Search Match between CS and HCM

PeopleSoft Integration Reference Guide