Run-Time Environment i ett nötskal
en SCORM conformant LMS krävs för att implementera ett API som består av 8 funktioner (Se avsnitt 3.3 i SCORM Run-Time Environment document för fullständig specifikation) som innehåll kan komma åt för att kommunicera med LMS.
- LMSInitialize()
- LMSFinish()
- LMSGetValue()
- LMSSetValue()
- LMSCommit()
- LMSGetLastError()
- lmsgeterrorstring()
- Lmsgetdiagnostic()
detta API implementeras av vad SCORM kallar en API-Adapter. En API-Adapter måste finnas i ett fönster som är ett öppnare fönster eller en överordnad ram i fönstret som innehåller innehållet. Detta innebär att LMS kan starta innehållet antingen i ett nytt fönster eller i en ramuppsättning. API-adaptern måste vara ett ECMAScript (JavaScript) – objekt med namnet ”API” som är tillgängligt även om DOM. Adaptern måste implementera de 8 funktioner som anges ovan.
all kommunikation mellan innehållet och LMS hanteras av denna adapter, så innehållsförfattaren behöver inte oroa sig för att kommunicera med servern, han behöver bara kunna hitta API-adaptern och göra lämpliga JavaScript-samtal. Denna separation av klient och server är avgörande för SCORM genom att den säkerställer portabilitet av innehåll genom att tvinga det att köras på en standardplattform (webbläsaren). Det är viktigt att notera att innehållet bara kan kommunicera med LMS via denna JavaScript API-Adapter. Det finns ingen SCORM-överensstämmande metod för innehåll att kommunicera med LMS genom andra metoder som webbtjänster eller HTTP-förfrågningar.
för minimal SCORM-överensstämmelse är det enda som ett innehåll behöver göra att ringa LMSInitialize() när det startar och sedan ringa LMSFinish() när det avslutas. Det kan vara så enkelt.
i den verkliga världen vill vi dock ha en mycket rikare interaktion. Vi vill kunna rapportera testresultat, spåra tid, bokmärka vår senaste plats och mer. Det är här de tre följande funktionerna kommer in för att spela. SCORM definierar en datamodell som består av datamodellelement som innehållet kan läsa från och skriva till, vilket underlättar denna typ av funktionalitet (se Avsnitt 3.4 I SCORM Run-Time Environment document för en fullständig lista över datamodellelement). LMSGetValue () hämtar ett datamodellelements värde från LMS, lmssetvalue() skriver ett värde för ett datamodellelement till LMS och LMSCommit () kan anropas efter att några värden har ställts in för att säkerställa att data kvarstår.
till exempel:
cmi.kärna.lesson_location är det dataelement som beskriver användarens plats i innehållet
när innehållet börjar (efter att det har kallats LMSInitialize();), kanske det vill ringa detta samtal för att ta reda på var Användaren slutade och returnera honom till den punkten:
strLastLocation = objAPI.LMSGetValue("cmi.core.lesson_location");
när innehållet går till ett annat område kan det göra det här samtalet för att spara användarens plats:
blnSuccess = objAPI.LMSSetValue("cmi.core.lesson_location", "page3"); blnSuccess = objAPI.LMSCommit("");
de andra tre funktionerna gör att innehållet kan fånga och intelligent hantera fel.
att implementera denna API-Adapter i LMS är lite mer involverad än att använda den från innehåll. API-adaptern måste implementera alla API-funktioner och stödja det mesta av SCORM-datamodellen. Det knepiga problemet med att implementera en SCORM-överensstämmande LMS är hur man hanterar webbläsaren-till-server-kommunikationen. Många väljer att göra detta med en Java-applet, men andra har lyckats med Flash, ActiveX-kontroller och ren JavaScript.