Les exemples suivants illustrent la composition des flux de données utilisateur (PERSON) et correspondent à un grand nombre de cas d'utilisation. Ces exemples utilisent le flux de données le plus simple possible. Dans certains cas, des informations supplémentaires peuvent être exigées par votre établissement : l'ajout des en-têtes et des données requis au flux de données permet de satisfaire à ces besoins. Une analyse des exigences de votre établissement en matière de système d'informations et de registres et une planification permettent de déterminer la profondeur des données nécessaires pour alimenter correctement Learn afin de répondre à vos objectifs de données et du cycle de vie.

Les exemples sont basés sur les paramètres par défaut de Learn qui sont visibles dans l'interface utilisateur de configuration de l'intégration. La modification de ces éléments de configuration entraînera la modification des résultats de l'exemple. Les explications de ces paramètres sont disponibles dans la Présentation du cadre SIS. Par ailleurs, il est supposé, sauf indication contraire, que l'intégration est configurée pour utiliser la même source de données pour toutes les données entrantes.

Utilisateurs

Les données utilisateur sont l'ensemble d'informations principal qui décrit qui a accès à learn, leur rôle dans votre établissement et leur rôle dans le système Learn. Dans le contexte des objets USER de données SIS, on parle souvent de « PERSON », ce qui se répercute dans les normes existantes. Étant antérieur à ces nombreuses normes, le fichier plat d'instantané Learn utilise « PERSON » et « USER » pour faire référence aux enregistrements liés aux utilisateurs en fonction du contexte. Les exemples suivants utilisent « PERSON » pour faire référence à l'enregistrement et « USER » pour faire référence à la personne.

Gestion des données de fichiers plats d'instantané

Le cadre SIS prend en charge les téléchargements de flux de données de fichier plat d'instantané via un téléchargement d'interface utilisateur et via un ensemble d'URL fourni par le système Learn.

Accédez aux informations HTTP et téléchargez le fichier de flux à l'aide du menu d'intégration de l'interface utilisateur d'intégration des systèmes d'informations sur les étudiants de l'intégration de données d'administrateur système.

Dans les deux cas, le comportement de l'opération de données est piloté par la configuration de l'intégration et le type d'opération sélectionné. Le type d'opération de données sélectionné contrôle la façon dont les données du flux sont « interprétées » et chaque URL fournira des résultats différents pour répondre aux objectifs de votre intégration.

Les exemples utilisent la fonctionnalité de chargement du fichier de source de données de l'interface utilisateur du cadre d'instantané. Pour en savoir plus sur l'automatisation ou l'utilisation d'autres opérations de programmation/ligne de commande, reportez-vous à Automatisation de fichier plat d'instantané.

Les données peuvent être fournies à Learn avant d'être ensuite mises à jour, supprimées ou modifiées. Par conséquent, vous pouvez commencer avec l'ensemble de données le plus simple et l'enrichir à mesure que les exigences en matière de données de votre établissement évoluent.

Les opérations suivantes sont disponibles via l'interface utilisateur et HTTP.

Opération Description
Stocker Stocke ou met à jour l'enregistrement fourni conformément à la configuration d'intégration. Lors de l'utilisation de ce type d'opération, les données contenues dans le fichier source sont stockées ou mises à jour (selon les paramètres de configuration) dans toutes les sources de données qui sont détenues par l'intégration. Pour la « propriété » des données, la source de données et les clés des données, reportez-vous à la Présentation du cadre SIS.
Actualiser Stocke, met à jour ou désactive la présence d'un enregistrement fourni dans le flux et Learn. Cette opération permet de stocker ou de mettre à jour les données contenues dans le flux de données, tout en désactivant les données qui ne figurent pas dans le flux de données associé à l'intégration dans toutes les sources de données.
Supprimer Désactive un enregistrement fourni. Cette opération désactive, selon les paramètres d'intégration, les enregistrements contenus dans le flux de données associé à l'intégration dans toutes les sources de données.
Actualisation complète par source de données Désactive un enregistrement fourni. Introduite dans SP12, cette opération effectue une actualisation complète des données associées UNIQUEMENT à la source de données d'intégration configurée. Cette opération émule plus étroitement le processus d'instantané de ligne de commande pour l'actualisation des données.

