Planning van SIS-integratie

Voordelen

Dit zijn de belangrijkste voordelen van het gebruiken van SIS-integraties (studenteninformatiesysteem) om gegevens door te geven aan Blackboard Learn voor het automatisch vullen en bijwerken van het systeem:

Het beheer van cursus- en gebruikersgegevens kan worden gedelegeerd aan een of meer beheerders die geen toegang via de opdrachtregel nodig hebben tot Blackboard-servers.
Gegevens kunnen snel en efficiënt worden uitgewisseld tussen Learning Management Systems (LMS).

Voordat je begint

Het is zeer belangrijk dat u pas SIS-integraties gaat definiëren nadat u met alle betrokken partijen hebt overgelegd over de gegevens die Blackboard Learn moet gebruiken om het systeem te vullen en uit welke bronnen deze afkomstig zijn en welke indeling ze moeten hebben. Aangezien het eenwegcommunicatie betreft vanuit het SIS naar Blackboard Learn, moeten alle gegevens voor cursussen, gebruikers en gebruikersrollen worden gedefinieerd en beschreven in Blackboard. Daarnaast moeten alle gebruikers beschikken over referenties waarmee ze uniek worden geïdentificeerd binnen Blackboard.

Het verzamelen van cursus-, gebruikers- en inschrijvingsgegevens is een terugkerend proces. Als mensen komen of vertrekken, cursussen worden toegevoegd en inschrijvingen worden aangepast, moeten de gegevens in Blackboard worden aangepast. Hoe vaak de gegevens moeten worden verzameld en geladen, wordt bepaald door het beleid van de instelling. De gegevensbronnen die gegevens leveren aan het systeem moeten worden gekoppeld aan procedures die eenvoudig kunnen worden herhaald om gegevens aan te bieden aan beheerders van Blackboard.

Het is mogelijk dat op de instelling al een geschikt proces is ingericht op basis van afgesproken bedrijfsregels. In dat geval is een uitvoerige planning mogelijk niet nodig. Het blijft echter wel essentieel dat u bekend bent met de informatievereisten van Blackboard, evenals de volgorde en frequentie van taken die moeten worden uitgevoerd. Als de instelling nog niet veel ervaring heeft met het uitvoeren of aanpassen van geautomatiseerde processen, is een uitgebreidere planning noodzakelijk om vóór de integratie te beschikken over de benodigde bedrijfsregels en informatie.

Vereiste informatie voor gebruikers, cursussen en inschrijvingen

Blackboard heeft de volgende informatie nodig voor gebruikers, cursussen en inschrijvingen om een integratie te kunnen maken. De eerste stap van het plannen bestaat uit het aangeven van de bron waaruit de verschillende soorten gegevens afkomstig zijn.

Vereiste gegevens
Object	Element
Gebruikers (personen)	Unieke persoons-ID Aanmeldings-ID Wachtwoord (voor toegang tot Blackboard) Voornaam Achternaam Bijnaam (optioneel) E-mailadres E-mailadres van de instelling Instellingsrol
Cursus	Unieke cursus-ID Cursus-ID Naam cursus Bron voor cursusinhoud (optioneel)
Inschrijvingen	Gekoppelde set gebruikers voor de cursus Rol van gebruiker in cursus

Verificatiemethode kiezen

Verzamel een aanmeldings-ID en wachtwoord voor elke gebruiker. U kunt het eigen verificatiesysteem van Blackboard gebruiken of het verificatiesysteem van uw instelling.

Als je het eigen verificatiesysteem van Blackboard gebruikt, moeten in ieder geval aanmeldings-ID's en wachtwoorden worden verzameld. Deze gegevens moeten aan elke gebruiker beschikbaar worden gesteld.
Als de aanmeldings-ID's en wachtwoorden afkomstig zijn uit het verificatiesysteem van uw instelling, verzamelt u de ID's en genereert u een willekeurig wachtwoord voor elke gebruiker. De gebruiker wordt dan geverifieerd door het verificatiesysteem van de instelling.

Gegevensbronnen definiëren

Hoewel het mogelijk is alle gegevens intern te verzamelen in een LMS zoals Vista, is het veel beter om officiële instellingsgegevens te gebruiken die door de instelling worden verzameld en onderhouden. Deze instellingsgegevens zijn waarschijnlijk afkomstig uit verschillende gegevensbronnen. Om welke gegevensbronnen het gaat en welke gegevens je hier kunt verzamelen, is misschien al beschreven binnen de instelling maar misschien moet deze stap nog worden uitgevoerd. In ieder geval moeten er afspraken zijn over de te gebruiken gegevensbronnen en over de methode om gegevens te extraheren voor de integratie.

