Techniques used to integrate and automate Sakai in a large university

advertisement
CSU supports over 32000 students
65% of these via distance education
Both within Australia and across the world
CSU Interact went live in December 2007
Interact is CSU’s branded version of Sakai 2.4.x
7083 Sakai subject sites were created this year
50522 Sakai users registered
Automatically provision sites, tools, users and existing
applications according to a predefined timeline
Customise Edit tools to support business rules
Link to existing applications via a custom Sakai tool
Add functionality to merge sites
Allow real-time user authentication and role updates
Start of Session
-60 days
- Subject sites created
- Coordinator automated access
- Student access site prior to -28
days ONLY if Coordinator publishes
a tool prior to Start Session -28 days
Start of Session
-28 days
- Student automated access
- Other Staff automated access
- Read Only automated access
- Automated publishing of fixed
informational tools begins
Start of
Session
Start of Session
-3 business days
- Automated publishing
of fixed activity tools
End of Session
+70 days
- Student access removed
- Other Staff access removed
- Read Only access removed
End of Session
+18 months
- Academic access
removed
- Site archived
End of
Session
Note: this diagram is not to scale
Supported via Enterprise Data feeds into a configuration database
Overnight ‘Provisioner’ runs to sync configuration database with
Sakai via API’s
Supported by enterprise data feeds
Contains Sakai Subject sites with associated:
Create/Open/Close/Archive dates
Head of School and Subject Coordinator user data
Tools both Fixed, Optional (and pilot)
Used by primarily by provisioner and edit tools
Uses CSU enterprise data to construct subject
sites in Sakai for use by students and academics.
Create/updates roles and services in the roles
system so that students and staff can gain
access to their Sakai subject sites.
Runs nightly via cron job.
Fully customised Edit tools interface
Allows Enforcement of Business rules
Date driven availability (by category)
Set to be available to subject coordinator only
Once available to all cannot be removed
When tool available to all, auto publish site early
CSU Services tool - EASTS/Evals/Forum/OASIS/Outline
Screenshot to follow
Provides dynamic linking to existing applications
Queries the application via webservice
Displays either a link or message (if no access)
Link may be different for users/managers
Attempts to open application in popup window
Sites created for every cohort (subject offering)
Allows management of a single site for multiple cohorts
Example: Accounting 100 Distance students share the
same Sakai site as Internal students
Merges Cohorts only (not content)
Old site unpublished (and flagged for archival)
Confirmation email sent
Merge will flow through to Forums and Oasis
Screenshots to follow
IMS Provider (access to Sakai) + overnight process
Group Provider (access to subjects) live link to enterprise roles
system
Authz - feed changes back through Group Provider to update
enterprise roles system real-time.
Modification to participant list to show provided users
Screenshot to follow
MSI – Mandatory Subject Information
OSAM – Online Assignments and Marking
Tools and Sites
Deleting sites
Archiving
Subsites
Australia’s first Sakai Community QA Server (QA1-AU)
Built using Continuum for automated, repeatable builds
Running in a Solaris / Oracle environment
http://qa1-au.sakaiproject.org/
AUSakai 08
Hosted by Monash and CSU in November
For more details contact:
Nathan Bailey ( Nathan.Bailey@its.monash.edu )
Matt Morton-Allen ( MMorton-allen@csu.edu.au )
David Roma
Charles Sturt University
droma@csu.edu.au
Paul Bristow (Technical)
pbristow@csu.edu.au
Download