Les objets associés aux opérations PERSON sont les suivants :

Personne Store, Complete Refresh, Delete, Complete Refresh By Data Source
Rôle secondaire de l'utilisateur dans l'établissement Store, Complete Refresh, Delete, Complete Refresh By Data Source
Association d'utilisateurs Store, Complete Refresh, Delete, Complete Refresh By Data Source

Les exemples d'association d'utilisateurs peuvent être trouvés dans la section Exemple de hiérarchie.

Les exemples fournis sont illustrés à l'aide de la fonctionnalité de chargement du fichier de source de données de l'interface utilisateur du cadre d'instantané. Pour en savoir plus sur l'automatisation ou l'utilisation d'autres opérations de programmation/ligne de commande, reportez-vous à Automatisation de fichier plat d'instantané.

Rappel concernant les clés de source de données

Tous les objets de données prennent en charge la fonctionnalité de modification de la clé de source de données pour le regroupement de l'ensemble de données et peuvent être utilisés pour modifier la source de données associée. Remarque : Ce champ n'est pas obligatoire dans les sources de données basées sur le cadre et sauf indication contraire dans les exemples ci-dessous, l'intégration est configurée pour utiliser une source de données unique.

Dans SP 12, a été introduite une fonctionnalité permettant de spécifier la source de données dans le flux de données séparément de la spécification d'une nouvelle source de données.

Pour en savoir plus, reportez-vous à Gestion des clés de source de données.

Remarque sur le mappage de champ

Le mappage de champ offre la possibilité de modifier les données entrantes avant de les stocker dans Learn. Cela vous permet d'avoir un contrôle total sur les données stockées et de respecter les règles de Learn spécifiques lorsque les données SIS que vous fournissez sont insuffisantes, par exemple pour la création de mots de passe utilisateur. Lorsqu'il est appliqué à un champ d'objet User, le script associé est exécuté par utilisateur, en modifiant ou en fournissant les données avant qu'elles ne soient stockées dans Learn. Une explication complète du mappage des champs du fichier plat d'instantané est fournie dans Mappage de champs du fichier plat d'instantané.

Remarque sur les mots de passe

Les mots de passe sont requis pour se connecter à Learn, mais ne constituent pas un champ obligatoire dans les flux de données PERSON. Si un mot de passe n'est pas fourni dans le flux de données, un mot de passe SHA512 aléatoire est généré et stocké dans la base de données Learn. Cela ne pose pas de problème si vous utilisez l'authentification externe (par exemple, LDAP), mais que se passe-t-il si vous utilisez la base de données Learn pour stocker des mots de passe de connexion utilisateur ? Vous devez fournir le mot de passe lors de la création de l'utilisateur, car sinon il ne pourra pas se connecter.

Si vous exécutez un flux et définissez le mot de passe d'un utilisateur qui change de mot de passe par la suite, la connexion est rompue. Oui et non : sur une opération de mise à jour, vous pouvez choisir de ne pas mettre à jour le champ mot de passe. Cela permettra à Learn de conserver le mot de passe actuel lors de la mise à jour. Si vous ne sélectionnez pas cette option, le mot de passe sera modifié et l'utilisateur devra être averti de la modification.


Exemples d'opération de personne

