Integration Retrofits and Modifications Frequently Asked Questions (FAQ)

Integration with Modifications

What should campuses pay special attention to when analyzing their campus customizations to ensure no loss of functionality or data?

CSU_PIP_HISTORY

The CS Baseline Work Study modification utilizes CSU_PIP_HISTORY to determine how Much money students have available for financial aid disbursement. The CHRS table JOB will be converted as of November 1, 2019. Currently, at least 10 campuses use this modification.

In CHRS, this table will contain converted data as of July 1, 2019.

EMPL_RCD

CHRS

In CHRS, faculty/staff that had more than one job in multiple campuses also would have duplicate EMPL_RCDs when consolidated into one database. Therefore, all EMPL_RCDs in this situation have been renumbered during conversion only. New data added into CHRS will not be maintained through this table.

CSU_JOBEMPL_MAP (mapping/crosswalk table in CHRS)
1. EMPLID (CHRS EMPLID)
2. EMPL_RCD (CHRS EMPL_RCD)
3. EMPLID_OLD (Campus EMPLID)
4. EMPL_RCD_PREV (Campus EMPL_RCD)
5. COMPANY (Campus/Company)

CS

APDB and Workstudy both use EMPL_RCD. At the time of conversion to CHRS, a script will be run in the corresponding CS campus to update three tables to match the EMPL_RCD from the CHRS crosswalk table.

CLASS_INSTR
INSTR_TERM_DTL
STDNT_WS_AWARD

Campuses should review all areas where EMPL_RCD is used and determine retrofits. The three tables above are not inclusive of CS Tables that contain EMPL_RCD, only ones that are used in baseline. Most of the other tables are related to payroll, which is not used at the CSU.

COMPANY

In CHRS, 7 campuses (CI, EB, FRE, LA, LB and SF + CO) had their Company changed (CIS, EBY, FRE, LAS, SFO, CHO). Many went from a 2 digit codes to a 3 digit code.

For CS, baseline has developed views that utilize the COMPANY conversion. Campuses should review all areas where COMPANY used and determine retrofits.

PAY_CHECK

CSU_PAY_CHCK_VW has been created to blank out the SSN field, making it so that the SSN is no longer available on this record (view). Campuses will need to review all areas where PAY_CHECK is used and determine retrofits. As CS will link to the new view and only have access to that view through DB links.

In CS, PeopleSoft Campus Community ID Delete (HR_PER502) process uses the PAY_CHECK record.

What areas should campuses be focused on testing for non-Oracle delivered processes?

Academic Advising - CAAR Advising Report
Financial Aid - Work Study
CSU ID Search
Campus Community – ALMA (Library modification)
Systemwide Reporting – APDB

What areas should campuses be focused on testing heavily?

Campus needs to heavily test:

CS Campus Customizations
CS Third Parties
Provisioning

Should campuses review ALL CS Custom modifications?

YES, campuses should review ALL CS Custom modifications and gather a list of all tables used. Then campuses should review whether the table is “owned” by HR. If not already on the DB Link list of tables:

If another table needs to be used that is in the DB link view then notify your CHRS Implementation Manager why a table is needed in CS
Note: Use this SQL as a guide to determine the application owner of the table:
1. Find all tables and views with an Owner ID of HR
2. Note that this only works for Peoplesoft-delivered objects
3. CSU objects do not have consistent owner IDs

SELECT *

FROM PSRECDEFN A

WHERE A.OBJECTOWNERID LIKE 'H%' -- Owner is HR

AND A. RECTYPE IN ('0', '1') -- Tables and views

ORDER BY RECNAME.

What should campuses look for when considering integration with their modifications?

Does the modification create a new person?
Whether this is a new person or an existing one, update that person's data using a different CI.

Can a Campus Customizations have a Bio/Demo Data insert that goes directly into CHRS?

No

What should a campus consider regarding: Campus Customizations that insert Bio/Demo Data directly into CHRS will not sync to CS?

Data will not be synchronized without a CI or API

