AnsweredAssumed Answered

Attempt data for all courses using REST API

Question asked by chrisboon on Apr 2, 2019
Latest reply on Aug 16, 2019 by chrisboon

My developer colleagues are updating an integration they made for our ILP (Individual Learning Plan) previously using the old SOAP Webservices - they are now recreating this using the REST API. The integration is designed to show grades from the Grade Centre on a student's ILP so that a tutor can see a student's academic progress from the ILP without going to the relevant Blackboard course.

 

The integration uses API calls to request a list of all courses, then iterates through these to request all columns for each, and then all attempts. The call for a list of courses uses this:

https://myblackboardurl/learn/api/public/v1/courses/

and then for the next 100 etc

https://myblackboardurl/learn/api/public/v1/courses/?offset=100

 

Then for each course the columns are requested:

https://myblackboardurl/learn/api/public/v1/courses/_12345_1/gradebook/columns

 

Then for each column, the attempts are requested:

https://myblackboardurl/learn/api/public/v1/courses/_12345_1/gradebook/columns/_987654_1/attempts

 

We're finding that a number of the calls to request attempt details of the format above wait for a long time and then fail without returning any data. Is there anything we can do to resolve or troubleshoot these?

 

The development manager has sent me a some requests based on the issues above:

 

Ideally:

  • These calls should return the attempt data.
  • You can return all the columns and attempts in a timely period when viewing the site (for this course).  Just the data should be quicker for any course.  Sometimes a successful call can take over a minute and even longer to tell it’s failed for a course with 200 columns at a minute each then it could be over three hours to get the results. Fortunately empty sets tend to be quicker.

 

Even Better:

  • The list of courses includes a created date but a last updated date would let us ignore things that hadn’t changed recently
  • When listing the columns a similar date last updated (attempted/marked) would let us discriminate and only make required calls
  • Adding an attribute to return only changes since a specified date would mean we didn’t have to run though a huge amount of data every time.

 

Is there anything that can be done to improve this process?  Or are we missing any quicker or easier route to import all attempt details into our ILP?

 

Many thanks,

Chris

 

(Please excuse any poorly worded parts of this, or any nonsense, as I'm not a developer and am passing on the information for the development manager!)

Outcomes