À un niveau avancé, vous pouvez appliquez les trois modèles de flux de données d'intégration SIS à toutes les opérations de données User et la sélection du modèle dépend des données que vous pouvez fournir.

  • À l'aide d'un seul fichier source, vous pouvez créer ou mettre à jour ou désactiver des enregistrements (store), ce qui modifie explicitement les enregistrements selon les données présentes dans le fichier.
  • À l'aide d'un fichier source unique, vous pouvez actualiser les données, créer ou mettre à jour, et désactiver (Complete Refresh) les enregistrements, ce qui modifie les enregistrements selon la présence (create/update) ou l'absence de données dans le fichier.
  • À l'aide d'une combinaison de fichiers que vous pouvez stocker (Store) avec un, et définir la disponibilité (Availability) ou désactiver (Disable) avec un autre.

Enfin, il ne s'agit pas d'un modèle de flux de données SIS, mais cela doit être mentionné, vous pouvez également désactiver et purger à partir de DSK seul à l'aide de l'outil gestion des sources de données disponible dans l'interface utilisateur. Vous devez être très prudent lorsque vous gérez vos données SIS fournies de cette manière. Cette option est particulièrement utile lors de la purge des données qui n'ont pas été ou ne sont plus fournies via le SIS comme les données résultant des opérations de test.

Notions de base : Personnes

Tous les comptes utilisateur nécessitent un ensemble d'informations de base pour établir un compte. Cet ensemble d'informations est détaillé dans Format de données de fichier plat d'instantané et En-têtes de fichier plat d'instantané.

Si vous utilisez actuellement les outils batch de l'interface utilisateur, passer au cadre SIS et à l'utilisation des données d'utilisateur minimales et des fonctionnalités de téléchargement d'interface utilisateur du cadre SIS vous permet de mieux consigner et rendre compte de vos données téléchargées sans modifier vos processus de collecte de données.

Données en bref

Les ensembles de données et en-têtes requis au minimum pour créer un compte utilisateur dans Learn comprennent les éléments suivants :

  • EXTERNAL_PERSON_KEY : identificateur unique pour l'enregistrement d'utilisateur.
  • DATA_SOURCE_KEY : identificateur unique pour les données définies dans cet enregistrement. Remarque : cette valeur est fournie dans le flux ou via la configuration d'intégration.)
  • USER_ID : code de l'utilisateur, utilisé pour la connexion en tant que nom d'utilisateur et devant être associé au CN LDAP, au NET ID ou à un autre identificateur externe de l'utilisateur, si vous utilisez l'authentification externe.
  • FIRST_NAME : prénom de l'utilisateur
  • LAST_NAME : nom de l'utilisateur
  • PASSWD : mot de passe de l'utilisateur
    Pour obtenir un exemple d'affectation dynamique d'un mot de passe si vous ne pouvez pas en fournir un dans le flux de données, reportez-vous à Mappage de champs personnalisés de fichier plat d'instantané.

Le cadre SIS, selon la configuration d'intégration, fournit des valeurs par défaut pour les champs non obligatoires ou les ignore. Les champs EMAIL et SYSTEM_ROLE ne sont pas obligatoires, mais utiles pour les flux de PERSON. EMAIL est requis pour la correspondance et les notifications par e-mail aux utilisateurs de Learn via la messagerie électronique Learn. Vous devez donc envisager de fournir ces données dans votre flux. SYSTEM_ROLE est par défaut configuré sur NONE (aucun).

Chacun de ces en-têtes est décrit plus en détail dans les Descriptions des en-têtes de fichier plat d'instantané.

Ajout d'informations de personne

Il existe deux cas d'ajout d'informations sur la personne. La première consiste à stocker (STORE) des informations de personne (PERSON) de manière additive, ce qui entraîne l'ajout ou la mise à jour d'enregistrements, comme indiqué dans le flux de données. La seconde consiste à actualiser (REFRESH) des informations de personne (PERSON) déjà présentes dans Learn, ce qui entraîne l'ajout ou la mise à jour d'enregistrements, comme indiqué dans le fichier de données lors de la désactivation des enregistrements existants qui ne sont pas présents dans le fichier de données.

Exemples d'opération de stockage

Exemple 1 : création de comptes de personne

