Die Laufzeitumgebung auf den Punkt gebracht
Ein SCORM-konformes LMS ist erforderlich, um eine API zu implementieren, die aus 8 Funktionen besteht (siehe Abschnitt 3.3 des SCORM-Laufzeitumgebungsdokuments für die vollständige Spezifikation), auf die Inhalte zugreifen können, um mit dem LMS zu kommunizieren.
- LMSInitialize()
- LMSFinish()
- LMSGetValue()
- LMSSetValue()
- LMSCommit()
- LMSGetLastError()
- LMSGetErrorString()
- LMSGetDiagnostic()
Diese API wird von dem implementiert, was die SCORM einen API-Adapter nennt. Ein API-Adapter muss sich in einem Fenster befinden, das ein Öffnerfenster oder ein übergeordneter Frame des Fensters ist, das den Inhalt enthält. Dies bedeutet, dass das LMS den Inhalt entweder in einem neuen Fenster oder in einem Frameset starten kann. Der API-Adapter muss ein ECMAScript-Objekt (JavaScript) mit dem Namen „API“ sein, auf das über das DOM zugegriffen werden kann. Der Adapter muss die 8 oben aufgeführten Funktionen implementieren.
Die gesamte Kommunikation zwischen dem Inhalt und dem LMS wird über diesen Adapter abgewickelt, sodass sich der Inhaltsautor nicht um die Kommunikation mit dem Server kümmern muss, sondern nur in der Lage sein muss, den API-Adapter zu finden und die entsprechenden JavaScript-Aufrufe auszuführen. Diese Trennung von Client und Server ist für SCORM insofern wesentlich, als sie die Portabilität von Inhalten gewährleistet, indem sie die Ausführung auf einer Standardplattform (dem Webbrowser) erzwingt. Es ist wichtig zu beachten, dass Inhalte nur über diesen JavaScript-API-Adapter mit dem LMS kommunizieren können. Es gibt keine SCORM-konforme Methode für die Kommunikation von Inhalten mit dem LMS über andere Methoden wie Webdienste oder HTTP-Anforderungen.
Für eine minimale SCORM-Konformität muss ein Inhalt nur LMSInitialize() aufrufen, wenn er gestartet wird, und dann LMSFinish() aufrufen, wenn er beendet wird. So einfach kann es sein.
In der realen Welt wollen wir jedoch eine viel reichere Interaktion. Wir möchten in der Lage sein, Testergebnisse zu melden, die Zeit zu verfolgen, unseren letzten Standort mit einem Lesezeichen zu versehen und vieles mehr. Hier kommen die nächsten drei Funktionen ins Spiel. Die SCORM definiert ein Datenmodell, das aus Datenmodellelementen besteht, aus denen der Inhalt lesen und in die er schreiben kann, was diese Art von Funktionalität erleichtert (siehe Abschnitt 3.4 des SCORM-Laufzeitumgebungsdokuments für eine vollständige Liste der Datenmodellelemente). LMSGetValue() ruft den Wert eines Datenmodellelements aus dem LMS ab, LMSSetValue() schreibt einen Wert für ein Datenmodellelement in das LMS und LMSCommit() kann aufgerufen werden, nachdem Werte festgelegt wurden, um sicherzustellen, dass die Daten beibehalten werden.
Zum Beispiel:
cmi.Kern.lesson_location ist das Datenelement, das den Speicherort des Benutzers im Inhalt
Wenn der Inhalt beginnt (nachdem er LMSInitialize(); aufgerufen hat), möchte er möglicherweise diesen Aufruf ausführen, um herauszufinden, wo der Benutzer aufgehört hat, und ihn an diesen Punkt zurückzubringen:
strLastLocation = objAPI.LMSGetValue("cmi.core.lesson_location");
Wenn der Inhalt in einen anderen Bereich verschoben wird, wird möglicherweise dieser Aufruf ausgeführt, um den Standort des Benutzers zu speichern:
blnSuccess = objAPI.LMSSetValue("cmi.core.lesson_location", "page3"); blnSuccess = objAPI.LMSCommit("");
Die anderen drei Funktionen ermöglichen es dem Inhalt, Fehler einzufangen und intelligent damit umzugehen.
Die Implementierung dieses API-Adapters im LMS ist etwas aufwändiger als die Verwendung von Inhalten. Der API-Adapter muss alle API-Funktionen implementieren und den größten Teil des SCORM-Datenmodells unterstützen. Das knifflige Problem bei der Implementierung eines SCORM-konformen LMS ist der Umgang mit der Browser-zu-Server-Kommunikation. Viele Leute entscheiden sich dafür, dies mit einem Java-Applet zu tun, aber andere waren erfolgreich mit Flash, ActiveX-Steuerelementen und reinem JavaScript.