L’Environnement d’exécution en un mot
Un LMS conforme à SCORM est requis pour implémenter une API composée de 8 Fonctions (voir la Section 3.3 du document sur l’Environnement d’exécution SCORM pour la spécification complète) auxquelles le contenu peut accéder pour communiquer avec le LMS.
- LMSInitialize()
- LMSFinish()
- LMSGetValue()
- LMSSetValue()
- LMSCommit()
- LMSGetLastError()
- LMSGetErrorString()
- LMSGetDiagnostic()
Cette API est implémentée par ce que le SCORM appelle un adaptateur d’API. Un adaptateur API doit résider dans une fenêtre qui est une fenêtre d’ouverture ou un cadre parent de la fenêtre qui contient le contenu. Cela signifie que le LMS peut lancer le contenu dans une nouvelle fenêtre ou dans un jeu de cadres. L’adaptateur API doit être un objet ECMAScript (JavaScript) nommé « API » accessible via le DOM. L’adaptateur doit implémenter les 8 fonctions énumérées ci-dessus.
Toute la communication entre le contenu et le LMS est gérée par cet adaptateur, ainsi l’auteur du contenu n’a pas à se soucier de communiquer avec le serveur, il doit seulement pouvoir trouver l’adaptateur API et effectuer les appels JavaScript appropriés. Cette séparation du client et du serveur est essentielle à SCORM dans la mesure où elle assure la portabilité du contenu en le forçant à fonctionner sur une plate-forme standard (le navigateur web). Il est important de noter que le contenu ne peut communiquer avec le LMS que via cet adaptateur API JavaScript. Il n’existe pas de méthode conforme à SCORM permettant au contenu de communiquer avec le LMS via d’autres méthodes telles que les services Web ou les requêtes HTTP.
Pour une conformité SCORM minimale, la seule chose qu’un contenu doit faire est d’appeler LMSInitialize() lorsqu’il démarre, puis d’appeler LMSFinish() lorsqu’il se termine. Ça peut être aussi simple que ça.
Dans le monde réel, cependant, nous voulons une interaction beaucoup plus riche. Nous voulons être en mesure de signaler les résultats des tests, de suivre l’heure, de marquer notre dernier emplacement et plus encore. C’est là que les trois fonctions suivantes entrent en jeu. Le SCORM définit un modèle de données composé d’éléments de modèle de données à partir desquels le contenu peut lire et écrire, facilitant ce type de fonctionnalité (voir la section 3.4 du document d’environnement d’exécution SCORM pour une liste complète des éléments de modèle de données). LMSGetValue() récupère la valeur d’un élément de modèle de données à partir du LMS, LMSSetValue() écrit une valeur pour un élément de modèle de données dans le LMS et LMSCommit() peut être appelé après la définition de toutes les valeurs pour s’assurer que les données sont conservées.
Par exemple :
cmi.core.lesson_location est l’élément de données qui décrit l’emplacement de l’utilisateur dans le contenu
Lorsque le contenu commence (après avoir appelé LMSInitialize();), il peut vouloir faire cet appel pour savoir où l’utilisateur s’est arrêté et le ramener à ce point:
strLastLocation = objAPI.LMSGetValue("cmi.core.lesson_location");
Lorsque le contenu va dans une autre zone, il peut effectuer cet appel pour enregistrer l’emplacement de l’utilisateur:
blnSuccess = objAPI.LMSSetValue("cmi.core.lesson_location", "page3"); blnSuccess = objAPI.LMSCommit("");
Les trois autres fonctions permettent au contenu de piéger et de traiter intelligemment les erreurs.
L’implémentation de cet adaptateur API dans le LMS est un peu plus complexe que de l’utiliser à partir du contenu. L’adaptateur API doit implémenter toutes les fonctions de l’API et prendre en charge la plupart du modèle de données SCORM. Le problème délicat lié à la mise en œuvre d’un LMS conforme à SCORM est de savoir comment gérer la communication du navigateur au serveur. Beaucoup de gens choisissent de le faire avec une applet Java, mais d’autres ont réussi à utiliser Flash, des contrôles ActiveX et du JavaScript pur.