Feed processing involves populating and synchronizing data that is maintained by an external system. Typical examples include user, course, and registration data, often found in the student information system. It is also possible to use feed processing to migrate data from one system to another, such as inserting course descriptions or outcomes directly on to syllabi, or to assist with configuration.
*Note: Before continuing, it may be helpful to get a better understanding of how courses, sections, and templates interact.
At the end of this article you will find the Concourse feed specifications, samples for each of the feed files, and a debugging guide. They detail everything you should need to know to construct and process feeds in the system.
Though many of the definitions and parameters should be straightforward, we call out a few of the more important and/or complex parameters below. Again, this is not an exhaustive list of all feed file parameters. Please see the specification for the full complement of feed parameters.
Further, while there are many feeds that can be created and run, it is only necessary to construct the ones that are required to support the current scope of your implementation. Likewise, we suggest you begin experimenting with feeds in your sandbox that contain only a few rows to make sure that they are constructed properly before moving ahead to fully populated files in your production system.
- Source: It is highly recommended that the data provided by these feeds be derived directly from their authoritative, often the Student Information System (SIS). This is critical to easily integrate Concourse with other campus systems.
- Separators: All feed files need to be a pipe "|" separated text file. Since much of this feed data should be obtained from a report or script within your SIS, IT should have no issue producing this for you. However, if you are to generate the data manually, note that this is different than a comma separated value (CSV) worksheet that is typical in Excel. You can learn how to work with PSV files here.
- Updates: Making changes to your feed file and processing them again will update all row data with some exceptions, such as the unique identifier(s) for a given feed row. For example if a new user, course, or section identifier is entered, it will create a new entry and not update the existing one. Feed specific exceptions are noted in the feed specification.
- Relationship: These feed files require a degree of coordination and sequencing in order to properly work:
- The user feed creates user accounts. It is normally the first feed to be processed.
- Second comes the course feed, which creates new course syllabi.
- Next is the section feed, which relates courses to course sections. It does not actually create individual sectional syllabi from course syllabi. Instead it takes the courses already processed and applies one or more sections to them, all of which will share the same syllabus.
- You also then have the option to process syllabus content feeds which will insert content directly onto a course syllabus.
- Last comes the registration feed, which ties together users with courses and their sections.
System Data Feeds
- User Feed
- USER_IDENTIFIER: This is the unique identifier for the user that is often used for common authentication (e.g. smithb).
- INTERNAL_USER: This defines whether the user will be logging in using credentials stored in Concourse (=1) or those from a central campus system (=0), such as an LMS or portal.
- Course Feed
- COURSE_IDENTIFIER: This is the unique identifier for the course and should be a sequence already used in the SIS (e.g. 2018_SP_ECON_1100_2A). Also it is typical to use this to uniquely define the template set, which should be constructed in such a way that an SIS script can easily concatenate the parameters into a unique identifier (e.g. ACCT_4010_TMPL).
- CAMPUS_IDENTIFIER: This needs to be set to one of the external identifiers provided on the domain administration page. Please note that if we have relabeld your domain titles to match your organizational structure (e.g. "Location" instead of "Campus"), the feed still needs to use the original system (Campus) column title and data.
- DEPARTMENT_IDENTIFIER: This needs to be set to one of the external identifiers provided on the domain administration page. Please note that if we have relabeld your domain titles to match your organizational structure (e.g. "Program" instead of "Department"), the feed still needs to use the original system (Department) column title and data.
- START_DATE and END_DATE: These are required for every course, even if they are not appropriate for something like a template. If that is the case, simply fill in a reasonable date range (e.g. the start of the academic year to the end). When templates are cloned, these dates are replaced with the then appropriate dates.
- CLONE_FROM_IDENTIFIER: Probably the trickiest of all the parameters, this will determine whether or not the course to be created should be from scratch or from another course using a course identifier already in the system. It is used most often when replicating a template for a given course section. This is why it is so important to create course identifiers for templates that can be scripted from the SIS (e.g. ACCT_4010_TMPL).
- IS_STRUCTURED: This will determine if the created course will be based on the Concourse structure (=1), that is using distinct fields for description, objectives, course policies, etc., or as simply a place to store uploaded syllabi (=0).
- IS_TEMPLATE: This is a flag to determine if the created course is to be a template (=1). If used in combination with the CLONE_FROM_IDENTIFIER and the course to be cloned is also a template, a linked template is then created, a very powerful but advanced concept.
- Section Feed
- Overview: This feed is used to "insert" instances of sections within the courses created from the course feed. The reason this feed is separate from the course feed is to allow for multiple sections to participate in a single "master" syllabus. However, most institutions simplify their processes by creating one section per syllabus. Further, if you do not run this feed following the course feed, no sections will be available for users to be registered with.
- SECTION_IDENTIFIER: As noted above, many institutions will create one section per syllabus, which means this identifier and the COURSE_IDENTIFIER will look very similar. In this case, the course identifier may be 2018_SP_ECON_1100_2A (i.e. a course identifier really being used as a unique section identifier) whereas the section identifier is then 2018_SP_ECON_1100_2A_SEC (i.e. a dummy section identifier).
- Registration Feed
- GROUP_NAME: This will determine into which group the user is placed when they are registered for a course. The seven available groups include: Managers, Developers, Assistants, Instructors, Students, Guests, and Public.
Data Removal Feeds
- Disable User Feed
- DISABLE: This determines whether a users' account is disabled (=1) or enabled (=0). A user must be disabled to later be completely removed from the system.
- Mark Course For Deletion Feed
- MARK_FOR_DELETION: This determines whether a course is marked for deletion (=1) or not (=0). A course must be marked for deletion to later be completely removed from the system.
- Drop Registrant Feed
- DROP: This determines whether a user should be dropped from a all course sections (=1) or not (=0). If a user is inadvertently dropped, they must be re-added using the registration feed.
- Copy Items
Copy Feeds can take item content from one syllabus ( a template or nontemplate) and update the item content on another syllabus. Each row represents a distinct copy, which means that you can pair many different source syllabi with many different destination syllabi. When an item is copied from one syllabus to another, the item and its children will be carried over.
Multiple items can be updated using one feed. For example, you may have two rows in your feed. One to update the institutional policies, and another row to update course descriptions. While similar in nature, Item Feeds are designed to work with external content, while Copy Feeds are designed to work with internal content.
- ITEM_CONTENT_TYPE: The content type (Item Class Name) on a syllabus you are attempting to copy (i.e. ContactInformation, Description, MeetingTime).
- COPY_FROM_IDENTIFIER: The external ID that tells the Feed where to get the item content you are copying.
- COPY_TO_IDENTIFIER: The external ID that tells the Feed where the item content you are copying is going.
Considerations when using the Copy Items Feed:
- Linked items still need to be updated through the template tree
- Content copied from another syllabus as a new item will adhere to initial permissions, while content copied over existing items will adhere to permissions set on the destination.
- Campus Feed
- CAMPUS_IDENTIFIER: This is the unique identifier for the campus where courses may be offered.
- School Feed
- SCHOOL_IDENTIFIER: This is the unique identifier for the school in which courses may be offered.
- Department Feed
- DEPARTMENT_IDENTIFIER: This is the unique identifier for the department and is a subset of the school in which courses may be offered.
Syllabus Content Feeds
- Item Feed
- Overview: It is important to understand the downstream effects of inserting syllabus content via a feed, especially when being placed on templates. If the item already exists, its data will be replaced entirely (all fields). If the item category does not exist, it will be inserted and inherit the group permissions assigned to the syllabus as a whole. Updated content in an item feed will replace existing content as a whole. In other words blank columns will end up removing content, not leave the fields alone. Further, item feeds will interact with linked templates the same as one manually editing syllabi would. In other words the addition/editing of content via a feed will cascade down to children syllabi, potentially removing content that was already present.
- NOTES: This is the HTML that will be directly inserted in to the syllabus. For that reason tags should be used in order to style the data as you'd like it to appear. In most cases this is simply the use of surrounding <p> tags.
- IS_LOCKED: This determines whether the syllabus content is locked (=1) or editable (=0) from within the system by those granted such editing permission. It is typical that synchronized data be locked and migrated (one-time) data be editable.
- DESCRIPTION, REQUISITES, OBJECTIVES, and OUTCOMES: Only a part of certain feed category types, these fields operate much like the NOTES field but data is inserted into more specifically labeled parts of the syllabus.
Delete Locked Items Feeds
- Item Feed
- Overview: It is important to understand the downstream effects of removing syllabus content via a feed, especially when being drawn from templates. The deletion of an item will remove it and any children from a syllabus. If the item is linked to other syllabi through templates, these will also be removing. Only locked items can be deleted with a feed.
- DELETE: This determines whether item content should be deleted from a syllabus (=1) or not (=0). If content is removed, it is not recoverable.
The feed processing area is located at Admin > Tools > Feeds. This is a feature that is only available to system administrators. Once you've created a feed, all you need to do is select the Type of feed you are going to run, Browse for the file on your computer, and click Process. The results of the processing and/or errors will then be shown below. Here's an example from running a course feed:
Created: 2018_F1_ACCT_2025_1A (line 1)
Created: 2018_FA_BIOL_4100_3C (line 2)
Created: Cloned 2018_FA_BIOL_4100_3D from 2018_FA_BIOL_4100_3C (line 3)
Updated: INST_TMPL (line 4)
ERROR: Bad row at line 5: Bad department identifier
A full list of processing errors, possible causes, and suggested resolutions is found in the PDF at the end of this article.
*Note: Feed processing is highly dependent on the size of the feed to be processed. Files with less than a hundred lines should process in short order, in less than a minute. However files exceeding a thousand records can take considerably longer.
Updates and Exceptions
In most cases data can be updated by simply re-running the feed with the new data. However there are a few instances where this is not possible.
- Identifiers: As the unique identifier for a feed, these cannot be updated by changing them. If a new identifier is used, a new entry in the database may be made. This includes the USER_IDENTIFIER, COURSE_IDENTIFIER, SECTION_IDENTIFIER, CAMPUS_IDENTIFIER, SCHOOL_IDENTIFIER, and DEPARTMENT_IDENTIFIER parameters.
- Rows: Feed rows are processed as a whole. Therefore the processing of a row will update all the columns for that row and not individual fields.
System Data Feeds
- Course Feed
- CLONE_FROM_IDENTIFIER: This field cannot be updated. Cloning happens upon initial creation only (i.e. the first time the row is processed).
- IS_STRUCTURED: Though this field can be updated, it may cause unexpected behavior. Switching a course from structured to unstructured or reverse will end up making syllabus data that was previously uploaded/entered inaccessible.
- IS_TEMPLATE: Once a template is cloned it is either linked to the new template or not. Updates to this field will not turn a regular course into a linked template or break the links of a previously linked template.
Data Removal Feeds
- Drop Registrant Feed
- DROP: If a user is dropped, entry of a 0 will not place the user back in the course sections. They must be re-added using the registration feed.
Delete Locked Items Feeds
- Item Feed
- DELETE: If syllabus content is deleted, entry of a 0 will not place the content back on the syllabus. It must be re-added using a syllabus item feed.
Once you've got the process of constructing and manually uploading feed files, you can go the extra mile to automate the processing of feeds on a regular basis. Learn about automated processing here.
*Note: The Syllabus Geeks understand that some institutions may be using a syllabus system from which they would like to migrate data to Concourse. For considerations regarding data migration, click here.
------------------- Feed Documentation -------------------