banner integration for elearning · ldis-p implementation ... this message reference guide defines...

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



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



Chapter 4 LDIS-P Messaging for Course Data



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



Chapter 5 LDIS-P Messaging for Term Data



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



Chapter 6 LDIS-P Messaging for Course Section Data



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



Chapter 7 LDIS-P Messaging for Cross-List Data



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



Chapter 8 LDIS-P Messaging for Person Data



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



Chapter 9 LDIS-P Messaging for Student Enrollment Data



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



vi Banner Integration for eLearning 8.0 May 2008Message Reference GuideContents

Chapter 10 LDIS-P Messaging for Faculty Assignment Data



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



Chapter 11 LDIS-P Messaging for Assign Student Grades



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


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


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.


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.


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.


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


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



Term recstatus

Term recstatus

Term recstatus

Course recstatus

Course recstatus

Course recstatus

CourseSection recstatus



Message Flow(part 1 of 2)

Update systemas appropriate






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 ( = )


Message Flow(part 2 of 2)





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.


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.


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.


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


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


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>


</properties>

<group>

<sourcedid>


<id>COLHS</id>

</sourcedid>

<grouptype>


<typevalue level="1">College</typevalue>



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>



</properties>

<group recstatus="3">

<sourcedid>


<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>


<id>INST.COLHS</id>

</sourcedid>


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.



2-6

May 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.


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.


group Element


/ sourcedid Element


LDIS-P Messaging for Department Data

3-2


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.



/ / id Element DEP{SIS department identifier}

SIS department identifier pre-pended to make the ID unique within the enterprise.Example: DEPENGL

/ grouptype Element


/ / typevalue Element Department



/ / short Element {department code} SIS-internal identifier for the college.Example: ENGL

/ / long Element {department name} Example: English


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>



</properties>

<group>

<sourcedid>


<id>DEPENGL</id>

</sourcedid>

<grouptype>


<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>



</properties>

<group>

<sourcedid>


<id>DEPENGL</id>

</sourcedid>

<grouptype>


<typevalue level="1">Department</typevalue>

</grouptype>



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>



</properties>


<sourcedid>


<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>


<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.


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.


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.





3-6

May 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.


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.


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.


group Element


/ sourcedid Element



/ / id Element CRS{subject code}-{course number}

Example: CRSENGL-101

/ grouptype Element


/ / typevalue Element Course



/ / 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


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}


/ / / 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.




/ / / id Element DEP{unique identifier of the parent department}

Example: DEPENGL

/ / label Element Department




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>



</properties>

<group>

<sourcedid>


<id>CRSENGL-101</id>

</sourcedid>

<grouptype>


<typevalue level="1">Course</typevalue>

</grouptype>

<description>

<short>ENGL-101</short>

<long>Introduction to English Literature</long>

</description>

<relationship relation="1">

<sourcedid>


May 200


<id>COLHS</id>

</sourcedid>

<label>College</label>

</relationship>


<sourcedid>


<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>



</properties>

<group>

<sourcedid>



</sourcedid>

<grouptype>


<typevalue level="1">Course</typevalue>

</grouptype>

<description>


<long>Introduction to Classic English Literature</long>

</description>


<sourcedid>


<id>COLHS</id>

</sourcedid>

<label>College</label>

</relationship>



4-6


<sourcedid>


<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>



</properties>


<sourcedid>



</sourcedid>

<description>


</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>


<id>INST-CRSENGL-101</id>

</sourcedid>


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.


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.




4-8

May 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


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.


group Element


/ sourcedid Element


LDIS-P Messaging for Term Data

5-2



/ / id Element {SIS term identifier} Example: 200520

/ grouptype Element


/ / typevalue Element Term



/ / 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


Banner Integration for eLearning 8.0 May 2008Message Reference GuideLDIS-P Messaging for Term Data

May 200


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>



</properties>

<group>

<sourcedid>


<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.




5-4

<grouptype>


<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>



</properties>

<group>

<sourcedid>


<id>200510</id>

