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.

Tables & Rules Mapped

Table	Rule
Entry	Entry
External_Task_Parameter	ExternalTaskParameter
Groups	Groups
List	List
Org_Validation_Value	OrgValidationValue
Organisation_Permission	OrganisationPermission
Polygon	Polygon
Polyline	Polyline
Profile	Profile
System_Data_Update	SystemDataUpdate
Terminology_Organisation	Terminology_Organisation
Travel_Time_Profile	TravelTimeProfile
Group_List	GroupList
Group_Permission	GroupPermission
List_Entry	ListEntry
Org_Schedule_Exception_Type	OrgScheduleExceptType
Organisation_List	OrganisationList
Polyline_Point	PolylinePoint
Profile_Parameter	ProfileParameter
Travel_Time_Barrier	TravelTimeBarrier
Travel_Time_Weighting	TravelTimeWeighting
Users	Users
Well_Known_Area	WellKnownArea
Travel_Time_Barrier_Blockage	TravelTimeBarrierBlock
Travel_Time_Polygon	TravelTimePolygon
User_External_Task	UserExternalTask
User_Group	UserGroup
User_Custom_List	UserCustomList
User_List	UserList
User_Parameter	UserParameter
User_Permission	UserPermission

Users Integration

A system data scheduling model called 'Users.scheduling' exists to map Users and Permission Sets related to IFS PSO Workbench. Read more about Users Integration.

The Users.scheduling file can be found in the IFS Optimization Framework (FNDSCH) component. The model contains data fetch queries on tables such as fnd_user, fnd_role_role.

Example:

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 Cloud

        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 permission sets can be updated automatically in IFS PSO when updated in IFS Cloud.

However, the change detection for granted permission sets to users is implemented differently. A 'fulldiffonchange' needs to be implemented so that we make sure we send the correct matching of users to permission sets/groups to PSO. 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.

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.