faq cs hcm integration

HCM - CS Integration FAQ Nov 2, 2010 of 12

CS – HCM Integration FAQ

October 2010 Document Purpose The purpose of this document is to ensure that our Customers, as well as the Oracle Field, Support, Consulting and Strategy teams understand the CS-HCM integration effort for the Higher Ed customer base. We want to communicate at least three major considerations about the HCM – CS Integration:

• There is a continuum of options for customers to achieve this integration, including direct integration as well as use of the Higher Education Constituent Hub

• Most of the tools the customer needs to achieve the integration are available now; enhancements are targeted for 2nd half 2010

• Customers don’t need to complete the separation (and integration) until they want to upgrade to HCM 9.1

Oracle plans to update this document as customers deploy the integration functionality and we find useful information to share. Please see this My Oracle Support Knowledge page for more information (Document ID 1259484.1 Feature Pack 4 in Bundle 19 for CS 9.0.)

Overview

1. What is happening with the CS – HCM separation? A: --HCM 9.0 contains the CS 9.0 and HRMS 9.0 applications, in a shared instance of the database. As a result of the Campus Solutions Continuous Delivery Model, introduced in 2009, Campus Solutions will not have a 9.1 release; new functionality will instead be released incrementally through Feature Packs. Since HRMS will upgrade to 9.1 but CS will not, Oracle needs to provide a way for customers to maintain the data relationships between CS 9.0 and HRMS 9.1. To do this, PeopleSoft HCM and CS Development will deliver objects to provide supported integration between the two instances.

2. What are these changes? A: Campus Solutions is not part of the HCM 9.1 upgrade. Campus Solutions will remain on the 9.0 codeline, delivering new functionality through Feature Packs in the maintenance stream. When customers upgrade to HCM 9.1, they will need to clone their HCM/CS 9.0 instance, upgrade one instance to HCM 9.1 and maintain the second instance for CS 9.0. Oracle will deliver supported integration for core Person data between CS 9.0 and HCM 9.0 or HCM 9.1. Customers will have options for the integration they want to deploy, from full bi-directional support to syncing the Emplid only.

3. When will customers be required to move to separate instances? A: Customers will be required to move to separate instances of CS 9.0 and HCM 9.1 when they upgrade to HCM 9.1. There is no CS 9.1 release. Customers may choose to separate the HCM 9.0 instance and integrate CS 9.0 with HCM 9.0, but this is not required. HCM 9.0 is covered by Premier Support through Dec 2011, Regulatory, Legal and Tax updates through Dec 2012 and Extended Support available through Dec 2014. Note that Oracle will waive the Extended Support Fee for 12 months, which extends coverage with no extra fee, through December 2012 (announced at Oracle Open World, Sept 2010).

4. Why is Oracle separating CS from HCM? A: Customer input starting with early releases of Campus Solutions suggested that the cost of upgrades and lock-step maintenance with HCM was outweighing the benefit of receiving new functionality in that upgrade. Therefore, Campus Solutions adopted a Continuous Delivery Model in 2009, taking it out of the upgrade stream for the PeopleSoft 9.1 releases.


5. What resources are available to assist customers with the integration?

A: Oracle has provided a number of Integration Guides, recorded TOIs and Peoplebook updates which are available on this My Oracle Support Knowledge page.

6. What skills should customers assume they need to have on campus to manage this new integration?

A: See the Learning Path for Campus Solutions IT job role on the OU website. CS Development is making efforts to provide straightforward documentation to help bridge skill gaps for the direct integration. However, we recommend you review the Learning Path information. We will work with the TAG and the newly-formed Feature Pack Focus Group to provide advice to the customer community about skills needed.

7. What new products will my institution need to purchase to support this integration? A: None. The enhancements to support the “direct integration” approach, outlined below, are provided as part of HCM and CS maintenance, beginning with October 2010 HCM bundles and a CS 9.0 Feature Pack. Customers will have the option of licensing middleware to support more sophisticated integration scenarios. Similarly, customers who have the need to govern the exchange of Person Data between multiple systems on campus may evaluate the Master Data Management solution for Higher Education, the Higher Education Constituent Hub.

8. Can Oracle provide hardware/OS Level/DBMS level recommendations? A: Please refer to the current Hardware/Software Guidelines for HCM 9.0 available in My Oracle Support. There are no additional recommendations relevant to the separate instances. Section I: Core Information

9. What options do customers have for this integration? What are the approaches Oracle will support?

A: See the documentation which describes the three approaches Oracle is supporting: 1. Bi-directional support via the Higher Education Constituent Hub. The governance rules in

