Gebruikersvoorbeelden van snapshot-flatbestanden

De volgende voorbeelden geven de compositie van User-gegevensfeeds (persoon) weer terwijl ze aan verschillende praktijkvoorbeelden voldoen. Deze voorbeelden gebruiken de eenvoudigst mogelijke gegevensfeed. Er zijn gevallen waarbij je instelling meer informatie nodig kan hebben. Aan deze vereisten wordt voldaan door de vereiste headers en gegevens toe te voegen aan de gegevensfeed. Analyse van het informatiesysteem van je instelling en de vereisten en planning van registrars helpen bij het bepalen van de diepte van de gegevens die nodig zijn om Blackboard goed te vullen om te voldoen aan je gegevens en levenscyclusdoelen.

Gebruikers

Gebruikersgegevens zijn de primaire informatieset die beschrijft wie toegang heeft tot Blackboard, wat hun rol is bij je instelling en wat hun rol is binnen het Blackboard-systeem. In de context van SIS-gegevens worden USER-objecten worden vaak 'PERSON' genoemd en dit wordt weerspiegeld in bestaande standaarden. Blackboard gebruikt 'PERSON' en 'USER' om te verwijzen naar gebruikersgerelateerde records op basis van de context. In de volgende voorbeelden wordt ‘PERSON’ gebruikt om te verwijzen naar de record en ‘USER’ om naar het persoon te verwijzen.

Gegevensbeheer van snapshot-flatbestanden

Het Studentinformatiesysteem Framework ondersteunt het uploaden van Snapshot Flat File-gegevensfeeds via een UI Feed Upload en via een set URL's die door het Blackboard-systeem worden geleverd.

Open HTTP-gegevens en Invoerbestand uploaden via het integratiemenu in de Gegevensintegratie van de Systeembeheerder voor UI-integraties voor Studenteninformatiesystemen.

In beide gevallen wordt het van de gegevensbewerking aangestuurd door de configuratie van de integratie en het geselecteerde type taak. Het geselecteerde type gegevensbewerking bepaalt hoe de gegevens in de feed 'geïnterpreteerd' worden en elke URL geeft een ander resultaat om te voldoen aan de gewenste doelen van de integratie.

Gegevens kunnen aan Blackboard worden verstrekt en vervolgens worden bijgewerkt, verwijderd of gewijzigd. Het is dus mogelijk dat je begint met de eenvoudigste gegevensset en dat de gegevensvereisten van de instelling veranderen.

De volgende taken zijn beschikbaar via de UI en HTTP:

De objecten die zijn gekoppeld aan PERSON-taken zijn:

De opgegeven voorbeelden worden weergegeven met behulp van de Momentopname Framework UI-functie voor het uploaden van invoerbestanden. Zie Snapshot Flat File Automation voor het automatiseren of anderszins gebruiken van opdrachtregel-/programmatische bewerkingen.

Een herinnering over gegevensbronsleutels

Alle gegevensobjecten ondersteunen de mogelijkheid om de gegevensbronsleutel voor de groepering van die gegevensset te wijzigen en kunnen worden gebruikt om de bijbehorende gegevensbron te wijzigen - Opmerking: dit is geen verplicht veld in op Framework gebaseerde gegevensfeeds en tenzij anders vermeld, wordt in de onderstaande voorbeelden aangenomen dat de integratie is geconfigureerd om één gegevensbron te gebruiken.

Zie Gegevensbronsleutelbeheer voor meer informatie.

Een opmerking over het in kaart brengen van velden

Field mapping biedt de mogelijkheid om binnenkomende gegevens te wijzigen voordat deze worden opgeslagen in Blackboard. Hierdoor heb je volledige controle over de gegevens die worden opgeslagen en kun je voldoen aan specifieke regels van Blackboard wanneer de Studentinformatiesysteem-gegevens die je worden verstrekt ontoereikend zijn, zoals het aanmaken van gebruikerswachtwoorden. Wanneer het wordt toegepast op een gebruikersobjectveld, wordt het bijbehorende script per gebruiker uitgevoerd, waardoor de gegevens worden gewijzigd of verstrekt voordat deze worden opgeslagen in Blackboard. Een volledige uitleg van Field Mapping voor Snapshot Flat File vindt u in Snapshot Flat File Field Mapping.