</sourcedid>

<grouptype>


<typevalue level="1">Term</typevalue>

</grouptype>

<description>



May 200

<long>Fall 2004</long>

</description>

<timeframe>



</timeframe>

<enrollcontrol>



</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>



</properties>


<sourcedid>


<id>200610</id>

</sourcedid>

<description>


</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.



5-6

<sourcedid>


<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.


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.”



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.


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.


group Element


/ sourcedid Element



/ / id Element {course reference number}.{term}

Example: 63331.200210


LDIS-P Messaging for Course Section Data

6-2

/ grouptype Element


/ / typevalue Element CourseSection



/ / 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


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.




/ / / 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.







6-4


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



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>



</properties>

<group>

<sourcedid>


<id>10102.200510</id>

</sourcedid>

<grouptype>


<typevalue level="1">CourseSection</typevalue>

</grouptype>

<description>


<long>ENGL-101-001</long>

<full>Introduction to English Literature</full>

</description>

<org>

<orgunit>English</orgunit>

</org>

<timeframe>



</timeframe>


<sourcedid>


<id>200510</id>



6-6

</sourcedid>

<label>Term</label>

</relationship>


<sourcedid>



</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>



</properties>

<group>

<sourcedid>


<id>10102.200510</id>

</sourcedid>

<grouptype>


<typevalue level="1">CourseSection</typevalue>

</grouptype>

<description>


<long>ENGL-101-001</long>

<full>Introduction to English Literature</full>

</description>

<org>

<orgunit>English Literature</orgunit>

</org>


May 200

<timeframe>



</timeframe>

<enrollcontrol>



</enrollcontrol>


<sourcedid>


<id>200510</id>

</sourcedid>

<label>Term</label>

</relationship>


<sourcedid>



</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>



</properties>


<sourcedid>


<id>10102.200510</id>

</sourcedid>

<description>



6-8


</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>


<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.


May 200


The LMS or its adapter is expected to consume all course section group sync messages published to the “LMS-only” topic.


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.




6-10

May 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.


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.


group Element


/ sourcedid Element




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


/ / typevalue Element CrossListedSection



/ / short Element Cross Listed Section Group


membership Element One membership structure reflecting the cross-list section group’s members.

/ sourcedid Element



/ / id Element XLS{SIS cross-list identifier}{SIS term identifier}

Example: XLSAU200520


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




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.




7-4


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>



</properties>

<group>

<sourcedid>


<id>XLSJF200310</id>

</sourcedid>

<grouptype>


<typevalue level="1">CrossListedSection</typevalue>

</grouptype>


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>



</properties>

<membership>

<sourcedid>



</sourcedid>

<member>

<sourcedid>


<id>17384.200520</id>

</sourcedid>

<idtype>2</idtype>

<role>

<status>1</status>

</role>

</member>

<member>

<sourcedid>


<id>35254.200520</id>

</sourcedid>

<idtype>2</idtype>

<role>

<status>1</status>

</role>

</member>

<member>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<idtype>2</idtype>



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>



</properties>

<membership>

<sourcedid>



</sourcedid>

<member>

<sourcedid>


<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>



</properties>

<membership>

<sourcedid>


May 200



</sourcedid>

<member>

<sourcedid>


<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>



</properties>


<sourcedid>



</sourcedid>

<description>

<short>Cross Listed Section Group</short>

</description>

</group>

</enterprise>



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>


<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.


The LMS or its adapter is expected to consume all cross-list section group and membership sync messages published to the “LMS-only” topic.




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.


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.


person Element


/ sourcedid Element



/ / id Element {SIS person identifier}