the hub determine which application(s) can “master” the bio/demo data and which are subscribers to updates from changes in the hub. The hub assigns the Universal ID to a person and then masters the emplid value from both CS and HCM.

2. Direct integration between CS and HCM, with an “Owner/Subscriber” approach (CS is the “owner” of the Personal data, which is messaged to HCM for the Hire activity and ongoing personal data maintenance). All persons are recorded in BOTH instances, replicating the functionality in the shared instance. Any activity which adds a new person to the CS or HCM database will initiate in the Campus Solutions instance. Messaging will then move the new person record to the HCM instance.

3. “Distinct Ownership” approach in which HCM and CS maintain separate records for individual’s personal data. The customer can use the External S/M functionality to sync the Emplid upon creation in either the HCM instance or the CS instance.

10. What data is kept in sync for these options?

A: See the Setup EIP and the Person Integration Guides for the message content. The specific pieces of data kept in sync vary based on which approach the customer takes. The supported messages include Bio/Demo data (e.g., Name, Address, Contact info, etc.) and the shared set up tables (e.g., Country, Location, etc.). Customers will evaluate the messages and decide which they want to deploy.

11. What data elements and utilities are unique to Campus Solutions and as such, will not be integrated with HCM?

A: The focus of the first phase of CS-HCM integration is on high value business processes where shared data is important. Therefore, the first phase of the integration support covers the high priority data


elements, based on customer input. As customers begin to leverage the integration, Oracle will respond to enhancement requests for additional data. Customers should also be aware that there are a number of Campus Solutions utilities that are not supported in the HCM application; these include the use of 3Cs, Population Selection/Update, Service Indicators, and Campus Self Service. Additionally, there are some data elements that exist only in Campus Solutions and therefore there is no reason to include them in the messages that update HCM (the fields do not exist in the HCM application). These include External System ID, Campus ID, FERPA, and External Organizations.

12. Which business processes are impacted by the integration? A: The Hire process (including Recruiting) as well as maintenance of Bio/Demo data for individuals (the data commonly considered part of Campus Community). The bio/demo data (and limited Job Data) for Instructors/Advisors will be in Campus Solutions to support business flows that require that information. Likewise, student bio/demo data will reside in the HCM instance, available should a student become a student worker. The institution will need to assess how they handle the Student Refunding process; Accounts Payable is the preferred solution but customers may use the Payroll application within the CS instance. Customers using Payroll within the CS instance will need to apply appropriate Payroll maintenance. This solution is limited by the fact that Payroll will stop delivering Tax Updates on HCM 9.0 when support for this release ends (December 2014).

13. The two models, owner / subscriber and distinct ownership, appear to be at opposite ends of the spectrum of supported integration. Are there additional points in-between customers should consider?

A: The concept of a school syncing SOME of the bio-demo data fields, such as Name, Address or email address is a point along the continuum that some schools may want to consider. Syncing only some of the setup tables is another option; we expect these requirements to vary by customer. Another approach customers might choose to take would be to do full person bio-demo data (data in the Person Basic Sync message), but not syncing any other person data (Visa/Permits, Citizenship, Ethnicity, etc.). Yet another example would be whether Job data is synced.

14. What is the Higher Education Constituent Hub? A: Oracle has released a Higher Education-specific version of the Siebel UCM data hub, called the "Higher Education Constituent Hub" (HECH). This data hub solution was designed with Higher Ed customers in mind and contains updates to attributes, labeling and so on to better fit the Higher Ed industry requirements. It is available today for institutions that want to deploy a data hub to connect campus systems together, including HCM and Campus Solutions.

15. Is there delivered integration between the HECH and Campus Solutions? A: Campus Solutions has already released (in Feature Pack 1 for CS 9.0) the Constituent Web Service and External Search/Match, which were built to support the integration of core person data between Campus Solutions 9.0 and other campus systems, including the Higher Ed Constituent Hub. The enhancements planned for Feature Pack 4 will include a suite of service operations and transformations specific to integration with the HECH. The customer will need to configure and develop aspects of the HECH product to complete the integration and they will need to "wire" the two systems together but they have all the basic pieces they need to do that.

16. Is there delivered integration between the HECH and PSoft HCM 9.1? A: There is no delivered integration that provides “out of the box” support between HECH and other PeopleSoft (or EBusiness) applications. However, Oracle is providing enhancements to CS 9.0 and HCM 9.1 to facilitate the customer’s efforts to integrate HECH with those two applications (e.g., HCM has enhanced Person_Basic_Sync and added support for External S/M). Note that the FP4 CS objects referenced in the above answer are not usable by HCM.