Een opmerking over wachtwoorden

Wachtwoorden zijn vereist om in te loggen op Blackboard, maar zijn geen verplicht veld in PERSON-datafeeds. Als er geen wachtwoord wordt opgegeven in de gegevensfeed, wordt een willekeurig SHA512-wachtwoord gegenereerd en opgeslagen in de Blackboard-database. Dit is geen probleem als je externe verificatie (zoals LDAP) gebruikt, maar wat gebeurt er als je de Blackboard-database gebruikt om inlogwachtwoorden van gebruikers op te slaan? Je moet het wachtwoord voor het maken van een gebruiker opgeven omdat ze zich niet kunnen aanmelden.

Als je een feed uitvoert en het wachtwoord voor een gebruiker instelt die daarna hun wachtwoord wijzigt, wordt de aanmelding gebroken. Bij een updatebewerking kunt u ervoor kiezen om het wachtwoordveld niet bij te werken. Hierdoor kan Blackboard het huidige wachtwoord behouden bij het updaten. Als je deze optie niet selecteert, wordt het wachtwoord gewijzigd en moet de gebruiker op de hoogte worden gesteld van de wijziging.

Voorbeelden person-taken

Op een hoog niveau kun je drie gegevensfeedpatronen van SIS-integratie toepassen op alle taken voor User-gegevens en de selectie van het patroon is afhankelijk van de gegevens die je kunt opgeven en de integratiedoelen.

Ten slotte, en dit is geen Studentinformatiesysteem-feedpatroon, maar het vermelden waard, kunt u ook uitschakelen en verwijderen op basis van alleen DSK met behulp van de tool voor Gegevensbronbeheer die beschikbaar is in de gebruikersinterface. Je moet uiterst zorgvuldig zijn met de SIS-gegevens die je op deze manier verkrijgt. Dit is uiterst nuttig bij het wissen van gegevens die nooit via het Studentinformatiesysteem zijn verstrekt of niet meer worden verstrekt, zoals gegevens die het resultaat zijn van testoperaties.

Alleen de basis: Personen

Voor alle gebruikersaccounts is een basisset van informatie vereist om een account op te kunnen stellen. Deze set informatie wordt gedetailleerd beschreven in Snapshot Flat File Data Format en Snapshot Flat File Header.

Gegevens in het kort

De minimale dataset of headers die nodig zijn voor het maken van een gebruikersaccount in Blackboard bestaan uit:

Het SIS Framework biedt per integratieconfiguratie standaardwaarden voor de niet-verplichte velden, of negeert deze. Twee nuttige velden die niet vereist zijn voor een PERSON-feed zijn EMAIL en SYSTEM_ROLE. E-mail is vereist voor het corresponderen en verstrekken van e-mailmeldingen aan Blackboard-gebruikers via Blackboard-e-mail, dus overweeg om deze gegevens in je feed op te geven. SYSTEM_ROLE wordt standaard ingesteld op de geconfigureerde instelling NONE.

Person-informatie toevoegen

Er bestaan twee gevallen voor het toevoegen van PERSON-informatie. De eerste is om PERSON-informatie additief op te slaan waardoor het toevoegen of bijwerken van de records wordt weergegeven in de gegevensfeed. De tweede is om PERSON-informatie die al op Blackboard staat, te VERNIEUWEN, wat resulteert in het toevoegen van nieuwe of het bijwerken van bestaande records zoals gepresenteerd in het gegevensbestand, terwijl bestaande records die niet aanwezig zijn in het gegevensbestand worden uitgeschakeld.

Voorbeelden store-taak

Voorbeeld #1: Persoonsaccounts aanmaken

Je wilt gebruikers toevoegen aan Blackboard zonder dat dit gevolgen heeft voor bestaande accounts. Je hebt de integratie geconfigureerd om dezelfde gegevensbron voor alle inkomende gegevens te gebruiken.

Voorwaarde

Geen.

Minimale vereisten voor datafeeds

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME

Oplossing

Maak een PERSONS.txt-gegevensbestand met de vereiste kopteksten en de bijbehorende gegevens per PERSON die je wilt toevoegen aan het systeem. Bijvoorbeeld:

Gebruik de UI om dit bestand te uploaden via het gegevenstype van de PERSON met behulp van de STORE-taak. Het gebruikersaccount wordt gemaakt en je kunt je aanmelden als de gebruiker.

Voorwaarde achteraf

Er worden persoonsrecords voor aanderson_test, bbrown_test en gcarlin_test gemaakt.

Voorbeeld #2: Gebruikersaccounts bijwerken

Je hebt gebruikersaccounts gemaakt en je moet deze wijzigen. Het vorige voorbeeld bevat bijvoorbeeld geen e-mailadressen van gebruikers. U heeft het e-mailadres voor aanderson_test.

Voorwaarde

Geen: updates worden uitgevoerd op eerder gemaakte records, gegevens die zijn opgenomen als een record niet bestaat in Blackboard, leiden ertoe dat de record wordt gemaakt.

Oplossing

Maak een PERSONS.txt-gegevensbestand met de vereiste kopteksten en de bijbehorende gegevens per PERSON die je wilt toevoegen aan het systeem. Bijvoorbeeld:

Gebruik de UI om dit bestand te uploaden via het gegevenstype van de PERSON met behulp van de STORE-taak. Het gebruikersaccount wordt bijgewerkt.

Voorwaarde achteraf

Het persoonsrecord voor aanderson_test wordt bijgewerkt met het opgegeven e-mailadres.

De persoonsrecords voor bbrown_test en gcarlin_test worden niet beïnvloed.

Persoon: Volledige vernieuwingsverrichting

COMPLETE REFRESH werkt anders dan STORE. VOLLEDIGE VERNIEUWING voert twee bewerkingen uit die neerkomen op een vergelijking van de gegevens in het feedbestand en de records in Blackboard die eigendom zijn van de integratie: het opslaan van nieuwe records, het bijwerken van bestaande records of het uitschakelen van records in Blackboard die niet in het gegevensbestand staan.

Voorbeeld: Volledig vernieuwen

De gegevens die uw Studentinformatiesysteem verstrekt, bevatten een volledige momentopname van de PERSONEN die toegang moeten hebben tot Blackboard. Deze gegevens bevatten persoonsrecords om toe te voegen, persoonsrecords om bij te werken en records die zijn verwijderd sinds eerdere COMPLETE REFRESH-bewerkingen die op de juiste manier per configuratie moeten worden afgehandeld (uitschakelen of verwijderen).

Voorwaarde

Geen.

Minimale vereisten voor datafeeds

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME

Oplossing

De gegevens van onze laatste winkelbewerking gebruiken en gcarlin_test uit de gegevensfeed verwijderen:

Voorwaarde achteraf

Het persoonsrecord voor aanderson_test wordt behouden en niet beïnvloed.

Het persoonsrecord voor bbrown_test wordt behouden en bijgewerkt met het e-mailadres.

De persoonsrecord voor gcarlin_test is gemarkeerd als uitgeschakeld of klaar om te worden verwijderd per integratieconfiguratie.

Persoon: Volledig vernieuwen door bewerking van de gegevensbron

COMPLETE REFRESH BY DATA SOURCE werkt als een COMPLETE REFRESH maar beperkt de gegevens die worden beïnvloed door de integratie van de gegevensbron.

Voorbeeld: Volledig vernieuwen per gegevensbron

De gegevens die uw Studentinformatiesysteem verstrekt, bevatten een volledige momentopname van de PERSONEN die toegang moeten hebben tot Blackboard. Deze gegevens bevatten persoonsrecords om toe te voegen, persoonsrecords om bij te werken en records die zijn verwijderd sinds eerdere REFRESH-bewerkingen die op de juiste manier per configuratie moeten worden afgehandeld (uitschakelen of verwijderen). Daarnaast zijn alle gegevens in deze vernieuwing bestemd om dezelfde gegevensbron te gebruiken zoals gedefinieerd in de integratie en worden ALLEEN gegevens met betrekking tot deze gegevensbronsleutel beïnvloed.

Voorwaarde

Geen.

Minimale vereisten voor datafeeds

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME

Oplossing

Het gebruik van de gegevens van de laatste keer dat we de store-taak hebben toegepast en verwijdert gcarlin_test uit de gegevensfeed:

Voorwaarde achteraf

Het persoonsrecord voor aanderson_test wordt behouden en niet beïnvloed.

Het persoonsrecord voor bbrown_test wordt behouden en bijgewerkt met het e-mailadres.

De eerder gemaakte persoonsrecord voor gcarlin_test is gemarkeerd als uitgeschakeld of klaar voor verwijdering per integratieconfiguratie.

Als andere persoonsrecords worden beheerd door deze integratie, worden ze NIET uitgeschakeld of verwijderd vanwege hun afwezigheid in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben als gespecificeerd door de integratie.

Beschikbaarheid Person-account

Met de instelling voor de beschikbaarheid van PERSON-accounts kan een account in Blackboard inloggen (beschikbaar) of niet (niet beschikbaar). Opmerking: dit is niet hetzelfde als het uitschakelen van een account. Het account is niet alleen niet-beschikbaar voor iedereen maar het is ook niet-beschikbaar voor aanvullende taken zoals lidmaatschapsbeheer. De toevoeging van deze gegevensfeedheader heeft geen invloed op het bovenstaande gebruik van STORE, COMPLETE REFRESH, COMPLETE REFRESH BY DATA SOURCE voor het maken van PERSON-records.

Voorbeeld: Beschikbaarheid van persoonsaccount

Je Studentinformatiesysteem bepaalt dat Blackboard-toegang beschikbaar is voor gebruikers en je datafeed geeft aan of gebruikers afzonderlijk toegang hebben tot Blackboard. Je wilt de toegang van individuele gebruikers wijzigen door het maken/bijwerken van PERSON.

Voorwaarde

Geen.

Minimale vereisten voor datafeeds

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
AVAILABILE_IND

Oplossing

Voeg de koptekst AVAILABLE_IND toe aan uw gegevensfeed en geef het enkele teken van Y op voor beschikbaar en N voor niet beschikbaar.

Voorwaarde achteraf

STORE

Alleen de persoonsrecords voor aanderson_test, bbrown_test en gcarlin_test worden bijgewerkt (ze zijn eerder gemaakt) en ddarling_test wordt gemaakt.

COMPLETE REFRESH

De persoonsrecords voor aanderson_test, bbrown_test en gcarlin_test worden bijgewerkt (ze zijn eerder gemaakt) en ddarling_test wordt gemaakt. Alle andere records worden uitgeschakeld of gemarkeerd voor verwijdering vanwege hun afwezigheid in de bovenstaande datafeed.

COMPLETE REFRESH BY DATA SOURCE

De persoonsrecords voor aanderson_test, bbrown_test en gcarlin_test worden bijgewerkt (ze zijn eerder gemaakt) en ddarling_test wordt gemaakt.

Als andere persoonsrecords worden beheerd door deze integratie, worden ze NIET uitgeschakeld of verwijderd vanwege hun afwezigheid in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben als gespecificeerd door de integratie. COMPLETE REFRESH BY DATA SOURCE werkt alleen voor records van de gegevensbron van de integratie.

Person-records uitschakelen

Als je een persoonsrecord in Blackboard uitschakelt, is deze niet toegankelijk voor aanmeldingsdoeleinden (de uitgeschakelde status overschrijft de beschikbaarheidsinstelling) en wordt de record ook ontoegankelijk voor UI-bewerkingen. Het is bijvoorbeeld niet mogelijk om een uitgeschakelde PERSON toe te voegen aan een cursus via de UI. Als je een record van Blackboard wilt verwijderen, moet die record bovendien eerst worden uitgeschakeld.

Het uitschakelen van records kan op twee manieren verlopen: uitschakelen via uitsluiting van feedgegevens bij REFRESH-bewerkingen en Uitschakelen via het gebruik van de feedheader ROW_STATUS.

De bovenstaande PERSON-taken met gebruik van REFRESH-taken tonen Uitschakeling door middel van uitsluiting aan. Het volgende geval en voorbeeld toont het aan door middel van ROW_STATUS.

Voorbeeld: Persoonsrecords uitschakelen