/ userid Element {person's access ID} Repeatable.


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


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.




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



May 200


A sync message (ldisp_type = Sync) is produced when a person record is created or updated.


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>



</properties>

<person>

<sourcedid>


<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-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>



</properties>

<person>

<sourcedid>


<id>9450</id>

</sourcedid>

<userid useridtype="Logon ID" pwencryptiontype="SSHA" password="{SSHA}OHHjWPR+6fM/iP+ZvcWHEVGxoAFFR0JUQUE4Qw==">sskinner</userid>



<userid useridtype="Email ID">sskinner</userid>

<name>


<n>


May 200




</n>

</name>

<demographics>

<gender>2</gender>

</demographics>


<tel teltype="1">555-555-5555</tel>

<adr>

<street>34 Crockett Ct. </street>

<locality>Lincoln</locality>

<region>NE</region>



</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>



</properties>

<person>

<sourcedid>


<id>9450</id>

</sourcedid>



8-8

<userid useridtype="Logon ID" pwencryptiontype="SSHA" password="{SSHA}OHHjWPR+6fM/iP+ZvcWHEVGxoAFFR0JUQUE4Qw==">gicglare</userid>



<userid useridtype = "Email ID">sskinner</userid>

<name>


<n>




</n>

</name>

<demographics>

<gender>2</gender>

</demographics>


<tel teltype="1">555-555-5555</tel>

<adr>

<street>24 E. 56th Street </street>

<locality>Brooklyn</locality>

<region>NY</region>



</adr>

<institutionrole primaryrole="No" institutionroletype="Student"/>

<extension>

<luminisperson>

<academicmajor>Chemical Engineering</academicmajor>

</luminisperson>

</extension>

</person>

</enterprise>


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>


<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.


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.”




8-10

May 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.


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.


membership Element This is one membership structure reflecting the section group’s student members.

/ sourcedid Element




Example: 63331.200520


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



/ / / 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}


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




9-4


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 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>



</properties>

<membership>

<sourcedid>


<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



May 200

</sourcedid>

<member>

<sourcedid>


<id>983364111</id>

</sourcedid>

<idtype>1</idtype>

<role roletype="01">

<status>1</status>

<timeframe>



</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>



</properties>

<membership>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<member>

<sourcedid>


<id>983364111</id>

</sourcedid>

<idtype>1</idtype>



9-6


<status>1</status>

<timeframe>



</timeframe>


<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>



</properties>

<membership>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<member>

<sourcedid>


<id>983364111</id>

</sourcedid>

<idtype>1</idtype>

<role recstatus="3" roletype="01">

<status>0</status>

</role>

</member>

</membership>

</enterprise>


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>


<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.


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.




9-8

May 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.


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.



membership Element

/ sourcedid Element




Example: 63331.200520

/ member Element



LDIS-P Messaging for Faculty Assignment Data

10-2


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.





/ / 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


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>



</properties>

<membership>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<member>

<sourcedid>


<id>336983611</id>

</sourcedid>

<idtype>1</idtype>


<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>





10-4

</properties>

<membership>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<member>

<sourcedid>


<id>336983611</id>

</sourcedid>

<idtype>1</idtype>


<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>



</properties>

<membership>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<member>

<sourcedid>


<id>336983611</id>

</sourcedid>

<idtype>1</idtype>

<role recstatus="3" roletype="02">

<status>0</status>

</role>

</member>


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>


<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.


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.




10-6

May 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.


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.



properties Element

/ extension Element

/ / luminisproperties Element

/ / / requestor Element

/ / / / sourcedid Element

/ / / / / source Element Banner {unique, unchangeable identifier for the institution}



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




Example: 63331.200520

/ member Element





Person identifier of the student being graded.


/ / role Element


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




11-4


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>


<extension>

<luminisproperties>

<requestor>

<sourcedid>


<id>336983611</id>

</sourcedid>

<idtype>1</idtype>

</requestor>

</luminisproperties>

</extension>

</properties>

<membership>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<member>

<sourcedid>


<id>389462321</id>

</sourcedid>

<idtype>1</idtype>


<status>1</status>



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>


<extension>

<luminisproperties>

<requestor>

<sourcedid>


<id>336983611</id>

</sourcedid>

<idtype>1</idtype>

</requestor>


</extension>

</properties>

<membership>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<member>

<sourcedid>


<id>983364111</id>

</sourcedid>



11-6

