Integrating Concourse

Integrating Concourse with your institution’s existing systems means that your students, faculty, and staff will be able to seamlessly work with Concourse while significantly reducing manual processes, duplication, and errors. It’s truly the way to realize the full potential of the solution.

This high value is achieved by pursuing at least one of three integration approaches: (1) central authentication, (2) learning management system (LMS) pairing, and (3) feed processing. The first involves being able to access Concourse with common credentials or via a portal. LMS integration covers embedding syllabi at the course level within your learning management system using the learning tools interoperability (LTI) standard. Last but not least is feeds, or the bulk upload and processing of users, courses, registrations, and even syllabus content that is helpful for synchronization with your student information system (SIS) or migration from another system.

If you now feel like you’re working with alphabet soup, don’t worry. 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.

But before we get ahead of ourselves the critical question to ask (which should be informed by the preceding template design and administration exercises) is what degree of integration is necessary, both immediately and over the long term.

For example if in the beginning you will be using a singular, institutional template, you may be able to rely upon auto creation for users and courses and therefore not need to process any feeds whatsoever. Alternatively if you consider the only gateway to Concourse to be the LMS, it can serve as your central authentication and you won’t need to utilize any other methods.

In short this article will cover a fairly extensive integrated situation even though only parts of this may pertain to your implementation.

Finally we cannot emphasize enough how important it is to test all of the integration steps outlined in this and other articles in your sandbox first before bringing the process to your production system. In fact this is good practice for all of the implementation phases, not just those related to integration.

 

Landscape

The first step to integration is to understand the two dimensions that drive complexity: access and capability.

To get started we’ll talk about access, or through what venues you expect to reach Concourse. In general you want to make at least two pathways available: authenticated and public. Here is a non-exhaustive list of how one might reach Concourse.

  • Direct (internal): Users arrive at the native login page and use a Concourse-specific set of credentials (email + Concourse password).
  • Direct (external): Users arrive at the native login page and use centrally administered credentials (e.g. college ID + common password).
  • Hosted: Users arrive at a Concourse-specific login page maintained on-campus to then be passed over to Concourse as already authenticated.
  • Portal: Users first log in to another system and then choose the Concourse application.
  • LMS: Users log in to the LMS and to access the Concourse application.
  • Public: Users visit Concourse directly (without logging in) and can search for and access publically available syllabi.

Once you have a sense of how you want to get people to Concourse you then need to think about the “capability” or depth of the integration at said intersection. For example do you want your public interface to bring users directly to a given syllabus sample from its catalog entry or is it sufficient to have users search for syllabi?

 

Authentication

Now that you’ve gotten a sense of what your integration landscape might look like we can begin to drill down on the three areas that can be used to support them, starting with authentication.

We find that many clients today use a combination of an SSO implementation, largely for faculty and staff through a portal and LTI via the LMS (described later).

Syllabus_Geek_Note_Smallest.png*Note: Internal authentication cannot be used simultaneously with any of the external (i.e. Directory, SSO, LTI) authentication choices. In other words a given user account can either be authenticated internally or externally, not both. It is possible however to coordinate the switch from internal to external during the implementation or even production use.

At this point you should understand how each group of users can reach the Concourse solution and what authentication method will help get them there. To continue with your implementation of these various gateways see the documentation specific to each method.

 

Learning Management System (LMS)

While the LMS is technically just another authentication vehicle given its importance to an exceptional instructor and student experience we call it out separately here.

LMS integration is generally achieved using a specialized standard called Learning Tools Interoperability (LTI). This protocol, specifically designed for ease of integration with learning systems, includes all the information one should need to bring in third party tools like Concourse into the learning environment. Newer versions of the standard even include support for functions such as grade feedback, though those are not discussed here as they are not pertinent to a syllabus tool.

But before we get too far into LTI it's important to start with the two key pieces to making LMS integration work: the user and the course (or context in LTI-speak). Concourse relies upon understanding who the person is and which syllabus to present when the LTI link is clicked within a course. Role (e.g. student, instructor, etc.) is often provided and considered by Concourse if available but not required if you are also shipping registration feeds to Concourse.

 Syllabus_Geek_Note_Smallest.png*Note: It is also possible to use the LMS as a "Portal" by enabling LTI to consider only the user and not the course. This would be useful if you wanted to provide general Concourse access, say for instructors and students interested in reviewing other syllabi or for Deans and Chairs to audit and report on courses.

Another factor to consider that should come out of your template design exercises is just what type of access you want to provide to a syllabus presented in an LMS course. Is it a static syllabus generated from a template for all sections of the same course? Is it a sectional syllabus that instructors build from? Do they author or upload one entirely from scratch? This will largely determine what you need to do in terms of unique course identification.

So, assuming your LMS is LTI-enabled, the next step is to figure out exactly what data it can provide through an LTI launch. This is done through first adding an LTI consumer to Concourse, next setting up a paired LTI tool within a representative course in your specific LMS, and then setting a custom parameter so that Concourse displays debug data. What you’ll be looking for is a value that resembles the user and another that resembles the course. These are likely IDs that you are used to seeing, either because you log in with them, they precede your email, or are the same as what you are loading into the LMS. 

Once you have discovered how your LMS formats and sends user and course IDs add examples of these and their matching parameters names to your Operating Manual. Additionally, it is just as helpful to jot down any other known formats for user or course IDs, such as what your portal might be using. One hopes they are similar but if not middleware tools like Apidapter exist to help equate them.

 

Feeds

The final step to completing the integration circle is the creation and submission of feed files, or the bulk upload and processing of users, courses, registrations, and even syllabus content. We leave this to last because of how dependent the construction, sequencing, and timing of feeds is on all the other decisions made during the implementation including template hierarchy, domain listing, and integration methods.

The other reason for leaving this step to to last is to understand the impact of the rest of the decisions made throughout the implementation and how they drive the need for simple, comprehensive, or even no feeds at all. At this point it is likely that you’ve already started to explore Concourse to enter syllabus data and setup at least a part of your domain listing, which means you are already creating users and courses manually. In fact this might be sufficient for some organizations. Small implementations (e.g. <100 courses per term) may not require the use of feeds at all as the effort in creating and maintaining them may exceed that of manual management. The same may be true with simple implementations (e.g. Concourse Lite or the use of only an institutional template) which can rely on the use of the auto-creation option associated with LMS integration.

Syllabus_Geek_Note_Smallest.png*Note: If you plan to migrate data from an existing syllabus system, the article entitled Points to Consider Regarding Migrating Data to Concourse should be reviewed to ensure all of the points listed have been taken into consideration.

 

Construction

The actual feed specification is fully documented here 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.

Again, the complete feed specification with downloadable sample feed files can be found here.

 

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.

 

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, and
  • 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.

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

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Powered by Zendesk