SIS Integration Planning

Advantages

Key advantages to using Student Information System (SIS) integrations to pass data to Blackboard Learn to automatically populate and update your system include the following:

• Managing course and user data can be delegated to one or more administrators who do not need command line access to Blackboard servers.
• Data can be transferred quickly and efficiently from one Learning Management System (LMS) to another.

Before you begin

Before creating one or more SIS integrations, it is critically important to engage all the stakeholders to plan what data from which sources and in what format will be used by Blackboard Learn to populate the system. Because communication is one-way from the SIS to Blackboard Learn, all the data for each course, user, and user role has to be defined and described to Blackboard. In addition, all users have to have credentials that uniquely identify them to Blackboard.

Gathering course, user, and enrollment data is a recurring process. As people enter and leave the institution, courses are created and enrollments change, so the data within Blackboard has to change. How often the data will have to be gathered and loaded is determined by institution policy. The data sources that provide information to the system should set up repeatable procedures for the delivery of data to Blackboard administrators.

Your institution may already have a robust process in place based on agreed upon business rules. In that case, extensive planning may not be necessary, but you will need to understand the information requirements Blackboard needs as well as the order and frequency of tasks that need to be completed. If your institution is just starting to run or changing automated processes, more in depth planning will be necessary so that you do have the business rules and information available before you start.

Required information for users, courses, and enrollments

You will need to provide Blackboard with the following information for users, courses, and enrollments to create an integration. Identifying where each piece of data comes from is the first part of planning.

Object	Element
Users (People)	Person unique identifier Login Identifier Password (to access Blackboard) First Name Last Name Nickname (optional) Email Address Institution Email Address Institutional Role
Course	Course unique identifier Course Identifier Course Name Source for Course Content (optional)
Enrollments	Associated set of users for the Course User's Role in course

Decide on authentication method

Gather a login identifier and password for each user. You can use Blackboard's native authentication system or your institution's authentication system.

• If you use Blackboard's native authentication system, the login identifier and a password will be among the user data gathered. The login identifier and the password will have to be distributed to each user.
• If the login identifier and password comes from your institutional authentication system, gather the login identifier and generate a random password for each user. The user would then authenticate against your institutional authentication system.

Define data sources

While it is possible to gather all your data information internally from an LMS like Vista, it is much better to use official institutional data that your institution gathers and maintains. This institutional data will probably come from different data sources. What those data sources are and what data you can collect from them may already be established at your institution, or it may yet to be decided. In any event, you will need to have agreed upon data sources and a method of extracting data to create an integration.

Every institution is set up differently, but there are some common places you can go to find the information you need.

• Student Information System (SIS): Repository for student information such as name, address, contact information, school year, or graduation dates.
• The Office of the Registrar: Course catalog information as well as course names, description and section information, also enrollment information.
• Human Resources Department or Human Resources Management System (HRMS): Information describing every person at your institution including teachers, staff, adjuncts, and teaching assistants (TAs).
• School Directory Service (white pages): Look up employee and departmental phone numbers, email addresses, and office addresses. This directory could be a source of information for your LMS.
• IT Department or Computer Services: Sets methods for authenticating users, such as an LDAP service. It may generate email addresses and login credentials.

Resolve conflicting data

When data is gathered from multiple data sources, conflicting data elements can occur. A policy to resolve the conflicts needs to be in place so the system knows which source to use. For example, the HRMS may ask the user for an email address. The registrar may also ask for an email address. Conflicting email addresses can occur when a user has two different roles at the institution such as student and teaching assistant, or staff and adjunct faculty. In this case, when two institutional email addresses are different, a decision must be made as to which source has precedence and will be taken as the Institution Email for the user.

Another example of conflicting data elements is when the Office of the Registrar and SIS each have an email address for students. The institution's directory service may also keep an email address for each user. One way to resolve this conflict is to choose one source over the other. Another solution is to allow the user to set their email address within Blackboard.

To create successful integrations, places where conflicting data elements can occur need to be identified and resolved.

What does the Institution Email mean and what does it support?

The Institution Email field allows customized field mappings between a client’s externally supported service and Blackboard Learn. In the case of a data provider that is also a cloud provider, such as Microsoft, the User Principle Name (UPN) is a primary unique identifier for each user consisting of a UPN prefix (the user’s account name) and a UPN suffix (a DNS domain name) joined together with an @ symbol. This creates a unique email address for each specific user within the data service directory.

To ensure data is accurate and enrollments or memberships between Blackboard Learn and the data service provider, are correctly achieved, a user’s email address must match between both systems. In Blackboard Learn, a user can change or override their existing Person Email address in the user interface, which could result in sync errors occurring and the user not being correctly added. The Institution Email field mapping ensures this level of security and validation checking can be correctly managed, whether the user has changed their Person Email within Blackboard or not.

Data loading order

All the information the system needs to create users, courses, and enrollments is required, but because the data can come from different sources, it needs to be loaded into Blackboard in a specific order. Course and user information needs to be loaded first because enrollments depends on that information. The order of data loading is:

1. Users
2. Courses
3. Enrollments

The specific information for creating users, courses, and enrollments is described in the sections below.

