Every LMS, SIS, etc. is not created equal. They all have different features, different ways of doing things, and different ways of accessing their data. While Edlink tries to make it as easy as possible to integrate with any of these systems, there are some differences that you should be aware of. We have also made some design decisions along the way to accommodate these differences which you may need to take into account.
Data Model
One of the major areas where differences can be found is in the data model. There are many properties that Edlink will store as an array that may be stored as a single string in other systems.
Some examples are roles, schools, and race.
There are strategies for consolidating the values of these arrays into a single string if your system requires it. However, if you have yet to implement your integration (or have a flexible enough data model) we recommend allowing for and expecting arrays.
You can read more about accounting for differences in the data model here.
It also important to note that while the majority of Edlink's data model is consistent across all providers, there are some differences.
For example, an SIS may not store an entire assignment but instead the metadata it needs to store grades for it. Because of this when creating an assignment in said SIS, you may find that certain properties are not supported and will be ignored. Edlink will use defaults for these properties where appropriate when returning the assignment to you.
It is best to know what providers you will be integrating with and be as familiar as possible with their features. This way you can be prepared for any differences you or your customers may encounter.
Submissions {differences-with-submissions}
Another area where differences can be found is in the way that submissions are handled. Edlink maintains a lifecyle for submissions and guarantees that there will always be a submission for every student enrolled in a class. This means that you may have items in your system that are not yet in the LMS. These are called Phantom Submissions. Edlink will create a submission in the LMS when the student submits an attempt.
Here is a list of providers that use phantom submissions:
- Canvas
- OneRoster
Additionally, there are some providers that do not support submissions at all:
- Aeries
- Clever
Furthermore, some providers require that a submission be returned to a student for them to receive the grade.
In this case, there is an additional /return endpoint that you can use to return a submission to the student.
If the provider does not support this feature, you will receive a response like this:
{
"$errors": [
{
"code": "UNSUPPORTED_OPERATION",
"message": "This provider does not support this operation."
}
]
}
Providers that don't support returning submissions usually do not support the concept of a submission state either.
In this case, Edlink will infer the state of the submission and will return an UNSUPPORTED_OPERATION error when attempting to reclaim/return a submission.
If you are using the /return or /reclaim endpoint and work with providers who do not support this functionality, you should be prepared to handle this response.
It is recommended to check for this error and simply ignore it, continuing as if the submission was returned.
The following providers support the /return endpoint:
- Microsoft
- Blackboard