banner integration for elearning · ldis-p implementation ... this message reference guide defines...
TRANSCRIPT
Banner Integration for eLearningMessage Reference Guide
Release 8.0May 2008
Banner®, Colleague®, PowerCAMPUS®, Luminis® and Datatel® are trademarks of Ellucian or its affiliates and are registered in the U.S. and other countries. Ellucian, Advance, DegreeWorks, fsaATLAS, Course Signals, SmartCall, Recruiter, MOX, ILP, and WCMS are trademarks of Ellucian or its affiliates. Other names may be trademarks of their respective owners.
©2006-2008 Ellucian. All rights reserved. The unauthorized possession, use, reproduction, distribution, display or disclosure of this material or the information contained herein is prohibited.
Contains confidential and proprietary information of Ellucian and its subsidiaries. Use of these materials is limited to Ellucian licensees, and is subject to the terms and conditions of one or more written license agreements between Ellucian and the licensee in question.
In preparing and providing this publication, Ellucian is not rendering legal, accounting, or other similar professional services. Ellucian makes no claims that an institution's use of this publication or the software for which it is provided will guarantee compliance with applicable federal or state laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services from competent providers of the organization’s own choosing.
Prepared by: Ellucian4375 Fair Lakes CourtFairfax, Virginia 22033United States of America
Revision History
Publication Date Summary
May 2009 New version that supports Banner Integration for eLearning 8.0.1 software.
Contents
Banner Integration for eLearning 8.0Message Reference Guide
Chapter 1 Introduction
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1
Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-2
System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
Message Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
Overall System Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
System Functions That Produce Messages . . . . . . . . . . . . . . . . . . . .1-5
Maintain College . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-5Maintain Department . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6Maintain Course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6Maintain Course Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6Maintain Term . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7Maintain Section Cross-List . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7Maintain Person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7Maintain Student Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7Maintain Faculty Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7Assign Student Grades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8
High-Level Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8
Message Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9
SIS Extract Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10
Multi-Entity Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-11
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-11
Message Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
May 2008 Banner Integration for eLearning 8.0 iiiMessage Reference Guide
Contents
Chapter 2 LDIS-P Messaging for College Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-2
Create College Group - Sample XML. . . . . . . . . . . . . . . . . . . . . . . .2-3
Update College Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . .2-3
Delete College Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . .2-4
MEP College Group - Sample XML. . . . . . . . . . . . . . . . . . . . . . . . .2-4
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .2-5
Chapter 3 LDIS-P Messaging for Department Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
Create Department Group - Sample XML . . . . . . . . . . . . . . . . . . . . .3-3
Update Department Group - Sample XML . . . . . . . . . . . . . . . . . . . . .3-3
Delete Department Group - Sample XML. . . . . . . . . . . . . . . . . . . . . .3-4
MEP Department Group - Sample XML . . . . . . . . . . . . . . . . . . . . . .3-4
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-4
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .3-5
Chapter 4 LDIS-P Messaging for Course Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Create Course Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . .4-4
Update Course Group - Sample XML. . . . . . . . . . . . . . . . . . . . . . . .4-5
Delete Course Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . .4-6
MEP Course Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . . .4-6
iv Banner Integration for eLearning 8.0 May 2008Message Reference GuideContents
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .4-7
Chapter 5 LDIS-P Messaging for Term Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3
Create Term Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . . .5-3
Update Term Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . . .5-4
Delete Term Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . . .5-5
MEP Term Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . . . .5-5
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .5-6
Chapter 6 LDIS-P Messaging for Course Section Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
Create CourseSection Group - Sample XML . . . . . . . . . . . . . . . . . . . .6-5
Update CourseSection Group - Sample XML. . . . . . . . . . . . . . . . . . . .6-6
Delete CourseSection Group - Sample XML . . . . . . . . . . . . . . . . . . . .6-7
MEP CourseSection Group - Sample XML . . . . . . . . . . . . . . . . . . . . .6-8
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-8
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .6-9
Chapter 7 LDIS-P Messaging for Cross-List Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-4
Create CrossListedSection Group - Sample XML . . . . . . . . . . . . . . . . .7-4
Update CrossListedSection Group - Sample XML . . . . . . . . . . . . . . . . .7-6
May 2008 Banner Integration for eLearning 8.0 vMessage Reference Guide
Contents
Delete CrossListed Section Group - Sample XML . . . . . . . . . . . . . . . . .7-7
MEP CrossListedSection Group - Sample XML . . . . . . . . . . . . . . . . . .7-8
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .7-8
Chapter 8 LDIS-P Messaging for Person Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5
Create Person (Student Role) - Sample XML. . . . . . . . . . . . . . . . . . . .8-5
Create Person (Faculty Role) - Sample XML . . . . . . . . . . . . . . . . . . . .8-6
Update Person - Sample XML . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7
MEP Person - Sample XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .8-9
Chapter 9 LDIS-P Messaging for Student Enrollment Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
Create Student Enrollment Membership - Sample XML . . . . . . . . . . . . . .9-4
Update Student Enrollment Membership - Sample XML . . . . . . . . . . . . . .9-5
Delete Student Enrollment Membership - Sample XML . . . . . . . . . . . . . .9-6
MEP Student Enrollment Membership - Sample XML . . . . . . . . . . . . . . .9-7
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .9-7
vi Banner Integration for eLearning 8.0 May 2008Message Reference GuideContents
Chapter 10 LDIS-P Messaging for Faculty Assignment Data
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Create Faculty Assignment Membership - Sample XML . . . . . . . . . . . . . .10-3
Update Faculty Assignment Membership - Sample XML . . . . . . . . . . . . . .10-3
Delete Faculty Assignment Membership - Sample XML . . . . . . . . . . . . . .10-4
MEP Faculty Assignment Membership - Sample XML . . . . . . . . . . . . . . .10-5
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5
Expected Consumption Behavior . . . . . . . . . . . . . . . . . . . . . . . .10-5
Chapter 11 LDIS-P Messaging for Assign Student Grades
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1
Message Production Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4
Single Student Grade - Sample XML . . . . . . . . . . . . . . . . . . . . . . . .11-4
Multiple Student Grades - Sample XML . . . . . . . . . . . . . . . . . . . . . .11-5
Multiple Student Grades (Multiple Members With Same Source ID) - Sample XML11-7
MEP Student Grade - Sample XML. . . . . . . . . . . . . . . . . . . . . . . . .11-9
Message Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9
recordid Tag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9
originalsource Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10
Reply Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10
Expected Consumption and Response Behavior . . . . . . . . . . . . . . . .11-10
\Status Code - Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-11
Status Code - Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-12
Infrastructure Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-12Invalid XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-13Failed SIS Validation for All Members) . . . . . . . . . . . . . . . . . . . . . .11-13
Status Code - Partial Success . . . . . . . . . . . . . . . . . . . . . . . . . . .11-15
May 2008 Banner Integration for eLearning 8.0 viiMessage Reference Guide
Contents
Appendix A LDIS-P Support for Multi-Entity Processing
LDIS-P Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-1
SIS Institution Extract Process . . . . . . . . . . . . . . . . . . . . . . . . . .A-2
Institution Group - Sample XML . . . . . . . . . . . . . . . . . . . . . . . . .A-3
viii Banner Integration for eLearning 8.0 May 2008Message Reference GuideContents
May 200
1 Introduction
Banner® Integration for eLearning offers you the power to integrate your Banner administrative system with Luminis Platform and the course tools of Learning Management Systems (LMS) such as Blackboard Learning System’s CE Enterprise and Vista Enterprise. These products combine information systems, learning tools, online services, communication tools, and community tools into one easy-to-use point of access for all members of your campus community.
About This Manual
This message reference guide defines the business processes and XML messages that are part of Banner Integration for eLearning. This information facilitates the integration of Ellucian student information systems with learning management systems and Luminis® Platform through enterprise messaging.
Although XML is used extensively, this document is more functional in nature. It does not define how messages are transported, transformed, or processed. These facets of the overall solution are covered in other related documentation.
Related Documentation
You should refer to the following related documentation for the planning, installation, and configuration of Banner Integration for eLearning. Your success with the implementation depends on it.
• Banner Integration for eLearning Administration Guide - Describes how to implement Banner Integration for eLearning, ensuring data synchronization and successful event and report processing.
• Banner Integration for eLearning Installation Guide – Describes how to install and configure Banner and Luminis Platform components with partner systems.
• Learning Management Gateway Installation Guide – Describes how to install and operate the Learning Management Gateway, the software component used to transfer data between the Banner database and the Luminis Message Broker.
• Luminis Message Broker (LMB) Installation and Administration Guide – Describes how to install and set up the Luminis Message Broker, the software component used to transfer information between Banner and learning management systems.
8 Banner Integration for eLearning 8.0 1-1Message Reference Guide
Introduction
1-2
• Integration Solutions Interdependencies – Lists all hardware and software dependencies required for installing Banner Integration for eLearning.
• Release and upgrade guides for various Banner baseline, self-service Web products, and Integration Technologies component middleware – Describe how to install and implement the products used with the Banner Integration for eLearning. The specific manuals you use depend on which products your institution is using. You can find the latest documentation for this software on the Customer Support Center under the product name.
• Luminis Platform documentation – Describes installation and configuration of Luminis Platform.
• Blackboard documentation – Describes installation and configuration of the Blackboard Learning System products. Find the most current Blackboard documentation for Banner Integration for eLearning on the Blackboard Web site:www.blackboard.com.
Terminology
The following terms are subject to ambiguity and are defined here to provide clarity.
Term Definition
Authoritative source Definitive or master source for some unit of quantifiable data in the enterprise. Usually implemented as an application or database.
Authoritative source systems publish synchronization messages when changes are made to data for which they are authoritative. Conversely, systems that are not authoritative must request the authoritative source to change any ‘data that they are trying to initiate.
College Subdivision or school within an institution of higher learning that offers courses and grants degrees in a particular field
Course Unit of a complete body of prescribed studies constituting a curriculum
Course section Specific instance of a course that is taught during an academic period. Also called section.
Cross-listed section A course section that, although listed separately in the course catalog, actually is taught by the same instructor via the same delivery mechanism within the same academic period, at the same time and in the same place, if applicable
Department Academic department in an institution of higher learning
Banner Integration for eLearning 8.0 May 2008Message Reference GuideIntroduction
May 200
System Overview
The principle objective behind Banner Integration for eLearning is to provide a near-real-time, seamless integration solution between Banner and an LMS that unifies an institution’s academic and administrative computing environments.
Achieving this objective requires the synchronization of enterprise data objects between the two systems via messaging. This synchronization occurs when these objects are created, updated, or deleted by system users, other systems, or system processes. Authoritative systems that “own” the enterprise copy of data objects publish synchronization messages that non-authoritative systems are expected to consume to keep data synchronized. Non-authoritative systems that need to update the enterprise copy of data objects are expected to make requests to the authoritative source for these changes.
The following sections describe the general system responsibilities in the integrated solution, the context in which messaging occurs (that is, the Banner and third-party LMS
DTD Document type definition
IMS-ES IMS Enterprise Specification
Institution A separate entity of higher education
JMS Java Message Service
LDIS-P LDIS protocol
LMB Luminis Message Broker
LMG Learning Management Gateway
LMS Learning management system
MEP Multi-Entity Processing
Section Specific instance of a course that is taught during an academic period. Also called course section.
SIS Student information system
Sync Synchronization
Term Academic period with specific beginning and end dates
VPD Virtual Private Database
Term Definition
8 Banner Integration for eLearning 8.0 1-3Message Reference Guide
Introduction
1-4
functions associated with message production), and the high-level flow of messages between the systems.
Banner Integration for eLearning also includes data extract processes that are used for initial and periodic synchronization of data for which the SIS is authoritative. One extract supports not only an LMS and Luminis Platform, but can also be used to populate assessment solutions such as TracDat. The extract process and its contents are described in more detail in “SIS Extract Process” on page 1-10.
By providing data synchronization via messaging as well as a batch extract, Banner Integration for eLearning supports both the event-driven and “snapshot” interface architectures described in the IMS Enterprise Best Practice and Implementation Guide, Version 1.1.
Message Specification
The messages in this document are defined to be common for all Ellucian student information systems.
The XML representation of business objects is based on the LDIS protocol, version 2.0, found in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification 2.0). The LDIS protocol specification is an implementation of the industry-standard IMS Enterprise Specification (IMS-ES) 1.1, which defines an XML data format for the exchange of information with learning management systems. The LDIS protocol extends the IMS-ES data definition, providing additional data elements and more detailed communication semantics and responsibilities of producers and consumers of messages based on the LDIS protocol. IMS-ES can be found online at http://www.imsproject.org.
Overall System Responsibilities
The LMS provides a browser-based content delivery mechanism through which educators can develop and publish course materials, educate via assignments, quizzes, and online chat facilities, and perform administrative functions such as assigning grades.
The SIS acts as the system of record for student, faculty, and administrative information:
• Institution’s organizational hierarchy
• Student academic records
• Existing and historical catalog and class schedules
The integrated solution requires the learning management system to have access to student, faculty, course, course enrollment, and faculty assignment data in order to allow authorized access to system functions. Additionally, the systems must integrate to allow grades entered in the learning management system to be properly reflected in the SIS.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideIntroduction
May 200
These responsibilities and their implications for messaging are expanded in greater detail in the next section, “System Functions That Produce Messages” on page 1-5.
System Functions That Produce Messages
To achieve near real-time data synchronization, messages are produced as the result of data changes in both the SIS and LMS. The following functions produce messages:
• “Maintain College” on page 1-5
• “Maintain Department” on page 1-5
• “Maintain Course” on page 1-6
• “Maintain Course Section” on page 1-6
• “Maintain Term” on page 1-6
• “Maintain Section Cross-List” on page 1-7
• “Maintain Person” on page 1-7
• “Maintain Student Enrollment” on page 1-7
• “Maintain Faculty Assignment” on page 1-7
• “Assign Student Grades” on page 1-7
Maintain College
The SIS is considered authoritative for information about colleges. According to the LDIS protocol, college is defined as a subdivision or school within an institution of higher learning that offers courses and grants degrees in a particular field, for example, the College of Engineering at the Smythe University.
The provision of college data from the SIS allows the LMS to capture and store information about the institution’s organizational hierarchy, which is critical to understanding and maintaining the relationships between course sections and the groups that sponsor them.
Because the LMS may require this data to establish security and functional constraints, the data is published as it is created, updated, and deleted in the SIS.
Maintain Department
The SIS is considered authoritative for information about departments. According to the LDIS protocol, department is defined as an academic department in an institution of higher learning.
8 Banner Integration for eLearning 8.0 1-5Message Reference Guide
Introduction
1-6
The provision of department data from the SIS allows the LMS to capture and store information about the institution’s organizational hierarchy, which is critical to understanding and maintaining the relationships between course sections and the groups that sponsor them. This information is also necessary for linking faculty to their respective organizational units.
Because the LMS may require this data, the data is published as it is created, updated, and deleted in the SIS.
Maintain Course
The SIS is considered authoritative for information about academic courses. According to the LDIS protocol, course is defined as a unit of a complete body of prescribed studies constituting a curriculum. The SIS differentiates between courses and course sections, which are specific instances of a course offered within a specific academic period.
In the SIS, courses act as templates for course sections, providing the following default data:
• Credit hours
• Delivery mechanism
• Relationships to organizational structures such as colleges and departments
As a result, the publication of course data by the SIS provides a critical link between course sections and the institution’s organizational hierarchy.
Because the LMS may require this data, the data is published as it is created, updated, and deleted in the SIS.
Maintain Course Section
The SIS is considered authoritative for information about course sections. According to the LDIS protocol, a section or course section is defined as a specific instance of a course that is taught during an academic period. The date ranges for the course section may exist outside the normal term dates.
The LMS requires section data as a starting point for content development and delivery as well as a basis for the establishment of authorized access to such content. As a result, course section data is published as it is created, updated, and deleted in the SIS.
Maintain Term
The SIS is considered authoritative for information about terms. According to the LDIS protocol, a term is defined as an academic period with specific beginning and end dates.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideIntroduction
May 200
Term is the basis for most academic processes and data in the SIS and, as such, is the principle control for synchronization with external systems. Only data that is associated with a “publishable” term is published for consumption by external systems.
Maintain Section Cross-List
According to the LDIS protocol, a cross-listed section is defined as one that, although listed separately in the course catalog, actually is taught by the same instructor via the same delivery mechanism within the same academic period, at the same time, and in the same place, if applicable.
The LMS requires cross-listed section data so that the individual sections can be linked and content can be developed and delivered via the same mechanism. As a result, cross-listed course section data is published as it is created, updated, and deleted in the SIS.
Maintain Person
The SIS is considered authoritative for information about persons, which includes person name, biographical, and contact data. This information is often created and updated within the context of a person’s role. For example, the person’s address might be updated when a user accesses the person’s student record. As a result, although some role-specific data is published by the SIS, the principal message-producing use case entails the creation and update of person data. Person data is not deleted in the SIS.
Maintain Student Enrollment
The SIS is authoritative for information about a student’s enrollment in particular sections of a course. This data includes whether the enrollment is active or inactive, gradable or not, and even the type of grading that should be used (that is, the grade mode). The SIS publishes student enrollment data as it is created, updated, and deleted.
Maintain Faculty Assignment
The SIS is authoritative for information about faculty assignments (that is, the relationship of a faculty member to a particular section of a course, including whether or not the faculty member is the primary or subordinate instructor for the section). The SIS publishes faculty assignment data as it is created, updated, and deleted.
Assign Student Grades
The SIS is authoritative for student grades. It might not, however, be the sole entry point, due to the provision by some LMSs of a facility by which course administrators can record grades for students taking online courses. To ensure that grades entered in the LMS adhere to the business rules established within the SIS, the LMS is expected to approve updates to student enrollments as part of its grade assignment workflow via an UpdateRequest
8 Banner Integration for eLearning 8.0 1-7Message Reference Guide
Introduction
1-8
message. The SIS provides a corresponding UpdateReply message with the status of the request.
High-Level Message Flow
The following sequence diagrams show the high-level message flow between the SIS and the LMS. The enterprise objects that are the subject of these messages and the messages themselves are documented in Chapters 2 through 11 of this guide.
Department created
Department updated
Department deleted
Term created
Term updated
Term deleted
Course created
Course updated
Course deleted
Course section created
Course section updated
Course section deleted
College created
College updated
College deleted
LearningManagement
System
Banner StudentInformation
System
LDIS-P College p (no recstatus)
LDIS-P College group (no recstatus)
LDIS-P College group (recstatus=3
Department recstatus
Department recstatus
Department recstatus
Term recstatus
Term recstatus
Term recstatus
Course recstatus
Course recstatus
Course recstatus
CourseSection recstatus
CourseSection recstatus
CourseSection recstatus
Message Flow(part 1 of 2)
Update systemas appropriate
Update systemas appropriate
Update systemas appropriate
Update systemas appropriate
Update systemas appropriate
Banner Integration for eLearning 8.0 May 2008Message Reference GuideIntroduction
May 200
Message Transport
Banner Integration for eLearning implements message transport services with a Java Message Service (JMS) provider, specifically, the Luminis Message Broker (LMB). The SIS produces and consumes messages using an adapter called the Learning Management Gateway (LMG), which is responsible for communication with LMB.
As the hub of the messaging enterprise, the LMB requires the establishment of topics and queues to which messages are published and from which messages are consumed. Ellucian provides a configuration script that establishes the queues and topics that are required by LMG as well as a SyncError topic to which third-party adapters are expected to publish if a sync message produced by the SIS cannot be consumed.
The following table shows the default name and use for each topic and queue.
Person created
Person updated
Student enrollment added
Student enrollment updated
Student enrollment deleted
Faculty assignment added
Faculty assignment updated
Faculty assignment deleted
LearningManagement
System
Banner StudentInformation
System
LDIS-P CrossListedSection p (no atus)
LDIS-P CrossListedSection group (no recstatus)
LDIS-P CrossListedSection group (recstatus=3
Course section cross-list created
Course section cross-list updated
Course section cross-list deleted
LDIS-P Person recstatus
Person recstatus
bership group (no )
LDIS-P membership group (no )
LDIS-P membership group ( = )
LDIS-P membership group (no )
LDIS-P membership group (no )
LDIS-P membership group ( = )
Update systemas appropriate
Message Flow(part 2 of 2)
Update systemas appropriate
Update systemas appropriate
Update systemas appropriate
8 Banner Integration for eLearning 8.0 1-9Message Reference Guide
Introduction
1-10
The publication and expected consumption behavior for specific LDIS objects is covered in more detail in Chapters 2 through 11 of this manual.
SIS Extract Process
In addition to the asynchronous messaging model, Banner Integration for eLearning provides an “on-demand” model described in the IMS Enterprise Specification, which can be found online at . This is an extract process that produces the same XML as that contained in comparable sync messages.
The consolidated extract process fulfills the following requirements:
• Initially populates a partner system
• Adds data to a partner system en masse
• Re-synchronizes a partner system, if required
The extract process can extract the following objects:
• Term
• College
• Department
Topic/Queue Use
com_sct_ldi_sis_Sync Topic to which all data produced by the SIS is published.
com_sct_ldi_sis_LmsSync Topic to which only data that is relevant to an LMS is published. This topic was established because an LMS requires only a subset of certain information produced by the SIS. Publishing the subset to this topic reduces the number of messages that an LMS is required to consume.
com_sct_ldi_sis_UpdateRequest Inbound queue to which grade exchange requests are queued. The Grade Adapter listens to this queue for such requests.
com_sct_ldi_sis_UpdateReply Outbound queue to which UpdateReply messages to grade update requests are provided by the Grade Adapter.
com_sct_ldi_sis_Error Topic for SyncError messages and orphaned UpdateReply messages.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideIntroduction
May 200
• Course
• Course section
• Cross-listed courses/sections
• Person
• Student enrollment
• Faculty assignment
The actual content of the extract is determined by the user initiating the extract job. More information about the common extract process is available in the Banner Integration for eLearning Administration Guide.
Multi-Entity Processing
Banner Integration for eLearning provides the following support for institutions using Multi-Entity Processing (MEP):
• Additional data elements in the individual message objects
• Separate extract process that creates an institution group object
Information concerning the additional data elements is contained in each chapter of this guide. General information concerning MEP and the additional MEP extract process are located in Appendix A, “LDIS-P Support for Multi-Entity Processing”.
Error Handling
If the consuming adapter cannot successfully process a sync message, it must publish a SyncError message (ldisp_type = SyncError), following the requirements of the LDIS-P specification:
• The SyncError message should supply the value of the JMSMessageID header from the original sync message as the value of its JMSCorrelationID message header.
• The message must contain a message property named ldisp_version that has as its value the version identifier for the protocol version to which the message conforms (2.0 for this version of the protocol).
• The message must contain a message property named ldisp_type with the value SyncError, which identifies its message class.
• The message should include an ldisp_correlation_id message property that contains the value of the ldisp_id message property from the original sync message.
8 Banner Integration for eLearning 8.0 1-11Message Reference Guide
Introduction
1-12
• The message body must be a processingresult XML document that details any errors encountered by the adapter when processing the sync message.
Message Details
The remaining chapters of this guide describe messaging for each function that produces messages. Included are the structure, content, and examples of the XML enterprise objects and messages produced and consumed, production and publication logic, and expected consumption behavior.
NoteAll dates within the XML are formatted in YYYY-MM-DD format.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideIntroduction
May 200
2 LDIS-P Messaging for College Data
Courses and course sections are normally sponsored by a college, which is a division or school of a university that grants degrees in a particular field. This relationship between a course and its sponsoring college is required in the SIS, requiring the definition of colleges that are valid for a particular implementation of the system. As a result, the SIS is considered the authoritative source for the following college data:
• College identifier
• College description
Maintenance of this data includes the initial creation of the college record, any subsequent updates to it, and its deletion.
NoteDeletion is possible only if the college is not associated with other entities in the SIS.
LDIS-P Implementation
College data is formatted for publication using the LDIS-P group structure, which implements and extends the IMS-ES group structure.
The following table defines the specific use of group attributes and elements to convey college data, making no distinction between specific Ellucian SISs.
NoteOnly those elements and attributes that can be published for a college message are included.
Tag Name Type Content Example/Comment
group Element
/ recstatus Attribute Not provided for create and update;3 for delete.
/ sourcedid Element
8 Banner Integration for eLearning 8.0 2-1Message Reference Guide
LDIS-P Messaging for College Data
2-2
Message Production Logic
A sync message (ldisp_type = Sync) is produced when a college record is created, the college description is updated, or the college record is deleted.
Messages conveying create or update actions include the full snapshot of the data known to the SIS at the time of production and do not contain a recstatus attribute. Consuming adapters take the appropriate default action as specified in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification) and IMS-ES, which can be found online at http://www.imsproject.org. The data operation defaults to a add if the entity does not exist or to an update if the entity already exists. See the IMS Enterprise Best Practice and Implementation Guide for more information.
Messages that represent delete actions do not contain a full snapshot of the entity being deleted, as specified in the LDIS-P and IMS-ES specifications. Only the required “key” data (sourcedid and description) for a group is produced.
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element COL{SIS college identifier}
SIS college identifier pre-pended to make the ID unique within the enterprise.Example: COLHS
/ grouptype Element
/ / scheme Element Luminis
/ / typevalue Element College
/ / / level Attribute 1
/ description Element
/ / short Element {college code} SIS-internal identifier for the college.Example: HS
/ / long Element {college name} Example: Humanities and Social Sciences
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for College Data
May 200
Create College Group - Sample XML
The following sample XML is produced upon creation of a college in the SIS with the title Humanities and Social Sciences and the unique identifier HS.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>COLHS</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">College</typevalue>
</grouptype>
<description>
<short>HS</short>
<long>Humanities and Social Sciences</long>
</description>
</group>
</enterprise>
Update College Group - Sample XML
The following sample XML is an excerpt of what is produced when changing the name of the college with the unique identifier of HS to College of Humanities and Social Sciences.
<enterprise>
<properties>
<datasource>Banner University </datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>COLHS</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">College</typevalue>
8 Banner Integration for eLearning 8.0 2-3Message Reference Guide
LDIS-P Messaging for College Data
2-4
</grouptype>
<description>
<short>HS</short>
<long>College of Humanities and Social Sciences</long>
</description>
</group>
</enterprise>
Delete College Group - Sample XML
The following sample XML is an excerpt of what is produced when deleting the college with the unique identifier of HS.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group recstatus="3">
<sourcedid>
<source>Banner University</source>
<id>COLHS</id>
</sourcedid>
<description>
<short>HS</short>
</description>
</group>
</enterprise>
MEP College Group - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the college object uses Multi-Entity Processing (MEP) functionality.
<sourcedid>
<source>Banner University</source>
<id>INST.COLHS</id>
</sourcedid>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for College Data
May 200
Message Publication
Messages relating to the creation, update, and deletion of college data are published to both topics supported by the LDI: the “all data” topic and the “LMS-only” topic. Publication to the “LMS-only” topic allows the LMS to understand the relationship of a course group to its parent college when course data is published and consumed.
Expected Consumption Behavior
The LMS or its adapter is expected to consume all college group sync messages and make the appropriate update to the LMS so it can interpret course group relationships to college groups.
Because update sync messages contain the full snapshot of the data known to the SIS at the time of production, consuming adapters are expected to adhere to the “replace” semantics inherent to the LDIS-P. That is, “the values supplied in the update should replace those currently held by the adapter and values that are not present in the update should be removed.” For more information, refer to the Architectural Considerations chapter of the IMS Enterprise Best Practice and Implementation Guide.
For error handling information, see “Error Handling” on page 1-11.
8 Banner Integration for eLearning 8.0 2-5Message Reference Guide
LDIS-P Messaging for College Data
2-6
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for College DataMay 200
3 LDIS-P Messaging for Department Data
Courses and course sections can be related to a department within a college. Defining the relationship between a course and its sponsoring department is possible in the SIS, although it might not always be mandatory. In either case, valid departments for a particular implementation of the system must be defined. As a result, the SIS is considered the authoritative source for the following department data:
• Department identifier
• Department description
Maintenance of this data includes the initial creation of the department record, any subsequent updates to it, and its deletion.
NoteDeletion is possible only if the department is not associated with other entities in the SIS.
LDIS-P Implementation
Department data is formatted for publication using the LDIS-P group structure, which implements and extends the IMS-ES group structure.
The following table defines the specific use of group attributes and elements to convey department data.
NoteOnly those elements and attributes that can be published for a department message are included.
Tag Name Type Content Example/Comment
group Element
/ recstatus Attribute Not provided for create and update;3 for delete.
/ sourcedid Element
8 Banner Integration for eLearning 8.0 3-1Message Reference Guide
LDIS-P Messaging for Department Data
3-2
Message Production Logic
A sync message (ldisp_type = Sync) is produced when a department record is created, the department description is updated, or the department record is deleted.
Messages conveying create or update actions include the full snapshot of the data known to the SIS at the time of production and do not contain a recstatus attribute. Consuming adapters take the appropriate default action as specified in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification) and IMS-ES, which can be found online at http://www.imsproject.org. The data operation defaults to a add if the entity does not exist or to an update if the entity already exists. See the IMS Enterprise Best Practice and Implementation Guide for more information.
Messages that represent delete operations do not contain a full snapshot of the entity being deleted, as specified in the LDIS-P and IMS-ES specifications. Only the required “key” data (sourcedid and description) for a group is produced.
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element DEP{SIS department identifier}
SIS department identifier pre-pended to make the ID unique within the enterprise.Example: DEPENGL
/ grouptype Element
/ / scheme Element Luminis
/ / typevalue Element Department
/ / / level Attribute 1
/ description Element
/ / short Element {department code} SIS-internal identifier for the college.Example: ENGL
/ / long Element {department name} Example: English
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Department Data
May 200
Create Department Group - Sample XML
The following sample XML is an excerpt of what is produced upon creation of a department with the title English and the unique identifier ENGL.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>DEPENGL</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">Department</typevalue>
</grouptype>
<description>
<short>ENGL</short>
<long>English</long>
</description>
</group>
</enterprise>
Update Department Group - Sample XML
The following sample XML is an excerpt of is produced when changing the name of the department with the unique identifier of ENGL to Department of English.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>DEPENGL</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">Department</typevalue>
</grouptype>
8 Banner Integration for eLearning 8.0 3-3Message Reference Guide
LDIS-P Messaging for Department Data
3-4
<description>
<short>ENGL</short>
<long>Department of English</long>
</description>
</group>
</enterprise>
Delete Department Group - Sample XML
The following sample XML is an excerpt of what is produced when deleting the department with the unique identifier of ENGL.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group recstatus="3">
<sourcedid>
<source>Banner University</source>
<id>DEPENGL</id>
</sourcedid>
<description>
<short>ENGL</short>
</description>
</group>
</enterprise>
MEP Department Group - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the department object uses Multi-Entity Processing (MEP) functionality.
<sourcedid>
<source>Banner University</source>
<id>INST.DEPENGL</id>
</sourcedid>
Message Publication
Messages relating to the creation, update, and deletion of department data are published to both topics supported by the LDI: the “all data” topic and the “LMS-only” topic.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Department Data
May 200
Publication to the “LMS-only” topic allows the LMS to understand the relationship of a course group to its parent department when course data is published and consumed.
Expected Consumption Behavior
The LMS or its adapter is expected to consume all department group sync messages and make the appropriate update to the LMS so it can interpret course group relationships to department groups.
Because update sync messages contain the full snapshot of the data known to the SIS at the time of production, consuming adapters are expected to adhere to the “replace” semantics inherent to the LDIS-P. That is, “the values supplied in the update should replace those currently held by the adapter and values that are not present in the update should be removed.” For more information, refer to the Architectural Considerations chapter of the IMS Enterprise Best Practice and Implementation Guide.
For error handling information, see “Error Handling” on page 1-11.
8 Banner Integration for eLearning 8.0 3-5Message Reference Guide
LDIS-P Messaging for Department Data
3-6
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Department DataMay 200
4 LDIS-P Messaging for Course Data
In the SIS, courses act as a template for course sections, providing default data such as credit hours, delivery mechanism, and relationships to organizational structures such as colleges and departments. As a result, the publication of course data by the SIS provides a critical link between course sections (the principle object in which LMSs have interest) and the institution’s organizational hierarchy. The SIS is considered the authoritative source for the following course data:
• Subject of the course
• Course number
• Course title
• Course description
• College sponsoring the course
• Department sponsoring the course
This data is stored historically, allowing the SIS to construct the appropriate “view” or “revision” of the course dynamically for a given academic period. LMSs, on the other hand, use course data to standardize content for course sections, and thus require a more static, snapshot view of the data predominantly for current academic periods.
To address the need for and use of course data by the LMS, the SIS follows a simple publication model and does not differentiate between course revisions. The creation of a course results in the initial publication of a course group with a unique sourcedid/id element. Subsequent changes to the course result in their publication referencing the same unique sourcedid/id that was published previously. The sourcedid/id includes only the data that is common to all revisions of a course, not taking into account the beginning term date for specific changes.
LDIS-P Implementation
Course data is formatted for publication using the LDIS-P group structure, which implements and extends the IMS-ES group structure. Because course data is more complex than college and department data, additional elements and attributes, such as those within the relationship tag are used as appropriate.
8 Banner Integration for eLearning 8.0 4-1Message Reference Guide
LDIS-P Messaging for Course Data
4-2
The following table defines the specific use of group attributes and elements to convey course data by the publishing adapter.
NoteOnly those elements and attributes that can be published for a course message are included. System-specific exceptions to the data that can be published are noted.
Tag Name Type Content Example/Comment
group Element
/ recstatus Attribute Not provided for create and update;3 for delete.
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element CRS{subject code}-{course number}
Example: CRSENGL-101
/ grouptype Element
/ / scheme Element Luminis
/ / typevalue Element Course
/ / / level Attribute 1
/ description Element
/ / short Element {subject code}-{course number}
Example: ENGL-101
/ / long Element {course title} Example: Introduction to English Literature
/ relationship Element One relationship structure for the course’s parent college
/ / relation Attribute 1 Parent relationship
/ / sourceid Element
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course Data
May 200
Message Production Logic
A sync message (ldisp_type = Sync) is produced when a course record is created, the course is updated, or the course record is deleted.
Messages conveying create or update actions include the full snapshot of the data known to the SIS at the time of production and do not contain a recstatus attribute. Consuming adapters take the appropriate default action as specified in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification) and IMS-ES, which can be found online at http://www.imsproject.org.
Creating a course in the SIS triggers the publication of a sync message for a course group whose sourcedid/id has not been published previously.
/ / / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / / id Element COL{unique identifier of the parent college}
Example: COLHS
/ / label Element College
/ relationship Element If available, one relationship structure for the course’s parent department
/ / relation Attribute 1 Parent relationship.
/ / sourceid Element
/ / / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / / id Element DEP{unique identifier of the parent department}
Example: DEPENGL
/ / label Element Department
Tag Name Type Content Example/Comment
8 Banner Integration for eLearning 8.0 4-3Message Reference Guide
LDIS-P Messaging for Course Data
4-4
Course group update sync messages (identified by a previously published sourcedid/id) are produced if any of the following changes are made to a course:
• Course description is updated.
• Course is associated with a different college.
• Course is associated with a new or different department.
• Course status code is changed from Inactive to Active.
• Course’s integration partner value is changed.
Deleting a course in the SIS triggers the publication of a course group delete sync message, which does not contain a complete snapshot of the entity being deleted, as allowed for in the LDIS-P and IMS-ES specifications. Only the required “key” data (sourcedid and description) for a group is produced.
Messages that represent delete operations do not contain a complete snapshot of the entity being deleted, as allowed for in the LDIS-P and IMS-ES specifications. Only the required “key” data (sourcedid and description) for a group is produced.
Create Course Group - Sample XML
The following sample XML is produced upon creation of the course English 101: Introduction to English Literature that is offered by the Department of English within the College of Humanities and Social Sciences.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>CRSENGL-101</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">Course</typevalue>
</grouptype>
<description>
<short>ENGL-101</short>
<long>Introduction to English Literature</long>
</description>
<relationship relation="1">
<sourcedid>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course Data
May 200
<source>Banner University</source>
<id>COLHS</id>
</sourcedid>
<label>College</label>
</relationship>
<relationship relation="1">
<sourcedid>
<source>Banner University</source>
<id>DEPENGL</id>
</sourcedid>
<label>Department</label>
</relationship>
</group>
</enterprise>
Update Course Group - Sample XML
The following sample XML is an excerpt of what is produced when changing the course description within the specified term.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>CRSENGL-101</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">Course</typevalue>
</grouptype>
<description>
<short>ENGL-101</short>
<long>Introduction to Classic English Literature</long>
</description>
<relationship relation="1">
<sourcedid>
<source>Banner University</source>
<id>COLHS</id>
</sourcedid>
<label>College</label>
</relationship>
8 Banner Integration for eLearning 8.0 4-5Message Reference Guide
LDIS-P Messaging for Course Data
4-6
<relationship relation="1">
<sourcedid>
<source>Banner University</source>
<id>DEPENGL</id>
</sourcedid>
<label>Department</label>
</relationship>
</group>
</enterprise>
Delete Course Group - Sample XML
The following sample XML is an excerpt of what is produced when deleting the course in the previous examples.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group recstatus="3">
<sourcedid>
<source>Banner University</source>
<id>CRSENGL-101</id>
</sourcedid>
<description>
<short>ENGL-101</short>
</description>
</group>
</enterprise>
MEP Course Group - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the course object is using Multi-Entity Processing (MEP) functionality.
NoteA hyphen (-) is used as a delimiter in the sourcedid.id in the course object.
<sourcedid>
<source>Banner University</source>
<id>INST-CRSENGL-101</id>
</sourcedid>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course Data
May 200
Message Publication
Messages relating to the creation, update, and deletion of course data are published to both topics supported by the LDI: the “all data” topic and the “LMS-only” topic. Publication to the “LMS-only” topic allows the LMS to understand the relationship of a course group to its parent course when section data is published and consumed.
Expected Consumption Behavior
The LMS or its adapter is expected to consume all course group sync messages and make the appropriate update to the LMS so it can interpret course group relationships to parent courses.
Because update sync messages contain the full snapshot of the data known to the SIS at the time of production, consuming adapters are expected to adhere to the “replace” semantics inherent to the LDIS-P. That is, “the values supplied in the update should replace those currently held by the adapter and values that are not present in the update should be removed.” (For more information, refer to the Architectural Considerations chapter of the IMS Enterprise Best Practice and Implementation Guide.
For error handling information, see “Error Handling” on page 1-11.
8 Banner Integration for eLearning 8.0 4-7Message Reference Guide
LDIS-P Messaging for Course Data
4-8
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course DataMay 200
5 LDIS-P Messaging for Term Data
Term is the basis for most academic processes and data in the SIS and, as such, is the principal control for synchronization with external systems. Because terms are defined and maintained in the SIS, the SIS is considered the authoritative source for the following term data:
• Term identifier
• Term description
• Term start date
• Term end date
• Enrollment and registration restrictions
LDIS-P Implementation
Term data is formatted for publication using the LDIS-P group structure, which implements and extends the IMS-ES group structure.
The following table defines the specific use of group attributes and elements to convey term data.
NoteOnly those elements and attributes that can be published for a term message are included.
Tag Name Type Content Example/Comment
group Element
/ recstatus Attribute Not provided for create and update;3 for delete.
/ sourcedid Element
8 Banner Integration for eLearning 8.0 5-1Message Reference Guide
LDIS-P Messaging for Term Data
5-2
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element {SIS term identifier} Example: 200520
/ grouptype Element
/ / scheme Element Luminis
/ / typevalue Element Term
/ / / level Attribute 1
/ description Element
/ / short Element {SIS term identifier} Example: 200520
/ / long Element {SIS term description}
Example: Spring 2005
/ timeframe Element
/ / begin Element {term start date}
/ / / restrict Attribute 0 Indicates that learner participation is not permitted before the term begin date
/ / end Element {term end date}
/ / / restrict Attribute 0 Indicates that learner participation is not permitted after the term end date
/ enrollcontrol Element
/ / enrollaccept Element 0 or 1 Indicates whether registration is permitted:0 = no1 = yes
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Term Data
May 200
Message Production Logic
Banner Student produces a sync message (ldisp_type = Sync) when a term that is flagged for synchronization with external systems is created, updated, or deleted.
Messages conveying create or update actions include the full snapshot of data known to the SIS at the time of production and do not contain a recstatus attribute. Consuming adapters take the appropriate default action as specified in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification) and IMS-ES, which can be found online at http://www.imsproject.org.
Messages that represent delete actions do not contain a full snapshot of the entity being deleted, as specified in the LDIS-P and IMS-ES specifications. Only the required “key” data (sourcedid and description) for a group is produced.
Create Term Group - Sample XML
The following sample XML is produced upon creation of a term in the SIS for the Fall 2004 term.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>200510</id>
</sourcedid>
/ / enrollallowed Element 0 Target system cannot enroll students. The SIS controls enrollment.
/ extension Element
/ / luminisgroup Element
/ / / sort Element {term sort order] SIS code by which the term should be sorted.
Tag Name Type Content Example/Comment
8 Banner Integration for eLearning 8.0 5-3Message Reference Guide
LDIS-P Messaging for Term Data
5-4
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">Term</typevalue>
</grouptype>
<description>
<short>200510</short>
<long>Fall 2004</long>
</description>
<timeframe>
<begin restrict="0">2004-08-30</begin>
<end restrict="0">2004-12-17</end>
</timeframe>
<enrollcontrol>
<enrollaccept>0</enrollaccept>
<enrollallowed>0</enrollallowed>
</enrollcontrol>
<extension>
<luminisgroup>
<sort>200510</sort>
</luminisgroup>
</extension>
</group>
</enterprise>
Update Term Group - Sample XML
The following sample XML is an excerpt of what is produced upon updating the Fall 2004 term to accept enrollments.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>200510</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">Term</typevalue>
</grouptype>
<description>
<short>200510</short>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Term Data
May 200
<long>Fall 2004</long>
</description>
<timeframe>
<begin restrict="0">2004-08-30</begin>
<end restrict="0">2004-12-17</end>
</timeframe>
<enrollcontrol>
<enrollaccept>1</enrollaccept>
<enrollallowed>0</enrollallowed>
</enrollcontrol>
<extension>
<luminisgroup>
<sort>200510</sort>
</luminisgroup>
</extension>
</group>
</enterprise>
Delete Term Group - Sample XML
The following sample XML is an excerpt of what is produced when deleting the Fall 2005 term (200610).
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group recstatus="3">
<sourcedid>
<source>Banner University</source>
<id>200610</id>
</sourcedid>
<description>
<short>200610</short>
</description>
</group>
</enterprise>
MEP Term Group - Sample XML
The following sample XML is an excerpt of how the sourcedid.source element is produced if the term object uses Multi-Entity Processing (MEP) functionality.
8 Banner Integration for eLearning 8.0 5-5Message Reference Guide
LDIS-P Messaging for Term Data
5-6
<sourcedid>
<source>Banner University</source>
<id>INST.200610</id>
</sourcedid>
Message Publication
Messages relating to the creation, update, and deletion of term data are published to both topics supported by the LDI: “all data” topic and the “LMS-only” topic. Publication to the “LMS-only” topic allows the LMS to understand the relationship of a course group to its parent term when course data is published and consumed.
Expected Consumption Behavior
The LMS or its adapter is expected to consume all term group sync messages and make the appropriate update to the LMS so it can interpret course group relationships to term groups.
Because update sync messages contain the full snapshot of the data known to the SIS at the time of production, consuming adapters are expected to adhere to the “replace” semantics inherent to the LDIS-P. That is, “the values supplied in the update should replace those currently held by the adapter and values that are not present in the update should be removed.”
For error handling information, see “Error Handling” on page 1-11.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Term Data
May 200
6 LDIS-P Messaging for Course Section Data
As defined in the LDIS-P, a section or course section is “a specific instance of a course that is taught during an academic period, wherein the date ranges for the course section may exist outside the normal term dates.”
Section data is required by the LMS as a starting point for content development and delivery as well as a basis for establishing authorized access to this content. As a result, course section data is published as it is created, updated, and deleted in the SIS.
LDIS-P Implementation
Section data is formatted for publication using the LDIS-P group structure, which implements and extends the IMS-ES group structure.
The following table defines the specific use of group attributes and elements to convey section data by the publishing adapter.
NoteOnly those elements and attributes that can be published for a course section message are included. System-specific exceptions to the data that can be published are noted.
Tag Name Type Content Example/Comment
group Element
/ recstatus Attribute Not provided for create and update;3 for delete.
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element {course reference number}.{term}
Example: 63331.200210
8 Banner Integration for eLearning 8.0 6-1Message Reference Guide
LDIS-P Messaging for Course Section Data
6-2
/ grouptype Element
/ / scheme Element Luminis
/ / typevalue Element CourseSection
/ / / level Attribute 1
/ description Element
/ / short Element {course reference number}
Example: 63331
/ / long Element {subject identifier}-{course number}-{section number}
Example: ENGL-101-001
/ / full Element {course title} Example: Introduction to English Literature
/ org Element
/ / orgunit Element {department name} Name of the department sponsoring the section, if available.
/ timeframe Element
/ / begin Element {beginning date for the section}
/ / / restrict Attribute 0 Indicates that learner participation is not permitted before the begin date.
/ / end Element {ending date for the section}
/ / / restrict Attribute 0 Indicates that learner participation is not permitted after the end date.
/ enrollcontrol Element
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course Section Data
May 200
/ / enrollaccept Element 0 or 1 Indicates whether registration is permitted.0 = no1 = yes
/ / enrollallowed Element 0 Target system cannot enroll students. The SIS controls enrollment.
/ relationship Element One relationship structure for the section’s term.
/ / relation Attribute 1 Term is the parent of the section.
/ / sourceid Element
/ / / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / / id Element {SIS term identifier} Example: 200520
/ / label Element Term
/ relationship Element One relationship structure for the section’s parent course.
/ / relation Attribute 1 Course is the parent of the section.
/ / sourceid Element
/ / / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
Tag Name Type Content Example/Comment
8 Banner Integration for eLearning 8.0 6-3Message Reference Guide
LDIS-P Messaging for Course Section Data
6-4
Message Production Logic
A sync message (ldisp_type = Sync) is produced when a course section record is created, updated, or deleted.
/ / / id Element CRS{subject identifier}-{course number}
Unique identifier of the parent course.Example: CRSENGL-101
/ / label Element Course
/ extension Element
/ / luminisgroup Element
/ / / events Element {term sort order} SIS code by which the term should be sorted.
/ / / / recurringevent Element Repeatable.
/ / / / / eventdescription Element
/ / / / / begindate Element {section begin date}
/ / / / / enddate Element {section end date}
/ / / / / daysofweek Element {days of week}
/ / / / / begintime Element {section begin time}
/ / / / / endtime Element {section begin time}
/ / / / / location Element TBAor{building with room number}
/ / / deliverysystem Element LMS responsible for content delivery.
Literal agreed to by Banner and the specific LMS vendor. Occurs only once for course section groups.Example: WEBCT
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course Section Data
May 200
Messages conveying create or update actions include the full snapshot of the data known to the SIS at the time of production and do not contain a recstatus attribute. Consuming adapters take the appropriate default action as specified in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification) and IMS-ES, which can be found online at http://www.imsproject.org.
Messages that represent delete actions do not contain a full snapshot of the entity being deleted, as allowed for in the LDIS-P and IMS-ES specifications. Only the required “key” data (sourcedid and description) for a group is produced.
Create CourseSection Group - Sample XML
The following sample XML is produced upon creation of a section of English 101 in the SIS.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>10102.200510</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">CourseSection</typevalue>
</grouptype>
<description>
<short>10102</short>
<long>ENGL-101-001</long>
<full>Introduction to English Literature</full>
</description>
<org>
<orgunit>English</orgunit>
</org>
<timeframe>
<begin restrict="0">2004-08-31</begin>
<end restrict="0">2004-12-17</end>
</timeframe>
<relationship relation="1">
<sourcedid>
<source>Banner University</source>
<id>200510</id>
8 Banner Integration for eLearning 8.0 6-5Message Reference Guide
LDIS-P Messaging for Course Section Data
6-6
</sourcedid>
<label>Term</label>
</relationship>
<relationship relation="1">
<sourcedid>
<source>Banner University</source>
<id>CRSENGL-101</id>
</sourcedid>
<label>Course</label>
</relationship>
<extension>
<luminisgroup>
<deliverysystem>WEBCT</deliverysystem>
</luminisgroup>
</extension>
</group>
</enterprise>
Update CourseSection Group - Sample XML
The following sample XML is an excerpt of what is produced when updating the English 101 section to accept enrollments.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>10102.200510</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">CourseSection</typevalue>
</grouptype>
<description>
<short>10102</short>
<long>ENGL-101-001</long>
<full>Introduction to English Literature</full>
</description>
<org>
<orgunit>English Literature</orgunit>
</org>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course Section Data
May 200
<timeframe>
<begin restrict="0">2004-08-31</begin>
<end restrict="0">2004-12-17</end>
</timeframe>
<enrollcontrol>
<enrollaccept>1</enrollaccept>
<enrollallowed>0</enrollallowed>
</enrollcontrol>
<relationship relation="1">
<sourcedid>
<source>Banner University</source>
<id>200510</id>
</sourcedid>
<label>Term</label>
</relationship>
<relationship relation="1">
<sourcedid>
<source>Banner University</source>
<id>CRSENGL-101</id>
</sourcedid>
<label>Course</label>
</relationship>
<extension>
<luminisgroup>
<deliverysystem>WEBCT</delivery>
</luminisgroup>
</extension>
</group>
</enterprise>
Delete CourseSection Group - Sample XML
The following sample XML is an excerpt of what is produced when deleting the section.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group recstatus="3">
<sourcedid>
<source>Banner University</source>
<id>10102.200510</id>
</sourcedid>
<description>
8 Banner Integration for eLearning 8.0 6-7Message Reference Guide
LDIS-P Messaging for Course Section Data
6-8
<short>10102</short>
</description>
</group>
</enterprise>
MEP CourseSection Group - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the course section object uses Multi-Entity Processing (MEP) functionality.
<sourcedid>
<source>Banner University</source>
<id>INST.10102.200510</id>
</sourcedid>
Message Publication
Messages relating to the creation, update, and deletion of course section data are published to the “all data” topic in all situations.
To reduce the number of messages that LMS adapters need to consume and to reduce the number of course sections that the LMS needs to store, a subset of course sections is published to the “LMS-only” topic as well under the following conditions:
• The course section is identified in the SIS as being delivered via an LMS. A course section group sync message with an /extension/luminisgroup/deliverysystem tag is produced and published to both the “all data” and the “LMS-only” topics when the section is created, updated, or deleted in the SIS.
• The course section is identified in the SIS as being delivered via an LMS and this designation changes in the SIS. This case, while still an update, is special, because it represents the update of the group in the SIS as well as in applications such as Luminis Platform; however, from the standpoint of the LMS, it represents the deletion of the group. Given these mixed semantics, limitations on the existing SIS adapter, and the absence of content-based routing software in this release of Banner Integration for eLearning, the SIS adapter continues to publish such changes as updates. Targeted group update and group delete Sync messages are not published.
In implementations of an SIS with a single LMS, this publication behavior should not impose additional processing on the LMS adapter. Only those messages that are relevant to the LMS are published to the “LMS-only” topic. The presence of the /luminisgroup/deliverysystem tag indicates that the LMS is “responsible” for content delivery, while the absence of this tag indicates that this responsibility has been removed.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course Section Data
May 200
Expected Consumption Behavior
The LMS or its adapter is expected to consume all course section group sync messages published to the “LMS-only” topic.
Because update sync messages contain the full snapshot of the data known to the SIS at the time of production, consuming adapters are expected to adhere to the “replace” semantics inherent to the LDIS-P. That is, “the values supplied in the update should replace those currently held by the adapter and values that are not present in the update should be removed.” For more information, refer to the Architectural Considerations chapter of the IMS Enterprise Best Practice and Implementation Guide.
One exception to this rule is the /luminisgroup/deliverysystem tag. The presence or absence of this should be treated by the LMS as a switch, indicating whether the LMS is responsible for content delivery.
More sophisticated logic is necessary in implementations of more than one LMS. Consuming adapters need to assess the value of the deliverysystem tag to determine whether the message should be processed and the LMS updated accordingly. Such behavior would ensure that the LMS properly reflects that it is no longer responsible for a course section’s delivery.
For error handling information, see “Error Handling” on page 1-11.
8 Banner Integration for eLearning 8.0 6-9Message Reference Guide
LDIS-P Messaging for Course Section Data
6-10
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Course Section DataMay 200
7 LDIS-P Messaging for Cross-List Data
Cross-list sections are those that are listed separately in the course catalog yet are actually taught by the same instructor via the same delivery mechanism, within the same academic period, at the same time, and in the same place, if applicable.
The LMS requires cross-list section data so that individual sections can be linked and content can be developed and delivered via the same mechanism. As a result, cross-list course section data is published as it is created, updated, and deleted in the SIS.
Maintenance of course section cross-lists includes the initial creation of the cross-list group, any subsequent updates to it, and its deletion. Cross-list updates predominantly entail the addition or removal of course sections from the cross-list.
LDIS-P Implementation
Cross-list data is formatted for publication using the LDIS-P group structure, which implements and extends the IMS-ES group structure.
The following table defines the specific use of group attributes and elements to convey cross-list data.
NoteOnly those elements and attributes that can be published for a cross-list message are included.
Tag Name Type Content Example/Comment
group Element
/ recstatus Attribute Not provided for create and update;3 for delete.
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
8 Banner Integration for eLearning 8.0 7-1Message Reference Guide
LDIS-P Messaging for Cross-List Data
7-2
The following table defines the specific use of membership attributes and elements to convey cross-list data.
NoteOnly those elements and attributes that can be published for a cross-list message are included.
/ / id Element XLS{SIS cross-list identifier}{SIS term identifier}
Example: XLSAU200520
/ grouptype Element
/ / scheme Element Luminis
/ / typevalue Element CrossListedSection
/ / / level Attribute 1
/ description Element
/ / short Element Cross Listed Section Group
Tag Name Type Content Example/Comment
membership Element One membership structure reflecting the cross-list section group’s members.
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element XLS{SIS cross-list identifier}{SIS term identifier}
Example: XLSAU200520
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Cross-List Data
May 200
/ member Element The number of members contained in this structure depends on how this data is produced by the SIS. If sections are related to a cross-list in a single transaction, the membership message might contain more than one member. This behavior would most likely be seen only during the initial creation of the cross-list. Normally, member additions and deletions are communicated as separate messages.
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element {course reference number}.{term}
Example: 63331.200520
/ idtype Element 2 The member is a group.
/ role Element
/ / recstatus Attribute Not provided for create and update;3 for delete.
/ / status Element 0 or 1 Indicates whether the group member is active.
Tag Name Type Content Example/Comment
8 Banner Integration for eLearning 8.0 7-3Message Reference Guide
LDIS-P Messaging for Cross-List Data
7-4
Message Production Logic
A sync message (ldisp_type = Sync) is produced when a cross-list whose parent term is enabled for synchronization is first added to the SIS. Subsequently, as course sections are added to the cross-list, membership sync messages (membership/member/role/@recstatus 3) are produced.
Any update to the cross-list itself results in the production of a group update message.
The removal of course sections from the cross-list results in the production of membership delete messages. (membership/member/role/@recstatus = 3), while the deletion of the cross-list group itself results in the production of a group delete message.
Messages conveying create or update actions include the full snapshot of data known to the SIS at the time of production and do not contain a recstatus attribute, allowing. Consuming adapters take the appropriate default action as specified in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification) and IMS-ES, which can be found online at http://www.imsproject.org.
Messages that represent delete actions do not contain a full snapshot of the entity being deleted, as allowed in the LDIS-P and IMS-ES specifications. Only the required “key” data (sourcedid and description) for a group is produced.
Create CrossListedSection Group - Sample XML
The following sample XML is produced upon creation of a cross-list and the addition of a section. Two messages are published: one reflecting the new cross-list group and one reflecting the new group’s membership.
The following XML reflects the creation of the cross-list:
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University</source>
<id>XLSJF200310</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">CrossListedSection</typevalue>
</grouptype>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Cross-List Data
May 200
<description>
<short>Cross Listed Section Group</short>
</description>
</group>
</enterprise>
The following XML reflects the initial group membership (assuming that three sections are added to the group in one database transaction):
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>XLSJF200310</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>17384.200520</id>
</sourcedid>
<idtype>2</idtype>
<role>
<status>1</status>
</role>
</member>
<member>
<sourcedid>
<source>Banner University</source>
<id>35254.200520</id>
</sourcedid>
<idtype>2</idtype>
<role>
<status>1</status>
</role>
</member>
<member>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<idtype>2</idtype>
8 Banner Integration for eLearning 8.0 7-5Message Reference Guide
LDIS-P Messaging for Cross-List Data
7-6
<role>
<status>1</status>
</role>
</member>
</membership>
</enterprise>
Update CrossListedSection Group - Sample XML
The following sample XML is an excerpt of what is produced when cross-listing another section (that is, adding to the cross-list group’s membership).
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>XLSJF200310</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>17384.200520</id>
</sourcedid>
<idtype>2</idtype>
<role>
<status>1</status>
</role>
</member>
</membership>
</enterprise>
The following sample XML is an excerpt of what is produced when a section is removed from the cross-list.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<membership>
<sourcedid>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Cross-List Data
May 200
<source>Banner University</source>
<id>XLSJF200310</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>17384.200520</id>
</sourcedid>
<idtype>2</idtype>
<role recstatus="3">
<status>0</status>
</role>
</member>
</membership>
</enterprise>
Delete CrossListed Section Group - Sample XML
The following sample XML is an excerpt of what is produced when a cross-list is deleted.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<group recstatus="3">
<sourcedid>
<source>Banner University</source>
<id>XLSJF200310</id>
</sourcedid>
<description>
<short>Cross Listed Section Group</short>
</description>
</group>
</enterprise>
8 Banner Integration for eLearning 8.0 7-7Message Reference Guide
LDIS-P Messaging for Cross-List Data
7-8
MEP CrossListedSection Group - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the cross-list object uses Multi-Entity Processing (MEP) functionality.
<sourcedid>
<source>Banner University</source>
<id>INST.XLSJF200310</id>
</sourcedid>
Message Publication
Messages relating to the creation, update, and deletion of cross-list data are published to the “all data” topic in all situations.
To reduce the number of messages that LMS adapters need to consume and to reduce the number of cross-list course sections the LMS needs to store, only a subset of cross-list data is published to the “LMS-only” topic. Cross-list group members are published to the “LMS-only” topic under the following conditions:
• The course section referenced in the group membership is identified in the SIS as being delivered via an LMS.
• The course section referenced in the group membership is identified in the SIS as being delivered via an LMS and this designation changes in the SIS.
This logic cannot be applied to the publication of cross-list section groups because their membership and corresponding delivery mechanism are not necessarily known at the time of creation. Cross-list section group sync messages are therefore published to both topics in all situations.
Expected Consumption Behavior
The LMS or its adapter is expected to consume all cross-list section group and membership sync messages published to the “LMS-only” topic.
Because update sync messages contain the full snapshot of the data known to the SIS at the time of production, consuming adapters are expected to adhere to the “replace” semantics inherent to the LDIS-P. That is, “the values supplied in the update should replace those currently held by the adapter and values that are not present in the update should be removed.” For more information, refer to the Architectural Considerations chapter of the IMS Enterprise Best Practice and Implementation Guide.
For error handling information, see “Error Handling” on page 1-11.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Cross-List Data
May 200
8 LDIS-P Messaging for Person Data
The maintenance of person data in the SIS includes the creation of the person record as well as its subsequent update. Persons are not deleted in the SIS.
LDIS-P Implementation
Person data is formatted for publication using the LDIS-P person structure, which implements and extends the IMS-ES person structure.
The following table defines the specific use of person attributes and elements to convey person data by the publishing adapter.
NoteOnly those elements and attributes that can be published for a person message are included. System-specific exceptions to the data that can be published are noted.
Tag Name Type Content Example/Comment
person Element
/ recstatus Attribute Not provided for create and update;3 for delete.
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element {SIS person identifier}
/ userid Element {person's access ID} Repeatable.
8 Banner Integration for eLearning 8.0 8-1Message Reference Guide
LDIS-P Messaging for Person Data
8-2
/ / useridtype Attribute One of the following recognized types:Logon IDSCTID UDCIdentifierEmail ID
/ / pwencryptiontype Attribute Type of encryption applied to password.
Used with Logon ID and SCTID.
/ / password Attribute Encrypted or unencrypted password associated with the user ID.
/ name Element
/ / fn Element Available elements concatenated as follows: prefixgivenpartnamefamilysuffix
Example: Mr. Charles M. Johnson, Jr.
/ / nickname Element {preferred first name} {last name}
Example: Chuck Johnson
/ / n Element
/ / / family Element {last name} Example: Johnson
/ / / given Element {first name} Example: Charles
/ / / prefix Element {name prefix} Mr., Mrs., Ms, Dr., and so onExample: Mr.
/ / / suffix Element {name suffix} Jr., III, Sr., and so onExample: Jr.
/ / / partname Element {middle name} Example: M.
/ / / / partnametype Attribute MiddleName
/ demographics Element
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Person Data
May 200
/ / gender Element {person’s gender} Person’s gender rendered in IMS-ES encoding scheme.1 = female2 = male0 = unknown
/ email Element {person’s e-mail address}
/ tel Element {person’s phone number}
Only one phone number is produced, although the element is repeatable. For cases where multiple numbers exist, the SIS provides for selection of the appropriate telephone number to include.
/ / teltype Attribute {phone number type} Phone number type rendered in IMS-ES encoding scheme.1 = voice2 = fax3 = mobile4 = pager
/ adr Element
/ / street Element {street address}
/ / locality Element {locality/city
/ / region Element {state or province}
/ / pcode Element {ZIP or postal code}
/ / country Element {country}
/ institutionrole Element Repeatable. One for each role that a person has within the institution.
Tag Name Type Content Example/Comment
8 Banner Integration for eLearning 8.0 8-3Message Reference Guide
LDIS-P Messaging for Person Data
8-4
/ / primaryrole Attribute No The concept of primary role does not exist within the SIS.
/ / institutionroletype Attribute {person’s role} One of the person’s roles within the institution as defined by the IMS Enterprise specification.StudentFacultyStaff (any person with an employee role)AlumniProspectiveStudent
/ extension Element
/ / luminisperson Element
/ / / academicmajor Element {student’s academic major}
/ / / academictitle Element {faculty member’s academic major}
/ / / academicdegree Element {faculty member’s earned degree}
/ / / customrole Element {person’s role} One of the following roles, or any custom role not covered by the IMS Enterprise specification:FriendsDevelopmentOfficerFinance ProspectApplicantInstitutionAcceptApplicantAcceptBannerINB
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Person Data
May 200
Message Production Logic
A sync message (ldisp_type = Sync) is produced when a person record is created or updated.
Messages conveying create or update actions include the full snapshot of data known to the SIS at the time of production and do not contain a recstatus attribute. Consuming adapters take the appropriate default action as specified in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification) and IMS-ES, which can be found online at http://www.imsproject.org.
Messages that represent delete actions do not contain a full snapshot of the entity being deleted, as specified in the LDIS-P and IMS-ES specifications. Only the required “key” data (sourcedid and description) for a person is produced.
Create Person (Student Role) - Sample XML
The following sample XML is produced upon creation of a person assigned a Student role.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<person>
<sourcedid>
<source>Banner University</source>
<id>9450</id>
</sourcedid>
<userid useridtype="Logon ID" pwencryptiontype="SSHA" password="{SSHA}OHHjWPR+6fM/iP+ZvcWHEVGxoAFFR0JUQUE4Qw==">sskinner</userid>
<userid useridtype="SCTID" pwencryptiontype="SSHA" password="{SSHA}OHHjWPR+6fM/iP+ZvcWHEVGxoAFFR0JUQUE4Qw==">N00013021</userid>
<userid useridtype="UDCIdentifier">40B35A4C069F0C11E0440003BA9B2B5B</userid>
<userid useridtype="Email ID">sskinner</userid>
<name>
<fn>Seymour Simon Skinner</fn>
<n>
<family>Skinner</family>
<given>Seymour</given>
<partname partnametype="MiddleName">Simon</partname>
</n>
</name>
<demographics>
8 Banner Integration for eLearning 8.0 8-5Message Reference Guide
LDIS-P Messaging for Person Data
8-6
<gender>2</gender>
</demographics>
<email>[email protected]</email>
<tel teltype="1">555-555-5555</tel>
<adr>
<street>9 West Linden Ave. </street>
<locality>Lincoln</locality>
<region>NE</region>
<pcode>34008</pcode>
<country>USA</country>
</adr>
<institutionrole primaryrole="No" institutionroletype="Student"/>
<extension>
<luminisperson>
<academicmajor>Chemical Engineering</academicmajor>
</luminisperson>
</extension>
</person>
</enterprise>
Create Person (Faculty Role) - Sample XML
The following sample XML is produced upon creation of a person assigned a Faculty role.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<person>
<sourcedid>
<source>Banner University</source>
<id>9450</id>
</sourcedid>
<userid useridtype="Logon ID" pwencryptiontype="SSHA" password="{SSHA}OHHjWPR+6fM/iP+ZvcWHEVGxoAFFR0JUQUE4Qw==">sskinner</userid>
<userid useridtype="SCTID" pwencryptiontype="SSHA" password="{SSHA}OHHjWPR+6fM/iP+ZvcWHEVGxoAFFR0JUQUE4Qw==">N00013021</userid>
<userid useridtype="UDCIdentifier">40B35A4C069F0C11E0440003BA9B2B5B</userid>
<userid useridtype="Email ID">sskinner</userid>
<name>
<fn>Seymour Simon Skinner</fn>
<n>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Person Data
May 200
<family>Skinner</family>
<given>Seymour</given>
<partname partnametype="MiddleName">Simon</partname>
</n>
</name>
<demographics>
<gender>2</gender>
</demographics>
<email>[email protected]</email>
<tel teltype="1">555-555-5555</tel>
<adr>
<street>34 Crockett Ct. </street>
<locality>Lincoln</locality>
<region>NE</region>
<pcode>34008</pcode>
<country>USA</country>
</adr>
<institutionrole primaryrole="No" institutionroletype="Faculty"/>
<extension>
<luminisperson>
<academictitle>Associate Professor</academictitle>
<academicdegree>M.A.</academicdegree>
<academicdegree>Ph.D.</academicdegree>
</luminisperson>
</extension>
</person>
</enterprise>
Update Person - Sample XML
The following sample XML is an excerpt of what is produced when changing a person assigned a Student role.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<person>
<sourcedid>
<source>Banner University</source>
<id>9450</id>
</sourcedid>
8 Banner Integration for eLearning 8.0 8-7Message Reference Guide
LDIS-P Messaging for Person Data
8-8
<userid useridtype="Logon ID" pwencryptiontype="SSHA" password="{SSHA}OHHjWPR+6fM/iP+ZvcWHEVGxoAFFR0JUQUE4Qw==">gicglare</userid>
<userid useridtype="SCTID" pwencryptiontype="SSHA" password="{SSHA}OHHjWPR+6fM/iP+ZvcWHEVGxoAFFR0JUQUE4Qw==">N00013021</userid>
<userid useridtype="UDCIdentifier">40B35A4C069F0C11E0440003BA9B2B5B</userid>
<userid useridtype = "Email ID">sskinner</userid>
<name>
<fn>Seymour Simon Skinner</fn>
<n>
<family>Skinner</family>
<given>Seymour</given>
<partname partnametype="MiddleName">Simon</partname>
</n>
</name>
<demographics>
<gender>2</gender>
</demographics>
<email>[email protected]</email>
<tel teltype="1">555-555-5555</tel>
<adr>
<street>24 E. 56th Street </street>
<locality>Brooklyn</locality>
<region>NY</region>
<pcode>10036</pcode>
<country>USA</country>
</adr>
<institutionrole primaryrole="No" institutionroletype="Student"/>
<extension>
<luminisperson>
<academicmajor>Chemical Engineering</academicmajor>
</luminisperson>
</extension>
</person>
</enterprise>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Person Data
May 200
MEP Person - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the person object uses Multi-Entity Processing (MEP) functionality.
<sourcedid>
<source>Banner University</source>
<id>INST.983364111</id>
</sourcedid>
Message Publication
Messages relating to the creation and update of person data are published to both topics supported by the LDI: the “all data” topic and the “LMS-only” topic, because there are no criteria by which persons can be filtered from the “LMS-only” topic.
Expected Consumption Behavior
The LMS or its adapter is expected to consume all person sync messages and make the appropriate update to system data.
Because update sync messages contain the full snapshot of the data known to the SIS at the time of production, consuming adapters are expected to adhere to the “replace” semantics inherent to the LDIS-P. That is, “the values supplied in the update should replace those currently held by the adapter and values that are not present in the update should be removed.”
For error handling information, see “Error Handling” on page 1-11.
8 Banner Integration for eLearning 8.0 8-9Message Reference Guide
LDIS-P Messaging for Person Data
8-10
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Person DataMay 200
9 LDIS-P Messaging for Student Enrollment Data
One of the principle functions of the SIS is to allow students to enroll in course offerings and to serve as a repository of student academic records. As a result, the SIS is considered the authoritative source for student enrollment data and provides for the creation, update, and deletion of this data.
LDIS-P Implementation
Enrollment data is formatted for publication using the LDIS-P membership structure, which implements and extends the IMS-ES membership structure.
The following table defines the specific use of membership attributes and elements to convey enrollment data.
NoteOnly those elements and attributes that can be published are included. System-specific exceptions to the data that can be published are noted.
Tag Name Type Content Example/Comment
membership Element This is one membership structure reflecting the section group’s student members.
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element {course reference number}.{term}
Example: 63331.200520
8 Banner Integration for eLearning 8.0 9-1Message Reference Guide
LDIS-P Messaging for Student Enrollment Data
9-2
/ member Element This is one membership structure reflecting the section group’s student members.
/ / sourcedid Element
/ / / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / / id Element {SIS person identifier}
/ / idtype Element 1 Indicates that the member is a person.
/ / role Element
/ / / recstatus Attribute Not provided for create and update;3 = for delete.
/ / / roletype Attribute 01 Indicates that the student has a learner role.
/ / / status Element {student’s status} Student’s enrollment status rendered in IMS-ES encoding scheme:
1 = active 0 = inactive
/ / / datetime Element {Date the membership was established}
/ / / timeframe Element
/ / / / begin Element {Beginning date for the enrollment}
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Student Enrollment Data
May 200
/ / / / restrict Attribute 0 or 1 Indicates whether a learner's access to an enrolled course section is restricted or not restricted based on begin date.
0 = restricted1 = not restricted
/ / / / end Element {Ending date for the enrollment}
/ / / / restrict Attribute 0 or 1 Indicates whether a learner's access to an enrolled course section is restricted or not restricted based on end date.
0 = restricted1 = not restricted
/ / / interimresult Element
/ / / / resulttype Attribute MidTerm
/ / / / mode Element {descriptive name of the grading mode}
/ / / finalresult Element
/ / / / mode Element {descriptive name of the grading mode}
/ / / extension Element Assumed gradable if not provided.
/ / / / luminisrole Element
Tag Name Type Content Example/Comment
8 Banner Integration for eLearning 8.0 9-3Message Reference Guide
LDIS-P Messaging for Student Enrollment Data
9-4
Message Production Logic
A sync message (ldisp_type = Sync) is produced when a student enrolls in or is dropped from a course section whose parent term is flagged for synchronization with external systems.
Messages conveying create or update actions include the full snapshot of data known to the SIS at the time of production and do not contain a recstatus attribute. Consuming adapters take the appropriate default action as specified in the Data Integration SDK Protocol IMS Specification (formerly LDIS Protocol Specification) and IMS-ES, which can be found online at http://www.imsproject.org.
Messages that represent delete operations do not contain a full snapshot of the entity being deleted, as specified in the LDIS-P and IMS-ES specifications.
Create Student Enrollment Membership - Sample XML
The following sample XML is an excerpt of what is produced upon creation of a student enrollment membership.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
/ / / / / gradable Element 0 or 1 Indicates whether a learner's membership can have interim or final results associated with it.
0 = cannot have interim or final results associated with it
1 = can have interim and/or final results associated with it
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Student Enrollment Data
May 200
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>983364111</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<timeframe>
<begin restrict="1">2005-09-01</begin>
<end restrict="1">2006-09-07</end>
</timeframe>
<interimresult resulttype="MidTerm">
<mode>Letter Grade</mode>
</interimresult>
<finalresult>
<mode>Letter Grade</mode>
</finalresult>
</role>
</member>
</membership>
</enterprise>
Update Student Enrollment Membership - Sample XML
The following sample XML is an excerpt of what is produced when changing a student enrollment membership.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>983364111</id>
</sourcedid>
<idtype>1</idtype>
8 Banner Integration for eLearning 8.0 9-5Message Reference Guide
LDIS-P Messaging for Student Enrollment Data
9-6
<role roletype="01">
<status>1</status>
<timeframe>
<begin restrict="1">2005-09-01</begin>
<end restrict="1">2006-09-07</end>
</timeframe>
<interimresult resulttype="MidTerm">
<mode>Audit</mode>
</interimresult>
<finalresult>
<mode>Audit</mode>
</finalresult>
</role>
</member>
</membership>
</enterprise>
Delete Student Enrollment Membership - Sample XML
The following sample XML is an excerpt of what is produced when deleting the student enrollment membership.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>983364111</id>
</sourcedid>
<idtype>1</idtype>
<role recstatus="3" roletype="01">
<status>0</status>
</role>
</member>
</membership>
</enterprise>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Student Enrollment Data
May 200
MEP Student Enrollment Membership - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the student enrollment object uses Multi-Entity Processing functionality.
<sourcedid>
<source>Banner University</source>
<id>INST.63331.200520</id>
</sourcedid>
Message Publication
Messages relating to the creation, update, and deletion of enrollment data are published to the “all data” topic in all situations.
Because only a subset of course sections is published to and consumed from the “LMS-only” topic, only those enrollments for course sections that have been identified in the SIS as being delivered via an LMS are published to the “LMS-only” topic. Refer to the “Message Publication” on page 6-8 for more information.
Expected Consumption Behavior
The LMS or its adapter is expected to consume all membership messages published to the “LMS-only” topic, determine whether the message is relevant to the LMS, and either update the LMS or discard the message as appropriate.
In the case of updates, the full snapshot of the data is sent each time, in accordance with LDIS-P and IMS-ES guidelines. The LMS or LMS adapter is responsible for determining what data changed and making the appropriate update to system data.
The LMS should record grade-mode information to prevent invalid grades from being entered in the LMS and subsequently being transferred to the SIS, where they will fail posting.
For error handling information, see “Error Handling” on page 1-11.
8 Banner Integration for eLearning 8.0 9-7Message Reference Guide
LDIS-P Messaging for Student Enrollment Data
9-8
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Student Enrollment DataMay 200
10 LDIS-P Messaging for Faculty Assignment Data
Data on faculty members and their assignments is maintained in the SIS, which provides for the creation, update, and deletion of this data. As a result, the SIS is considered the authoritative source for faculty assignment data and the corresponding publication of sync messages.
LDIS-P Implementation
Faculty assignment data is formatted for publication using the LDIS-P membership structure, which implements and extends the IMS-ES membership structure.
The following table defines the specific use of membership attributes and elements to convey faculty assignment data.
NoteOnly those elements and attributes that can be published are included. System-specific exceptions to the data that can be published are noted.
Tag Name Type Content Example/Comment
membership Element
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element {course reference number}.{term}
Example: 63331.200520
/ member Element
/ / sourcedid Element
8 Banner Integration for eLearning 8.0 10-1Message Reference Guide
LDIS-P Messaging for Faculty Assignment Data
10-2
Message Production Logic
Membership messages are produced when a teaching assignment is made or removed for a course section whose parent term is flagged for synchronization with external systems. Changes to an instructor’s role (for example, from primary instructor to subordinate) are addressed through the production of multiple add and delete membership messages.
In terms of the XML structure used or the data that is produced, there is no distinction between these scenarios.
/ / / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / / id Element {SIS person identifier}
/ / idtype Element 1 Indicates that the member is a person.
/ / role Element
/ / / recstatus Attribute Not provided for create and update;3 for delete.
/ / / roletype Attribute 02 Indicates that the faculty member has an instructor role.
/ / / subrole Element Primary or Subordinate
Specifies whether the instructor is the primary or subordinate instructor for the section.
/ / / status Element {faculty member’s status}
Faculty member’s status rendered in IMS-ES encoding scheme:1 = active0 = inactive
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Faculty Assignment Data
May 200
In the case of updates, the full snapshot of the data is sent each time, in accordance with LDIS-P and IMS-ES guidelines. Likewise, deletions contain the full snapshot of the data as known by the SIS, allowing consuming applications to verify that they have the most recent copy.
Create Faculty Assignment Membership - Sample XML
The following sample XML is an excerpt of what is produced upon creation of a faculty assignment membership.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>336983611</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="02">
<subrole>Primary</subrole>
<status>1</status>
</role>
</member>
</membership>
</enterprise>
Update Faculty Assignment Membership - Sample XML
The following sample XML is an excerpt of what is produced when changing a faculty assignment membership.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
8 Banner Integration for eLearning 8.0 10-3Message Reference Guide
LDIS-P Messaging for Faculty Assignment Data
10-4
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>336983611</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="02">
<subrole>Subordinate</subrole>
<status>1</status>
</role>
</member>
</membership>
</enterprise>
Delete Faculty Assignment Membership - Sample XML
The following sample XML is an excerpt of what is produced when deleting the faculty assignment membership.
<enterprise>
<properties>
<datasource>Banner University</datasource>
<datetime>2004-01-01</datetime>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>336983611</id>
</sourcedid>
<idtype>1</idtype>
<role recstatus="3" roletype="02">
<status>0</status>
</role>
</member>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Faculty Assignment Data
May 200
</membership>
</enterprise>
MEP Faculty Assignment Membership - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the faculty assignment object uses Multi-Entity Processing functionality.
<sourcedid>
<source>Banner University</source>
<id>INST.63331.200520</id>
</sourcedid>
Message Publication
Messages relating to the creation, update, and deletion of faculty assignment data are published to the “all data” topic in all situations.
Because only a subset of course sections are published to and consumed from the “LMS-only” topic, only those enrollments for course sections that have been identified in the SIS as being delivered via an LMS are published to the “LMS-only” topic. Refer to the “Message Publication” on page 6-8 for more information.
Expected Consumption Behavior
The LMS or its adapter is expected to consume all membership messages published to the “LMS-only” topic, determine whether the message is relevant to the LMS, and either update the LMS or discard the message as appropriate.
In the case of updates, the full snapshot of the data is sent each time, in accordance with LDIS-P and IMS-ES guidelines. The LMS or LMS adapter is responsible for determining what data changed and making the appropriate update to system data.
For error handling information, see “Error Handling” on page 1-11.
8 Banner Integration for eLearning 8.0 10-5Message Reference Guide
LDIS-P Messaging for Faculty Assignment Data
10-6
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Faculty Assignment DataMay 200
11 LDIS-P Messaging for Assign Student Grades
Although the Banner SIS is considered authoritative for student grade information, Banner Integration for eLearning provides for the assignment of student grades in the LMS and the subsequent recording of the grades in the SIS. This allows grades to be assigned in the system through which instruction is delivered, and, at the same time, to be validated against SIS business logic, ensuring that only the proper type of grade is assigned. This is the only message-producing use case originating in the LMS.
The exchange of grades with the SIS can be for a single student or for multiple students and can be for midterm or final grades.
LDIS-P Implementation
Grade data is formatted in a request to the SIS using the LDIS-P membership structure, which implements and extends the IMS-ES grade assignment structure.
The following table defines the specific use of membership attributes and elements to convey student grade data entered by a faculty member.
NoteOnly those elements and attributes that can be published are included. System-specific exceptions to the data that can be published are noted.
Tag Name Type Content Example/Comment
properties Element
/ extension Element
/ / luminisproperties Element
/ / / requestor Element
/ / / / sourcedid Element
/ / / / / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
8 Banner Integration for eLearning 8.0 11-1Message Reference Guide
LDIS-P Messaging for Assign Student Grades
11-2
/ / / / / id Element {instructor ID} Identifier of the instructor assigning grades in the LMS. This ID must match the ID of a valid instructor in the SIS who has authority to assign grades for the section identified in the membership element.
/ / / / idtype Element 1 Indicates that the instructor is a person.
membership Element One membership structure reflecting the section group’s student members.
/ sourcedid Element
/ / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element {course reference number}.{term}
Example: 63331.200520
/ member Element
/ / sourcedid Element
/ / / source Element Banner {unique, unchangeable identifier for the institution}
Example: Banner University
/ / / id Element {SIS person identifier}
Person identifier of the student being graded.
/ / idtype Element 1 Indicates that the member is a person.
/ / role Element
Tag Name Type Content Example/Comment
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Assign Student Grades
May 200
/ / / recstatus Attribute Not provided; interpreted as an update.
/ / / roletype Attribute 01 Indicates that the student has a learner role.
/ / / status Element {student’s status} Student’s enrollment status rendered in IMS-ES encoding scheme:1 = active0 = inactive
/ / / interimresult Element
/ / / / resulttype Attribute MidTerm
/ / / / result Element {interim result grade} Interim result grade to be entered in the SISExample: Pass
/ / / finalresult Element
/ / / / result Element {final result grade} Final result grade to be entered in the SISExample: B
/ / / extension Element
/ / / / luminisrole Element
/ / / / / recordid Element
/ / / / / / id Element {identifier defined by the publishing adapter for this record}
Used to correlate data objects to processing errors.Example: 9956333003
Tag Name Type Content Example/Comment
8 Banner Integration for eLearning 8.0 11-3Message Reference Guide
LDIS-P Messaging for Assign Student Grades
11-4
Message Production Logic
The Grade Exchange Adapter can accept and process LDIS-P 2.0-compliant XML messages that contain either a single student grade or multiple student grades. The LMS must determine when and how messages of this type are produced.
Single Student Grade - Sample XML
The following sample XML is for a grade exchange request to record the mid-term grade for a single student. The instructor making the request is identified by the luminisproperties/requestor element. The optional luminisrole/recordid element is provided by the publishing adapter for correlation purposes.
<enterprise>
<properties>
<datasource>Banner University Blackboard Vista Enterprise</datasource>
<datetime>2004-01-01</datetime>
<extension>
<luminisproperties>
<requestor>
<sourcedid>
<source>Banner University</source>
<id>336983611</id>
</sourcedid>
<idtype>1</idtype>
</requestor>
</luminisproperties>
</extension>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>389462321</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<interimresult resulttype="MidTerm">
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Assign Student Grades
May 200
<result>C</result>
</interimresult>
<extension>
<luminisrole>
<recordid id="389462321"/>
</luminisrole>
</extension>
</role>
</member>
</membership>
</enterprise>
Multiple Student Grades - Sample XML
The following sample XML is for a grade exchange request to record the final grade for four students. The instructor making the request is identified by the luminisproperties/requestor element. The optional luminisrole/recordid element is not provided in this example.
<enterprise>
<properties>
<datasource>Banner University Vista Enterprise</datasource>
<datetime>2004-01-01</datetime>
<extension>
<luminisproperties>
<requestor>
<sourcedid>
<source>Banner University</source>
<id>336983611</id>
</sourcedid>
<idtype>1</idtype>
</requestor>
</luminisproperties>
</extension>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>983364111</id>
</sourcedid>
8 Banner Integration for eLearning 8.0 11-5Message Reference Guide
LDIS-P Messaging for Assign Student Grades
11-6
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<finalresult>
<result>Complete</result>
</finalresult>
</role>
</member>
<member>
<sourcedid>
<source>Banner University</source>
<id>864257312</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<finalresult>
<result>Pass</result>
</finalresult>
</role>
</member>
<member>
<sourcedid>
<source>Banner University</source>
<id>597272913</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<finalresult>
<result>C</result>
</finalresult>
</role>
</member>
<member>
<sourcedid>
<source>Banner University</source>
<id>597272518</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<finalresult>
<result>B</result>
</finalresult>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Assign Student Grades
May 200
</role>
</member>
</membership>
</enterprise>
Multiple Student Grades (Multiple Members With Same Source ID) - Sample XML
The following sample XML contents include three unique members with four member elements: two members have final results only, while the third member has both midterm and final results, represented as two separate member elements. The instructor ID is part of extension under the properties object.
<enterprise>
<properties>
<datasource>Banner University Vista Enterprise</datasource>
<datetime>2004-01-01</datetime>
<extension>
<luminisproperties>
<requestor>
<sourcedid>
<source>Banner University</source>
<id>336983611</id>
</sourcedid>
<idtype>1</idtype>
</requestor>
</luminisproperties>
</extension>
</properties>
<membership>
<sourcedid>
<source>Banner University</source>
<id>63331.200520</id>
</sourcedid>
<member>
<sourcedid>
<source>Banner University</source>
<id>983364111</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<finalresult>
<result>Complete</result>
</finalresult>
8 Banner Integration for eLearning 8.0 11-7Message Reference Guide
LDIS-P Messaging for Assign Student Grades
11-8
<extension>
<luminisrole>
<recordid id="9956333001"/>
</luminisrole>
</extension>
</role>
</member>
<member>
<sourcedid>
<source>Banner University</source>
<id>864257312</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<finalresult>
<result>Pass</result>
</finalresult>
<extension>
<luminisrole>
<recordid id="9956333002"/>
</luminisrole>
</extension>
</role>
</member>
<member>
<sourcedid>
<source>Banner University</source>
<id>597272913</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<interimresult resulttype="MidTerm">
<result>C</result>
</interimresult>
<extension>
<luminisrole>
<recordid id="9956333003"/>
</luminisrole>
</extension>
</role>
</member>
<member>
<sourcedid>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Assign Student Grades
May 200
<source>Banner University</source>
<id>597272913</id>
</sourcedid>
<idtype>1</idtype>
<role roletype="01">
<status>1</status>
<finalresult>
<result>B</result>
</finalresult>
<extension>
<luminisrole>
<recordid id="9956333004"/>
</luminisrole>
</extension>
</role>
</member>
</membership>
</enterprise>
MEP Student Grade - Sample XML
The following sample XML is an excerpt of how the sourcedid element is produced if the student grade assignment object uses Multi-Entity Processing functionality.
<sourcedid>
<source>Banner University</source>
<id>INST.63331.200520</id>
</sourcedid>
Message Publication
Although the LMS has some discretion regarding when grade exchange requests are produced and whether they are for one or multiple students, the following guidelines should be followed.
recordid Tag
In addition to the sourcedid XML tag, the grade exchange request provides for an additional recordid tag that helps to uniquely identify a particular “member-action” in the request. Such an identifier is necessary because an IMS-ES document might contain elements that convey multiple actions that need to be taken on the same data object, making the data object's sourcedid ambiguous. The use of the recordid element removes this ambiguity by allowing each “data object-action” to be uniquely identified.
8 Banner Integration for eLearning 8.0 11-9Message Reference Guide
LDIS-P Messaging for Assign Student Grades
11-10
Although the recordid tag is not a mandatory element from the standpoint of the DTD, it should be supplied by the requesting system if data conditions warrant to help correlate “records” to errors. If a recordid element is provided, the Grade Exchange Adapter returns it within the appropriate successdetail or errordetail element of the response. This is in addition to the corresponding sourceid element provided in the request.
originalsource Tag
The LDIS protocol also defines an optional originalsource tag in the successdetail and errordetail elements. Although originalsource is supported at the message level, it is not supported at the detail level.
The Grade Exchange Adapter currently processes grade exchange requests from a “single-system LMS implementation.” In other words, the adapter assumes that requests are made directly from the LMS in which the grade was recorded. As a result, the adapter disregards any member-level datasource tag that would correspond to an originalsource tag at the detail level in the response.
Supporting implementations where grades are recorded in one system but grade exchange requests are made from an intermediary system would require the Grade Exchange Adapter to be modified to return an originalsource tag containing the value of the membership-level datasource tag from the request message in the corresponding successdetail or errordetail element of the response.
Reply Channel
The LMS needs to provide a reply channel (JMS queue) in the grade exchange request. Grade Exchange Adapter queues grade exchange responses to the JMS queue provided in the request. The requestor can supply either a temporary queue or a permanent queue, and this should be transparent to the consumer of the UpdateRequest (the Grade Exchange Adapter in this case). The reply-to queue should be placed in the JMSReplyTo message header by the requestor. The consumer of the request needs to have ‘Produce’ permission on the queue that is supplied.
Expected Consumption and Response Behavior
Grade exchange request messages are consumed by the target SIS adapter, which tries to process the request and record the grade in the SIS. The SIS adapter does the following:
• Determines whether the XML content provided is valid according to the LDIS-P 2.0 DTD
• Determines whether the SIS is available
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Assign Student Grades
May 200
• Ensures that each member’s grade is valid according to the SIS business rules. Validation includes the following:
• Student, section, and student enrollment exist.
• Section and enrollment are gradable.
• Existing grade or component grade does not exist.
• Grade is of the right type for the enrollment grade mode.
• Faculty member identified in the request has authority to enter grades.
The grade exchange response is not an IMS-ES-compliant document nor does it contain the original XML message contents. Rather, the response consists of the following elements:
• processingresult document with a status code (/processingresult/@statuscode) that indicates the overall result of the request. The status code has one of the following values:
• Success
• Failure
• Partial success
• errordetail elements for member elements with errors
• successdetail elements for successfully processed member elements
\Status Code - Success
This status indicates the grade exchange transaction as a whole was successful. All students’ grades were updated successfully in the SIS. Response messages with this status include a successdetail element for each member element from the original request message. Each successdetail/successdescription element contains the following text:
GE00: Grade has been successfully updated.
The following sample XML is produced for the “Multiple Student Grades - Sample XML” on page 11-5 if all four member elements were processed successfully.
<processingresult statuscode="Success">
<datasource>Banner_ERP_GE_ADAPTER</datasource>
<datetime>2004-01-01T09:26:33</datetime>
<successdetail>
<sourcedid>
<source>Banner University</source>
<id>983364111</id>
</sourcedid>
8 Banner Integration for eLearning 8.0 11-11Message Reference Guide
LDIS-P Messaging for Assign Student Grades
11-12
<successdescription>GE00: Grade has been successfully updated.
</successdescription>
</successdetail>
<successdetail>
<sourcedid>
<source>Banner University</source>
<id>864257312</id>
</sourcedid>
<successdescription>GE00: Grade has been successfully updated.
</successdescription>
</successdetail>
<successdetail>
<sourcedid>
<source>Banner University</source>
<id>597272913</id>
</sourcedid>
<successdescription>GE00: Grade has been successfully updated.
</successdescription>
</successdetail>
<successdetail>
<sourcedid>
<source>Banner University</source>
<id>597272518</id>
</sourcedid>
<successdescription>GE00: Grade has been successfully updated.
</successdescription>
</successdetail>
</processingresult>
Status Code - Failure
This status indicates the grade exchange transaction as a whole failed. All student grade updates failed. Failures can be due to an infrastructure failure, invalid XML, or failed SIS validation.
Infrastructure Failure
A typical example of an infrastructure failure is when the SIS database is not available and a grade update request is attempted. The following occurs:
• The grade exchange transaction is considered a failure.
• The errordetail/@code in the response is set to InfrastructureFailure.
• The errordetail/errordescription element specifies the specific error encountered.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Assign Student Grades
May 200
The following sample XML is produced if the Banner SIS were not available to service the request.
<processingresult statuscode="Failure">
<datasource>Banner_ERP_GE_ADAPTER</datasource>
<datetime>2004-01-01T09:26:33</datetime>
<errordetail code="InfrastructureFailure">
<errordescription>ORA-01034: Oracle not available
</errordescription>
</errordetail>
</processingresult>
Invalid XML
The Grade Exchange Adapter validates the grade exchange XML received from the LMS against the LDIS-P 2.0 DTD. If the XML document does not validate against the DTD, the following occurs:
• No further processing is done.
• The errordetail/@code in the response is set to XmlNotValid.
• The errordetail/errordescription element specifies the specific location in the XML that is invalid.
The following sample XML is produced if the XML document in the request is invalid.
<processingresult statuscode="Failure">
<datasource>Banner_ERP_GE_ADAPTER</datasource>
<datetime>2004-01-01T09:28:56</datetime>
<errordetail code="XmlNotValid">
<errordescription>Element type "myelement" must be declared. The content of element type "member" must match "(comments?,
sourcedid,idtype,role+)".
</errordescription>
</errordetail>
</processingresult>
Failed SIS Validation for All Members)
This type of failure occurs if student information in the XML request contains invalid data from the standpoint of the SIS. This can occur for any of the following reasons:
GE01 Student ID does not exist.GE02 Section does not exist.GE03 Section is not gradable.
8 Banner Integration for eLearning 8.0 11-13Message Reference Guide
LDIS-P Messaging for Assign Student Grades
11-14
The /processingresult/errordetail/errordescription element contains specific error information, such as the preceding error codes and messages, and the /processingresult/errordetail/@code is set to ConstraintViolation.
The following sample XML is produced for the “Multiple Student Grades - Sample XML” on page 11-5 if all four member elements failed the SIS business rules.
<processingresult statuscode="Failure">
<datasource>Banner_ERP_GE_ADAPTER</datasource>
<datetime>2004-01-01T09:33:31</datetime>
<errordetail code="ConstraintViolation">
<sourcedid>
<source>Banner University</source>
<id>983364111</id>
</sourcedid>
<errordescription>GE08: Grade not valid for section.
</errordescription>
</errordetail>
<errordetail code="ConstraintViolation">
<sourcedid>
<source>Banner University</source>
<id>864257312</id>
</sourcedid>
<errordescription>GE08: Grade not valid for section.
</errordescription>
</errordetail>
<errordetail code="ConstraintViolation">
<sourcedid>
<source>Banner University</source>
<id>597272913</id>
</sourcedid>
<errordescription>GE01: Student ID does not exist.
</errordescription>
GE04 Student enrollment does not exist.GE05 Student enrollment is not gradable.GE06 Gradable component records exist; must generate midterm grade
through component marks.GE07 Gradable component records exist - must generate final grade
through component marks.GE08 Grade not valid for section.GE09 Grade already rolled to historyGE010 Received grade already posted to student enrollment. No update
performed.GE011 Faculty ID is not assigned to section.
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Assign Student Grades
May 200
</errordetail>
<errordetail code="ConstraintViolation">
<sourcedid>
<source>Banner University</source>
<id>597272518</id>
</sourcedid>
<errordescription>GE04: Student enrollment does not exist.
</errordescription>
</errordetail>
</processingresult>
Status Code - Partial Success
This status indicates only some of the member’s/student’s grades contained in the request were successfully updated in the SIS. The processingresult element contains both successdetail and errordetail elements, indicating the result of processing each student grade in the SIS. Member records that were successfully updated result in the production of successdetail elements, while member records that were not updated result in the production of errordetail elements.
Because the processingresult element contains both successdetail and errordetail child elements, ordering of these elements does not match the order of the corresponding member records in the original request.
Every response message has a JMS message header JMSCorrelationID that helps identify and correlate the response received to a particular request made by the LMS. The JMSMessageId header from the UpdateRequest message is the value of the JMSCorrelationID header on the UpdateReply message. If the requestor supplies an ldisp_id message property on the UpdateRequest, then the ldisp_correlation_id message property on the UpdateReply contains the value ldisp_id.
The following sample XML is produced for the “Multiple Student Grades - Sample XML” on page 11-5 if two of the membership objects were in error but the other two passed.
<processingresult statuscode="PartialSuccess">
<datasource>Banner_ERP_GE_ADAPTER</datasource>
<datetime>2004-01-01T09:33:31</datetime>
<errordetail code="ConstraintViolation">
<sourcedid>
<source>Banner University</source>
<id>983364111</id>
</sourcedid>
<errordescription>GE08: Grade not valid for section.
</errordescription>
</errordetail>
<errordetail code="ConstraintViolation">
8 Banner Integration for eLearning 8.0 11-15Message Reference Guide
LDIS-P Messaging for Assign Student Grades
11-16
<sourcedid>
<source>Banner University</source>
<id>864257312</id>
</sourcedid>
<errordescription>GE08: Grade not valid for section.
</errordescription>
</errordetail>
<successdetail>
<sourcedid>
<source>Banner University</source>
<id>597272913</id>
</sourcedid>
<successdescription>GE00: Grade has been successfully updated.
</successdescription>
</successdetail>
<successdetail>
<sourcedid>
<source>Banner University</source>
<id>597272518</id>
</sourcedid>
<successdescription>GE00: Grade has been successfully updated.
</successdescription>
</successdetail>
</processingresult>
Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Assign Student Grades
May 200
A LDIS-P Support for Multi-Entity Processing
Ellucian supports Multi-Entity Processing (MEP) utilizing Virtual Private Database (VPD) technology. VPD is an Oracle 8i feature that separates the Banner® SIS data into logical groups. The VPD utility adds the user's identity to each query statement (Select, Insert, Update, or Delete) so that users can access only the data to which they have the authority to see. The data is segregated by institution code.
MEP impacts Banner Intcomp in two ways:
• As defined by the Data Integration Protocol IMS Specification, Banner Intcomp publishes unique event objects. To enforce uniqueness and maintain support of the protocol, the VPDI code is included in the event object key (sourcedid id) when the key data is derived from a table with a VPD policy. Refer to the latest Data Integration SDK Protocol IMS Specification for details and examples.
• When an event object contains VPD data that is child data of non-VPD data, then Banner Intcomp must publish all child event data for all institutions to conform to the Data Integration Protocol. In this case, all data is selected from all institutions.
The SIS is considered the authoritative source for the following institution data:
• Institution identifier
• Institution description
LDIS-P Implementation
Institution data is formatted for publication using the LDIS-P group structure, which implements and extends the IMS-ES group structure.
The following table defines the specific use of group attributes and elements to convey institution data.
9 Banner Integration for eLearning 8.0.1 A-1Message Reference Guide
LDIS-P Support for Multi-Entity Processing
A-2
SIS Institution Extract Process
Banner Integration for eLearning provides an additional extract process that produces institution group XML. No comparable synchronization messages are created for this group. All institutions present in the SIS are created by the process and rendered into an XML format that can be loaded into LDIS-P consumers.
Tag Name Type Content Example/Comment
group Element
/ recstatus Attribute Not provided for create and update;3 for delete.
/ sourcedid Element
/ / source Element {unique, unchangeable identifier for the institution}
Example: Banner University
/ / id Element {SIS institution identifier}
SIS institution identifier to make the ID unique within the enterprise.Example: BCC
/ grouptype Element
/ / scheme Element Luminis
/ / typevalue Element Institution
/ / / level Attribute 1
/ description Element
/ / short Element {institution name} Example: Banner Community College
Banner Integration for eLearning 8.0.1 May 2009Message Reference GuideLDIS-P Support for Multi-Entity Processing
May 200
Institution Group - Sample XML
The following sample XML is produced to convey institution data.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE enterprise SYSTEM "ldisp-2.0.dtd">
<enterprise>
<properties lang="en">
<datasource>Banner University</datasource>
<datetime>2006-02-14T09:47:50</datetime>
</properties>
<group>
<sourcedid>
<source>Banner University SCT Banner</source>
<id>BCC</id>
</sourcedid>
<grouptype>
<scheme>Luminis</scheme>
<typevalue level="1">Institution</typevalue>
</grouptype>
<description>
<short>Banner Community College</short>
</description>
</group>
</enterprise>
9 Banner Integration for eLearning 8.0.1 A-3Message Reference Guide
LDIS-P Support for Multi-Entity Processing
A-4
Banner Integration for eLearning 8.0.1 May 2009Message Reference GuideLDIS-P Support for Multi-Entity Processing