Create users

• EXTERNAL_PERSON_KEY. This element is used to identify the user internal to the database. While this key is never displayed, it should have no person identifiable data, no names, no social security numbers or birth dates. The reason is that people's data changes. Some get married, divorced, legal name changes, or change their social security number. By not including person identifiable data, you avoid any problems with changes. This key can be up to 64 characters long. Because of the risk of accidentally exposing student data to another student, this key should never be re-used. Once it is issued to a student it should not be issued again. A re-issued EXTERNAL_PERSON_KEY risks making one user's information visible to another user. Therefore, Blackboard recommends that this key be part of a very large key space. A good way to construct such a key, if you do not already have an appropriate identifier, is to generate a random 16-20 digit hexadecimal number per student. The large variability and random distribution allows the database to build a balanced index.
• USER_ID. The USER_ID is sometimes known as a network id, a username, or login name. This element, in conjunction with a password, is used to authenticate a user to the LMS. If a centralized authentication system does not exist, Blackboard can be used as the authentication system. In this case, the Blackboard administrator needs to create the USER_IDs and passwords for each user. If using a centralized authentication system with a protocol that is supported by Blackboard, we recommend authenticating Blackboard users with that system. In this case, a list of USER_IDs tied to the EXTERNAL_PERSON_KEYs must be assembled to load into Blackboard. This will also serve as authorization for Blackboard.
• FIRSTNAME, LASTNAME, NICKNAME. These elements determine how the student's identity is displayed within Blackboard. If possible, have the source of the name data split the names into their components before it is delivered to Blackboard. This name is likely to be the official name used by the institution for official records, such as grade transcripts, Internal Revenue Service W2 forms, or identification cards. Not all people are hailed by their official first name, some insist on a nickname. Blackboard provides the ability to (optionally) specify a nickname with the NICKNAME data element. Configure the LMS to display the contents of NICKNAME instead of FIRSTNAME. As a best practice, formalize and centralize the gathering and storage of nicknames.
• EMAIL. The email address is required for communication with the user.
  • Blackboard supports two email addresses per person (Person Email and Institution Email). If the user has multiple email addresses due to data collection from multiple data sources, an institution must either:
    • Choose a system of record as the primary email, or
    • Use the Institution Email field to set an official email address for the users’ account, allowing the user to set their own email address in Blackboard without conflicts occurring.
  • Multiple emails situations may also happen when a user has more than one role within the institution such as student and teaching assistant or staff and adjunct instructor. You must choose one or the other for this user.
  • Some instructors may want an email address to use within Blackboard that is not their official email address, and some students may want to separate their course work email address from their social email address. To make this possible, the user must be able to update their email address within Blackboard. (The institution can decide whether students can update their email address.) Once a user has changed their email address you cannot update it again from the official source. It becomes the user's responsibility to keep their email address within Blackboard current. The danger is that the user will forget to update their official record, and email communication will not arrive at the correct address.
• INST_EMAIL: now available for all existing SIS integration types with the exception of SIF, the Institution Email  is a primary unique identifier for each user consisting of a UPN prefix (the user’s account name) and a UPN suffix (a DNS domain name) joined together with an @ symbol. This creates a unique email address for each specific user within a data service directory, allowing institutions to manage the data synchronization process effectively between Blackboard Learn Ultra and the service. It is set by default to the Person Email for all SIS formats and requires to be unique for each person. All existing integrations that are setup and running will have this data mapping in place, as SIS will fail to import users if their email is duplicated.
  You can manage it from the SIS Advanced Configuration Settings > Users Learn Object Type > Field Mapping.

  No email communications are sent to the inst_email. It's strictly used with 3rd party integrations at this point.
  This user field can't be set via batch file in the Users -> Create section of the admin panel.

• INSTITUTION_ROLE. This element holds a user's role at the institution. This is not their role in the course but rather a way to identify a user's role at the institution. The INSTITUTION_ROLE determines what the user can view in Blackboard. This role is also used to specify which users will have elevated privileges within the application. If there is no desire to present different portal page views to users based on their role at the institution the INSTITUTION_ROLE data element can be set to 'none'.
• SYSTEM_ROLE. This element holds a user's role within Blackboard. This role grants the ability to manage aspects of Blackboard. They include system administration, course creation and course content management. The role of 'NONE' provides no system administration or course creation privileges and is the most commonly assigned role.

Create courses