Studenten schrijven zich in of hoeven geen toegang meer te hebben tot Blackboard. Je bent verplicht om hun toegang tot en aanwezigheid in Blackboard volledig te verwijderen (in tegenstelling tot het onbeschikbaar maken van het record, dat alleen het inloggen beperkt). Als je STORE-taken gebruikt, moet je de cursus expliciet uitschakelen om deze Gebruiker verwijderen door de header ROW_STATUS te gebruiken. Dit is ook handig voor handmatige taken buiten het bereik van SIS-feeds.

Voorwaarde

Records die als doelwit zijn, bevinden zich binnen het Blackboard-systeem.

Minimale vereisten voor datafeeds

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
ROW_STATUS

Oplossing

Voeg de header ROW_STATUS toe aan de gegevensfeed en schakel de optie ENABLED voor ingeschakeld in en DISABLED voor uitgeschakeld.

Voorwaarde achteraf

STORE

Alleen de persoonsrecords voor aanderson_test, bbrown_test, gcarlin_test en ddarling_test worden gemaakt of bijgewerkt met de ROW_STATUS expliciet wordt bijgewerkt.

COMPLETE REFRESH

De persoonsrecords voor aanderson_test, bbrown_test, gcarlin_test en ddarling_test worden aangemaakt of bijgewerkt; Alle andere records worden uitgeschakeld of gemarkeerd voor verwijdering vanwege hun afwezigheid in de bovenstaande gegevensfeed.

COMPLETE REFRESH BY DATA SOURCE

De persoonsrecords voor aanderson_test, bbrown_test, gcarlin_test en ddarling_test worden gemaakt of bijgewerkt, met de ROW_STATUS expliciet wordt bijgewerkt.

Als andere persoonsrecords worden beheerd door deze integratie, worden ze NIET uitgeschakeld of verwijderd vanwege hun afwezigheid in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben als gespecificeerd door de integratie. COMPLETE REFRESH BY DATA SOURCE werkt alleen voor records van de gegevensbron van de integratie.

Beheer van secundaire gebruikersrol binnen instelling

Als je een licentie voor Community Engagement hebt, heb je toegang tot extra tollen die je aan gebruikers kan toewijzen. Deze zijn handig voor het beheren van toegang tot materialen en tabbladen in het Community Portal.

Het beheer van secundaire rollen is een afzonderlijke activiteit van het maken of bijwerken van gebruikers en daardoor maakt het beheer van secundaire rollen geen deel uit van de gegevensfeed van PERSON voor maken/bijwerken.

Voorbeeld: Rollen van secundaire instellingen toevoegen

Je moet Portal-inhoud aanbieden die specifiek is voor studenten en de Faculty of the School of Engineering.

Voorwaarde

Je hebt een nieuwe instellingsrol gemaakt door middel van de UI voor de systeembeheerder (zie ...) genaamd "ENGINEERING_STUDENT"

Minimale vereisten voor datafeeds

EXTERNAL_PERSON_KEY
ROLE_ID

Oplossing

Maak een Institutional_Role-feed met de records die je wilt maken/bijwerken.

Net als bij andere gegevensobjecten kun je ook de ROW_STATUS opgeven om de PERSON-toegang in of uit te schakelen voor de inhoud die gekoppeld is aan de secundaire rol. Bijvoorbeeld:

Voorwaarde achteraf

STORE

Alleen de rolrecords van de secundaire instelling voor aanderson_test, bbrown_test, gcarlin_test en d worden gemaakt of bijgewerkt met de rol van secundaire instelling.

COMPLETE REFRESH

De rolrecords van de secundaire instelling voor aanderson_test, bbrown_test, gcarlin_test en d worden gemaakt of bijgewerkt; Alle andere records worden uitgeschakeld of gemarkeerd voor verwijdering vanwege hun afwezigheid in de bovenstaande gegevensfeed.

COMPLETE REFRESH BY DATA SOURCE

De rolrecords van de secundaire instelling voor aanderson_test, bbrown_test, gcarlin_test en d worden gemaakt of bijgewerkt.

Als andere persoonsrecords worden beheerd door deze integratie, worden ze NIET uitgeschakeld of verwijderd vanwege hun afwezigheid in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben als gespecificeerd door de integratie. COMPLETE REFRESH BY DATA SOURCE werkt alleen voor records van de gegevensbron van de integratie.

Waarnemers