Is there a location campus should refer to regarding customizations?

Refer to a sample component interface in the Application Engine program below:

CSU_ESP_PST
Section POST
Step01 (PeopleCode)

How will campus customizations integrate data?

Campuses will need to retrofit their customizations which update personal data by adding a synchronization step OR by performing the update in both CS and CHRS applications. The synchronization step is done via component interface or API. All baseline delivered modifications have already been updated. Some examples of campus customizations are:

Updating preferred name
Synchronizing home address for reporting
Auto-creating POIs in HR
Updating Business Phone
AAWS Web Services
Duplicate ID Deletion
Email address update
Load Runner to update addresses

What should I understand about provisioning?

In the current CMS environment Integration Broker links are heavily used to synchronize data back and forth between the HR and CS applications. In CHRS, there will be a single IB connection from CS-CHRS. Campuses will need to modify their provisioning processes in CS when implementing.

CHRS Security- User Profile

CHRS will use the CS ID to create a User ID. This ID will not exist when an employee is created. Once the employee is created in CHRS a message will be sent to Campus Solutions to also create the person. The crosswalk table will be populated to show the relationship between the CHRS ID and the CS ID. In doing so Campus Solutions will know that a User ID will need to be provisioned in CHRS. CS will send a message to the CHRS system so the User ID can be created. The message will contain the following fields:

CHRS ID
Campus Solutions ID
Campus Code
When the User Profile is created in CHRS, a User Profile is NOT created in CS. Campuses must create a provisioning process if they want a User Profile created in CS.

Review Integration Functionality Frequently Asked Questions (FAQ) for more information.

Business Phone

Personal Data updated in CS will not be sent back to CHRS, including the Business Phone. However, if the Business Phone number is updated in CHRS, it will be sent back to CS.

Review Integration Functionality Frequently Asked Questions (FAQ) for more information.

Business Email

Personal Data that is updated in CS will not be sent back to CHRS. The exception to this is the business email. CS business email will be sent to the User Profile (PSOPRDEFN) in CHRS under the field EMAILID. In CS the business email must be added/updated using the Add/Update a Person component and not the Electronic Addresses component.
- Campus Solution Navigations: Menu > Campus Community > Personal Information > Add/Update a Person
- CHRS Navigations: Menu > PeopleTools > Security > User Profiles > User Profiles
For CHRS if the EMAILID is updated in PSOPRDEFN, it will not be sent to CS.
Campuses will need to modify their provisioning process in CS, if they want the Business Email to flow to CHRS.

Review Integration Functionality Frequently Asked Questions (FAQ) for more information.

Database Link / Access Questions

What should campuses know about CHRS database links, including how data is structured, secured, and what retrofitting may be required?

A single database link contains multiple tables/views that CS, CHRS, and CFS use to pull data. These tables/views have been standardized, simplified, and approved by the Chancellors Office. With CHRS being a shared environment, some of the tables/views have been modified to remove Level 1 Data (SSN, Citizenship, DOB, etc.). Many of the views are locked down in CS using a crosswalk table that uses Business Unit or Company. There will be 23 database links pulling CS data into CHRS (I.e., for TAE, Student Hire). The naming convention is CSU_<3 digit company>CS * per development environment views; this may change. Campuses should review all areas where database links are used and determine retrofits.

For more information review the DB Link Details and Integration FAQ documents located in the CHRS Knowledge Base.

What are the tables/views that will be available through a DB Link?

There is a variety of tables/views that are available through DB Links between CS/CHRS and CHRS/CFS. The full list can be found in the DB Link Details located in the CHRS Knowledgebase.

How will personal data synchronization between HR and Campus Solutions (CS) change in CHRS, and how will database links and ID mapping be handled in the new shared environment?

In the current CMS environment, all personal data is shared between HR and CS for each campus. Any person entering either system is automatically synched between the two. Campuses currently have no way of knowing if a person exists at another campus. In CHRS this will no longer be the case because it is a shared environment. CHRS employees/POIs have their personal data in Campus Solutions but those who are only students will no longer have personal data or exist in CHRS. CS has a mapping table that connects the CS and CHRS IDs because the Employee ID will no longer be the same in each system.