17. Do Upgrade scripts need to be revised to accommodate the instance separation?


A: No. Customers will continue to use the HCM 9.0 to HCM 9.1 upgrade scripts, which do not contain any Campus Solutions scripts.

18. What does Oracle recommend with respect to the HR objects in CS instance and vice versa?

A: In this first phase, Oracle will not be providing automation to remove any objects or data. Oracle’s long-term goal is to have an instance of CS that does not contain the HRMS structures (and vice versa). Each customer will be responsible to remove the person data that is no longer needed in each instance. The HCM Strategy team reports there should be no legal issue with having Payroll data residing in the CS instance, but they caveat that this is not a legally-informed position and the customers should research what their data maintenance policies are.

19. What is the path for a HCM 8.9 customer to move to the separate instance? A: There is no supported upgrade path that automatically moves a customer from HCM 8.9 to a separate instance of CS 9.0 and HCM 9.1. The supported path is to upgrade HCM/CS 8.9 to HCM/CS 9.0, then to deploy separate instances, and finally to upgrade to HCM 9.1.

20. How will the functionality supporting the integrations be delivered? A: Oracle will deliver the new functionality as part of a Feature Pack (for CS) or a bundle (for HCM). The first phase of support will be delivered in CS 9.0 Feature Pack 4 (with Bundle 19) and with HCM 9.0 Bundle 14 or HCM 9.1 Bundle 3. Additional capabilities will be delivered in subsequent HCM and CS maintenance.

21. What does Oracle recommend doing first; 9.0 upgrade or separating CS and HCM? A: Since the supported integration is between CS 9.0 and HCM 9.0 or HCM 9.1, Oracle recommends customers upgrade from HCM 8.9 to HCM 9.0 and then clone and separate the instances. Section II: Messaging Infrastructure

22. Which messages will be used in the integration? Which versions of the delivered HCM messages (Person_Basic_Sync, Workforce_Sync, Constituent Web Service) will be used?

A: Please see the Person Data Integration Guide documentation. This document includes an Appendix listing the service operations.

23. Is Middleware required to manage this integration? A: No. The direct integration approach is point-to-point, using PeopleSoft’s Integration Broker. The customer may choose to use middleware (e.g., BPEL) to facilitate more complex integration scenarios (e.g., multiple CS instances to a single HCM system).

24. Are we going to deliver Full Sync for Person_Basic_Sync (PBS)? A: Please see the Person Data Integration Guide documentation.

25. Does Workforce Sync work in the integration? A: Please see the Person Data Integration Guide documentation.

26. To what extent will Oracle deliver service operations that are “pre-packaged” and implemented in Campus Solution and HCM for the integration? To what extent will the institution be required to do development and/or configuration?

A: Oracle will deliver a solution that is as “pre-packaged” as Integration Broker allows. All the integrations in scope are planned to use delivered Service Operations, using typical Integration Broker configuration tasks. Aside from the actual database activities related to an HCM 9.1 upgrade or HRCS 9.0 database cloning, customers will need to complete the typical configuration tasks to setup Gateways, Nodes, Queues, and then activate the appropriate Integration Broker settings for all Service Operations they plan to


implement. As an example, for a full Owner/Subscriber model configuration (sync’ing all Setup and Person data) we plan about 50 different integrations that will require configuring. We will issue Integration Guides with the release of the enhanced messages that will document the configuration tasks, and which will provide implementation guidance.

27. Is the Constituent Web Service (delivered in Feature Pack 1) used as a part of the solution for integrating independent instances? If so, how?

A: The CWS is used in the integration with the Higher Ed Constituent Hub solution. It is not anticipated for use (and will not be documented as part of our “best practice” in our Integration Guide) for direct CS-HCM integration, because of the nature of the CWS and the fact that this message structure doesn’t exist in HCM. The Constituent Web Service (CWS) starts by subscribing to PERSON_BASIC_SYNC, then enriches it with attributes from the PERSON_SA table, and further enriches it with AFFILIATIONS data. Because PERSON_SA and AFFILIATIONS are CS-specific, using CWS as the exposure of CS-side data means publishing CWS (PBS+PERSON_SA+AFFILIATIONS) then, in the subscription handler on the HCM side, stripping out PERSON_SA and AFFILIATIONS data! Therefore, for direct integration, we are documenting a best practice of using PERSON_BASIC_SYNC as the integration message between the systems.

