Implementing External Search Match Between CS and HCM
-
Upload
jasonpaul81 -
Category
Documents
-
view
22 -
download
0
description
Transcript of Implementing External Search Match Between CS and HCM
-
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
-
Implementing External Search Match between CS and HCM
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
Implementing External Search Match between CS and HCM
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
-
Copyright Oracle USA 2010. All rights reserved. Page 4 of 43
Implementing External Search Match between CS and HCM
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 5 of 43
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 6 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.
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 7 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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 8 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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 9 of 43
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 10 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 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 11 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 12 of 43
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 13 of 43
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 14 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 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 15 of 43
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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 16 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.
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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 17 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 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 18 of 43
./ADDRESS2 UCMHEConstituentAddress StreetAddress2
./ADDRESS3 UCMHEConstituentAddress StreetAddress3
./ADDRESS4 UCMHEConstituentAddress StreetAddress4
./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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 19 of 43
./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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 20 of 43
./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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 21 of 43
./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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 22 of 43
./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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 23 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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 24 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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 25 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:
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 26 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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 27 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 28 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 29 of 43
d. Make sure that the Active check box is checked.
5. Setup the Handler for SCC_SM_FETCH
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 = Request Handler
h. Package Name = SCC_HR_INTEGRATION
i. Path = Request_Handler
j. ClassID = ProcessFetchRequest
k. Method = OnRequest
l. Click OK
6. Setup the Routings for SCC_SM_FETCH
a. Click on the Routings Tab
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
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_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
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 30 of 43
Routing Name SCC_SM_FETCH_RESP_from_HR
t. Save
Setup the External SM Search Service in HCM 9.0 database
7. Activate the Search Service SCC_SM_SERVICE
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
e. Make sure that the Active check box is checked.
8. 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
9. Setup the Routings for SCC_SM_SERVICE for HR database
a. Click on the Routings Tab
b. Enter Outbound Routing
c. Enter the Routing Name i.e. SCC_SM_Request_to_CS
d. Description = Search Request from CS 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 31 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
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_CS
t. Save
10. 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.
11. Setup the Handler for SCC_SM_FETCH
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 = Request Handler
h. Package Name = SCC_HR_INTEGRATION
i. Path = Request_Handler
j. ClassID = ProcessFetchRequest
k. Method = OnRequest
l. Click OK
12. Setup the Routings for SCC_SM_FETCH
a. Click on the Routings Tab
b. Define the Outbound Routing
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 32 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)
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_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)
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_FETCH_RESP_from_CS
t. Save
Configure External Search Match Services for HECH
Setup the External SM Search Service for the Campus Solutions database
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. Configure and activate the Routings for SCC_SM_SERVICE
a. Click on the Routings Tab
b. Click on the Routing Name i.e. SCC_SM_SERVICE from the existing routings
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 33 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
3. 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.
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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 34 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 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 35 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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 36 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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 37 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:
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 38 of 43
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'
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 39 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 +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. Click the WS Security tab.
p. Set Authentication Token Type = 'none'.
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'
e. Node Password = 'PS'
f. Default User ID = 'PS'
g. Click the 'Connectors' tab.
h. Select Gateway = (Note: this is not the local gateway.)
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
o. Click the WS Security tab.
p. Set Authentication Token Type = 'none'.
q. Disable the 'encrypted' checkbox.
r. Click Save.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 40 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:
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. Gateway ID = (Note: this is not the local gateway.)
i. Set Connector Id = 'PSFTTARGET'.
j. Click the Portal tab.
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
o. Click the WS Security tab.
p. Set Authentication Token Type = 'none'.
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. Navigate: PeopleTools > Integration Broker > Configuration > Gateways.
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
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 41 of 43
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.
a. Navigate: PeopleTools > Integration Broker > Configuration > Gateways.
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'.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 42 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. 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.
-
Implementing External Search Match between CS and HCM
Copyright Oracle USA 2010. All rights reserved. Page 43 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.