CHRS functionality requires limited information from the CS system. Database links will be used by CHRS to retrieve the data from CS. This means that CHRS will require 23 database links, one for each campus separated by business unit. These exceptions are detailed below.

Student Hire

Uses database links to perform the necessary validations in Campus Solutions. The module confirms that a student is currently enrolled in classes to work for that semester. If they are not enrolled, a warning message is generated. For work study, if a student is being hired or is already employed in that job code, the module confirms that the student has an award for the current term. Along with confirming the award minus disbursed amount is greater than zero.

Time and Labor Student Processing

Contains validations to ensure students are eligible to report time and not go over their Work Study amounts. The module used database links to perform these edits.

Temporary Academic Employment (TAE)

Uses database links to access the necessary data in Campus Solutions for the Course Assignments tab under the Appointment Notice Tile in Employee Self Service.
Uses database links to access the necessary data in Campus Solutions for the employees term workload under the "Empl Stat" value located on the CSU TAE Appointment Data Entry and CSU TAE My Approval pages.

CHRS Crosswalk Table

The CHRS Crosswalk table is housed on the Campus Solutions side.
Campus must allow the mapping table to be built if they want the views from CS to CHRS to work.
Campus Solutions delivers this mapping table that links the CHRS ID to the Campus Solutions Employee ID. The CHRS process is going to change the Employee ID of employees in the HR system. This will necessitate some mapping tables to link a person with different ID’s. The following are the list of mapping tables that have been identified:
- Historical HR Data – All historical data is not going to be converted into CHRS.
  - Each campus will have its own repository of historical information. Because the Employee ID is going to be changed in CHRS a mapping between the old Employee ID and new CHRS ID is necessary.
  - Employee Record Number Mapping (CSU_JOBEMPL_MAP) – Employee Record numbers may need to change when employees are converted. CHRS conversion will create a mapping table that will map the old Employee Record Number to the New Record number for the CHRS ID. Processes such as PIP and the PPT which use the Employee Record number will need to use this mapping. In CS, the Employee Record will be converted at the time of CHRS implementation.
- CS to CHRS ID - The Campus Solutions system has views into the Job Data of the employees in HR. This view will need to be able to map the CS Employee ID to the CHRS ID. A cross reference table will be maintained in the CS database that will contain the mapping (CSU_CHRS_XREF). Only the Employees for that campus will be included in each campus’s system. This will allow the views to join to the mapping to ensure a campus cannot see Job data from another campus. Because people can have jobs in multiple campuses, Business Unit was added into the baseline views to restrict the jobs that can be viewed.
  - Campus Solution Navigation: Menu > CSU SA Baseline > CSU Campus Community > CHRS Cross Reference
- CHRS ID to CS ID from PSOPRDEFN- In CHRS, the CSU_EMPL_MAP_VW is updated when a new employee or POI is created in CHRS, is sent to CS, and CS returns an entry to PSOPRDEFN which includes CS EMPLID. In the table “EMPLID” refers to CHRS ID and “OPRID” refers to the two digit campus code +9 digit CS EMPLID.
  - CHRS Navigation: Menu > PeopleTools > Security > User Profiles > User Profiles

Can a campus have a custom database link from a campus (local) database to the CHRS database? Example: an onbase service account from the onbase database that uses a DB link and credentials that are defined in the HCM database in order to query data in HCM?

No, CHRS is a standardized database where the tables included in the database link between CS/CFS/CHRS are set.

Can campuses have a DS (view only) campus account (ie. DS_55) in CHRS?

No

Can campuses have a Service Account in CHRS?

No

If campuses cannot have a Service Account in CHRS, how can they pull data efficiently?

It is recommended that campuses pull from Snowflake.

In Campus Solutions (CS), the tables PS_PER_POI_SCRTY and PS_PER_POI_TRANS exist locally and are also accessible through the database link. Are these the same tables?