• EXTERNAL_COURSE_KEY. This element uniquely identifies the course. It is not seen by any Blackboard users. As best practice, format these data elements to make them convenient to sort and manipulate. You will need to gather several data elements that describe a course uniquely across several years (your data retention time). The registrar often keeps a number that uniquely identifies the course at least within a given semester. For example, if you have a chemistry 301 course for the fall of 2012 with a unique course number of 12345, you might choose 2012_fall_12345_CH_301 as the value of the EXTERNAL_COURSE_KEY. An additional improvement is to make all the elements of the EXTERNAL_COURSE_KEY the same length if possible, particularly the department and dates. A semester can be represented by a month digit, 1, 6, 9. Some third party Building Blocks require that the fields be the same length. This is especially true for the date information. The previous example separated the individual data elements with a consistent data separator of underscore, '_'.
• COURSE_ID. This element is used for portal modules when sorting courses. This element cannot be changed once the course is created. This key is visible to users, and must contain information that is readily understood by the user. In general, this key should contain both a year and semester for sorting. It should also contain the department and course numbers as well as a unique identifier. For example, a COURSE_ID might be 2010_9_12345_CHEM_301. Use a consistent data separator, underscore is recommended. By default, the 'My Courses' portal module sorts courses by COURSE_ID; this is important when the list of courses gets long.
• COURSE_NAME. This element can be anything that describes the course. It does not have to be unique and can be changed during a data load, or by the instructor. Some Building Blocks sort by COURSE_NAME.
• TEMPLATE_COURSE_KEY. The optional TEMPLATE_COURSE_KEY holds the name of an existing course that has been prepared with content. Some organizations need to offer courses with standardized content, which is possible with TEMPLATE_COURSE_KEY. This content can include files, surveys, quizzes, announcements, and even instructors. The template course must be complete before the courses are created. The content is copied into the new course at the time of creation. Changing the template course after courses are created will have no effect on the previously created courses. The template course must exist in its final form before creating new courses based upon the template. Choose a standardized naming convention for template courses. For example, start all template courses with 'template' followed by an underscore and some other identifier.

Create enrollments

An enrollment is an assignment of a user to a course and the definition of the user's role, such as student or instructor, in the course.

• EXTERNAL_COURSE_KEY. This element is the unique key from the course data.
• EXTERNAL_PERSON_KEY. This element is the unique key from the user data. These keys must be defined before a particular enrollment record can be processed.
• ROLE. The ROLE data element defines the user's role in the course.

Label and format your data

After you have identified all your data sources, set conflict resolution rules, and gathered all the data elements from your sources, you need to create some labels for your data, called Data Source Keys (DSKs), so that a set of data can be processed in a single operation. You also need to ensure that your data is formatted so that it can be recognized and processed correctly by the type of integration you select.

Create data source keys

A data source key is a label that can be given to a set of data so that it can be handled in a single operation rather than having each record processed individually. You can create multiple data source keys and use them to load and process data in Blackboard.

As a best practice, design your data source keys so that you can load all similar items together. Put users under one data source key. Put each semester's courses into another data source key. This way you can efficiently manipulate a semester's worth of courses with a single command without affecting the users. Load each semester's enrollments into their own data source key for the same reasons.

Build the DATA_SRC_KEY name using the year, semester, source and type of data. For example, use 2011_fall_SIS_courses to label the Fall 2011 courses.

More on data source keys

Format the data

The data has to be formatted such that the SIS Integration Building Block can recognize each element and process it accordingly. Every data element has to be identified as to its type. Extensible Markup Language (XML) provides a simple generalized and verbose method to describe data. The XML format will be slightly different depending on the type of integration you select.

Additional planning information

As part of your planning for SIS integrations you will need to decide which type or types of integration you want to create as well as make other decisions based on your institution's policies and requirements.

Integration types

There are six types of Integrations available, and the data format will be slightly different depending upon the type selected. There is no limit to the number of Integrations a system may have. It is possible, although unusual, to have a variety of Integration Types on a single system.

• IMS Enterprise 1.1
• IMS Enterprise 1.1 - Vista
• IMS Learning Information Services
• Snapshot Flat File
• Snapshot XML
• Grades Journey

To learn more about the data mapping for each integration type, see Create and Edit SIS Integrations.

SSHA password encryption for IMS learning information services

Authorization is based on methods used by Sungard Banner. If you set encryption type in the field mapping to SSHA, it will prepend the {SSHA} if not already there. In addition to the SSHA prefix being set and embedded, pwencryptiontype is also set and embedded as shown in the following example:

<userid useridtype="SCTID" pwencryptiontype="SSHA" password="{SSHA}OMMjWPR+6fM/iQ+ZvpWHEVGxoAEFT0JUQUE4Qz==">N00013021</userid>

Plan for communication disruptions

In the event that there is a communication problem between the SIS and Blackboard, you need a plan on how to deal with the disruption. It is possible to upload your data manually into the Integration in the GUI. System triggers and backups need to be established to keep your system running smoothly and system data current.

Set the integration status

Blackboard recommends that new integrations begin in the Testing status. Selecting this status will allow you to test the Integration, and fix any issues which may arise before committing to the Integration. Once the Testing is complete, set the status to Inactive or Active. An Inactive status will not process requests or update data in the database. An Active, the system will process requests, update data in the database, and be visible to the users.

Blackboard also suggests creating this integration on a Staging or Test environment prior to releasing to production.

Logging

Setting the log verbosity during integration creation will dictate the type and depth of logging kept on your system for the selected Integration. Logs can be filtered using an advanced search method which includes the type of error, the integration, and a date range.

Advanced configuration

The Learn Object Type, and the Object Type from your SIS system are mapped in a 1 to 1 list. Select how to handle inserts, updates, and deletes for each Object Type.

Learn more

Learning Information Services Specification Primer

Learning Information Services