Ondanks dat iedere instelling anders is ingericht, zijn er toch een paar vaste plekken waar de vereiste informatie kan worden verkregen.

Studenteninformatiesysteem (SIS) - een centrale opslaglocatie voor studenteninformatie zoals naam, adres, contactgegevens, schooljaar of afstudeerdatums.
De administratie: de gegevensbron voor informatie over de cursuscatalogus, cursusnamen, beschrijvingen van cursussen en sectiegegevens, evenals inschrijvingsgegevens.
HR-afdeling of HRMS (Human Resources Management System): informatie over alle medewerkers van de instelling, zoals docenten, administratief personeel en onderwijsassistenten.
Adresboek van de instelling: de plaats voor het opzoeken van telefoonnummers van medewerkers en afdelingen, evenals e-mailadressen en kantooradressen. Dit adresboek kan een bron van informatie zijn voor het LMS.
IT-afdeling of helpdesk: bepaalt de methoden voor het verifiëren van gebruikers, zoals een LDAP-service. Deze afdeling kan verantwoordelijk zijn voor het genereren van e-mailadressen en aanmeldingsgegevens.

Problemen met conflicterende gegevens oplossen

Als uit verschillende gegevensbronnen gegevens worden verzameld, kunnen er conflicten tussen gegevenselementen ontstaan. Er moet daarom een beleid worden opgesteld om conflicten op te lossen, zodat het systeem weet welke gegevensbron moet worden gebruikt. Zo wordt er voor gebruikers bijna altijd een e-mailadres vastgelegd in het HRMS. De kans is groot dat de administratie ook om een e-mailadres vraagt. Conflicten met e-mailadressen kunnen ontstaan wanneer een gebruiker twee verschillende rollen heeft binnen de instelling, zoals student en onderwijsassistent of cursusleider en faculteitsmedewerker. Als in een dergelijk geval twee e-mailadressen van de instelling worden gehanteerd, moet er worden besloten welke gegevensbron prioriteit heeft en gebruikt zal worden als het e-mailadres van de instelling voor de gebruiker.

Een ander voorbeeld van conflicterende gegevenselementen is wanneer er voor studenten verschillende e-mailadressen zijn vastgelegd door de administratie en in het SIS. Misschien dat in het adresboek van de instelling weer een ander e-mailadres wordt gebruikt. Om in een dergelijk scenario conflicten te voorkomen, kunt u de prioriteit van de gegevensbronnen instellen. Een andere oplossing is gebruikers toestemming te geven hun e-mailadres in te stellen binnen Blackboard.

Integraties werken alleen goed als vooraf wordt gekeken waar gegevenselementen conflicten kunnen veroorzaken en hiervoor regels worden opgesteld.

Wat houdt het e-mailadres van de instelling in en welke ondersteuning biedt het?

Het veld E-mailadres van de instelling maakt het mogelijk om veldtoewijzingen toe te passen tussen de extern ondersteunde service van een client en Blackboard Learn. In het geval van een gegevensprovider die ook een cloudprovider is, zoals Microsoft, is de gebruikersprincipenaam (UPN) een primaire unieke ID voor elke gebruiker die bestaat uit een UPN-voorvoegsel (de accountnaam van de gebruiker) en een UPN-achtervoegsel (een DNS-domeinnaam) die zijn samengevoegd met een @ symbool. Hierdoor wordt binnen de map met gegevensservice een uniek e-mailadres gemaakt voor elke specifieke gebruiker.

Om ervoor te zorgen dat gegevens juist zijn en inschrijvingen of lidmaatschappen tussen Blackboard Learn en de gegevensserviceprovider juist zijn bereikt, moet het e-mailadres van een gebruiker tussen beide systemen overeenkomen. In Blackboard Learn kan een gebruiker in de gebruikersinterface het bestaande Persoonlijke e-mailadres wijzigen of vervangen, waardoor er synchronisatiefouten kunnen optreden en de gebruiker niet correct wordt toegevoegd. De veldtoewijzing van het e-mailadres van de instelling zorgt ervoor dat dit niveau van beveiliging en validatiecontrole op de juiste manier beheerd kan worden, ongeacht of de gebruiker het persoonlijke e-mailadres binnen Blackboard heeft gewijzigd of niet.

Volgorde voor het laden van gegevens

