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. Analyses van het informatiesysteem van je instelling en registratievereisten en planning helpen om het niveau van de gegevens te bepalen die nodig zijn om Learn op de juiste manier te vullen waarbij er aan je doelen voor gegevens en de levensduur wordt voldaan.
De voorbeelden zijn gebaseerd op standaardinstellingen van Learn die zichtbaar zijn in de integratieconfiguratie van de UI. Als je deze configuratie-elementen wijzigt, worden de resultaten van het voorbeeld gewijzigd. Uitleg van deze instellingen is beschikbaar in Overzicht van SIS Framework. Het wordt ook aangenomen, indien anders aangegeven, dat de integratie geconfigureerd is om dezelfde gegevensbron te gebruiken voor alle inkomende gegevens.
Gebruikers
Gebruikersgegevens zijn primaire gegevens die beschrijven wie toegang heeft tot Learn, hun rol bij de instelling en hun rol binnen het Learn-systeem. In de context van SIS-gegevens worden USER-objecten worden vaak 'PERSON' genoemd en dit wordt weerspiegeld in bestaande standaarden. Voorafgaand aan veel van deze standaarden gebruikt Learn ‘PERSON’ en ‘USER’ om naar gebruikersrecords te verwijzen 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.
Beheer van Momentopname-bestand
Het SIS Framework ondersteunt gegevensfeeduploads van Momentopname-bestanden via een UI-feedupload en via een set URL's die door het Learn-systeem worden aangeboden.
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.
De voorbeelden gebruiken de Momentopname Framework UI-functie voor het uploaden van invoerbestanden. Voor meer informatie over het automatiseren of het gebruik van opdrachtregel-/ programmatische taken, raadpleeg je Automatisering van Momentopname-bestand.
Gegevens kunnen worden verstrekt aan Learn en daarna 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:
| Bewerking | Beschrijving |
|---|---|
| Opslaan | Je kunt een opgegeven record opslaan of bijwerken per integratieconfiguratie. Wanneer je dit type taak gebruikt, dan worden gegevens die deel uitmaken van het bestand opgeslagen of bijgewerkt (per configuratie-instellingen) voor alle gegevensbronnen die eigendom zijn van de integratie. Bekijk voor gegevenseigendom, gegevensbron en sleutels het Overzicht van SIS Framework. |
| Vernieuwen | Je kunt een record opslaan, bijwerken, of uitschakelen die aanwezig is in de Feed of Learn. Met deze taak worden gegevens opgeslagen of bijgewerkt die deel uitmaken van de gegevensfeed tijdens het uitschakelen van gegevens die niet zijn opgenomen in de gegevensfeed die is gekoppeld aan de integratie in alle gegevensbronnen. |
| Verwijderen | Opgegeven record uitschakelen. Deze taak schakelt per integratie-instellingen de records uit in de gegevensfeed die gekoppeld is aan de integratie in alle gegevensbronnen. |
| Complete Refresh By Data Source | Opgegeven record uitschakelen. Deze taak is geïntroduceerd in SP 12 en voert een volledige vernieuwing uit van gegevens die alleen zijn gekoppeld aan de geconfigureerde gegevensbron voor integratie. Deze taak imiteert de opdrachtregel nauwkeuriger voor het momentopnameproces voor het vernieuwen van gegevens. |
De objecten die zijn gekoppeld aan PERSON-taken zijn:
| Persoon | Store, Complete Refresh, Delete, Complete Refresh By Data Source |
| Secundaire gebruikersrol binnen instelling | Store, Complete Refresh, Delete, Complete Refresh By Data Source |
| Gebruikerskoppeling | Store, Complete Refresh, Delete, Complete Refresh By Data Source |
Voorbeelden van gebruikerskoppeling kun je vinden in de sectie Hiërarchievoorbeeld.
De opgegeven voorbeelden worden weergegeven met behulp van de Momentopname Framework UI-functie voor het uploaden van invoerbestanden. Voor meer informatie over het automatiseren of het gebruik maken van opdrachtregel-/ programmatische taken, raadpleeg je Automatisering van Momentopname-bestand.
Een herinnering over gegevensbronsleutels
Alle gegevensobjecten ondersteunen de mogelijkheid om de gegevensbronsleutel te wijzigen voor de groepering van die gegevensset en kan gebruikt worden om de bijbehorende gegevensbron te wijzigen. Opmerking: dit veld is niet vereist in gegevensfeeds op basis van Framework en tenzij de onderstaande voorbeelden worden vermeld, wordt ervan uitgegaan dat de integratie is geconfigureerd voor het gebruik van één gegevensbron.
In SP 12 bestaat de mogelijkheid om de gegevensbron in de gegevensfeed apart te specificeren van de specificatie van een nieuwe gegevensbron.
Zie Beheer gegevensbronsleutel voor meer informatie.
Een opmerking over veldtoewijzing
Veldtoewijzing biedt de mogelijkheid om inkomende gegevens te wijzigen voordat deze in Learn worden opgeslagen. Op deze manier heb je volledige controle over de opgeslagen gegevens en kun je voldoen aan de specifieke regels voor Learn wanneer de SIS-gegevens die je hebt opgegeven onvoldoende zijn, bijvoorbeeld door het maken van een gebruikerswachtwoord. Wanneer dit wordt toegepast op een veld van het User-object, wordt het bijbehorende script uitgevoerd per gebruiker, door de gegevens te wijzigen of in te leveren voordat het wordt opgeslagen in Learn. Er een volledige uitleg over veldtoewijzing voor momentopname-bestanden gegeven in Veldtoewijzing voor tekstbestanden zonder van Momentopname.
Een opmerking over wachtwoorden
Wachtwoorden zijn vereist om je aan te melden bij Learn, maar zijn geen vereist veld in PERSON-gegevensfeeds. Als er geen wachtwoord in de gegevensfeed wordt opgegeven, wordt er een willekeurig SHA512-wachtwoord gegenereerd en opgeslagen in de Learn-database. Dit is geen probleem als je externe verificatie (zoals LDAP) gebruikt, maar wat gebeurt er als je de Learn-database gebruikt om aanmeldingswachtwoorden 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. Ja en nee, voor een update-taak kun je selecteren dat het wachtwoordveld niet bijgewerkt wordt. Hierdoor kan Learn het huidige wachtwoord behouden bij een update. 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.
- Door één gegevensbestand te gebruiken, kun je records (Store) maken, bijwerken of uitschakelen, waarbij gegevens expliciet worden gewijzigd via gegevens die aanwezig zijn in het bestand.
- Door één gegevensbestand te gebruiken, kun je gegevens vernieuwen - records maken, bijwerken en uitschakelen (Complete Refresh) - waarbij records gewijzigd worden via aanwezigheid (maken/bijwerken) of afwezigheid van gegevens in het bestand.
- Met een combinatie van bestanden kun je met deze opslaan en de Beschikbaarheid instellen of Uitschakelen met een andere.
Tot slot kun je ook, en dit is niet een SIS-invoerpatroon maar wel noemenswaardig, uitschakelen en verwijderen op basis van alleen gegevensbronsleutels waarbij er gebruik wordt gemaakt van de Gegevensbronbeheertool die beschikbaar is in de UI. Je moet uiterst zorgvuldig zijn met de SIS-gegevens die je op deze manier verkrijgt. Dit is erg handig bij het opschonen van gegevens die nooit werden of niet meer worden aangeboden via het SIS zoals gegevens die het resultaat zijn van de uitvoering van testen.
Alleen de basis: Person’s
Voor alle gebruikersaccounts is een basisset van informatie vereist om een account op te kunnen stellen. Deze informatie wordt beschreven in Gegevensindeling van Momentopname-bestand en Header van Momentopname-bestand.
Als je momenteel de UI-batchtools gebruikt om te schakelen naar SIS Framework en de minimale gebruikersgegevens en de UI-uploadfuncties van het SIS Framework, bieden we een betere logboekregistratie en rapportage van je gegevensuploads zonder je processen voor gegevensverzameling aan te passen.
Gegevens in het kort
De minimale gegevensset of headers die vereist zijn voor het maken van een gebruikersaccount in Learn bestaat uit:
- EXTERNAL_PERSON_KEY - een unieke ID voor deze gebruikersrecord.
- DATA_SOURCE_KEY - een unieke ID voor de gegevensset van deze record. Opmerking: dit wordt aangeboden in de feed of via de integratieconfiguratie)
- USER_ID - De gebruikers-ID, dit wordt gebruikt als de gebruikersnaam bij de aanmelding en moet gekoppeld worden met de LDAP CN, NET ID of ander extern ID van de gebruiker als je externe verificatie gebruikt.
- FIRST_NAME - De voornaam van de gebruiker
- LAST_NAME - De achternaam van de gebruiker
- PASSWD - Het wachtwoord voor deze gebruiker
Voor een voorbeeld van het dynamisch toekennen van een wachtwoord als je er geen kunt opgeven in de gegevensfeed, raadpleeg je Veldtoewijzing voor tekstbestanden zonder opmaak van Momentopname.
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. EMAIL is vereist voor communicatie en het bieden van e-mailmeldingen aan Learn-gebruikers via Learn-e-mail. Het is daarom raadzaam om deze gegevens in je feed op te geven. SYSTEM_ROLE wordt standaard ingesteld op de geconfigureerde instelling NONE.
Elk van deze headers wordt volledig beschreven in Gegevensindeling van Momentopname-bestand.
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 de PERSON-informatie te vernieuwen die al is in Learn, waardoor nieuwe of bestaande records worden toegevoegd zoals weergegeven in het gegevensbestand. Bestaande records worden uitgeschakeld die niet aanwezig zijn in het gegevensbestand.
Voorbeelden store-taak
Voorbeeld nr. 1: Person-accounts maken
Je wilt gebruikers toevoegen aan Blackboard Learn zonder dat dit gevolgen heeft voor bestaande accounts. Je hebt de integratie geconfigureerd om dezelfde gegevensbron voor alle inkomende gegevens te gebruiken.
Vereiste
Geen.
Minimale vereisten voor gegevensfeed
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:
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME
testPerson1|aanderson_test|changeme|Alpha|Anderson
testPerson2|bbrown_test|changeme|Beta|Brown
testPerson3|gcarlin_test|changeme|Gamma|Carlin
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
PERSON-records voor aanderson_test, bbrown_test, and ccarlin_test worden gemaakt.
Voorbeeld nr. 2: Gebruikersaccounts bijwerken
Je hebt gebruikersaccounts gemaakt en je moet deze wijzigen. Het vorige voorbeeld bevat bijvoorbeeld geen e-mailadressen van gebruikers. Je hebt het e-mailadres voor aanderson_test.
Vereiste
Geen: updates worden uitgevoerd op eerder gemaakte records. Als bij gegevens een record wordt opgenomen die niet in Learn bestaan dan wordt er een record 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:
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME|EMAIL
testPerson1|aanderson_test|changeme|...owhere.erehwon
Aangezien STORE alleen werkt met de gegevens in het bestand heeft dit geen invloed op de records bbrown_test en ccarlin_test die eerder zijn verzonden.
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
De PERSON-record voor aanderson_test wordt bijgewerkt met het opgegeven e-mailadres.
De PERSON-record voor bbrown_test en ccarlin_test wordt niet beïnvloed.
Person: Complete refresh-taak
COMPLETE REFRESH werkt anders dan STORE. Met COMPLETE REFRESH worden twee taken uitgevoerd die een vergelijking hebben tussen de gegevens in het invoerbestand en de records in LEARN die eigendom zijn van de integratie: opslaan van nieuwe records, bijwerken van bestaande records of het uitschakelen van records in LEARN die niet in het gegevensbestand staan.
Voorbeeld: Complete refresh
De gegevens die je SIS geeft, bevatten een volledige momentopname van de PERSON's die toegang moeten hebben tot LEARN. Deze gegevens bevatten PERSON-records om toe te voegen, PERSON-records om bij te werken en records die verwijderd zijn sinds de vorige uitvoering van COMPLETE REFRESH die op de juiste manier afgehandeld zou moeten zijn per configuratie (uitschakelen of verwijderen).
Vereiste
Geen.
Minimale vereisten voor gegevensfeed
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 gcarlin_test verwijderen uit de gegevensfeed:
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME
testPerson1|aanderson_test|changeme|Alpha|Anderson
testPerson2|bbrown_test|changeme|Beta|Brown
Als andere PERSON-records beheerd worden door deze integratie dan zullen deze uitgeschakeld of verwijderd worden omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed.
Voorwaarde achteraf
De PERSON-record voor aanderson_test wordt behouden en niet beïnvloed.
De PERSON-record voor bbrown_test wordt behouden en bijgewerkt met de e-mailadres
De PERSON-record voor ccarlin_test wordt gemarkeerd als uitgeschakeld of klaar voor verwijdering per integratieconfiguratie.
Person: Complete refresh by data source-taak
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: Complete refresh by data source
De gegevens die je SIS geeft, bevatten een volledige momentopname van de PERSON's die toegang moeten hebben tot LEARN. Deze gegevens bevatten PERSON-records om toe te voegen, PERSON-records om bij te werken en records die verwijderd zijn sinds de vorige uitvoering van REFRESH die op de juiste manier afgehandeld zou moeten zijn per configuratie (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.
Vereiste
Geen.
Minimale vereisten voor gegevensfeed
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:
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|firstname|lastname
testPerson1|aanderson_test|changeme|Alpha|Anderson
testPerson2|bbrown_test|changeme|Beta|Brown
Voorwaarde achteraf
De PERSON-record voor aanderson_test wordt behouden en niet beïnvloed.
De PERSON-record voor bbrown_test wordt behouden en bijgewerkt met de e-mailadres
De eerder gemaakte PERSON-record voor ccarlin_test wordt gemarkeerd als uitgeschakeld of klaar voor verwijdering per integratieconfiguratie.
Als andere PERSON-records beheerd worden door deze integratie dan worden ze NIET uitgeschakeld of verwijderd omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben zoals opgegeven door de integratie.
Beschikbaarheid Person-account
De instelling voor de beschikbaarheid van een PERSON-account zorgt ervoor dat een account in LEARN kan aanmelden (beschikbaar) of niet aanmelden (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.
De standaardinstellingen voor integratie wanneer een AVAILABILITY-instelling niet geleverd is voor het object dat beschikbaar gemaakt moet worden voor de taken maken/bijwerken.
Voorbeeld: Beschikbaarheid Person-account
Je SIS beheert de beschikbaarheid van toegang tot LEARN voor gebruikers en je gegevensfeed geeft aan of gebruikers individueel toegang hebben tot Learn. Je wilt de toegang van individuele gebruikers wijzigen door het maken/bijwerken van PERSON.
Vereiste
Geen.
Minimale vereisten voor gegevensfeed
EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
AVAILABILITY_IND
Oplossing
Voeg de AVAILABLE_IND-header toe aan je gegevensfeeds en geef het teken Y op voor beschikbaar en N voor niet-beschikbaar.
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME|AVAILABLE_IND
testPerson1|aanderson_test|changeme|Alpha|Anderson|Y
testPerson2|bbrown_test|changeme|Beta|Brown|Y
testPerson3|gcarlin_test|changeme|Gamma|Carlin|N
testPerson4|ddarling_test|changeme|Delta|Darling|Y
Voorwaarde achteraf
STORE
Alleen de PERSON-records voor aanderson_test, bbrown_test en ccarlin_test worden bijgewerkt (ze zijn eerder gemaakt) en ddarling_test wordt gemaakt.
COMPLETE REFRESH
De PERSON-records voor aanderson_test, bbrown_test en ccarlin_test worden bijgewerkt (ze zijn eerder gemaakt) en ddarling_test wordt gemaakt. Alle andere records worden uitgeschakeld of gemarkeerd om verwijderd te worden omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed.
COMPLETE REFRESH BY DATA SOURCE
De PERSON-records voor aanderson_test, bbrown_test en ccarlin_test worden bijgewerkt (ze zijn eerder gemaakt) en ddarling_test wordt gemaakt.
Als andere PERSON-records beheerd worden door deze integratie dan worden ze NIET uitgeschakeld of verwijderd omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben zoals opgegeven door de integratie. COMPLETE REFRESH BY DATA SOURCE werkt alleen voor records van de gegevensbron van de integratie.
Person-records uitschakelen
Als je een PERSON-record in Learn uitschakelt, dan is deze niet meer toegankelijk voor aanmeldingen (de status uitgeschakeld vervangt de beschikbaarheidsinstelling) en de record is ook niet meer toegankelijk voor UI-taken.. Het is bijvoorbeeld niet mogelijk om een uitgeschakelde PERSON toe te voegen aan een cursus via de UI. Als je daarnaast een record uit Learn verwijdert, moet de record eerst uitgeschakeld worden.
Door het uitschakelen van een record en de daarop volgende verwijdering, worden alle referenties van de record uit Learn verwijderd. Blackboard beveelt aan dat het verwijderen of uitschakelen van records alleen plaats mag vinden na een bepaalde tijdsperiode zoals bepaald door je bedrijf en/of juridische praktijken waarvan een record met activiteiten wordt vereist.
Het uitschakelen van records kan twee modellen volgen: Uitschakelen via de uitsluiting van invoergegevens bij REFRESH-taken en Uitschakelen door middel 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: Person-records uitschakelen
Studenten schrijven zich in of hebben geen toegang meer nodig tot Learn. Je moet de toegang tot en de aanwezigheid in Learn expliciet verwijderen (in tegenstelling tot het niet-beschikbaar maken van de record waardoor alleen aanmeldingen worden 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.
Vereiste
Er bestaan gerichte records binnen het Learn-systeem.
Minimale vereisten voor gegevensfeed
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.
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME|ROW_STATUS
testPerson1|aanderson_test|changeme|Alpha|Anderson|enabled
testPerson2|bbrown_test|changeme|Beta|Brown|enabled
testPerson3|gcarlin_test|changeme|Gamma|Carlin|disabled
testPerson4|ddarling_test|changeme|Delta|Darling|enabled
Voorwaarde achteraf
STORE
Alleen de PERSON-records voor aanderson_test, bbrown_test, ccarlin_test en ddarling_test worden gemaakt of bijgewerkt waarbij de ROW_STATUS expliciet wordt bijgewerkt.
COMPLETE REFRESH
De PERSON-records voor aanderson_test, bbrown_test, ccarlin_test, en ddarling_test worden gemaakt of bijgewerkt. Alle andere records worden uitgeschakeld of gemarkeerd om verwijderd te worden omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed.
COMPLETE REFRESH BY DATA SOURCE
De PERSON-records voor aanderson_test, bbrown_test en ccarlin_test worden bijgewerkt (ze zijn eerder gemaakt) en ddarling_test wordt gemaakt.
Als andere PERSON-records beheerd worden door deze integratie dan worden ze NIET uitgeschakeld of verwijderd omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben zoals opgegeven door de integratie. COMPLETE REFRESH BY DATA SOURCE werkt alleen voor records van de gegevensbron van de integratie.
COMPLETE REFRESH BY DATA SOURCE
De PERSON-records voor aanderson_test, bbrown_test, ccarlin_test en ddarling_test worden gemaakt of bijgewerkt waarbij de ROW_STATUS expliciet wordt bijgewerkt.
Als andere PERSON-records beheerd worden door deze integratie dan worden ze NIET uitgeschakeld of verwijderd omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben zoals opgegeven 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: Toevoegen van secundaire gebruikersrol binnen instelling
Je moet Portal-inhoud aanbieden die specifiek is voor studenten en de Faculty of the School of Engineering.
Vereiste
Je hebt een nieuwe instellingsrol gemaakt door middel van de UI voor de systeembeheerder (zie ...) genaamd "ENGINEERING_STUDENT"
Minimale vereisten voor gegevensfeed
EXTERNAL_PERSON_KEY
ROLE_ID
Oplossing
Maak een Institutional_Role-feed met de records die je wilt maken/bijwerken.
EXTERNAL_PERSON_KEY|ROLE_ID
testPerson1|engineering_student
testPerson2|engineering_faculty
testPerson3|engineering_faculty
testPerson4|engineering_student
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:
EXTERNAL_PERSON_KEY|ROLE_ID|ROW_STATUS
testPerson1|engineering_student|enabled
testPerson2|engineering_faculty|enabled
testPerson3|engineering_student|disabled
Voorwaarde achteraf
STORE
Alleen de records van de secundaire instellingsrol voor aanderson_test, bbrown_test, ccarlin_test en dworden gemaakt of bijgewerkt met de secundaire instellingsrol.
COMPLETE REFRESH
De records van de secundaire instellingsrol voor aanderson_test, bbrown_test, ccarlin_test en d worden gemaakt of bijgewerkt. Alle andere records worden uitgeschakeld of gemarkeerd om verwijderd te worden omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed.
COMPLETE REFRESH BY DATA SOURCE
De records van de secundaire instellingsrol voor aanderson_test, bbrown_test, ccarlin_test en dworden gemaakt of bijgewerkt.
Als andere PERSON-records beheerd worden door deze integratie dan worden ze NIET uitgeschakeld of verwijderd omdat ze niet aanwezig zijn in de bovenstaande gegevensfeed, tenzij ze dezelfde gegevensbron hebben zoals opgegeven 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 waarnemersaccount heeft dezelfde informatie nodig als een User voor het aanmaken van een account en heeft een extra laag voor ‘Gebruikerskoppelingbeheer’, waarbij de waarnemer 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 nr. 1: Waarnemerskoppeling maken
Je wilt een student koppelen aan het account van hun ouders (of een andere geschikte gebruiker) zodat de activiteit kan worden waargenomen.
Vereiste
Je hebt een student-ID gemaakt door een external_person_key (test_student_100 in dit voorbeeld) en een waarnemers-ID door een external_person_key (test_student_100_observer en test_student_200_observer in dit voorbeeld).
Minimale gegevensvereisten
De external_person_key van de waarnemer: EXTERNAL_OBSERVER_KEY
De external_person_key van de waargenomen student: EXTERNAL_USER_KEY
Oplossing
Maak een gegevensbestand met de external_person_key van de waarnemer en de external_person_key van de student.
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_100
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 nr. 2: Record van een waarnemerskoppeling bijwerken
Je moet een koppeling wijzigen.
Vereiste
Je hebt een koppeling gemaakt tussen test_student_200_observer en test_student_100, maar het gekoppelde studentaccount moet test_student_200 zijn.
Oplossing
Maak een bestand met de revisie.
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_200_observer|test_student_200
Gebruik de UI om dit bestand te uploaden via het gegevenstype van de waarnemerskoppeling met behulp van de Store-taak.
Voorwaarde achteraf
De koppeling wordt bijgewerkt en je kunt je aanmelden als waarnemer om de cursusactiviteit van de juiste student te bekijken.
Voorbeeld nr. 3: Record van een waarnemerskoppeling uitschakelen
Je hebt een waarnemerskoppeling niet meer nodig en je wilt deze uitschakelen.
Vereiste
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:
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_200
Er bestaan twee feedpatronen om een koppeling van een waarnemer uit te schakelen, afhankelijk van je vereisten:
- Je wilt een subset uitschakelen van een waarnemerskoppeling die gekoppeld is aan de huidige integratie/gegevensbron.
- Je wilt een subset van een waarnemerskoppeling uitschakelen tijdens het opslaan of bijwerken van extra records.
Een subset van waarnemerskoppelingen 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:
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_200_observer|test_student_200
Een subset van waarnemerskoppelingen uitschakelen tijdens het opslaan van nieuwe/bestaande koppelingen
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:
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_200
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:
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_300_observer|test_student_300
test_student_400_observer|test_student_400
Voorwaarde achteraf
De record voor test_student_200_observer|test_student_200 is uitgeschakeld.
Meer informatie
Header-beschrijvingen van Momentopname-bestand
