Refreshing Security Join Tables

To refresh security join tables, use the Nightly SJT Refresh Process component (SCRTY_SJTDLY_RC), Refresh Trans. SJT tables component (SCRTY_SJT_RC), the Refresh SJT_CLASS_ALL component (SCRTY_OPR_RC), and the Refresh SJT_OPR_CLS component (SCRTY_OPRCLS_RC).

These topics describe when to use and how to run the security refresh processes.

Page Name

Definition Name

Usage

Nightly SJT Refresh Process Page

SCRTY_SJTDLY_RC

Refresh the transaction security join tables to capture data changes that were not automatically loaded into the table. Run shortly after midnight to capture effective-dated changes.

Refresh Trans. SJT tables Page

SCRTY_SJT_RC

Refresh some or all of the data in the transaction-based security join tables to capture data changes that were not automatically loaded into the table.

Refresh SJT_CLASS_ALL Page

SCRTY_OPR_RC

Refresh some or all of the data in the SJT_CLASS_ALL table to capture changes to permission lists that were not automatically loaded into the table.

Refresh SJT_OPR_CLS Page (security operator class)

SCRTY_OPRCLS_RC

Refresh some or all of the data in the SJT_OPR_CLS to capture the current relationship between user profiles and permission lists.

PeopleSoft HCM core row level security has four refresh processes. Use the refresh processes to keep your security data up to date so that the system is enforcing data permission using the most current information.

Important! The refresh processes are designed to refresh each row included in the process definition in sequence, causing the system to take an exceptionally long time to run the process when there are a large number of rows. To improve performance, we recommend clearing the Refresh All Rows check boxes on the run control pages and creating more defined run controls to run concurrently. (For example, create a run control for each permission list and run them simultaneously, rather than refreshing all permission lists under a single run control). You can save the run controls and use them as often as necessary.

Nightly Refresh SJT

Run the Nightly Refresh SJT process nightly to refresh the transaction security join tables. The nightly refresh process:

  • Updates the transaction security join tables with any changes to transaction security data that bypassed the SavePostChange PeopleCode.

    The system automatically updates the transaction security join tables when you make and save a change on the transaction components, either by manual entry or a mass update that triggers the component interface. If you bypass the PeopleCode, you will need to capture the changes using a refresh process.

  • Updates the security join table with future-dated security rows that have become current (when the current calendar date matches up with the effective date of the transaction record) because SavePostChange PeopleCode is not triggered when a future-dated row becomes current.

  • If you are using future-dated security rows deletes the old security row and makes the future-flagged row the current row.

Run this process nightly for every security set you are using.

See Nightly SJT Refresh Process Page.

SJT Refresh

Run the SJT Refresh process to refresh the transaction security join tables.

You will need to refresh the tables using this process when you:

  • Enable or disable a security access type.

    When you enable a security access type, you need to load the transaction security data for that type into the security join table.

    You need to run it when you disable a security access type in order to clear the security join table of the transaction security data. You won't compromise your security if you don't run it but you will improve performance by removing the unnecessary rows.

  • Update the transaction components using a process that bypasses the component interfaces.

    The Nightly Refresh SJT process also captures this data but you may want to refresh the tables immediately rather than waiting for a scheduled run.

You can run this process for all security sets at once, individually, or by a smaller grouping of data.

See Refresh Trans. SJT tables Page.

Refresh Row Security Operator

Run the Refresh SJT_CLASS_ALL process to refresh SJT_CLASS_ALL.

You will need to refresh SJT_CLASS_ALL using this process when you:

  • Modify a security access type.

    Modifications include selecting to use future-dated security rows or changing the job data security options.

  • Create or modify a department security tree.

  • Create or modify a row security permission list on the Security by Dept Tree component.

    Modifications include adding or removing data permission and refreshing the effective dates of trees.

See Refresh SJT_CLASS_ALL Page.

Refresh SJT_OPR_CLS

