interoperability ps sa

Download
Share  Add to  Flag Embed
Uploaded from authorPOINT
Views:
 
Category: Product Traini..
     
 
License:   All Rights Reserved

Presentation Description

No description available.

Comments

Presentation Transcript

PeopleSoft Student Admin Interoperability with APBS and Desire2Learn: 

PeopleSoft Student Admin Interoperability with APBS and Desire2Learn Warren Alkire UW-MILER (Cambridge Technology Partners)

Agenda: 

Agenda APBS-SA Interop Status APBS-SA Current Design Models Desire2Learn Current Integration Desire2Learn Future Integration Next Steps

APBS Interop Status: 

APBS Interop Status Let’s cut to the chase SA Interop on hold awaiting funding Would be new functionality Part of APBS 5% budget cut Work left to easily resume Provided foundation for other interop projects

APBS Work to Date: 

APBS Work to Date Expanded on proof-of-concept work Documented Student Admin environments Designed alternative interop architectures Created initial data element list Element list needs institutional validation

APBS-SA Data Elements: 

APBS-SA Data Elements Interoperability data of 2 types Data requiring immediate update Data tolerant of day’s lag APBS-SA concentrating on immediate update data needs Warehouse may meet some needs Refreshed overnight Superset of immediate update data

Initial Data Element List: 

Initial Data Element List APBS Data Warehouse APBS-SA Interoperability Data

Initial Data Element List: 

Initial Data Element List Name (First, Middle, Last) Gender Birth date Campus Address (4 lines, City, State, Zip, Country) Race (AA purposes) Campus Email Campus Phone Home Addr andamp; Phone Check Addr andamp; Phone SSN Previous SSN IAA ID

Initial Data Element List: 

Initial Data Element List Appointment ID Appt Institution Appt Title Code Appt Title Effective Date Appt Major Dept (UDDS code) Appt Begin Date Appt End Date Primary Academic Organization Campus (Colleges) FERPA flag(s)

Initial Data Element List: 

Initial Data Element List Visa data I9 data Faculty Indicator Ed Prep Codes CUPA Codes

Student Admin Environments: 

Student Admin Environments Architecture shaped by environments Expand proof-of-concept scope '15' UW Institutions 13 comprehensive/doctoral Colleges administered centrally = '1' Extension counted as 1 Extension data in several systems Extension sees no current APBS need

Student Admin Environments: 

Student Admin Environments Student Admin Application Systems 10 PeopleSoft 5 Datatel, custom-built or mix of 'other' Only 67% PeopleSoft ('D') Student Admin Database Systems 11.5 Oracle 3.5 MS SQL Server, Unidata, DMS, 'other' 83% Oracle ('B' or 'C')

APBS-SA Interop Architectures: 

APBS-SA Interop Architectures Two Models Proposed Designed to address needs of: PeopleSoft and non-PeopleSoft Oracle and non-Oracle Directory-based Model Web Services Model

Directory-based Model: 

Directory-based Model Data primarily identity data Directory serves as hub of identity data APBS publishes updates to directory SA systems consume updates from directory Expect to use IAA Registry as directory Reuse APBS and SA systems’ connections (current and future) to IAA Agreement in principle, details TBD

Web Services Model: 

Web Services Model Web Services: info systems using Internet Expansion of proof-of-concept model Asynchronous messaging to provide near, real-time updates Tools Application Messaging likely for PeopleSoft DoIT Framework full web services for Oracle Third-party possible for all or others

APBS-SA Summary: 

APBS-SA Summary No promises for APBS-SA interoperability Funding (e.g. spending priority) required from some source APBS and SA interoperability discussion likely still needed in other forums

Desire2Learn Current Integration: 

Desire2Learn Current Integration Phase 1 Top Priorities External Authentication Class Rosters Tight Schedule influenced choices Authentication to campus LDAP Class Rosters are batch interface

D2L Class Rosters: 

D2L Class Rosters Comply with IMS Enterprise Specification IMS=XML specification for data exchange with Learning Management System (LMS) D2L committed to IMS compliance DEPS cloned from PeopleSoft IMS extract IMS version 1.1 D2L supported IMS elements only WebDAV transport mechanism

IMS Enterprise Spec: 

IMS Enterprise Spec IMS version 1.01 vs. version 1.1 PeopleSoft extract v1.01 compliant D2L developed IMS import for UW so v1.1 DEPS Subset of full IMS spec Snapshot vs. Update mode – only Snapshot supported by D2L at present Drop processing challenging in PeopleSoft D2L determines drops by missing records

IMS Enterprise Spec: 

IMS Enterprise Spec andlt;personandgt; data Information on students and instructors May not be from PeopleSoft andlt;groupandgt; data Information about classes Can be used for other groupings andlt;membershipandgt; data – associates students and instructors to classes (Groups)

Identifying People: 

Identifying People D2L needs login USERID D2L uses independent person ID PeopleSoft’s person ID is EMPLID Extract sends EMPLID for D2L person ID USERID to ID (EMPLID) cross-reference in D2L

Identifying Classes: 

Identifying Classes Data sent at class section level Strict, PeopleSoft definition of 'class' Enrolling in or teaching class drives select Sections can be combined in D2L but left separate in PeopleSoft Future feeds from D2L must provide unique keys to the class level Class ID generated by SQR

Class ID Parts: 

Class ID Parts Institution – 5 characters Term Code – Term name displayed in D2L Session Code Subject Course Number Section Class Number UWSBP_1038_1_ENGL_100_SEC001_8003

FERPA: 

FERPA Limited FERPA-controlled data sent to D2L Main FERPA concern is email address FERPA handled in D2L, not extract – data sent in extract; masked in D2L FERPA limited to yes or no for now Extension to IMS specification

Using DEPS: 

Using DEPS Standard PeopleSoft installation PeopleSoft setup required because DEPS was cloned from PeopleSoft SQR 'ALLDONE' file available for automation Need to set up WebDAV access Selection criteria constant throughout term USER, CLASS and ROSTER submitted together or separately

Define Data Source: 

Define Data Source

Define LMS Target: 

Define LMS Target

Define LMS Type: 

Define LMS Type

Data Selection: 

Data Selection To flag or not to flag, that is the question LMS File Type of 'XML' provided by PS XML file type can be set at Institution Level Course Level Class Level Other than Class Level, choice must be made before class schedule created

Institution Level Flag: 

Institution Level Flag

Course Level Flag: 

Course Level Flag

Class Level Flag: 

Class Level Flag

Running the Process: 

Running the Process If using XML File Type, set File Type for each class according to institutional policy Place process on desired menu Standard Process Scheduler run After run, 'WebDAV' to D2L server

Running – Setup: 

Running – Setup

Class Selection Options: 

Class Selection Options All Classes Class Number XML Flagged Classes Filter (All Classes) Filter (XML Flagged Classes)

Running – Criteria: 

Running – Criteria

Running – Output: 

Running – Output

Desire2Learn Future Integration: 

Desire2Learn Future Integration Grade Import – highest priority Building prototype technical 'legos' Comparing Gradebook and D2L grading Define requirements Possible near, real-time integration – crude, partial prototype built Next phase as defined by D2L teams Authentication by IAA

Next Steps - APBS: 

Next Steps - APBS Build business case for 'HR' data in SA needs Find funding Finalize data elements needed Choose architecture Define project and implement it

Next Steps – D2L: 

Next Steps – D2L Implement current at other PS-SA/D2L Define Requirements for Grade Import Develop Grade Import Develop near, real-time interoperability Where are the highest business needs? Continue assembling interop toolbox

Slide40: 

Questions? Discussion?