28. How is person messaging triggered? What does “near” real-time mean?? A: We are deploying standard “asynchronous” messaging, commonly known as “Publish/Fire and Forget”. Campus Solutions components publish the message and the HCM application will subscribe to the message. Asynchronous means that this type of message interaction is not synchronous; “synchronous” means that you save a change to a component and have to wait for a response from HCM that that system has received the message. The delivered solution uses asynchronous messaging because we didn’t want the integration to be dependent on a tightly coupled relationship between HCM and CS. Asynchronous messaging allows the HCM application to be “down” while updates continue to be made in CS. In asynchronous messaging, the published message may take less than a second or, depending on traffic, may take a few seconds or more. Example for the Hire business process: the process needs to start with a CS page to add core person data. Once the user saves the page where he has added core person data, the message is fired. The newly assigned Emplid appears at top of the CS page. At that point, the user moves to the HCM page to complete the Hire process (adding Employment and Job data). The user will need to specify the new Emplid in the HCM page and can then access the information that was just saved in the CS instance – the HCM instance has subscribed to the message so that data is available.

29. Will the Job, Position and the earnings tables be synched up from HCM to CS? A: The new approach has core bio-demo person data added in CS and synced to HCM. However, the Job information is passed from HCM to Campus Solutions via the Workforce_Sync message. The Earnings Table synchronization may be added to the integration if Oracle adds support for Federal Work-Study. If a customer needs to use the Earnings values within the CS application, they will configure the integration points to subscribe to that data. We will describe this available integration in our documentation.

30. Will Prospects continue to be a part of the HCM database, as they are today in the shared instance? Is there a supported approach that allows an institution to maintain their Prospects in CRM, but not in the HCM instance?

A: In the Owner/Subscriber approach, all prospect data loaded to CS is messaged to HCM. In phase 1 for Owner/Subscriber, we are not delivering the capability to limit or filter the records sent over to HCM. We know this type of filtering is desired by some customers and we are interested in evaluating those options with customers for a later phase. In the Distinct Ownership approach, prospects data stays in CS only. If a customer is using PS CRM to store and manage prospects, the best practice is to maintain the prospect data only in CRM. Once the person becomes an applicant in the CS Admissions module, the applicant data will be messaged to HCM, if the customer is using the Owner/Subscriber model.

31. Will EmplIDs be created in HCM as a result of Campus Solutions batch loads of data (e.g., applicants through test score loads)?


A: Yes, this is the case if the customer is deploying the Owner/Subscriber approach of direct integration. All Campus Solutions batch loads (prospect load, test scores, ISIR, TAC, etc) all invoke a service or process that can publish the Person_Basic_Sync message. How that happens can vary depending on the program - App Engine programs (like prospect loads) invoke certain services, legacy Cobol/SQR (lSIR) invoke a batch publish process, etc. For example, the TS189 (SQR) process cannot invoke a web service directly. But the TS189 process is delivered with a process that does publish PBS. This Batch Publish process was delivered in 8.9, and was implemented in all delivered CS legacy SQR/Cobol programs. Many customers have not been in practice of using it there have been no business requirements to deploy the messaging infrastructure. Customers who deploy the Distinct Owner approach are not sync'ing Person data, and we don't expect them to use PBS between the CS and HCM instances.

32. On the HR side, are there any batch loads of recruits or employees into HCM that will be handled in this integration?

A: There is a US Federal process that batch creates persons in HR, but US Federal support is out of scope now. There are some processes tied to personal data updates, e.g., running personal data refresh to update future-dated addresses to the personal data snapshot table. We are recommending revised business processes that will have users perform those Person data updates in the CS instance instead of HCM. As noted earlier, the Person_Basic_Sync message will publish from CS to HCM and updates will be synchronized in both instances that way.

33. What special considerations are there for batch programs, especially those that create identities in Campus Solutions or HCM? Do an institution’s custom batch load programs need to be modified to invoke the web services in order for the integration to be properly handled?

A: Yes. For the Owner/Subscriber model we expect Person data to be integrated only one-way, from CS to HCM. Delivered CS batch programs already integrate with the appropriate web services for publishing person data. For example, the SAD_TEST_PST (the Admissions Test Score Search/Match/Post app engine program) will publish PERSON_BASIC_SYNC as part of creating or updating data. The customer will need to modify their custom programs to ensure they are invoking the right services to send the data to HCM. Publishing PBS is already a requirement for anyone who has deployed the Constituent Web Services. For the Distinct Ownership model we don’t expect Person data to be synchronized between the databases (except when establishing the EMPLID, at time of initial Person create, using External Search/Match.) Note that in Phase 1 of the CS-HCM integration, External S/M is invoked with online updates, but not batch updates.

34. Can we get some guidance on how to modify our custom processes to work with the integration?