Run the Refresh SJT_OPR_CLS process to refresh SJT_OPR_CLS.

You will need to refresh SJT_OPR_CLS whenever you create or change the relationship between a user profile and a permission list with data permission. Run the process when you:

  • Clone a user profile that has data permission.

  • Add a row security permission list that has data permission to, or delete one from, a user on the User Profile - General page.

  • Add a role with permission lists with data permission to, or delete one from, a user.

  • Add a permission list with data permission to, or delete one from, a user-assigned role

Note: SavePostChange PeopleCode on the Security by Dept Tree component and the Security by Permission List component updates SJT_OPR_CLS when you add a permission list to either component for the first time. If you add a permission list to the user first, either in the Row Security field or by way of a role, and then add it to the Security by Dept Tree page or Security by Permission List page, you do not need to run the process.

You can enable the USER_PROFILE message and the local subscription HCM_Refresh_SJT_OPR_CLS and the ROLE_MAINT message and the local subscription HCM_Role_Refresh_SJT_OPR_CLS to automatically update SJT_OPR_CLS.

PeopleSoft does not deliver the system with these messages enabled in order to prevent unnecessary publishing. If you would like to use them, follow these steps:

  1. Uncomment the following PeopleCode found in the USERMAINT.GBL SavePostChange PeopleCode.

    /*
If %Mode="A" Then
	%MSG.CopyRowset(&USERPROFILECHANGE);
	&MSG.Publish();
Else
	&MSG.CopyRowsetDelta(&USERPROFILECHANGE);
	&MSG.Publish();
End-If,*/

  2. Use PeopleSoft Application Designer to activate the USER_PROFILE and ROLE_MAINT messages by:

    1. Opening each message.

    2. Click on the Properties icon.

    3. Select the User tab.

    4. Select the Active check box.

  3. Use PeopleSoft Application Designer to activate the handler/application class for the USER_PROFILE and ROLE_MAINT messages:

    1. Open each message.

    2. Under Message Subscriptions, select HCM_Refresh_SJT_OPR_CLS (for USER_PROFILE) or HCM_ROLE_REFRESH_SJT_OPR_CLS (for ROLE_MAINT), right click, and select Message Subscription Properties.

    3. Select the Active check box.

  4. Confirm that the queues are running:

    1. Select PeopleTools > Integration Broker > Monitor Integrations > Monitor Message.

    2. On the Monitor Message - Channel Status page (AMM_CHNL_STATUS), scroll down until you locate both the USER_PROFILE and ROLE_MAINT channels.

    3. Confirm that both channels have a status of Running.

  5. Make the USER_PROFILE and ROLE_MAINT messages active on the HCM node by:

    1. Select PeopleTools > Integration Broker > Integration Setup > Node Definitions.

    2. On the Node Definitions - Transaction page (IB_NODETRXLIST), change the status of each message to Active.

See Working with HCM Local Integrations.

See Refresh SJT_OPR_CLS Page.

Refresh Processes by Action

This table indicates which refresh processes you should run when implementing HCM security:

Action

Refresh SJT_CLASS_ALL

SJT_Refresh

Make changes to the implementation settings on the Security Installation Settings page.

Run

Run

Enable a security access type.

Run

Disable a security access type.

Run

Run

Modify an enabled security access type (for example, by selecting or deselecting the Include Future Dates check box).

Run

Run

This table indicates which refresh processes you should run when using security trees and creating and modifying row security permission lists:

Action

Refresh SJT_CLASS_ALL

Create a department security tree.

Create a new effective-dated version of an existing tree.

Note: You do not need to refresh SJT_CLASS_ALL yet because you'll have to update the data permission lists to reference the new tree. You'll run the SJT_CLASS_PROCESS then.

Modify a department security tree without changing the effective date.

Run

Add a new permission list to the Security by Dept Tree page and add to it data permission.

Run

Modify the data permission of a permission list on the Security by Dept Tree page.

Run

