TOPIC:

Hello everyone,
I’m working with Xerte 3.15 and exporting learning objects (LO) to my LMS as SCORM 1.2 using the following tracking configuration:
- Tracking option: Full tracking of last pass
- Passing score: 50%
- Required time for page completion: 0
- Forced tracking mode: Do not restart session
- “Hide session button”: enabled
- The LO ends with an “End of Unit” page that includes a finish button.

I’m having difficulties getting reliable progress tracking in an external LMS. The LMS provider requires the SCORM package to store two specific variables inside cmi.suspend_data in order to calculate progress:

VarPaginas_totales=XX; VarPaginas_visitadas=XX;
(Translated: TotalPages and PagesVisited.)

Since I could not find any configuration option in Xerte that would allow adding custom values to suspend_data, I tried to solve this by editing xttracking_scorm1.2.js. To meet the LMS requirement, I modified the functions finishTracking(), initTracking() and XTExitPage(). I can provide specific details if needed, but my intention was simply to append the LMS‑required values to suspend_data without disrupting Xerte’s internal logic.

During the first launch after this changes, everything seems to work correctly: the LO loads, tracking updates and the LMS displays the expected progress percentage. However, when re‑entering the SCORM, the LMS shows:

“Unable to find an API adapter”

and the content does not load. The screen remains blank, so Xerte’s JavaScript never starts.

This behaviour only occurs after modifying the tracking script. Without the changes, the package launches normally but does not meet the LMS’s suspend_data requirement.

Before exploring more invasive changes, I would like to ask:
- Am I using a correct (the best?) tracking configuration?
- Is there any way in Xerte to add custom values to cmi.suspend_data without editing xttracking_scorm1.2.js?
- Has anyone successfully implemented LMS‑specific suspend_data formats through configuration rather than code changes?
- Could modifying only these three tracking functions affect re‑entry behaviour in certain LMS environments?
- Has anyone experienced similar issues when adjusting SCORM tracking logic?

I searched the forum but could not find similar cases. Any advice or suggestions would be greatly appreciated. My goal is to meet the LMS requirement in the safest possible way and determine whether Xerte provides a better method than manually modifying the tracking script.

Thank you very much in advance,

Roberto

There is now way to change the suspend data without modifying the code.
On revisiting the LO, Xerte expects a jason structure to be in the uspend_data and just tries to decode the data, which now will fail. So you need to change that piece of code as well.

Thanks for the explanation, Tom. That helps a lot.
I understand now that Xerte expects cmi.suspend_data to contain valid JSON when the LO is revisited, and that simply appending extra text will cause the JSON decoding to fail unless the restore logic is also adapted. That makes sense.
In my case, though, the behaviour I’m seeing seems to happen even earlier. On re‑entering the LO, the LMS shows “Unable to find an API adapter” before the Xerte content actually loads. The iframe stays empty, window.API is undefined and Xerte’s JavaScript never runs, so it doesn’t even get to the point of reading or parsing suspend_data.
That said, your comment is very useful, because it confirms that my current approach (adding non‑JSON data to suspend_data) is not safe, even if the LMS issue were fixed.
So my main questions now are:
Is there any recommended way in Xerte to extend suspend_data while keeping it valid JSON?
Has anyone successfully adapted both the save and restore parts of xttracking_scorm1.2.js for LMS‑specific tracking requirements?
Or is this kind of custom tracking considered outside the intended use of Xerte?

Thanks again for the insight — it definitely clarified part of the issue.

Roberto

Hi,

No, there is no prior example. I did not look into the actual code yet, so I don't know why you would see the erro that the API cannot be found. Also, please keep in mind that in SCORM 1.2 the suspend_data is about 4096 (4k) bytes, so that is not a lot.

Are there any errors in the console of the browser?

Hi!
I just wanted to thank you for your help and for the guidance shared here.
After digging further and looking for console errors, I finally discovered what was causing the issue: the LMS was misinterpreting the content written to cmi.comments (mainly because of unescaped characters and line breaks). This resulted in invalid JavaScript being generated on the LMS side during resume.
In the end, I solved it by disabling the writing of cmi.comments within the tracking logic, while keeping the rest of the SCORM behaviour intact. With that change, everything is now running smoothly.
Next stop: tracking issues!
Thanks again for your support and the valuable discussions in this forum!
Roberto