A: First, let’s review some background on what is provided by Oracle for batch updates within Campus Solutions. For SQR and COBOL processes, updates happen directly at the table level, but an additional insert is made to an auxiliary table that is used to trigger a Person_Basic_Synch message (by an app engine process). There is also a variant of this for some higher volume loads that leverage something called CS_PERSON_SERVICE, but it in turns fires Person_Basic_Synch. The result is that all delivered batch updates will have information flow through Person_Basic_Synch and thus keep separate instances informed (depending upon the type of instance separation). So, the delivered updates are covered, but any customizations or additional processes created by customers would have to be reviewed. Section III: Impact on Customers

35. How will my institution learn about the instance separation?


A: Customers can see a description of the change in the annual Campus Solutions Statement of Direction FY2011, published in July 2010. Then, they can review the Release Value Proposition update, published shortly before the enhancements are released in the Feature Pack. Finally, they will have the PeopleBooks updates that accompany the Feature Pack; the major source of documentation will be contained in the Integration Guides that will outline how to use the messages and utilities provided with the Feature Pack.

36. Is Oracle providing recommendations on what new hardware is required to support the separate instances and integration?

A: We are planning to engage with the HEUG’s Technical Advisory Group and other customers to help with recommendations.

37. What impact does this separation have on the normal CS maintenance cycle? A: No change to the CS maintenance cycle is anticipated.

38. Will this new integration affect any other Oracle/PSFT applications or just HCM? A: Other integrations between CS and PSFT FMS, PS CRM and EBusiness GL remain the same. Only the HCM interaction is impacted. However, in a future Feature Pack, we plan to introduce enhancements to the integration with PSFT Accounts Payable to support student refunding. See Question #49 for some specifics around integration with PSFT Financials.

39. How will the Hire Process be impacted? A: The impact will be outlined in the CS-HCM Integration White Paper. The impact is different for each of the three approaches. For the Distinct Owner model, the users will maintain the person’s data in the application that is managing that person (e.g., HRMS for employees, CS for students/alumni). You will use External S/M as part of the Add Person activity to determine if a person already exists in the other database. If that person does exist already, External S/M will facilitate the ability to import the existing EMPLID and personal data into the new instance and then continue with the add (hire) activity. For the Owner/Subscriber approach, all persons must be added in CS first, regardless of if you’re adding a prospect, an alumni, an applicant who is going through the Hire process or a Hire without using Recruiting. Navigation can be consolidated in the application portal to streamline the process of using the CS component to “Add Person” and then completing the transaction in the HCM instance. For the HECH approach, users will maintain the data in the respective instance; the HECH will create the mapping of the Emplid(s).

40. How will HCM Recruiting be impacted? A: See the answer related to the Hire process. For the Distinct Owner approach, you will use External S/M to determine if the applicant has a record in the CS instance and use the Import feature to bring their EMPLID and core bio-demo data into the HCM instance. For the Owner/Subscriber approach, when an applicant is ready to move through the Hire process, he/she must first be added to the CS instance as a Person, establishing an EMPLID and core bio-demo data. Then the Hire process is completed in HCM. We anticipate working with customers, post the first phase of this deliverable, to streamline the data entry flow.

41. How will updates to employee and/or student bio-demo data be impacted? What about self-service updates to personal data?

A: For the Distinct Owner approach, data will be updated in the instance that “owns” that information and will not be synced by any automated process. Self-service usage for HCM is not impacted. For the Owner/Subscriber approach, all updates for core bio-demo data (see list of synced data elements) will be made in CS. Employees will not be able to use HCM Self-service to update core bio-demo data as it is not synchronized back to CS. However, employees can use either CS Self-service for bio-demo data updates or, for that matter, they could use the HCM Self-service that exists in the CS instance. As long as the employee is updating a bio-demo data component in the CS instance, that update will be synced to the


HCM instance. In the HECH, core bio-demo data is maintained in the appropriate application (HCM or CS), synced to the hub and then distributed, based on your governance rules.

42. What documentation will be provided? A: A new Section in Campus Solutions PeopleBooks will be created. Updates will be made to the HCM PeopleBooks, focused on Higher Education customers. We plan to also create additional Integration Guides to explain how to deploy the services, External S/M and the other utilities that will support the integration.

43. Will there be pre-requisites for the CS HCM integration? A: The customer must have created separate instances for CS 9.0 and either HCM 9.0 or 9.1. The customer must have applied the HCM and CS bundles delivered in October 2010. See Knowledge [ID 1159773.1] in My Oracle Support for the correct sequence of applying HCM and CS Bundles (October 2010).

44. What is the impact of the separate instance integration on managing HCM and CS maintenance?