Waarnemers zijn een speciaal User-geval waarbij een account gekoppeld is aan een ander gebruikersaccount voor overzicht of waarneming. De waarnemer kan inloggen en de bijbehorende gebruikerscursussen en activiteiten bekijken.

Een Observer-account vereist dezelfde informatie als een Gebruiker voor het aanmaken van een account en heeft een extra laag van 'User Association Management' waarbij de Observer wordt gekoppeld aan een Gebruikersaccount door de external_person_keys van de twee accounts te koppelen.

Het account van de waarnemer wordt op precies dezelfde manier gemaakt als een gebruikersaccount waarbij je de vereisten voor gegevensverwerking van je instelling moet volgen.

Voorbeeld #1: Waarnemersassociatie maken

Je wilt een student koppelen aan het account van hun ouders (of een andere geschikte gebruiker) zodat de activiteit kan worden waargenomen.

Voorwaarde

U hebt een Student gemaakt die wordt geïdentificeerd door een external_person_key (test_student_100 in dit voorbeeld) en een waarnemer die wordt geïdentificeerd door een external_person_key (test_student_100_observer en test_student_200_observer in dit voorbeeld).

Minimale gegevensvereisten

Het external_person_key van de waarnemer: EXTERNAL_OBSERVER_KEY

Waargenomen external_person_key van de Student: EXTERNAL_USER_KEY

Oplossing

Maak een gegevensbestand met de external_person_key van de waarnemer en de external_person_key van de student.

Gebruik de UI om dit bestand te uploaden via het gegevenstype van de waarnemerskoppeling met behulp van de Store-taak. De koppeling wordt gemaakt en je kunt je aanmelden als waarnemer om de cursusactiviteit van de student te bekijken.

Voorbeeld #2: Een record van een waarnemersvereniging bijwerken

Je moet een koppeling wijzigen.

Voorwaarde

Je hebt een koppeling gemaakt tussen test_student_200_observer en test_student_100, maar het gekoppelde studentenaccount moet test_student_200.

Oplossing

Maak een bestand met de revisie.

Gebruik de gebruikersinterface om dit bestand te uploaden via het gegevenstype Observer Association met behulp van de bewerking Opslaan

Voorwaarde achteraf

De koppeling wordt bijgewerkt en je kunt je aanmelden als waarnemer om de cursusactiviteit van de juiste student te bekijken.

Voorbeeld #3: Waarnemersassociatierecords uitschakelen

Je hebt een waarnemerskoppeling niet meer nodig en je wilt deze uitschakelen.

Voorwaarde

Je hebt koppelingen gemaakt tussen studenten en waarnemers.

Oplossing

(Gebruik de gegevens die worden gebruikt in dit voorbeeld)

Je hebt eerder koppelingen gemaakt met de Store-methode en het volgende bestand:

Er bestaan twee feedpatronen om een koppeling van een waarnemer uit te schakelen, afhankelijk van je vereisten:

Een subset van waarnemersassociaties uitschakelen

Om een subset met gegevens uit te schakelen, maak je een koppelingsfeed en upload je deze naar de Delete-taak. Bijvoorbeeld:

Als je de koppeling tussen test_student_100_observer|test_student_100 in de werkende gegevens wilt verwijderen, maak je een invoerbestand met de volgende gegevens en upload je deze met de Delete-taak:

Een subset van waarnemersassociaties uitschakelen tijdens het opslaan van nieuwe/bestaande associaties

Als je een subset met gegevens wilt uitschakelen die ook het bijwerken van bestaande koppelingen of het opslaan van nieuwe koppelingen toestaat, maak je een koppelingsbestand dat bestaande en nieuwe koppelingen bevat, verwijder de bestanden die je wilt uitschakelen en uploaden met de Complete Refresh-taak. Bijvoorbeeld met behulp van de werkset van:

We willen de koppeling test_student_200_observer|test_student_200 uitschakelen, zodat het bestand alleen de koppeling test_student_100_observer|test_student_100 bevat. Als we ook twee nieuwe koppelingen willen toevoegen (die voldoen aan het vereiste dat de gebruikersaccounts zijn gemaakt), moeten we het volgende uploaden:

Voorwaarde achteraf

Het record voor test_student_200_observer|test_student_200 is uitgeschakeld.

Meer informatie