Yes and no. The PS_PER_POI_SCRTY and PS_PER_POI_TRANS tables remain in CS from the HR 9.0 split; however, they are no longer updated with data.

Campuses that need POI information in CS must retrieve it through the database link. There is also a local view in CS, PS_CSU_POI_INFO_VW, which is built using the PS_PER_POI_SCRTY and PS_PER_POI_TRANS tables accessed via the database link and combined with PS_CSU_EMPL_MAP_VW.

Testing Considerations

What does my campus need to understand about testing?

Prior to each pass, a snapshot is taken of both the CS and HR 9.0 databases. Campuses are then provided with an unmasked CS (CA**WAA) environment that can be used throughout the testing pass. Campuses will receive instructions on when to complete post-clone activities, establish DB links, and perform integrations in the CA**WAA database, which has the CS008 and CHMP3.00 packages applied to ensure integration functionality.

During a campus’s Move to Production (MTP), the CS008 and CHMP3.00 packages will be automatically applied to their CS production environment during the scheduled downtime.

How many opportunities do Implementing Campuses get to test integration between CS and CHRS?

Campuses can learn integration and test retrofits during Pass A and B.

Who completes setup integration between CS, CHRS, and CFS for each pass?

CMS will connect the CHRS to CS and CFS. Campuses are responsible for configuring the CA***WAA to the CHRS database.

Is the CS database for Pass A and B supplied to campuses, or must they provide it?

Campuses will provided with an unmasked CS (CA**WAA) environment that can be used throughout the testing pass.

For the CS databases provided for Passes A and B, what level or type of access will campuses be granted?

Campuses will receive a unmasked CS (CA**WAA) environment for each pass. These databases will not include single sign-on functionality and access will be based on the campus Post Clone script ran.

During Move to Production (MTP) to CHRS, what should campuses expect?

During MTP, each campus will receive a scheduled time when their HR 9.0 production environment will be taken offline to begin conversion. Before that time, campuses must verify that all integration messages are in a Done status in HR 9.0, CS, and CFS. Campuses are also responsible for pausing all automated processes—such as provisioning and reports—in both HR 9.0 and CS.

Campuses will also be given a separate scheduled time for when their CS production environment will be taken down. During this downtime, CS008 and CHMP3.00 will be applied for each campus, along with any campus-submitted CS COMRs.

During Move to Production (MTP) to CHRS can campuses have CS COMR applied to their CS?

Yes, during the CS downtime, any campus-submitted CS COMRs can be applied after CS008 and CHMP3.00 have been applied.

When does a campus have to submit a CS COMR to have it applied during the Move to Production (MTP) to CHRS?

Campuses will be given a window of time to submit their CS COMR prior to Pass B ending.

How does a campus submit a COMR to be applied to CS during the Move to Production (MTP) to CHRS?

Campuses will need to submit a ServiceNow Ticket to CMS-CHRS with the following information and attachments:

CS Prod Environment Name
Project Name
Data Migration Workbench (DMW) Migration (Yes/No)
Date of Migration (Indicate Wave # and MTP Date)
Translate Value Approval Incident # (if applicable)
Suspected Run Time
Special Notes (if applicable)
Attach Project zip file, Migration Request and Impact Analysis Forms

Are campuses required to submit a CS COMR to be applied during the Move to Production (MTP) to CHRS?

No, campuses are simply given the option to submit a CS COMR to be applied during the Move to Production (MTP) for CHRS. This gives campuses an opportunity to have CMS review their project and confirm that it will not affect integration or any functionality required between CS and CHRS. It also allows campuses to have their project implemented right away so they don’t need to worry about it after go-live.

If a campus does not submit its CS COMR by the deadline, the project will need to wait until the campus’s next CS maintenance window to be applied.

Heading anchor Integration with Modifications

Heading anchor Database Link / Access Questions

Heading anchor Testing Considerations

Integration-CS/CHRS/CFS

Recently Updated Articles

Integration with Modifications

Database Link / Access Questions

Testing Considerations