System Data

System data includes tables that configure security (users, permissions etc.) and scheduling system-wide settings. See the Scheduling System Schema Guide for more detail in the latest IFS Planning and Scheduling Optimization (PSO) documentation.

A system data scheduling model called 'Users.scheduling' exists to map Users and Roles related to IFS Scheduling Workbench. If the scheduling model is scheduled to run regularly, each user that has a role of 'FNDSCH_RUNTIME' (either directly or grantees of this global scheduling role) will be mapped to IFS PSO. This will then allow the user to log in to the Scheduling Workbench with all the default permissions a user has in IFS Scheduling.

If the administrator wishes to create a user with admin permissions on Scheduling Workbench, the user can be granted the 'FNDSCH_ADMIN' role (or a grantee of this role). This will grant the user the following extra permissions:

• AdministrationWorkspace
• Administrator
• DataCaptureView
• History
• ModifyViewableTasks
• ScheduleAnalysisView
• ViewAllDatasets
• PortalWorkspace

The mappings between IFS Applications Security configuration and IFS PSO configuration are the following:

• Each user in IFS Apps maps to a User in Scheduling.
• Each role in IFS Apps is mapped to a Group in IFS Scheduling.
• If a user is granted a role, the 'UserGroup' is used to link the Group (Role in IFS Apps) to the User (User in IFS Apps).

For detailed configuration of permissions, e.g. workspace, view, columns view or edit permissions, the administrator has to configure this via the 'Permissions' view in the Administration Workspace of the Scheduling Workbench.

There are two roles created as part of the installation (see FndschInstallation utility model in fndsch):

• FNDSCH_RUNTIME - Role needed for IFS Scheduling Workbench End User
• FNDSCH_ADMING -  Role needed for IFS Scheduling Workbench Administrator End User

The Users.scheduling file can be found in the FNDSCH module. The model contains selects on tables such as fnd_user, fnd_role_role. An example is:

groups Groups {

changedetection {

trigger on FND_ROLE_TAB {

objkey OBJKEY;

}

}

// Select all roles (granted roles) from fnd_role_role table, filtered by the granted_role

// - grantee_type of 'ROLE' and granted_role of 'FNDSCH_RUNTIME' (or any child roles of this).

// these will form the groups in IFS Scheduling, which are used to define 'groups of permissions' that users can be linked to (via UserGroup) - these

// can be viewed as a similar notion to roles in IFS Apps

SELECT

'FNDSCH_RUNTIME' id,

NULL group_id

FROM dual

UNION

SELECT

grantee id,

granted_role group_id

FROM fnd_role_role

WHERE grantee_type='ROLE'

START WITH granted_role = 'FNDSCH_RUNTIME'

CONNECT BY PRIOR grantee = granted_role;

}

Note that in the above example of a data fetch within the security scheduling model 'Users.scheduling', there is a 'changedetection' section. This is added so that roles can be updated automatically in the scheduling environment, when updated in EE.

However, for granted roles to users change detection is a bit different. A 'fulldiffonchange' needs to be implemented so that we make sure we send to the Scheduling environment the correct matching of users to roles/groups. The reason for using 'fulldiffonchange' in this particular case is because the table 'SECURITY_SYS_ROLE_TREE_TAB' doesn't have an objkey. Using triggers based on objkey is recommended, however if not possible 'fulldiffonchange' can be used as a

usergroup UserGroups {

changedetection {

trigger on FND_USER_ROLE_TAB {

objkey OBJKEY;

}

trigger on SECURITY_SYS_ROLE_TREE_TAB {

fulldiffonchange

}

}

For more detail of how this works please see section Change Detection.

Tables & Rules Mapped