A: Customers will need to apply core HRMS maintenance to the CS instance. If customers choose to use North American Payroll in the CS instance to process Student refunds, they will need to also apply Payroll maintenance to the CS instance. Oracle suggests that customers need to retest the delivered integration only if we issue a data model change or a change in the integration itself (the publish or subscription pieces of the messages). Other sorts of functionality changes around bio-demo data are not likely to require re-testing of the integration.

45. Will supported versions of PeopleTools be consistent for CS 9.0 and HCM 9.1 (and beyond)?

A: Yes, PeopleTools is backward compatible.

46. If a CSHR9.0 customer upgrades to HCM 9.1, what are the options for refunding students?

A: Oracle’s recommendation is to use PSFT A/P for refunding functionality. We plan to deliver enhancements in a future Feature Pack to support direct deposit capabilities for PSFT A/P. There will be no provided integration between CS 9.0 and a separate instance of HCM Payroll. If customers want to use North American Payroll for refunding, they will need to do so using the Payroll application that is part of the CS instance. Customers that want to continue to use Payroll for processing Student Refunds would need to do the requisite payroll setup in the CS instance to process student refunds alone. All other non-student related payroll would continue to be processed in the separate HCM/Payroll instance. If customers choose to use the Payroll application within the CS instance, they will need to apply Payroll maintenance to that instance.

47. HCM 9.0 support ends in Dec 2011, with Regs/Legs/Tax updates provided through Dec 2012. Extended Support for HCM 9.0 is available through Dec 2014. How will customers get fixes for HR Core and Payroll (tax) objects for the CS 9.0 codeline once Extended Support for HCM 9.0 expires in Dec 2014?

A: Just like any other HCM 9.0 customer, after Dec 2014, customers will go into Sustaining Support for HCM 9.0, including Payroll. If there are fixes required for core Person objects required AFTER December 2014, Campus Solutions will provide those for the Campus Solutions codeline, to ensure the integration continues to work. For customers concerned about North American Payroll support after Dec 2014, the suggested path is to evaluate processing student refunds through the PSFT A/P solution.

48. Will the use of HCM Payroll in the CS instance for student be supported when HCM 9.0 support ends in 2014?

A: There are no plans to extend support beyond the standard Oracle Sustaining Support. For customers concerned about North American Payroll support after Dec 2014, the suggested path is to evaluate processing student refunds through the PSFT A/P solution.


49. What changes to the GL interface and other Financial integration should we expect? Is Oracle providing messaging to support moving all chartfields over to the HCM instance?

A: Student Financials will continue to send GL transactions directly to PSFT Financials as we do in the existing HCM/CS 9.0 instance and the remaining GL transactions that get generated as a result of cutting a check or processing a direct deposit will come from either Payroll (in the CS instance) or from the AP instance to Financials.

PFST Financials publishes messages to which Student Financials subscribes in order to load Chartfields. There is also the batch publish of accounting line information from Student Financials to PSFT Financials. Regardless of the separate instances, any Financials related enhancements (e.g. support of additional Project Cost Chartfields) or changes in Financials that has potential to impact the SF-GL interface would need to worked upon by Campus Student Financials Multiple nodes (CS and HCM instead of just a single HCM node) should not impact the integration. Project Costing Chartfields: PS Financials supports the Project Costing chartfields but they are not consumed/supported in the HCM/CS 9.0 instance today. (The underlying tables that store the chartfields and the valid values are owned by HCM – CS simply leverages those.) These additional chartfields are supported in HCM 9.1. So, if a CS customer is project centric, meaning they do plan to use Project Costing Chartfield functionality in HCM 9.1 and they decide to move to separate instances, then they would need Project Costing Chartfield support in the CS 9.0 instance. We acknowledge that this is a valid scenario/requirement that SF would need to support as part of the separate CS-HCM model but that support is currently out of scope for FP4. We will evaluate the customer priority for this support for future phases of the CS-HCM integration support.

50. What is the impact on FERPA controls with the separate instance? What about restrictions around sharing Employee personal data?

A: There are no changes in the FERPA process. Students continue to use CS to indicate their FERPA restrictions. Institutions would continue their (assumed) current business process in which CS is the system of record for FERPA release/restrictions. The FERPA flag (defined as a Y/N value) is part of the PBS message, so the value will be sent to HCM and can be stored in the existing Person_SA record. Technically, FERPA does not cover Employee data. Employee data can be hidden/restricted in the CS instance using delivered security.

51. In the Distinct Ownership model, how are faculty handled? Are faculty handled like student-employees, who are in both databases but independently maintained?