Refresh the effective date of the trees on the Security by Dept Tree page because you created a new effective-dated version of an existing tree.

Run

This table indicates which refresh processes you should run when creating and modifying row security permission lists:

Action

Refresh SJT_CLASS_ALL

Add a new permission list to the Security by Permission List page and add to it data permission.

Note: The system uses SavePostChange PeopleCode to update SJT_CLASS_ALL automatically when you save the component.

Modify the data permission of a permission list on the Security by Permission List page.

Note: The system uses SavePostChange PeopleCode to update SJT_CLASS_ALL automatically when you save the component.

This table indicates which refresh processes you should run when you add, delete, or modify a user's data permission:

Note: This table assumes that you have not enabled the USER_PROFILE message and the local subscription HCM_Refresh_SJT_OPR_CLS and the ROLE_MAINT message and the local subscription HCM_Role_Refresh_SJT_OPR_CLS to automatically update SJT_OPR_CLS. PeopleSoft does not deliver the system with these messages enabled.

If these messages are enabled, the system updates SJT_OPR_CLS and you do not need to run the refresh process following any of these actions.

Action

Refresh SJT_OPR_CLS

Add a row security permission list to a user profile on the User Profile – General page.

Run

Delete a row security permission list from a user profile on the User Profile – General page.

Run

Change a row security permission list on a user profile on the User Profile – General page.

Run

Create a new user profile by copying an existing profile that has permission lists with data permission (whether by the Copy User Profiles page, the Create Users process, or the Create Row Security - Dept Mgr process).

Run

Add a role-based permission list (one that has data permission from the Security Permission List page) to a role that is already assigned to a user.

Run

Delete a role-based permission list (one that has data permission from the Security Permission List page) from a role that is already assigned to a user.

Run

Add a role that has one or more role-based permission lists (permission lists that have data permission from the Security Permission List page) to a user profile.

Run

Delete a role that has one or more role-based permission lists (permission lists that have data permission from the Security Permission List page) from a user profile.

Run

Add a permission list that is already assigned to a user (by way of a role) to the Security by Permission List page and give it data permission.

Add a permission list that is already assigned to a user on the User Profile – General page to the Security by Dept Tree page and give it data permission.

This table indicates which refresh processes you should run when you add, delete, or modify the following transaction security data:

  • Job data record for a person.

  • Person of interest record for a person.

  • Department.

  • Job opening.

Action

SJT Refresh process

Add, delete, or modify an existing transaction record.

Create a future-dated transaction record.

Using a mass update process that triggers the component interfaces, create, delete, or modify multiple transaction records

Using a mass update process that does not trigger the component interfaces (or otherwise bypass the component interface on the transaction record), create, delete, or modify multiple transaction records.

Run

Use the Nightly SJT Refresh Process page (SCRTY_SJTDLY_RC) to refresh the transaction security join tables to capture data changes that were not automatically loaded into the table.

Run shortly after midnight to capture effective-dated changes.

Navigation:

Set Up HCM > Security > Core Row Level Security > Nightly SJT Refresh Process > Nightly SJT Refresh Process

This example illustrates the fields and controls on the Nightly SJT Refresh Process page. You can find definitions for the fields and controls later on this page.

 Nightly SJT Refresh Process page

Set up this process to run every night shortly after midnight using a recurring schedule and leaving the As Of Date field empty. By running the process shortly after midnight, you capture the formerly future-dated rows that have just become effective.

Field or Control

Description

Transaction Sec Join Table

Select the transaction security join table to update.

Include yesterday's changes?

Select to include the previous day's changes. The program searches the system for any changes to the transaction records on the previous day and updates the transaction security join tables with those changes. This ensures that any changes that were made to the data outside of components or component interfaces are captured.

If you do not select this check box, the process will only update the transaction security join tables with the changes made on the as of date.

Note: It is recommended that you select this option every time you run this process to guarantee that you are updating the transaction security join tables with the latest information. Only deselect the check box if you are experiencing performance issues and you are certain that the records are not being updated outside of the regular user interface or component interfaces.

