Banner | SIS Import Question...
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.
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.
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.
Would you be willing to share your SFAREGS tweaks? I've embraced the ICGORLDI exports but have noticed they don't catch student course drops. In a perfect world, it would all be automated, but I can handle manual uploads leading up to the start of the semester.
Thanks for any info you're able to share!
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:
- Copy the student enrollment file and staff enrollment file into a new folder then zip the folder.
- Login to Canvas and click on SIS Import tab in left hand navigation panel
- Click the Choose File button and select the zip file you created in step 1
- Import type: Instructure formatted CSV or zipfile of CSV
- Select This is a full batch update
- Select the current term (Ex: 2016:S1) Note: You may have to run this more than once to fix enrollments for multiple terms such as 2016:T1, 2016:YR, 2016:S1)
- Students and staff that have dropped courses or moved are now removed from sections.
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.
Would you be willing to share what you have? We currently are using a similar process as Carol Zadnik in the post above. But it is annoying as we don't have it completely figured out just yet. We get a few upload errors and are working on finding the reasons for it. Until we do, I have to manually update the users and enrollments.
I don't think that would be a problem. Are you comfortable receiving the source code in a tar.gz or zip? Off list? Do you have folks with Java and JEE container(tomcat,jetty,etc.) experience? It's configured via java .properties file but you may want to tweak the logic a bit(sortable name munging, etc.) so you may need a Java programmer available. BTW it's also an endpoint for Grade push from canvas, configurable.
Sr Software Development Lead
Office of Information Technology (OIT)
University of Alabama in Huntsville
Sorry for the delay in this reply, but swamp-ed-ness happens! 🙂
I'd love to look at the code but am not sure how to get it from you. What do you need from here?
(We do have a java programmer. thanks for the heads up on that)
I have to code ready to share, like you, not sure how to deliver it to you. Maybe just email our helpdesk, email@example.com, which will open a crm ticket that will get assigned to me. Via the crm I can send you a file.
This will also let management easily track who/what/when/where.