A: Yes, the intent with Distinct Ownership is that the customer will maintain the core bio-demo data (e.g., name, email addresses) in BOTH HCM and CS. See the earlier comment on the continuum; customers can choose to keep these two data elements in sync using delivered messaging, as a hybrid approach of Distinct Ownership and the Owner/Subscriber model.

Section IV: Emplid Synchronization

52. How will Emplids be kept in sync between the separate instances? A: All three supported approaches maintain the ability for the customer to maintain either the equivalent of a single Emplid for HCM and CS or an actual single Emplid. The HECH uses a Universal ID to which other IDS (e.g., EMPLID) is mapped. In the Distinct Ownership approach, the customer will use External S/M to look at the other instance before adding the new record, to see if the person (either student or employee) exists in that instance. If the match is found, the new External S/M can “import” the person’s Emplid as well as core bio-demo data and the business process can continue. In the Owner/Subscriber approach, all persons are added to the CS instance, so all Emplids are assigned using that Installation counter.


53. Does Oracle recommend institutions maintain two ranges (sets) of Emplids? For example, an institution may have a large (batch) student application/admissions SQR that will now have to look at two instance/systems to determine if the person already exists with an emplid.

A: Yes, for customers who are choosing to deploy the Distinct Ownership model of direct integration, the recommendation is to maintain two distinct ranges of Emplids in the CS and HCM instances. For the Owner/Subscriber approach, all Emplids are assigned using the CS Installation Counter. For the HECH bi-directional integration approach, the hub provides the ID synchronization capabilities, so the Installation counters don’t need to be modified. The CS batch loads will continue to execute S/M, as they always have. Search/Match will search against the CS instance. Therefore, if you are using Distinct Ownership model, you will not be searching against the HCM instance (only the CS instance). Currently, External Search/Match is not deployed against BATCH jobs, only the online transactions. If you are using the Owner/Subscriber model, all persons exist in the CS instance, so S/M will look at the full HCM/CS population by searching against CS. We are evaluating the need to leverage External S/M with batch jobs against an HCM instance. Section V: Portal and Security Configuration

54. Our school also has a portal database and we message over user profiles from CS/HCM to our portal database as they are created. Are there plans to integrate userprofile creation from CS 9.0 and HCM9.1 separately to the portal database?

A: Yes, this will be standard in the PS Enterprise Portal.

55. Whichever model, owner/subscriber or distinct ownership, is chosen, does the PSOPRDEFN table need to be identical in both databases?

A: Not necessarily. For example, in a Distinct Ownership model, you might not want operators in your HCM system to have entries in your CS system, only those users who NEED access to both systems (for example, student-employees) – a pure EMPLOYEE would have no need nor any real business having an operator ID in CS.

56. Will security tables (PSOPRDEFN, etc.) be included in sync? A: Yes, user profiles will be synced through standard process.

57. Where do User Profiles for portal aggregation exist? Is there a message to keep User Profiles in sync between the two separate instances?

A: See Enterprise PeopleTools 8.50 PeopleBook: Security Administration > Working with User Profiles Across Multiple PeopleSoft Databases.

58. It makes sense that in the Ownership/Subscriber model, with Campus Solutions as the owner, messaging would go from Campus Solutions to the Portal to provision psoprdefn in the Portal. This is because in the ownership / subscriber model, all persons (students, faculty, and staff) will be present in Campus Solutions, as they are now in the present combined database.

Related to the distinct ownership model: Will messaging to the Portal be from both Campus Solutions and HCM? If so, aren't there possible collisions in the Portal? It seems this could occur when a student is first created in Campus Solutions and later hired as an employee in HCM and therefore is already in the Portal at the time of the hire.

A: Both CS and HCM will message to the Enterprise Portal. User Profile attributes (including User ID, Roles, and ID Type values) which exist in both CS and HCM databases will be reconciled in the Enterprise Portal at subscription time. These also can be sync’ed between CS and HCM as required. There is a good


description of how User Profiles are managed between multiple PeopleSoft databases in PeopleBook doc. See Enterprise PeopleTools 8.50 PeopleBook: Security Administration > Working with User Profiles Across Multiple PeopleSoft Databases.

59. Can you register a CREF from an independent database in an application portal of another database?

A: Yes, you can add a link to a page which resides in another database instance to the application portal navigation that is resident in the original database. In other words, you can add a CREF for a CS page in the HCM 9.1 application portal navigation. In fact, this is one of the options to streamline navigation for users deploying the Owner/Subscriber model.

60. The value “HRMS” is delivered by default as the Portal NODE during the PeopleSoft Enterprise Portal installation. How do we create a separate node for CS (Campus Solution) and make sure the CREF is referencing this node?