Alle gegevens die het systeem nodig heeft voor het aanmaken van gebruikers, cursussen en inschrijvingen zijn verplicht. Maar omdat de gegevens uit verschillende bronnen afkomstig kunnen zijn, moeten de gegevens in een bepaalde volgorde in Blackboard worden geladen. Cursus- en gebruikersgegevens moeten eerst worden geladen omdat inschrijvingen afhankelijk zijn van deze gegevens. Gebruik deze volgorde voor het laden van gegevens:

Gebruikers
Cursussen
Inschrijvingen

De specifieke informatie voor het aanmaken van gebruikers, cursussen en inschrijvingen wordt hieronder beschreven.

Gebruikers maken

EXTERNAL_PERSON_KEY. Dit element wordt gebruikt om de gebruiker binnen de database aan te duiden. Hoewel deze sleutel nooit wordt weergegeven, mag de sleutel geen persoonsgegevens, namen, burgerservicenummers of geboortedatums bevatten. De reden hiervoor is dat de gegevens van gebruikers kunnen veranderen. Zo kan iemand trouwen, scheiden of een ander BSN krijgen. U voorkomt problemen door dergelijke gegevens niet op te nemen in dit gegevenselement. Deze sleutel is maximaal 64 tekens lang. Om het risico te voorkomen dat de gegevens van een student door een andere student worden gezien, mag deze sleutel nooit worden hergebruikt. Als de sleutel is toegewezen aan een student, mag de sleutel nooit meer worden uitgegeven. Het opnieuw uitgeven van EXTERNAL_PERSON_KEY kan betekenen dat persoonlijke gegevens van een gebruiker zichtbaar worden voor een andere gebruiker. Blackboard adviseert daarom deze sleutel op te nemen in een zeer grote sleutelruimte. Als u nog niet beschikt over een geschikte identificatie, wordt geadviseerd deze sleutel samen te stellen door per student een willekeurig hexadecimaal getal van 16-20 tekens te genereren. De grote variabiliteit en willekeurige verdeling zorgen ervoor dat er een goed uitgebalanceerde index van de database kan worden gemaakt.
USER_ID. De USER_ID wordt ook wel een netwerk-ID, gebruikersnaam of aanmeldingsnaam genoemd. Dit element wordt samen met een wachtwoord gebruikt om een gebruiker te verifiëren bij het LMS. Als geen centraal verificatiesysteem wordt gebruikt, kan Blackboard hiervoor worden gebruikt. In dit geval moet de beheerder van Blackboard de USER_ID's en wachtwoorden maken voor alle gebruikers. Als een centraal verificatiesysteem wordt gebruikt met een protocol dat wordt ondersteund door Blackboard, is het raadzaam gebruikers van Blackboard met dat systeem te verifiëren. In dat geval moet er een lijst met USER_ID's die zijn gekoppeld aan EXTERNAL_PERSON_KEY's worden samengesteld voor gebruik in Blackboard. Deze gegevens worden dan ook gebruikt als verificatie voor Blackboard.
FIRSTNAME, LASTNAME, NICKNAME. Deze elementen bepalen hoe de identiteit van een student wordt weergegeven binnen Blackboard. Indien mogelijk moeten namen in de bron van de naamsgegevens worden opgesplitst, dus voordat deze naar Blackboard worden overgebracht. Deze namen zijn meestal de officiële namen die door de instelling in officiële stukken worden gebruikt, zoals cijferlijsten of identificatiebadges. Niet alle mensen willen met hun officiële voornaam worden geregistreerd. Soms willen ze een andere naam of bijnaam gebruiken. Blackboard biedt de mogelijkheid om (desgewenst) een bijnaam op te geven via het gegevenselement NICKNAME. Configureer het LMS zo dat de inhoud van NICKNAME wordt weergegeven in plaats van FIRSTNAME. Het is een goed idee het verzamelen en vastleggen van bijnamen volgens vaste procedures en centraal te laten uitvoeren.
EMAIL. Het e-mailadres is vereist voor communicatie met de gebruiker.
- Blackboard ondersteunt twee e-mailadressen per persoon (persoonlijk e-mailadres en e-mailadres van de instelling). Als een gebruiker meerdere e-mailadressen heeft omdat er gegevens uit verschillende bronnen zijn verzameld, moet een instelling:
  - een systeem kiezen met records als de primaire e-mail, of
  - het veld E-mailadres van de instelling gebruiken om een officieel e-mailadres in te stellen voor het account van de gebruiker, zodat de gebruiker zonder conflicten een eigen e-mailadres kan instellen in Blackboard.