Vous souhaitez ajouter des utilisateurs à Blackboard Learn sans que celai ait d'incidence sur les comptes existants. Votre intégration est configurée pour utiliser la même source de données pour toutes les données entrantes.

Pré-requis

aucun.

Exigences minimales de flux de données

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME

Solution

Créez un fichier de données PERSONS.txt contenant les en-têtes requis et les données associées par personne que vous souhaitez ajouter au système. Par exemple :

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

Utilisez l'interface utilisateur pour télécharger ce fichier via le type de données PERSON à l'aide de l'opération STORE. Le compte utilisateur sera créé et vous pourrez vous connecter en tant qu'utilisateur.

Postcondition

Les enregistrements PERSON pour aanderson_test, bbrown_test, and ccarlin_test sont créés.

Exemple 2 : mise à jour des comptes utilisateur

Vous avez créé des comptes d'utilisateur et devez les modifier. Par exemple, l'exemple précédent n'incluait aucune adresse e-mail d'utilisateur. Vous avez l'adresse e-mail de aanderson_test.

Pré-requis

Aucun. Les mises à jour n'ont pas lieu sur les enregistrements créés précédemment, les données incluses dans un enregistrement qui n'existe pas dans Learn entraînent la création de l'enregistrement.

Solution

Créez un fichier de données PERSONS.txt contenant les en-têtes requis et les données associées par personne que vous souhaitez ajouter au système. Par exemple :

EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME|EMAIL
testPerson1|aanderson_test|changeme|...owhere.erehwon

Étant donné que STORE n'est appliqué que sur les données contenues dans le fichier, les enregistrements bbrown_test et ccarlin_test précédemment validés ne sont pas affectés.

Utilisez l'interface utilisateur pour télécharger ce fichier via le type de données PERSON à l'aide de l'opération STORE. Le compte utilisateur sera mis à jour.

Postcondition

L'enregistrement PERSON pour aanderson_test est mis à jour pour inclure l'adresse e-mail fournie.

Les enregistrements PERSON pour bbrown_test et ccarlin_test ne sont pas affectés.

Personne : Opération d'actualisation complète

COMPLETE REFRESH ne fonctionne pas de la même manière que STORE. COMPLETE REFRESH effectue deux opérations qui correspondent à une comparaison des données dans le fichier source et des enregistrements de LEARN détenues par l'intégration : stockage de nouveaux enregistrements, mise à jour d'enregistrements existants ou désactivation d'enregistrements dans LEARN qui ne sont pas dans le fichier de données.

Exemple : actualisation complète

Les données que votre SIS fournit contiennent un instantané complet des enregistrements PERSON qui doivent exister dans Learn. Ces données contiennent les enregistrements PERSON à ajouter, les enregistrements PERSON à mettre à jour et les enregistrements qui ont été supprimés depuis les opérations COMPLETE REFRESH précédentes, qui sont traités conformément à la configuration (désactivés ou purgés).

Pré-requis

aucun.

Exigences minimales de flux de données

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME

Solution

Utilisation des données de notre dernière opération de stockage et suppression de gcarlin_test du flux de données :

EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME
testPerson1|aanderson_test|changeme|Alpha|Anderson
testPerson2|bbrown_test|changeme|Beta|Brown

Notez que si d'autres enregistrements PERSON sont gérés par cette intégration, ils seront désactivés ou purgés en raison de leur absence du flux de données ci-dessus.

Postcondition

L'enregistrement PERSON pour aanderson_test est conservé et n'est pas affecté.

L'enregistrement PERSON pour bbrown_test est conservé et mis à jour pour inclure l'adresse e-mail fournie.

L'enregistrement PERSON pour ccarlin_test est marqué comme étant désactivé ou prêt pour la purge selon la configuration d'intégration.

Personne : Actualisation complète par source de données

L'opération d'actualisation complète par source de données (COMPLETE REFRESH BY DATA SOURCE) effectue une opération COMPLETE REFRESH mais restreint les données affectées uniquement à ce qui est associé à la source de données de l'intégration.

