Requirements for Data Provisioning using Providers and Batch Processes
Provisioning Data in Sakai: Requirements
The following is a list of requirements necessary to meet campus needs for providing data to Sakai for pilot rollouts. The list details data provided via Sakai providers, and coming from the identified sources below.
Provisioning Users
Users should be provisioned via the UCDavisUserDirectoryProvider mechanism. This mechanism will both handle (auth via SecureWeb, WebDav, and identity management)
*Batch loading is not occuring for users. Users and their accounts are created dynamically via the UserDirectory lookup mechanism (e.g. getUser()).
On the fly provisioning
*Users who may not already be able to log into Sakai should be automatically provided upon authentication.
*Authentication for normal Sakai login procedure should happen via Secureweb only
*No provisioning of users after WebDAV auth is necessary.
*Any person who has an active LDAP account will be provisioned (once auth'd), this is represented currently by feeds into the external database by Mothra_Person feeds
*Handled via the UCDavisUserDirectoryProvider mechanism
*Q:What role are users given once provisioned? They are given the default role of "registered". Enterprise level roles need to be well defined, see JIRA ticket https://jira.ucdavis.edu:8444/jira/browse/SAK-37
Provisioning Roles/Groups
User access to resources, sites, realms, etc. should be handled via both a batch tool, and the UCDavisGroupProvider mechanism in Sakai. This provider should handle gathering enterprise level roles for users (e.g. Scott is a Student), and also roles for a particular entity (e.g. Course, CRN #.....). Realms will be created via these mechanisms, defining what the user has access to see in Sakai. A note, inherent admin level roles will be designated through Sakai's admin user to another user in the system.
Batch load
*Batch loading should occur by an admin via the SVM model Import Tool, or another mechanism. Batching should only be for course sites. Current development for the campus batch loading method is done by Scott Amerson, and the specs are defined http://confluence.ucdavis.edu:8080/confluence/display/UCDSAKAI/Course+Batching+Strategy.
*Sakai's internal tables store users' roles in realm tables. These realm tables are inserted/updated when users (via providers) interact with courses that have been batch created. All users' roles will be designated by affiliation queries against the enterprise level Oracle mViews.
On the fly provisioning
*User's roles should be auto-provisioned via the provider mechanism in Sakai. A direct query against the above views, and check against Sakai, will allow users to be given roles dynamically.
*Q:What role by default?
*Automatic provisioning should happen via the UCDavisGroupProvider mechanism, and their association is determined by these views. (e.g. Scott = student in CRN..)
Creating Courses
Courses and course data should all be created via a batch process. This process will create course sites so that someone logging in can see their current course memberships automatically.
Membership and course members are assigned dynamically via the provider mechanisms.
TODO Scheduling for courses should be dynamically provided vs. batch created.
Batch load
*Courses should be batch loaded by an admin via the SVM model Import Tool, or equivalent (see above information for current development on this tool). A direct query against materialized views from Banner, and other subsets of data will provided the necessary data elements for Sakai to use to create course sites.
*Handled by the ucd-enterprise-data module CourseService, and members provided by CourseManagementProvider mechanism
*Existing course content in MyUCDavis should be imported into Sakai using Melete or other possible import tools available for Sakai.
Batching courses based on enrollment or not?
With the need to create course sites in advance of the batch creation term, courses should not be restricted to enrollment. However, having this requirement has an alternative impact in that instructors who log into SmartSite that have been associated to more than 1000 crns will not be able to see their sites correctly. The reason for this, as found in unit and integration testing, is that the database has a limit (1000) to the number of parameters in the IN statement for realms.
see JIRA item (https://jira.ucdavis.edu:8444/jira/browse/SAK-185)
On the fly provisioning
No current on the fly mechanism for course provisioning is being developed. Other attributes of the courses (e.g. Sections, Schedules, cross-listing, Rosters, etc. are loaded via the CourseManagementProvider mechanism or to be defined by the to-be new Course Mgmt API in Sakai).