- Situaties met meerdere e-mailadressen kunnen ook ontstaan wanneer een gebruiker twee verschillende rollen heeft binnen de instelling, zoals student en onderwijsassistent of cursusleider en faculteitsmedewerker. U moet dan beslissen welk e-mailadres u wilt gebruiken.
- Sommige cursusleiders willen een e-mailadres gebruiken in Blackboard dat niet hun officiële e-mailadres is en er zijn ook studenten die hun e-mailadres voor cursuswerk willen loskoppelen van hun gewone e-mailadres. U kunt deze scenario's ondersteunen door gebruikers toestemming te geven hun e-mailadres bij te werken in Blackboard. (De instelling kan beslissen of studenten hun e-mailadres kunnen bijwerken.) Dit betekent dat je een door de gebruiker gewijzigd e-mailadres niet meer kunt bijwerken vanuit de bron met officiële gegevens. Het is dan de verantwoordelijkheid van de gebruiker om ervoor te zorgen dat het e-mailadres in Blackboard altijd actueel is. Het blijft echter een risico dat gebruikers vergeten dit aan te passen, waardoor e-mails niet op het juiste adres worden afgeleverd.
INST_EMAIL: nu beschikbaar voor alle bestaande typen SIS-integratie, met uitzondering van SIF. Het e-mailadres van de instelling is een primaire unieke ID voor elke gebruiker die bestaat uit een UPN-voorvoegsel (de accountnaam van de gebruiker) en een UPN-achtervoegsel (een DNS-domeinnaam) samengevoegd met een @-symbool. Hierdoor wordt er een uniek e-mailadres gemaakt voor iedere specifieke gebruiker binnen een gegevensservicemap, waardoor instellingen de synchronisatieprocessen van gegevens tussen Blackboard Learn Ultra en de service effectief kunnen beheren. Dit is standaard ingesteld op het persoonlijk e-mailadres voor alle SIS-indelingen en moet voor elke persoon uniek zijn. Alle bestaande integraties die ingesteld en actief zijn, hebben deze gegevenstoewijzing. SIS kan de gebruikers anders niet importeren als ze een dubbele e-mail hebben.
Je kunt dit beheren via de pagina Geavanceerde configuratie-instellingen van het SIS > Learn-objecttype > Veldtoewijzing.
Er worden geen e-mailberichten verzonden naar inst_email. Op dit moment wordt het uitsluitend gebruikt met integraties van derden.
Dit gebruikersveld kan niet worden ingesteld via batchbestand in de sectie Gebruikers > Maken van het configuratiescherm voor systeembeheerder.
INSTITUTION_ROLE. Dit element bevat de rol van een gebruiker binnen de instelling. Dit is niet de rol in de cursus, maar een manier om de rol van een gebruiker binnen de instelling te beschrijven. De INSTITUTION_ROLE bepaalt wat de gebruiker kan zien in Blackboard. Deze rol wordt ook gebruikt om op te geven welke gebruikers verhoogde bevoegdheden hebben binnen de toepassing. Als het niet nodig is om verschillende beginpagina's weer te geven aan gebruikers op basis van hun rol binnen de instelling, kan het gegevenselement INSTITUTION_ROLE worden ingesteld op ‘none’.
SYSTEM_ROLE. Dit element bevat de rol van een gebruiker binnen het systeem. Deze rol geeft de gebruiker toestemming bepaalde aspecten van Blackboard te beheren. Het betreft de aspecten systeembeheer, cursussen maken en inhoudsbeheer van cursussen. De rol ‘NONE’ beschikt niet over bevoegdheden voor systeembeheer of het maken van cursussen en is de rol die het vaakst wordt toegewezen.

Cursussen maken