Exemple : actualisation complète par source de données

Les données que votre SIS fournit contiennent un instantané complet des enregistrements PERSON qui doivent exister dans Learn. Ces données contiennent les enregistrements PERSON à ajouter, les enregistrements PERSON à mettre à jour et les enregistrements qui ont été supprimés depuis les opérations REFRESH précédentes, qui sont traités conformément à la configuration (désactivés ou purgés). En outre, toutes les données de cette actualisation sont ciblées à l'aide de la même source de données que celle définie dans l'intégration et SEULES les données liées à cette clé de source de données seront affectées.

Pré-requis

aucun.

Exigences minimales de flux de données

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME

Solution

Utilisation des données de notre dernière opération de stockage et suppression de gcarlin_test du flux de données :

EXTERNAL_PERSON_KEY|USER_ID|PASSWD|firstname|lastname
testPerson1|aanderson_test|changeme|Alpha|Anderson
testPerson2|bbrown_test|changeme|Beta|Brown

Postcondition

L'enregistrement PERSON pour aanderson_test est conservé et n'est pas affecté.

L'enregistrement PERSON pour bbrown_test est conservé et mis à jour pour inclure l'adresse e-mail fournie.

L'enregistrement PERSON précédemment créé pour ccarlin_test est marqué comme étant désactivé ou prêt pour la purge selon la configuration d'intégration.

Si d'autres enregistrements PERSON sont gérés par cette intégration, ils ne seront PAS désactivés ou purgés en raison de leur absence du flux de données ci-dessus, à moins qu'ils n'aient la même source de données que celle spécifiée par l'intégration.

disponibilité du compte de personne

Le paramètre disponibilité du compte PERSON permet à un compte dans LEARN de se connecter (disponible) ou non (non disponible). Notez que ce n'est pas la même chose que de désactiver un compte, ce qui rend non seulement le compte invisible, mais le rend également indisponible pour d'autres opérations telles que la gestion des adhésions. L'ajout de cet en-tête de flux des données n'a pas d'impact sur l'utilisation des opérations STORE, COMPLETE REFRESH, COMPLETE REFRESH BY DATA SOURCE décrite ci-dessus pour la création des enregistrements PERSON.

Par défaut, lorsque le paramètre AVAILABILITY (disponibilité) n'est pas configuré, l'intégration met à disposition l'objet lors des opérations de création/mise à jour.

Exemple : disponibilité du compte de personne

Votre SIS contrôle la disponibilité de l'accès à LEARN pour les utilisateurs, et votre flux de données indique si chaque utilisateur peut accéder à Learn. L'accès de chaque utilisateur peut être modifié à l'aide du paramètre de création/mise à jour de l'objet PERSON.

Pré-requis

aucun.

Exigences minimales de flux de données

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
AVAILABILITY_IND

Solution

Ajoutez l'en-tête AVAILABLE_IND à votre flux de données et spécifiez le caractère unique Y pour disponible et N pour non disponible.

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

Postcondition

STORE (STOCKER)

Seuls les enregistrements PERSON pour aanderson_test, bbrown_test, et ccarlin_test sont mis à jour (ils ont été créés précédemment) et ddarling_test est créé.

COMPLETE REFRESH (actualisation complète)

Les enregistrements PERSON pour aanderson_test, bbrown_test, et ccarlin_test sont mis à jour (ils ont été créés précédemment) et ddarling_test est créé. Tous les autres enregistrements seront désactivés ou marqués pour être purgés en raison de leur absence du flux de données ci-dessus.

COMPLETE REFRESH BY DATA SOURCE (actualisation complète par source de données)

Les enregistrements PERSON pour aanderson_test, bbrown_test, et ccarlin_test sont mis à jour (ils ont été créés précédemment) et ddarling_test est créé.

