We are looking for input from an institution that uses "Banner" as it's SIS. When making users "active" or "deleted" in a course, how are you monitoring for this in Banner, so that the SIS Import "Enrollments" file puts the correct status for the user if they have dropped or been removed from a course section? *If I didn't word that correctly, please forgive me.
I am told that one way to handle this, and I guess not have to monitor a "dropped course" field in Banner, if there is one, is to "use Canvas imports with a Full Batch flag for enrollments." Anyone not in the enrollment list would be removed from the course. Is this the preferred method, or what process can be used to pull from Banner that a person has dropped, or switched sections of a course?
We use Banner here (UNCG), and I'll be happy to chat/demo about our process if you'd like.
Our process is to have Banner feed a full zip file of all courses, sections, users, and enrollments to our home-grown app (PHP/MySQL/Zend Framework) that then processes/manipulates it before uploading to canvas via API.
We perform the diff'ing process, so that the Zip file that is eventually uploaded to canvas only contains the changes since the last successful SIS import. This works well for us, so that we can perform validation/verification steps and allow my LMS Admin team more visibility and control of the process, as opposed to all the logic happening directly in Banner.
We are looking at potentially using the "diff_data_set_identifier" option in the SIS uploads, but we're currently unsure if it will fit our needs.
Hi Bill - We are using ICGORLDI in BANNER and loading the XML directly into Canvas. If you are using ICGORLDI, I can share what we did to make sure that students are removed from courses. We had to change an internal business process in how data was being stored in SFAREGS. Once we made the adjustment, ICGORLDI did the rest for us.
We just do a manual batch update in canvas a couple of times a semester. The thing that is kind of annoying going this route is that you have to apply the import against terms individually (Ex: S1, T1, YR). Here are some generalized instructions for what has worked for us:
Notes of caution: I always run this against our test instance before trying it on our production site and have some of our teachers look at the test site before proceeding.
We have a job submission process that runs in extract from Banner in the format of a csv user and csv enrollment file with an updated status. The enrollments csv file will list a deleted status for students that drop a course.
Follow up note.... if you choose to go the "Full Batch" update route, then that effectively means that Banner contains all the requisite information about roles for the LMS (teacher, student, ta, designer, observer etc).
Our Banner instance only knows/cares about teachers and students, meaning that any additional roles are added directly in the LMS via the UI. Teaching Assistants, Grad Assistants, Observers, Designers, ITCs, etc all fall into this case (added via UI, not via SIS).
If you do a full batch update, then it will blow away any custom enrollments. As explained to us by Canvas support, the full batch update is the "nuclear" option.
CAUTION! This is sometimes referred to as the nuclear option because it can
delete large data sets without any prompt or warning for confirmation. This option
will affect only data created via previous SIS imports.
So..... if Banner knows "EVERYTHING" about your enrollments, then batch updates are the easiest method to use. If you need to add custom role'd people to the LMS, then full batch updates will blow away those customizations.
Sidenote: we run our process every 2 hours, and process about 90,000 enrollments, 6500 courses, 6500 sections, and 40,000 users (all part of the original SIS Zip that comes out of Banner). Our diff process results in only a few hundred (at most) changes every 2 hours though, which makes the process extremely quick once we upload to canvas.
We wrote our own sync process in Java using the Canvas REST API. It allowed us to query Banner directly for who is enrolled in a course, adding those missing as well as removing those not listed in Banner. One additional is we only un-enroll in canvas by specific roles. Allowed us to leave custom roles enrolled in canvas when not enrolled in Banner.
Automated, runs twice per day syncing users, courses, sections and enrollments. Also does this for a non-banner system on campus.
Your solution with your homegrown app interests me. Currently we are uploading csv flat files queried from Banner. Then, using an automated process and a schedule, we upload our files to Canvas from a server. Currently we're not using the diffing process but I would love to see it in action. In addition our Luminis Message Broker doesn't provide us with the format we need in Canvas. If we can customize the output, and then upload it, this would reduce our manual maintenance issues a great deal.
Let me know if you'd be willing to share what you have and how you did it.