EXTERNAL_COURSE_KEY. Dit element vormt een unieke aanduiding van de cursus. Het element wordt niet weergegeven aan Blackboard-gebruikers. Het is raadzaam voor deze gegevenselementen een syntaxis te gebruiken waarmee u ze snel kunt sorteren en manipuleren. U moet verschillende gegevenselementen verzamelen die een cursus gedurende een aantal jaren uniek beschrijven (de bewaarperiode voor gegevens). De administrateur hanteert meestal een nummer dat een cursus uniek identificeert binnen ten minste een bepaald semester. Als er bijvoorbeeld een cursus Biologie 301 is gepland voor het najaar van 2012 met het unieke cursusnummer 12345, kunt u 2012_najaar_12345_BIO_301 gebruiken als de waarde voor EXTERNAL_COURSE_KEY. Het is nog beter als u voor alle elementen van de EXTERNAL_COURSE_KEY hetzelfde aantal tekens gebruikt, indien mogelijk. Dit is met name handig voor de namen van afdelingen en datums. Een semester kan worden voorgesteld door een maandnummer, zoals 1, 6 of 9. Voor sommige Building Blocks van derden moeten de velden dezelfde lengte hebben. Dit is zeker zo voor de datumgegevens. In het bovenstaande voorbeeld worden de afzonderlijke gegevenselementen overal gescheiden door een onderstrepingsteken. ‘_’.
COURSE_ID. Dit element wordt gebruikt voor portaalmodules bij het sorteren van cursussen. Dit element kan niet meer worden gewijzigd nadat de cursus is gemaakt. Deze sleutel is zichtbaar voor gebruikers en moet daarom informatie bevatten die duidelijk is voor de gebruiker. Meestal bevat deze sleutel een jaartal en semester voor sorteerdoeleinden. Daarnaast moet de sleutel de afdeling en cursusnummers bevatten, plus een unieke ID. Een voorbeeld van een COURSE_ID is dan 2010_9_12345_SCHE_301. Gebruik steeds hetzelfde scheidingstekens, bij voorkeur een onderstrepingsteken. In de portaalmodule ‘Mijn cursussen’ worden cursussen standaard gesorteerd op COURSE_ID. Dit is belangrijk wanneer de lijst met cursussen erg lang wordt.
COURSE_NAME. Dit element kan elke waarde bevatten die een omschrijving geeft van de cursus. De waarde hoeft niet uniek te zijn en kan worden gewijzigd tijdens het laden van gegevens, of door de cursusleider. Sommige Building Blocks sorteren op COURSE_NAME.
TEMPLATE_COURSE_KEY. Het optionele element TEMPLATE_COURSE_KEY bevat de naam van een bestaande cursus die is voorbereid met inhoud. Sommige organisaties bieden cursussen aan met gestandaardiseerde inhoud. Hiervoor is TEMPLATE_COURSE_KEY een hulpmiddel. Deze inhoud kan bestaan uit bestanden, enquêtes, vragenlijsten, mededelingen en zelfs cursusleiders. De voorbeeldcursus moet zijn afgerond voordat de cursussen worden gemaakt. De inhoud van de voorbeeldcursus wordt namelijk bij het maken van de nieuwe cursus gekopieerd. Als de voorbeeldcursus wordt gewijzigd nadat er cursussen op zijn gebaseerd, heeft dit geen gevolgen voor deze bestaande cursussen. De voorbeeld- of sjablooncursus moet helemaal af zijn voordat er nieuwe cursussen op de sjabloon worden gebaseerd. Gebruik een vaste naamgevingsconventie voor sjablooncursussen. Begin de naam bijvoorbeeld altijd met het voorvoegsel ‘sjabloon’, gevolgd door een onderstrepingsteken en een ID.

Inschrijvingen maken

Een inschrijving is de koppeling van een gebruiker aan een cursus en de definitie van de rol van de gebruiker in de cursus, zoals student of cursusleider.

EXTERNAL_COURSE_KEY. Dit element is de unieke sleutel uit de cursusgegevens.
EXTERNAL_PERSON_KEY. Dit element is de unieke sleutel uit de gebruikersgegevens. Deze sleutels moeten zijn gedefinieerd voordat een bepaalde inschrijvingsrecord kan worden verwerkt.
ROLE. Het gegevenselement ROLE definieert de rol van de gebruiker in de cursus.

Gegevens labelen en opmaken