Si d'autres enregistrements PERSON sont gérés par cette intégration, ils ne seront PAS désactivés ou purgés en raison de leur absence du flux de données ci-dessus, à moins qu'ils n'aient la même source de données que celle spécifiée par l'intégration. L'opération d'actualisation complète par source de données (COMPLETE REFRESH BY DATA SOURCE) ne s'applique que sur les enregistrements de la source de données d'intégration.

désactivation des enregistrements de personne

La désactivation d'un enregistrement PERSON dans Learn le rend inaccessible à des fins de connexion (l'état désactivé remplace le paramètre de disponibilité) et rend également l'enregistrement inaccessible pour les opérations de l'interface utilisateur. Par exemple, vous ne pouvez pas ajouter un enregistrement PERSON désactivé à un cours via l'interface utilisateur. De plus, pour purger un enregistrement de Learn, vous devez d'abord désactiver cet enregistrement.

La désactivation d'un enregistrement et sa purge ultérieure suppriment toutes les références à cet enregistrement de Learn. Blackboard recommande de ne procéder à la purge des enregistrements désactivés qu'au bout d'un certain temps, tel que défini par vos pratiques commerciales et juridiques, qui pourraient sinon nécessiter un enregistrement de l'activité.

La désactivation des enregistrements peut suivre deux modèles : Désactivation via l'exclusion du flux de données d'alimentation lors des opérations REFRESH et désactivation par le biais de l'en-tête ROW_STATUS.

Les opérations PERSON ci-dessus, qui utilisent des opérations REFRESH, démontrent la désactivation par exclusion, le cas et l'exemple ci-après illustrent l'utilisation de ROW_STATUS.

Exemple : désactivation des enregistrements de personne

