Overview of Concourse Feeds

Overview of Concourse Feeds

This is a General Information article designed to give you a general overview of the Concourse feed process. If you are looking for technical specifications for feeds, consider exploring Construct and Process System Data Feeds or Automated Feed Processing to get started with technical aspects of feeds.

Feeds Overview

Feeds are an invaluable Administrative tool that allows Concourse admins to "feed" or migrate data from external systems into the Concourse platform. Choosing to migrate information from external systems allows institutions to ensure data is consistent throughout Concourse and the rest of an institution's academic environments. This can be true for data ranging from user information, course registrations and roles, syllabus content, and more. By utilizing feeds, institutions can cut down on countless hours of manual creation, troubleshooting, and reporting on syllabus quality. Additionally, feeds can be run at any frequency so it works well for most institutions, regardless of academic calendars, processes, etc.

Still, even though feeds are an amazing resource, there are instances when you might not need to utilize feeds:
  1. When running a pilot
  2. When your number of users and/or courses is less than 100
  3. When auto-create (for users and/or courses) is an option
Your implementation team will work with you every step of the way as you decide whether or not you need to utilize feeds and which feeds will benefit your institution's unique needs the most. 

Feed Construction

The actual feed specification is fully documented in other technical articles within the support center, but we’ll emphasize a few aspects here. First, the most important part to get right with feeds is the external ID. It is how each row in the database is uniquely identified and may be used to tie together the actions of one feed with another. This will always be the first column in each feed and as the key will not be modifiable by subsequent processing. Most every other field (with a few exceptions) can simply be updated by running the feed again.

Next is sequence. The four common feeds generated for Concourse are: User, Course, Section, and Registration. (There are other types but many of the same principles will apply.) The easiest feed to construct is that for Users and where most clients begin. It can be run independently as it does not require any data yet be in the system.

The course feed is also (largely) independent but much more comprehensive. It will include fields like title, subject code, start and end dates, and term. Additionally, critical to implementations using templates and where we often get questions is the use of a CLONE_FROM_IDENTIFIER. If used this tells Concourse from which course (as identified by the course ID) to copy content and settings. This is why a course feed may not always be "independent" as it is possible that it will rely on the existence of another course, whether created manually or from a previous feed run.

The next field in the course feed we typically receive questions about is the use of the IS_TEMPLATE flag. On its own this simply designates a course as a template. However, if a course is cloned as a template from one that is also a template, it will cause them to be "joined." This is how our linked template functionality is enabled.

You’ll also need to be sure that your domain listing includes identifiers that match the CAMPUS_IDENTIFIER and DEPARTMENT_IDENTIFIER fields.

Once your courses are loaded you must run a Section feed to "insert" one or more sections into the syllabus for that course. In most cases you will end up with one corresponding row in your section feed for each row in the course feed, meaning that you’ll end up with one syllabus per course section. More advanced implementations may put multiple sections into a single course, such as when a static "master" syllabus is to used across every instance of a course offered in a given semester.

Another FAQ is how to handle sections for templates. Again in most cases you will insert a single section into each template course with a section Label of "All".

The final major feed is that of Registrations, which ties together users with sections. You will also indicate their role (e.g. Students, Instructors, etc.) when creating this feed.

 

Feed Sequencing

Once all your feeds are built up one needs to think about the sequence how feeds should be processed. We just noted that a natural pattern is that of (1) User, (2) Course, (3) Section, and (4) Registration. However, based on your template structure it may require some inner iterations of this sequence, such as the subsequent processing of pairs of course and section feeds to first setup an initial course-level template structure and then again for creating the actual instructional syllabi for the term.

Another concept enabled by feeds is template archival. Generally you will have a collection of syllabus templates that are continually updated for future terms. You'll also inherently have all the instructional syllabi delivered to students that were cloned from these templates. However say in addition to these in classroom syllabi you want to take a "snapshot" of all the templates as they stood at the beginning of the term. This could be accomplished through the use of another pair of course and section feeds after changes to templates have been finalized for the term but before instructor editing commences.

 

Feed Timing

Closely related to sequencing is timing. You may find that some of these feeds need to be run continually, others on a one-time basis. Further still something like the snapshot archival described above could be once a term or even once a year based on when template changes are made and finalized.

Timing is not only about absolute frequency but when within the academic cycle these runs need to take place. Some of the gates to think about include when:

  • templates will be updated
  • syllabi will be audited
  • instructors will first edit syllabi
  • students should be able to access syllabi
  • how these timings interact with other campus systems

 which in turn may translate into when: 

  • templates can be cloned
  • archival can take place
  • permissions need to be updated
  • instructors can begin editing
  • students can begin viewing

and so forth. As you can see it’s probable that process and policy decisions need to be made by Academic Affairs to inform this part of the implementation.

 

Feed Processing Details

There are two methods for getting feeds into Concourse: manual and automated. As the terms imply manual will mean that you have to log in to Concourse to upload a correctly constructed feed file which is stored on your machine. By contrast, automated feeds are constructed and posted to Concourse using a script against your student information system. This section gives general overview of manual feed processing. To learn more about automated feeds, consider exploring the Automated Feed Processing article in our support center.

Even if you expect to reach a fully automated environment, you will want to stick to a path of increasing sophistication as you build out your feeds. In other words, you might not want to start with automating everything. On one hand determining if your integration is performing as expected is far easier when you can isolate issues to basic feed construction (1), data cleanliness and scale (2), or automation scripting (3). At the same time, depending on your situation, you may come to find that it is easier to continue with manual uploads rather than invest in the technical resources to automatically run feeds.

Therefore, we strongly urge you to take the following, sequential approach to building out your feed processing:

  1. The manual creation and upload of sample feed files
  2. The manual creation and upload of full feed files
  3. The automatic creation and upload of sample feed files
  4. The automatic creation and upload of full feed files

When we talk about samples, we mean around the first ten rows of your file, way less than the thousands you will almost certainly have in the full feeds. These first ten will immediately expose whether the file is constructed appropriately quickly and easily. In fact many times that can be created and tested by just filling dummy data in and without the need to generate a report from your SIS.

As always, the sandbox should be your best friend throughout this entire process.


    • Related Articles

    • Construct and Process Copy Feeds

      This article is designed for IT professionals or those who have a background in running feeds and just want the technical specifications for running copy feeds. If you would like more generalized information on the uses and benefits of Feeds, or you ...
    • Construct and Process Item Feeds

      This article is designed for IT professionals or those who have a background in running feeds and just want the technical specifications for running system data feeds. If you would like more generalized information on the uses and benefits of Feeds, ...
    • Integrating Concourse

      Integration is fairly technical in nature so you will want to be sure that your IT department works with you on this task. They should already be familiar with the technologies and processes discussed in this article. Integrating Concourse with your ...
    • Construct and Process System Data Feeds

      This article is designed for IT professionals or those who have a background in running feeds and just want the technical specifications for running system data feeds. If you would like more generalized information on the uses and benefits of Feeds, ...
    • Using Feeds to Populate Syllabus Item Content

      Item-based feeds with syllabus content can be created and run to populate syllabus content in Concourse. Clients typically do this on an infrequent (e.g. once a year) basis to migrate from an existing syllabus or related solution, to populate a large ...