CODEWITHSUNDEEP
javascriptscormscorm2004
Nikola.grancharov
Nikola.grancharov

Reputation: 672

SCORM: is this a proper behaviour for commiting data to the LMS

I have the flowing issue. I have a costume course that I am building, that is based on SCORM 2004 3th edition, and it is deployed on SABA LMS. What i am doing is:

  1. I use "API.SetValue" to set some data

  2. I use "API.Commit" to save the data to the LMS

    (i am using an wrapper library but it is using the core functions nevertheless )

now I am doing this several times for different data fields, lets call them "X", "Y" and "Z".

What i expect is on the first request to the server, is to see only "X" being send, and that is exactly what I see. Then on the second I expect to see only "Y", but here is what I do not understand, I see that the API is sending both "X" and "Y". And of course the 3th is sending "X", "Y" and "Z"

you can understand what my concern is. I get to a point that every time i want so save 0.1k of data, I have to make 40-50K of request.

Can anybody explain to me if this is a problem of SCORM, the specific LMS that I am using (SABA) or it is something that i am doing wrong?

Upvotes: 0

Views: 969

Answers (2)

Rycochet
Rycochet

Reputation: 2938

Firstly I want to say you're doing nothing wrong, it's entire the fault of the API there - this is the second API I've come across today (coincidences lol) doing bad practices:

There's good practices and ideas, and bad ones - unfortunately the bad ones are a lot quicker to code so people tend to not think about these things when putting together a client side API.

  • The easiest and worst (literally) way of doing things is to simply set all the data within a single object, and send that entire object whenever Commit is called.
  • An improvement on that is to cache the keys that have changed since the last commit - the benefit is that not everything gets sent, the drawback is that values that don't change are sent again.
  • The best thing to do is to cache the values that are sent when commit is called, and then compare them the next time - that way only values that have changed are sent.
  • Finally is merging the two methods above - cache the keys so you're only checking those values and not every one.

Other things to bear in mind:

  • Compressing the data is worthwhile - zip is easy to do in Javascript, and would reduce network bandwidth significantly.
  • Sending a hash or magic number to validate the data should also be a requirement - let the server know that this should be set.
  • Replying with a hash or magic number is important so the client knows that the cache needs to be updated (updating on send is sort of safe, but not as safe as waiting for a reply and knowing that the server matches the client).

The data in the API can be stored in several ways, but given a choice I'd go for a standard Javascript Object, with each key being the cmi key, and the value being an Object (or Array) with the various flags and cache values as well as the current value (for subsequent GetValue / Commit calls).

Finally remember that Commit itself is optional - the API itself should effectively be calling it after a period of time when SetValue is called.

So to repeat my first sentence - not your fault, entirely the fault of the API provided. Making changes to it should be easy for them - on the server side it would simple need to support merging rather than replacing the data sent.

Upvotes: 2

tom creighton
tom creighton

Reputation: 487

It is not a SCORM thing. SCORM just tells you the API - GetValue, SetValue, Commit, etc - and a general behavior for each call. But it does not dictate how the LMS actually does those things. It appears that the LMS is saving the data client-side. So when you set X, it saves it locally. When you call Commit, the LMS takes all of the data client side and sends it back to the server. Later when you set Y and Z it is doing the same thing - taking all of the data and sending back to the LMS.

Short of getting the LMS to change its behavior I don't think there's anything you can really do about it. The rule of thumb I go by is only commit when you really need to. You could just call SetValue for X, Y and Z, then Commit only when going on to another SCO or getting to a point where you decide this data must be saved to the LMS.

Upvotes: 2

Related Questions