OneRoster (1.2 và các nhóm nâng cao)

OneRoster là một tiêu chuẩn quốc tế để trao đổi danh bạ trường học (do 1EdTech ban hành): nó mô tả, theo một định dạng chung, các tổ chức, các năm học, các khóa học, các lớp, các ghi danh và các người dùng của một trường. Tiêu chuẩn này dùng để nối một SIS, một không gian làm việc số (ENT) hay một LMS với công cụ khác mà không phải nhập lại dữ liệu, cũng không cần định dạng độc quyền.

Trang này dành cho bộ phận công nghệ thông tin (CNTT) của trường. Trang mô tả những gì Omniscol cung cấp và tiếp nhận theo chuẩn OneRoster, cơ chế xác thực được yêu cầu, và phạm vi thực tế của từng chiều trao đổi.

Các phiên bản được hỗ trợ

Omniscol hỗ trợ OneRoster 1.2 Rostering — tầng nền (Org, AcademicSession, Course, Class, Enrollment, User, Demographics) — cùng với tầng OR-Groups (Advanced Groups Service), tiêu chuẩn nhóm bổ sung thêm ba thực thể (Group, GroupMembership, GroupAssociation) lên trên bản 1.2.

Tầng OR-Groups là một tiêu chuẩn đang trong quá trình ban hành. Nó bổ sung thuần túy lên trên bản 1.2: một Group chỉ tham chiếu đến các Class / User / Org / AcademicSession của bản 1.2, ở chế độ chỉ đọc. Theo thông báo, phiên bản 1.3 của OneRoster sẽ biến Class thành một dạng chuyên biệt của Group — hướng đi mà cách triển khai của Omniscol vốn đã đi theo.

Omniscol là bên phát dữ liệu (Omniscol → ENT / LMS)

Ở vai trò bên phát dữ liệu, Omniscol cung cấp danh bạ của trường ở chế độ chỉ đọc, qua một API REST tuân thủ OneRoster, để một ENT hay một LMS đọc được danh bạ đó.

  • Tầng nền Rostering 1.2 được phục vụ dưới /ims/oneroster/rostering/v1p2/… (ví dụ /orgs, /schools, /academicSessions, /courses, /classes, /enrollments, /users, /teachers, /students, /demographics, mỗi điểm truy cập đều có các biến thể lồng nhau của nó).
  • Tầng nhóm được phục vụ dưới /ims/oneroster/groups/v1p0/… (/groups, /groupMemberships, /groupAssociations cùng các biến thể lồng nhau).
  • Mặc định, phạm vi là năm học hiện hành; một tham số cho phép nhắm tới một năm học khác hoặc bao trùm mọi năm học.

Dữ liệu phản ánh kết quả lập kế hoạch đã hợp nhất của Omniscol (các thời khóa biểu đã công bố). Bên phát dữ liệu chỉ đọc theo chủ đích: không một thao tác ghi nào (PUT / DELETE) được mở ra — một hệ thống ở xa không điều khiển việc tạo hay xóa thực thể trong Omniscol.

Xác thực của bên phát dữ liệu

Các điểm truy cập của bên phát dữ liệu được bảo vệ bằng OAuth2 theo luồng client_credentials (mã thông báo máy với máy, không có người dùng), do máy chủ OAuth2 của Omniscol cấp. Chúng không dành riêng cho các tài khoản Premium: quyền truy cập được kiểm soát bằng phạm vi (scope) OAuth2, chứ không bằng gói dịch vụ. Mỗi phạm vi gắn với một dịch vụ cụ thể, và quyền đọc dữ liệu nhân khẩu học được tách riêng ngay bên trong bản 1.2:

Điểm truy cập Phạm vi được chấp nhận
Rostering 1.2 (không gồm dữ liệu nhân khẩu học) https://purl.imsglobal.org/spec/or/v1p2/scope/roster-core.readonly, https://purl.imsglobal.org/spec/or/v1p2/scope/roster.readonly
Rostering 1.2 /demographics https://purl.imsglobal.org/spec/or/v1p2/scope/roster.readonly, https://purl.imsglobal.org/spec/or/v1p2/scope/roster-demographics.readonly
OR-Groups (toàn bộ) https://purl.imsglobal.org/spec/or-groups/v1p0/scope/roster-group.readonly

Một mã thông báo OR-Groups không mở quyền vào tầng nền Rostering, và ngược lại. Không có phạm vi ghi nào được công bố. Các phạm vi đặc quyền do bộ phận quản trị Omniscol cấp vào lúc đăng ký ứng dụng khách OAuth2; một ứng dụng khách không thể tự cấp chúng cho mình. Việc quản lý ứng dụng khách OAuth2 và mã thông báo được mô tả tại OAuth2 / OIDC (nhà cung cấp) và API Omniscol.

Danh sách học sinh do tầng nhóm đảm nhiệm

Một lựa chọn mang tính cấu trúc: danh sách học sinh của một lớp hay một nhóm được cung cấp qua OR-Groups (GroupMembership), chứ không phải qua riêng tầng nền 1.2. Bên nhận dữ liệu nào chỉ đọc Rostering 1.2 sẽ có danh mục (Courses, Classes), các ghi danh giáo viên → khóa học và danh bạ người dùng, nhưng không có quan hệ thành viên của học sinh. Muốn biết ai đang ở lớp nào hay nhóm nào, bên nhận dữ liệu phải triển khai tầng OR-Groups. Lựa chọn này phản ánh mô hình của Pháp: một học sinh được ghi danh vào một lớp hoặc một nhóm, chứ không phải theo từng môn học.

