PeopleSoft Portal Sync | PeopleSoft Tutorial

PeopleSoft Portal Sync

When you migrate permission lists and portal registries from one database to another, Portal Security Sync process has to be run in the target environment for these permission lists and portal registries to take effect. If your company has separate roles for PeopleSoft Admin and Security Admin, you also have the option of ignoring to migrate the roles and permissions and letting your Security Admin perform these tasks manually, followed by Portal Security Sync process.
The reason why Portal Sync is needed is because portal object security settings get unsynchronized when portal objects are moved from one database to another using the Project Copy feature in PeopleSoft Application Designer. When you merge projects this way, if the projects contain any portal objects with identical names, the security settings of the portal objects in the last project copied overwrite the security settings of portal objects copied earlier. Also, when a copied portal object doesn’t overwrite an existing object, it changes the structure of the resulting portal registry hierarchy.

PeopleSoft Portal Security Sync

Running the Portal Security Sync (PORTAL_CSS, AE Program) reinstates the correct security relationships between objects in the portal registry after you copy a project that contains portal objects. PeopleSoft portal security sync process is be run from the navigation: PeopleTools > Portal > Portal Security Sync.  It invokes PORTAL_CSS appengine program.

Parameters required to run Portal Security Sync process?
  1. A mandatory ‘Portal Name’ – Specify a portal name which comes with a prompt button. For example: select EMPLOYEE portal. This process can be used only on local portals and not on portals on remote databases. In addition, from any local portal, it can be run against another local portal.
  1. An optional ‘Delete Invalid Security Option’ check box – Select the Delete Invalid Security check box to remove non-existing roles and permission lists from folders and content references. When portal objects are moved from one database to another, roles and permission lists assigned to folders and content references on the source database may not exist on the target database and they become invalid. Selecting this option will delete such invalid security options. When a non-existing role or permission list is found on the portal registry structure, it is removed from that portal registry structure.
    Note. When the Delete Invalid Security option is selected, the PORTAL_CSS process runs more slowly as it checks every role and permission list on every portal registry structure.
Relationship between objects in portal registry?
The hierarchical relationships and dependencies between objects in the portal registry determine what security settings each object must have. The portal won’t work correctly if these security relationships aren’t maintained. Some examples of these relationships:
  • A folder that is not public or hidden must have at least the level of access that its immediate child objects (folders, content references, and content reference links) have.
  • A content reference link must have exactly the same level of access as the object (content reference or content reference link) to which it links.
  • A content reference that represents a PeopleSoft component or iScript must have exactly the same level of access as the object that it represents.

The portal objects are synchronized as follows for the specified local portal name:

  1. The security settings of each content reference are compared to the component or iScript that it represents, and updated to match.
  2. The security settings of each content reference link are compared to the content reference or content reference link to which it connects, and updated to match.
  3. The security settings of each content reference and content reference link are propagated to its parent folder, in addition to the parent folder’s existing settings.
    None of the parent folder’s existing security access is reduced.

    Note. The settings aren’t propagated if the parent folder is public or hidden.
  4. The security settings of each folder are propagated to its parent folder, in addition to the parent folder’s existing settings.
    None of the parent folder’s existing security access is reduced.

    Note. The settings aren’t propagated if the parent folder is public or hidden.

Common security synchronization errors:

  • No permissions in PSAUTHITEM for object %1
  • Cref %1 points to Menu: %2, Component: %3 which doesn’t exist.
    Note. When this message appears you need to delete the invalid cref.
Apurva Tripathi
 

>