Als u klaar bent met het identificeren van alle gegevensbronnen, het opstellen van regels voor het oplossen van conflicten en het verzamelen van alle gegevenselementen uit de bronnen, moet u enkele labels maken voor uw gegevens. Deze zogenaamde gegevensbronsleutels (DSK's) zijn nodig om een set gegevens in één bewerking te kunnen verwerken. Daarnaast moet je ervoor zorgen dat de gegevens zo zijn opgemaakt dat deze worden herkend en op de juiste manier worden verwerkt door het type integratie dat je selecteert.

Gegevensbronsleutels maken

Een gegevensbronsleutel is een label dat kan worden toegewezen aan een set gegevens, zodat deze in één bewerking kunnen worden verwerkt in plaats van iedere record afzonderlijk. U kunt meerdere gegevensbronsleutels definiëren en gebruiken om gegevens te laden en te verwerken in Blackboard.

Het is raadzaam de gegevensbronsleutels zo te definiëren dat u alle vergelijkbare items tegelijk kunt laden. Dit betekent dat u alle gebruikers onder één sleutel moet plaatsen. Plaats de cursussen van elk semester in een andere gegevensbronsleutel. Op deze manier kunt u de cursussen van een bepaald semester met één opdracht efficiënt manipuleren zonder dat dit gevolgen heeft voor de gebruikers. Om dezelfde reden moet je ook de inschrijvingen van een semester in een afzonderlijke gegevensbronsleutel laden.

Stel de DATA_SRC_KEY samen door het jaar, het semester, de bron en het type gegevens aan te geven. Gebruik bijvoorbeeld 2011_najaar_SIS_cursussen voor cursussen uit het najaar van 2011.

Meer informatie over gegevensbronsleutels

De gegevens opmaken

De gegevens moeten zo worden opgemaakt dat het Building Block SIS-integratie alle elementen kan herkennen en op de juiste manier kan verwerken. Voor elk gegevenselement moet het type worden ingesteld. XML (Extensible Markup Language) biedt een eenvoudige, gestandaardiseerde en toch krachtige methode om gegevens te beschrijven. De XML-indeling verschilt iets per type integratie dat u selecteert.

Aanvullende informatie voor de planning

Als onderdeel van de planning van SIS-integraties moet je ook beslissen wat voor type of typen integratie je wilt maken. Daarnaast moet je nog andere beslissingen nemen op basis van beleidsregels en vereisten die gelden binnen de instelling.

Soorten integratie

Er zijn zes soorten integraties beschikbaar en de gegevensindeling is voor elke soort net iets anders. Er is geen limiet voor het aantal integraties dat een systeem kan hebben. Het is ongebruikelijk, maar wel mogelijk, om binnen één systeem verschillende soorten integraties toe te passen.

IMS Enterprise 1.1
IMS Enterprise 1.1 - Vista
IMS Learning Information Services
Momentopname-bestand
Momentopname-XML
Grades Journey

Zie SIS-integraties maken en bewerken voor meer informatie over de gegevenstoewijzing voor elke type integratie.

SSHA-wachtwoordcodering voor IMS Learning Information Services

Verificatie wordt uitgevoerd op basis van methoden die worden gebruikt door Sungard Banner. Als u het type codering in de veldkoppeling instelt op SSHA, wordt het voorvoegsel {SSHA} toegevoegd (tenzij al aanwezig). Daarnaast wordt de parameter pwencryptiontype ingesteld, zoals je kunt zien in het onderstaande voorbeeld:

Plan van aanpak voor communicatieproblemen

Als er sprake is van een communicatieprobleem tussen het SIS en Blackboard, is het belangrijk dat je een plan van aanpak hebt om dit probleem op te lossen. Het is mogelijk om je gegevens handmatig te uploaden naar de integratie in de GUI. Er moeten systeemtriggers en backups worden ingesteld om het systeem probleemloos te laten draaien en de systeemgegevens actueel te houden.

De integratiestatus instellen

Blackboard adviseert nieuwe integraties eerst de status Testen te geven. Als u deze status selecteert, kunt u de integratie eerst testen en eventuele problemen verhelpen voordat u de integratie uitrolt in de productieomgeving. Als de testfase is afgerond, kunt u de status instellen op Inactief of Actief. Inactief wil zeggen dat er geen verzoeken worden verwerkt en geen gegevens worden bijgewerkt in de database. Stel de status in op Actief om verzoeken te verwerken, gegevens bij te werken in de database en de integratie zichtbaar te maken voor gebruikers.

Blackboard adviseert ook om deze integratie te maken in een staging- of testomgeving en daarna pas vrij te geven aan productie.

Logboekregistratie

Het detailniveau van de logboekfunctie bepaalt het type en de uitgebreidheid van de gegevens die voor de geselecteerde integratie worden vastgelegd. Dit niveau wordt ingesteld tijdens het maken van de integratie. Logbestanden kunnen worden gefilterd via een geavanceerde zoekmethode. U kunt bijvoorbeeld filteren op het type fout, de integratie en een datumbereik.

Geavanceerde configuratie

Het type Learn-object en het objecttype uit uw SIS-systeem worden 1 op 1 gekoppeld. Geef per objecttype aan hoe het invoegen, bijwerken en verwijderen van gegevens moet worden afgehandeld.

Meer informatie

Learning Information Services Specification Primer

Learning Information Services

Taal