As Of Date

Leave the as of date blank when you schedule this run control ID to run on a recurring basis. The system will use the current, system date each time it runs.

Use the Refresh Trans. SJT tables page (SCRTY_SJT_RC) to refresh some or all of the data in the transaction-based security join tables to capture data changes that were not automatically loaded into the table.

Navigation:

Set Up HCM > Security > Core Row Level Security > Refresh Trans. SJT tables > Refresh Trans. SJT tables

This example illustrates the fields and controls on the Refresh Trans. SJT tables page. You can find definitions for the fields and controls later on this page.

 Refresh Trans. SJT tables page

Field or Control

Description

Refresh All Sets?

Select All Security Sets to refresh all security sets.

Select One Security Set to refresh one security set.

Security Set and SJT Table

If you are refreshing one security set, select the set. The system displays the transaction security join table associated with the security set.

Refresh All Rows?

Select to refresh every row in the security join table.

Deselect to refresh select rows in the security join table. The system displays the Rows to Update grid.

Rows to Update

Select the rows to update. The options available are the ones you selected for the security set on the Security Sets component.

Rows to Update

The fields and buttons in the Rows to Update grid will vary depending on the rows you select to update in the Rows to Update field. Enter the rows of data you want to update.

For example, if you select Security Type in the Rows to Update field, select the security types whose transaction data you want to refresh.

Use the Refresh SJT_CLASS_ALL page (SCRTY_OPR_RC) to refresh some or all of the data in the SJT_CLASS_ALL table to capture changes to permission lists that were not automatically loaded into the table.

Navigation:

Set Up HCM > Security > Core Row Level Security > Refresh SJT_CLASS_ALL > Refresh SJT_CLASS_ALL

This example illustrates the fields and controls on the Refresh SJT_CLASS_ALL page. You can find definitions for the fields and controls later on this page.

 Refresh SJT_CLASS_ALL page

Row Level Security Refresh

Field or Control

Description

Refresh All Rows?

Select to refresh every row in SJT_CLASS_ALL.

Deselect to refresh selected rows. The system displays the Refresh Set field.

Refresh Set

Select the set of rows to refresh. The system displays the Set of Security to Refresh grid.

You can select to refresh:

  • All Trees.

  • Permission List

  • Security Type

  • Specific Tree

Refresh Tree Effdts by (refresh tree effective dates by)

Select the date as of which you are refreshing the table. The process will refresh the table with the security data that is effective as of this date.

Set of Security to Refresh

Select the values to refresh.

For example, if you've modified a row security permission list, rather than refreshing the entire table, select Permission List in the Refresh Set field and select the permission list you modified here.

If you've modified a specific tree, select Specific Tree in the Refresh Set field and select the setID's to refresh for that tree.

Use the Refresh SJT_OPR_CLS (security operator class) page (SCRTY_OPRCLS_RC) to refresh some or all of the data in the SJT_OPR_CLS to capture the current relationship between user profiles and permission lists.

Navigation:

Set Up HCM > Security > Core Row Level Security > Refresh SJT_OPR_CLS > Refresh SJT_OPR_CLS

This example illustrates the fields and controls on the Refresh SJT_OPR_CLS page. You can find definitions for the fields and controls later on this page.

 Refresh SJT_OPR_CLS page

The Refresh SJT_OPR_CLS process refreshes SJT_OPR_CLS as of the system date.

Field or Control

Description

Refresh All Rows?

Select to refresh every row in SJT_OPR_CLS.

Deselect to refresh selected rows. The system displays the Set of Security to Refresh field.

Set of Security to Refresh

Select the set of rows to refresh.

You can select to refresh:

  • Classid

    Select to refresh the table with the selected row security or role-based permission lists IDs of users to whom they are attached.

  • Orpid

    Select to refresh the table with the selected user IDs and the permission lists assigned to them.