A: In order to register an external content reference, you need to point that content reference to the external source. This is accomplished by defining the new node in the external application and then, when registering the content references in your hosting portal, including the external node instead of the internal node. This can be done both in the Enterprise Portal as well as the standard Application (PIA) portal. For example, in an Owner/Subscriber model in which Campus Solutions is the system of record, you could easily include links in your HRMS application portal to components in your Campus Solutions instance by defining the menu and component in your Portal CREF definitions list, but rather than pointing to the local (“HRMS”) node, you would point to the external (e.g., “CAMPUS”) node. In addition to simply registering external content references in your portal navigation, Peopletools 8.5 allows for the use of Related Content, the ability to embed components directly within another component to allow for a more seamless business process that spans multiple components or transactions. As with the aggregated navigation, you will need to create an external node and references that external node when registering your related content. For more information on defining and configuring external content references, please see the Portal Navigation Aggregation Guide. For more information about Related Content, and registering CREFs in portal structures in general, please see the PeopleSoft Portal Solutions Peoplebook.

61. Will Oracle provide an automatic way for customers to lock down tables for editing - for example, if the table setup is sent from HCM to CS, will the subscriber environment be open for editing? If not, how will customer prevent their two instances from getting out of sync.

A: We are not delivering anything to PREVENT updates of shared tables in HCM and CS. We expect customers will enforce controls on data entry via policy and/or changing Security Permissions. We are considering whether we will deliver support for this type of control in the Owner/Subscriber approach in a future update (for example: pages that should be Display only.)

62. In the Distinct Ownership model, for administrative staff using Campus Solutions for administrative functions, what is needed to provision them in Campus Solutions? Are they handled like faculty in the Distinct Ownership model?

A: In order to access pages/components, etc., the user (admin staff) will need to have an operator record in the CS instance (OPRID). However, they do NOT have to have an EMPLID – there are different “ID TYPES” that can be associated with an OPRID (including NONE, as well as Employee, etc.). Permissions and Roles are not tied to ID TYPES. Please consult Peoplesoft Security Peoplebooks for more details. Section VI: Reporting

63. What impact on the existing SQR, Crystal reports and Queries should an institution expect once the instance is split? What about existing views, etc.?


A: The first step is to understand what data is kept in sync, in each database. Then, understand the source of the data for each report or Query. You may either need to create custom integration to support the data needs of that report or look at creating new sources for that report. Note that you can’t use PS Query to access records across two databases. Data Model changes are not taking place by virtue of this project. Customers who use the Campus Solutions and/or HCM Warehouses will continue to utilize those reporting structures. The PS Campus Solutions Warehouse does pull data from different sources and in some cases it does aggregate data (but that is not the case today for PERSON related data). The impact the separate instances has on the warehouse is similar to the impact on the reporting side. The warehouse needs to identify where to pull the master data from; probably the most complicated scenario is the distinct ownership, where the data may need to be pulled from different databases. For customers that will create their custom reports, they should be aware of the implications. If they just do counts out of context, then they could have issues. In context reports should behave as expected. The Source SYS ID key field will be the differentiator.

• The EPM Warehouses rely on a Source System ID to join dimensions to the FACTs and to do lookups. If you are using a Campus Solutions FACT, it will look to do the join using a dimension—even if common—that has a row with the same source system ID (it doesn’t really care what it is, as long as there is a match).

• In cases where the Personal data is duplicated across the CS or HCM DB, it will work, but there will be two data rows for the same person in the Dimensions. Not a technical issue, though customers may question why there are two rows of data for a single person. With the current design, there is no easy way to alter this result and we deem it too invasive at this point to change the functionality.

• In the case where Personal data only exists where it is needed—Distinct Ownership—it should also not be a problem. Employees who are not students will only be needed for HCM FACTS and Students who are not in HCM will only be used in CS. Where data is duplicated—Students who are also Employees—the same thing will occur with duplicated rows (but for the source sys ID) and it should work fine as well. The joins will take place taking into account the source sys ID. It is the customer’s responsibility to ensure that they synch up where necessary for those who need to be in both DBs.

Subsequent to the Phase 1 updates, Oracle may attempt to analyze the impact each of the three most typical integration approaches (owner/subscriber, distinct ownership or Integration with Constituent Hub) could have on reporting. We will ask our Focus Group for support in this analysis. Section VII: Miscellaneous Topics ***Our intent is to continue to update this Document with additional Questions and Answers as our customers leverage the integration capabilities. Customers should leverage the normal Support process to record their question or issue and if that question is applicable to the majority of customers, we’ll add it to this document.

faq cs hcm integration

Documents