<idtype>1</idtype>


<status>1</status>

<finalresult>

<result>Complete</result>

</finalresult>

</role>

</member>

<member>

<sourcedid>


<id>864257312</id>

</sourcedid>

<idtype>1</idtype>


<status>1</status>

<finalresult>

<result>Pass</result>

</finalresult>

</role>

</member>

<member>

<sourcedid>


<id>597272913</id>

</sourcedid>

<idtype>1</idtype>


<status>1</status>

<finalresult>

<result>C</result>

</finalresult>

</role>

</member>

<member>

<sourcedid>


<id>597272518</id>

</sourcedid>

<idtype>1</idtype>


<status>1</status>

<finalresult>

<result>B</result>

</finalresult>


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>


<extension>

<luminisproperties>

<requestor>

<sourcedid>


<id>336983611</id>

</sourcedid>

<idtype>1</idtype>

</requestor>


</extension>

</properties>

<membership>

<sourcedid>


<id>63331.200520</id>

</sourcedid>

<member>

<sourcedid>


<id>983364111</id>

</sourcedid>

<idtype>1</idtype>


<status>1</status>

<finalresult>

<result>Complete</result>

</finalresult>



11-8

<extension>

<luminisrole>

<recordid id="9956333001"/>

</luminisrole>

</extension>

</role>

</member>

<member>

<sourcedid>


<id>864257312</id>

</sourcedid>

<idtype>1</idtype>


<status>1</status>

<finalresult>

<result>Pass</result>

</finalresult>

<extension>

<luminisrole>

<recordid id="9956333002"/>

</luminisrole>

</extension>

</role>

</member>

<member>

<sourcedid>


<id>597272913</id>

</sourcedid>

<idtype>1</idtype>


<status>1</status>


<result>C</result>

</interimresult>

<extension>

<luminisrole>

<recordid id="9956333003"/>

</luminisrole>

</extension>

</role>

</member>

<member>

<sourcedid>


May 200


<id>597272913</id>

</sourcedid>

<idtype>1</idtype>


<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>


<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.



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


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>


<id>983364111</id>

</sourcedid>



11-12

<successdescription>GE00: Grade has been successfully updated.

</successdescription>

</successdetail>

<successdetail>

<sourcedid>


<id>864257312</id>

</sourcedid>



</successdetail>

<successdetail>

<sourcedid>


<id>597272913</id>

</sourcedid>



</successdetail>

<successdetail>

<sourcedid>


<id>597272518</id>

</sourcedid>



</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.


May 200

The following sample XML is produced if the Banner SIS were not available to service the request.

<processingresult statuscode="Failure">



<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.




<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.



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.




<errordetail code="ConstraintViolation">

<sourcedid>


<id>983364111</id>

</sourcedid>

<errordescription>GE08: Grade not valid for section.

</errordescription>

</errordetail>


<sourcedid>


<id>864257312</id>

</sourcedid>


</errordescription>

</errordetail>


<sourcedid>


<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.


May 200

</errordetail>


<sourcedid>


<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">




<sourcedid>


<id>983364111</id>

</sourcedid>


</errordescription>

</errordetail>




11-16

<sourcedid>


<id>864257312</id>

</sourcedid>


</errordescription>

</errordetail>

<successdetail>

<sourcedid>


<id>597272913</id>

</sourcedid>



</successdetail>

<successdetail>

<sourcedid>


<id>597272518</id>

</sourcedid>



</successdetail>

</processingresult>


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


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.


group Element


/ sourcedid Element

/ / source Element {unique, unchangeable identifier for the institution}


/ / id Element {SIS institution identifier}

SIS institution identifier to make the ID unique within the enterprise.Example: BCC

/ grouptype Element


/ / typevalue Element Institution



/ / 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">



</properties>

<group>

<sourcedid>

<source>Banner University SCT Banner</source>

<id>BCC</id>

</sourcedid>

<grouptype>


<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

banner integration for elearning · ldis-p implementation ... this message reference guide defines...

Documents