Les étudiants s'inscrivent ou ne sont plus tenus d'avoir accès à Learn. Vous devez entièrement supprimer leur accès et leur présence dans Learn (contrairement à la non-disponibilité de l'enregistrement qui restreint uniquement la connexion). Si vous utilisez des opérations STORE, vous devez désactiver explicitement les utilisateurs à l'aide de l'en-tête ROW_STATUS. Cela est également utile dans les opérations manuelles excédant la portée des flux SIS.

Pré-requis

Les enregistrements ciblés existent dans le système Learn.

Exigences minimales de flux de données

EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
ROW_STATUS

Solution

Ajoutez l'en-tête ROW_STATUS à votre flux de données et spécifiez ENABLED pour activé et DISABLED pour désactivé.

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

Postcondition

STORE (STOCKER)

Seuls les enregistrements COURSE pour aanderson_test, bbrown_test, ccarlin_test et ddarling_test sont créés ou mis à jour avec le ROW_STATUS explicitement mis à jour.

COMPLETE REFRESH (actualisation complète)

Les enregistrements PERSON pour aanderson_test, bbrown_test, ccarlin_test, et ddarling_test sont créés ou mis à jour. Tous les autres enregistrements seront désactivés ou marqués pour être purgés en raison de leur absence du flux de données ci-dessus.

COMPLETE REFRESH BY DATA SOURCE (actualisation complète par source de données)

Les enregistrements PERSON pour aanderson_test, bbrown_test, et ccarlin_test sont mis à jour (ils ont été créés précédemment) et ddarling_test est créé.

Si d'autres enregistrements PERSON sont gérés par cette intégration, ils ne seront PAS désactivés ou purgés en raison de leur absence du flux de données ci-dessus, à moins qu'ils n'aient la même source de données que celle spécifiée par l'intégration. L'opération d'actualisation complète par source de données (COMPLETE REFRESH BY DATA SOURCE) ne s'applique que sur les enregistrements de la source de données d'intégration.

COMPLETE REFRESH BY DATA SOURCE (actualisation complète par source de données)

Seuls les enregistrements PERSON pour aanderson_test, bbrown_test, ccarlin_test et ddarling_test sont créés ou mis à jour avec le ROW_STATUS explicitement mis à jour.

Si d'autres enregistrements PERSON sont gérés par cette intégration, ils ne seront PAS désactivés ou purgés en raison de leur absence du flux de données ci-dessus, à moins qu'ils n'aient la même source de données que celle spécifiée par l'intégration. L'opération d'actualisation complète par source de données (COMPLETE REFRESH BY DATA SOURCE) ne s'applique que sur les enregistrements de la source de données d'intégration.

Gestion des rôles secondaires d'utilisateur dans l'établissement

Comme vous disposez d'une licence Community, vous avez accès à des rôles supplémentaires que vous pouvez attribuer aux utilisateurs. Ils sont utiles pour gérer l'accès aux supports et aux onglets du portail Community.

La gestion des rôles secondaires est une activité distincte de la création ou de la mise à jour des utilisateurs, elle n'entre donc pas dans le cadre de la création/mise à jour du flux de données PERSON.

Exemple : ajout de rôles secondaires d'utilisateur dans l'établissement

Vous devez fournir un contenu de portail spécifique aux étudiants et au corps enseignant de l'école d'ingénierie.

Pré-requis

Vous avez créé un nouveau rôle institutionnel à l'aide de l'interface utilisateur de l'administrateur système (voir...) nommé « ENGINEERING_STUDENT ».

Exigences minimales de flux de données

EXTERNAL_PERSON_KEY
ROLE_ID

Solution

Créez un flux de rôle d'établissement Institutional_Role contenant les enregistrements à créer/mettre à jour.

EXTERNAL_PERSON_KEY|ROLE_ID
testPerson1|engineering_student
testPerson2|engineering_faculty
testPerson3|engineering_faculty
testPerson4|engineering_student

Comme pour les autres objets de données, vous pouvez également fournir le ROW_STATUS pour activer ou désactiver l'accès d'une personne au contenu associé au rôle secondaire. Par exemple :

EXTERNAL_PERSON_KEY|ROLE_ID|ROW_STATUS
testPerson1|engineering_student|enabled
testPerson2|engineering_faculty|enabled
testPerson3|engineering_student|disabled

Postcondition

STORE (STOCKER)

Seuls les enregistrements de rôle secondaire d'établissement pour aanderson_test, bbrown_test, ccarlin_test et d sont créés ou mis à jour avec le rôle secondaire d'établissement.

COMPLETE REFRESH (actualisation complète)

Les enregistrements de rôle secondaire d'établissement pour aanderson_test, bbrown_test, ccarlin_test et d sont créés ou mis à jour. Tous les autres enregistrements seront désactivés ou marqués pour être purgés en raison de leur absence du flux de données ci-dessus.

COMPLETE REFRESH BY DATA SOURCE (actualisation complète par source de données)

Les enregistrements de rôle secondaire d'établissement pour aanderson_test, bbrown_test, ccarlin_test et d sont créés ou mis à jour.

Si d'autres enregistrements PERSON sont gérés par cette intégration, ils ne seront PAS désactivés ou purgés en raison de leur absence du flux de données ci-dessus, à moins qu'ils n'aient la même source de données que celle spécifiée par l'intégration. L'opération d'actualisation complète par source de données (COMPLETE REFRESH BY DATA SOURCE) ne s'applique que sur les enregistrements de la source de données d'intégration.

Observateurs

Les observateurs sont des utilisateurs particuliers dont le compte est lié à un autre compte utilisateur remplissant un rôle de supervision ou d'observation. L'observateur peut se connecter et voir l'activité et les cours de l'utilisateur associé.

Pour être créé, un compte d'observateur nécessite les mêmes informations que celles d'un utilisateur et dispose d'une couche supplémentaire de « gestion d'association d'utilisateurs » dans laquelle l'observateur est associé à un compte utilisateur en liant les external_person_keys des deux comptes.

Le compte de l'observateur est créé exactement comme vous créeriez un compte utilisateur conformément aux exigences de traitement des données de votre établissement.

Exemple 1 : créer une association d'observateur

Vous souhaitez associer un étudiant au compte de son parent (ou d'un autre utilisateur approprié) afin que son activité puisse être contrôlée.

Pré-requis

Vous avez créé un étudiant identifié par un external_person_key (test_student_100dans cet exemple) et un observateur identifié par un external_person_key (test_student_100_observer et test_student_200_observer dans cet exemple).

Exigences minimales en termes de données

External_person_key de l'observateur : EXTERNAL_OBSERVER_KEY

External_person_key de l'étudiant observé : EXTERNAL_USER_KEY

Solution

Créer un fichier de données contenant l'external_person_key de l'observateur et la clé de personne externe de l'étudiant.

EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_100

Utilisez l'interface utilisateur pour télécharger ce fichier via le type de données d'association d'observateur (Observer Association Data Type) à l'aide de l'opération Store. L'association sera créée et vous pourrez vous connecter en tant qu'observateur et afficher l'activité de cours de l'étudiant.

Exemple 2 : mise à jour d'un enregistrement d'association d'observateur

Vous devez modifier une association.

Pré-requis

Vous avez créé une association entre test_student_200_observer et test_student_100, mais le compte étudiant associé doit être test_student_200.

Solution

Créer un fichier contenant la révision.

EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_200_observer|test_student_200

Utilisez l'interface utilisateur pour télécharger ce fichier via le type de données d'association d'observateur (Observer Association Data Type) à l'aide de l'opération Store.

Postcondition

L'association sera mise à jour et vous pourrez vous connecter en tant qu'observateur et afficher l'activité de cours du bon étudiant.

Exemple 3 : désactiver les enregistrements d'association d'observateur

Une association d'observateur n'est plus nécessaire et vous souhaitez la désactiver.

Pré-requis

Vous avez créé des associations entre des étudiants et des observateurs.

Solution

(En utilisant les données utilisées dans ce thème d'exemple)

Vous avez déjà créé des associations à l'aide de la méthode Stocker et du fichier suivant :

EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_200

Il existe deux modèles liés au flux de données qui permettent de désactiver une association d'observateur à sélectionner selon vos besoins :

  1. Vous souhaitez désactiver un sous-ensemble d'associations d'observateur associées à la source d'intégration/de données actuelle.
  2. Vous souhaitez désactiver un sous-ensemble d'associations d'observateur lors du stockage ou de la mise à jour d'enregistrements supplémentaires.
Désactivation d'un sous-ensemble d'associations d'observateur

Pour désactiver un sous-ensemble de données, vous devez créer un flux d'association et le charger via l'opération de suppression Delete. Par exemple :

pour supprimer l'association entre test_student_100_observer|test_student_100 dans l'ensemble de données de travail, vous devez créer un fichier de flux contenant les éléments suivants et le télécharger à l'aide de l'opération Delete :

EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_200_observer|test_student_200

Désactivation d'un sous-ensemble d'associations d'observateur lors du stockage d'associations nouvelles/existantes

Pour désactiver un sous-ensemble de données qui autorise également la mise à jour des associations existantes ou le stockage de nouvelles associations, vous devez créer un fichier d'association qui contient des associations existantes et nouvelles, et supprimer celles que vous souhaitez désactiver et télécharger à l'aide de l'opération d'actualisation complète Complete Refresh. Par exemple, à partir de l'ensemble :

EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_200

Nous voulons désactiver l'association test_student_200_observer|test_student_200 de sorte que le fichier ne contienne que l'association test_student_100_observer|test_student_100. Si nous souhaitions également ajouter deux nouvelles associations (à la condition préalable que les comptes utilisateur ait été précédemment créés), nous aurions téléchargé le contenu suivant :

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

Postcondition

L'enregistrement pour test_student_200_observer|test_student_200 est désactivé.


En savoir plus

Présentation du framework SIS

Descriptions de l'en-tête du fichier plat d'instantané

Format de données du fichier plat d'instantané

Automatisation du fichier plat d'instantané