Bên phát dữ liệu hoạt động theo REST. Còn định dạng gói CSV OneRoster (một tệp nén zip, mỗi tập dữ liệu một tệp) thì được hỗ trợ ở chiều nhập, dành cho những nhà cung cấp giao danh bạ bằng tệp thay vì bằng API — xem phần bên nhận dữ liệu bên dưới.

Omniscol là bên nhận dữ liệu (SIS → Omniscol)

Nhập danh bạ OneRoster (SIS → Omniscol): Omniscol có thể nhập danh bạ của một SIS tuân thủ OneRoster — tổ chức, năm học, khóa học, lớp, nhóm, người dùng và dữ liệu nhân khẩu học — qua API REST của nhà cung cấp hoặc qua một gói CSV, rồi đối chiếu vào dữ liệu của trường. Cấu hình tiếp nhận này thuộc về đồng bộ hóa với các hệ thống bên ngoài, khả dụng trên các tài khoản Premium và được xác định theo dự án cùng đội ngũ Omniscol.

Ở vai trò bên nhận dữ liệu, Omniscol nhập danh bạ của một SIS tuân thủ OneRoster rồi đối chiếu nó vào dữ liệu của trường. Cấu hình tiếp nhận này thuộc về đồng bộ hóa với các hệ thống bên ngoài: nó khả dụng trên các tài khoản Premium và được xác định theo dự án cùng đội ngũ Omniscol (xem Đồng bộ hóa với các hệ thống bên ngoài).

  • Đường truyền — hoặc là API REST của nhà cung cấp (địa chỉ gốc được cấu hình, cơ chế phân trang chuẩn của OneRoster được tuân thủ), với xác thực OAuth2 theo luồng client_credentials đối với máy chủ của nhà cung cấp; hoặc là một gói CSV (tệp nén zip).
  • Hồ sơ cấu hình — hồ sơ này cho biết cần đọc đến đâu: riêng tầng nền 1.2, tầng nhóm, hay bản ánh xạ dành cho giáo dục phổ thông Pháp. Một nhà cung cấp thuần 1.2, không có dịch vụ nhóm, vẫn nhập vào bình thường.
  • Áp dụng có kiểm soát — việc nhập tuân theo cùng nguyên tắc như các trình kết nối khác: Omniscol lấy về rồi đối chiếu dữ liệu, và quản trị viên phê duyệt việc áp dụng vào trường. Hệ thống ở xa không bao giờ đẩy thẳng dữ liệu vào Omniscol.
  • Nhập lại không sinh trùng lặp — các liên kết mã định danh bên ngoài đều được giữ lại, nên một lần nhập lại không tạo ra bản trùng, kể cả khi nhà cung cấp đổi tên một nhãn.

Hồ sơ Pháp (giáo dục phổ thông)

Hồ sơ Pháp dành cho giáo dục phổ thông ánh xạ các khái niệm của Pháp sang mô hình OneRoster: một lớp hành chính (chính là lớp theo nghĩa thực tế) trở thành một Group thuộc kiểu tổ chức chính; một nhóm trở thành một Group phục vụ việc giảng dạy; một nhóm của nhóm trở thành một Group liên kết ngang; các phân vùng và căn chỉnh nhóm trở thành các liên kết giữa các nhóm; việc phân công một giáo viên vào một khóa học trở thành một ghi danh giáo viên. Những mã định danh như INE hay mã định danh nhân sự được mang trong trường userIds của người dùng.

Mã định danh và quyền riêng tư

Mỗi thực thể được cung cấp đều mang một mã định danh ổn định là sourcedId.

  • Các mã định danh cấu trúc (tổ chức, năm học, khóa học, lớp, nhóm) ổn định và không đổi từ lần xuất này sang lần xuất khác: bên nhận dữ liệu có thể dựa vào chúng để đối chiếu dữ liệu theo thời gian.
  • Mã định danh của người dùng thì được ẩn danh: Omniscol không bao giờ đưa mã định danh gắn với danh tính người dùng lên đường truyền. Mã đưa lên đường truyền được dẫn xuất bằng một hàm một chiều (HMAC) riêng cho từng tài khoản; các ghi danh và các quan hệ thành viên dùng lại mã đó mà không bao giờ để lộ mã định danh gốc.

Trạng thái

  • Bên phát dữ liệu — đã sẵn sàng và có thể trình diễn mà không cần đối tác ở xa (bản thân việc xuất đã đủ). Rostering 1.2 và tầng OR-Groups được phục vụ ở chế độ chỉ đọc, với xác thực OAuth2.
  • Bên nhận dữ liệu — cấu hình nhập thuộc về gói đồng bộ hóa Premium. Việc đưa vào vận hành một luồng đồng bộ trực tiếp với một SIS còn tùy nhà cung cấp và, nếu có, tùy lịch trình của cơ quan chủ quản: việc này được xác định theo yêu cầu, theo từng trình kết nối. Đây không phải là một cơ chế đồng bộ chìa khóa trao tay dùng được ngay.

Xem thêm