Os exemplos a seguir demonstram a composição dos feeds de dados do Usuário (Pessoa) ao mesmo tempo que atendem a uma variedade de casos de uso. Esses exemplos utilizam o feed de dados mais simples possível. Há casos em que mais informações podem ser exigidas pela sua instituição. Elas são atendidas pela adição dos cabeçalhos e dados necessários ao feed de dados. A análise do sistema de informações da sua instituição e os requisitos e o planejamento do registrador ajudarão a determinar a profundidade dos dados necessários para preencher corretamente o Learn para atender aos seus dados e às metas do ciclo de vida.
Os exemplos são baseados em configurações padrão do Learn, que são visíveis na IU de configuração da integração. A alteração desses elementos de configuração resultará em alterações nos resultados de exemplo. Explicações dessas configurações estão disponíveis em Visão geral da estrutura do SIA. Além disso, supõe-se que, a menos que observado de outra forma, a integração esteja configurada para usar a mesma fonte de dados para todos os dados de entrada.
Usuários
Os dados do usuário são o conjunto de informações principais que descreve quem tem acesso ao Learn, sua função na instituição e sua função no sistema do Learn. No contexto de dados do SIA, os objetos do usuário geralmente são chamados de "pessoa" e isso é refletido nos padrões existentes. Precedendo muitos desses padrões, o Learn usa "pessoa" e "usuário" para fazer referência aos registros relacionados ao usuário com base no contexto. Os exemplos a seguir usarão "pessoa" para fazer referência ao registro e "usuário" para fazer referência à pessoa.
Gerenciamento de dados do arquivo simples de instantâneo
A estrutura do SIA é compatível com uploads do feed de dados de arquivos simples de instantâneos por meio de um upload do feed de IU e por meio de um conjunto de URLs fornecido pelo sistema do Learn.
Acesse as informações de HTTP e carregue o arquivo de feed por meio do menu de integração na UI de integração de sistemas de informações do aluno para integração de dados de administração do sistema.
Em ambos os casos, o comportamento da operação de dados é orientado pela configuração da integração e pelo tipo de operação selecionado. O tipo de operação de dados selecionado controla como os dados no feed são "interpretados" e cada URL fornecerá diferentes resultados para atender às metas desejadas da sua integração.
Os exemplos usam o recurso de arquivo de feed de upload da IU da estrutura do instantâneo. Para automatizar ou usar linhas de comando/operações de programação, consulte Automação de arquivo simples de instantâneo.
Os dados podem ser fornecidos ao Learn e, posteriormente, atualizados, removidos ou corrigidos. Assim, você pode começar com o conjunto de dados mais simples e aumentar conforme a mudança nos requisitos de dados da sua instituição.
As operações a seguir estão disponíveis por meio da IU e do HTTP.
| Operação | Descrição |
|---|---|
| Armazenamento | Armazenar ou Atualizar um registro fornecido pela configuração da integração. Ao usar esse tipo de operação, os dados contidos no arquivo de feed são armazenados ou atualizados (por definições de configuração) em todas as fontes de dados que pertencem à integração. Para “propriedade” de dados, fonte de dados, e chaves, consulte Visão geral da estrutura do SIA. |
| Atualizar | Armazenar, atualizar ou desativar a presença de um registro fornecido no Feed e no Learn. Essa operação armazena ou atualiza os dados contidos no feed de dados e, ao mesmo tempo, desabilita os dados que não estão contidos no feed de dados associado à integração em todas as fontes de dados. |
| Excluir | Desativar registro fornecido. Esta operação desabilita, por configurações de integração, os registros contidos no feed de dados associado à integração em todas as fontes de dados. |
| Atualização completa pela fonte de dados | Desativar registro fornecido. Apresentada no SP 12, essa operação executa uma atualização completa dos dados associados APENAS à fonte de dados configurada para integração. Esta operação emula mais de perto o processo de instantâneo da linha de comando para atualizar dados. |
Os objetos associados às operações de pessoa são:
| Pessoa | Armazenamento, atualização completa, exclusão, atualização completa pela fonte de dados |
| Função de instituição secundária do usuário | Armazenamento, atualização completa, exclusão, atualização completa pela fonte de dados |
| Associação de usuário | Armazenamento, atualização completa, exclusão, atualização completa pela fonte de dados |
Os exemplos de associação de usuário podem ser encontrados na seção Exemplo de hierarquia.
Os exemplos fornecidos são demonstrados usando o recurso de arquivo de feed de upload da IU da estrutura do instantâneo. Para automatizar ou utilizar linhas de comando/operações de programação, consulte Automação de arquivo simples de instantâneo.
Um lembrete sobre chaves de fonte de dados
Todos os objetos de dados oferecem suporte à capacidade de alterar a chave de fonte de dados para o agrupamento do conjunto de dados e podem ser usados para alterar a fonte de dados associada. Nota: este não é um campo obrigatório em feeds de dados baseados na estrutura e, a menos que indicado, os exemplos abaixo presumem que a integração esteja configurada para usar uma única fonte de dados.
Apresentado no SP 12, é a capacidade de especificar a fonte de dados no feed de dados separadamente da especificação de uma nova fonte de dados.
Para saber mais, consulte Gerenciamento da chave de fonte de dados.
Uma observação sobre mapeamento de campo
O mapeamento de campo fornece a capacidade de alterar os dados de entrada antes de serem armazenados no Learn. Isso permite que você tenha total controle sobre os dados que são armazenados e permite que você cumpra as regras específicas do Learn quando os dados do SIA fornecidos forem insuficientes, como a criação de senhas do usuário. Quando aplicado a um campo do objeto de Usuário, o script associado é executado de acordo com o usuário, alterando ou fornecendo os dados antes de serem armazenados no Learn. Uma explicação completa do mapeamento de campo para arquivo simples de instantâneo é fornecida em Mapeamento de campo de arquivo simples de instantâneo.
Uma observação sobre senhas
As senhas são necessárias para fazer logon no Learn, mas não são um campo obrigatório em feeds de dados de pessoa. Se uma senha não for fornecida no feed de dados, uma senha aleatória do SHA512 será gerada e armazenada no banco de dados do Learn. Isso não será um problema se você estiver usando a autenticação externa (como LDAP), mas o que acontecerá se você estiver usando o banco de dados do Learn para armazenar senhas de logon do usuário? Você deve fornecer a senha na criação do usuário, pois não será possível fazer logon.
Se você executar um feed e definir a senha para um usuário que altere subsequentemente a senha, o logon será quebrado. Sim e não: em uma operação de atualização você pode optar por não atualizar o campo de senha. Isso permitirá que o Learn retenha a senha atual na atualização. Se você não selecionar essa opção, a senha será alterada e o usuário precisará ser notificado da alteração.
Exemplos da operação de pessoa
Em um nível alto, você pode aplicar três padrões de feed de dados de integração do SIA a todas as operações de dados do usuário, e a seleção do padrão depende dos dados que você pode fornecer e das metas de integração.
- Usar um único arquivo de feed que você pode criar ou atualizar, ou desativar registros (armazenamento): alterar explicitamente os registros por meio de dados presentes no arquivo.
- Usando um único arquivo de feed, você pode atualizar dados – criar ou atualizar e desativar (atualização completa) registros – alterando registros por meio da presença (criar/atualizar) ou da ausência de dados no arquivo.
- Usar uma combinação de arquivos que você pode armazenar com um, e definir a disponibilidade ou desativar com outro.
Finalmente, e esse não é um padrão de feed do SIA, mas vale a pena mencionar, você também pode desativar e limpar com base no DSK sozinho, utilizando a ferramenta de gerenciamento de fonte dados disponível na IU. Você deve ser muito discreto ao gerenciar os dados fornecidos pelo SIA dessa maneira. Isso é extremamente útil ao remover dados que não são mais fornecidos pelo SIA, ou nunca foram fornecidos por meio dele, como os dados provenientes de operações de teste.
Apenas os princípios básicos: Pessoas
Todas as contas de usuário requerem um conjunto básico de informações para estabelecer uma conta. Esse conjunto de informações é detalhado no Formato de dados de arquivo simples de instantâneo e no Cabeçalho de arquivo simples de instantâneo.
Se você estiver usando as ferramentas de lote da IU alternando para o uso da estrutura do SIA e usando o mínimo de dados de usuário e recursos de upload da IU da estrutura do SIA, você terá mais registros e relatórios de uploads de dados sem alterar seus processos de coleta desses dados.
Dados em breve
O conjunto mínimo de dados ou os cabeçalhos necessários para criar uma conta de usuário no Learn consistem em:
- EXTERNAL_PERSON_KEY – um identificador exclusivo para esse registro de usuário.
- DATA_SOURCE_KEY – um identificador exclusivo para os dados define este registro. Observação: isso é fornecido no feed ou por meio da configuração de integração.
- USER_ID – o código do usuário – é usado para fazer logon como o nome de usuário e deve ser associado ao CN de LDAP do usuário, ao código NET ou a outro identificador externo, se você estiver usando a autenticação externa.
- FIRST_NAME – O nome do usuário
- LAST_NAME – O sobrenome do usuário
- PASSWD – A senha para este usuário
Para obter um exemplo de atribuição dinâmica de uma senha se não for possível fornecer uma no feed de dados, consulte Mapeamento de campo personalizado de arquivo simples de instantâneo.
A estrutura do SIA, conforme uma configuração de integração, fornece valores padrão para campos não obrigatórios ou os ignora. Dois campos úteis que não são obrigatórios para um feed de pessoa são EMAIL e SYSTEM_ROLE. O e-mail é obrigatório para fazer a correspondência e fornecer notificações por e-mail com usuários do Learn via e-mail do Learn. Portanto, você deve considerar fornecer esses dados em seu feed. Padrões SYSTEM_ROLE para a configuração definida de NONE.
Cada um desses cabeçalhos é descrito completamente em Formato de dados de arquivos simples de instantâneo.
Como adicionar informações pessoais
Existem dois casos para adicionar informações pessoais. O primeiro é armazenar informações pessoais de maneira aditiva, resultando na adição ou atualização de registros, conforme apresentado no feed de dados. O segundo é atualizar informações pessoais já presentes no Learn, resultando na adição de novos registros ou na atualização de registros já existentes, conforme apresentado no arquivo de dados, ao mesmo tempo que desativa os registros já existentes que não estão presentes no arquivo de dados.
Exemplos da operação de armazenamento
Exemplo 1: Criar contas pessoais
Você quer adicionar usuários ao Blackboard Learn sem afetar as contas existentes. Você tem sua integração configurada para usar a mesma fonte de dados para todos os dados de entrada.
Pré-requisito
Nenhum.
Requisitos mínimos do feed de dados
EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
Solução
Criar um arquivo de dados pessoas.txt que contenha os cabeçalhos exigidos e os dados associados por pessoa que você quer adicionar ao sistema. Por exemplo:
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
Use a IU para carregar este arquivo por meio do tipo de dados de pessoa usando a operação de armazenamento. A conta de usuário será criada e você poderá fazer logon como o usuário.
Pós-condições
Registros de PESSOAS para aanderson_test, bbrown_test, and ccarlin_test são criados.
Exemplo 2: Atualizar contas de usuário
Você criou as contas de usuário e precisa alterá-las. Por exemplo, o exemplo anterior não incluía endereços de e-mail de nenhum usuário. Você tem o endereço de e-mail para aanderson_test.
Pré-requisito
Nenhum: as atualizações ocorrerão em registros criados anteriormente, os dados incluídos nos quais um registro não existe no Learn resultarão na criação do registro.
Solução
Criar um arquivo de dados pessoas.txt que contenha os cabeçalhos exigidos e os dados associados por pessoa que você quer adicionar ao sistema. Por exemplo:
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME|EMAIL
testPerson1|aanderson_test|changeme|...owhere.erehwon
Como ARMAZENAMENTO opera apenas nos dados contidos no arquivo, os registros bbrown_test e ccarlin_test enviados antes não são afetados.
Use a IU para carregar este arquivo por meio do tipo de dados de pessoa usando a operação de armazenamento. A conta de usuário será atualizada.
Pós-condições
O registro de PESSOA para aanderson_test é atualizado para incluir o endereço de e-mail fornecido.
Os registros de PESSOA para bbrown_test e ccarlin_test não são afetados.
Pessoa: Operação de atualização completa
COMPLETE REFRESH opera de maneira diferente de STORE. A atualização completa executa duas operações que se aplicam a uma comparação dos dados no arquivo de feed e dos registros do LEARN de propriedade da integração – armazenamento de novos registros, atualização de registros existentes ou desabilitação de registros no LEARN que não estão no arquivo de dados.
Exemplo: Atualização completa
Os dados fornecidos pelo SIA contêm um instantâneo completo de pessoas que devem ter acesso ao Learn. Esses dados contêm registros de pessoa a serem adicionados, atualizados e que foram removidos desde as operações de anteriores de atualização completa, que devem ser manipuladas corretamente por configuração (desativar ou remover).
Pré-requisito
Nenhum.
Requisitos mínimos do feed de dados
EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
Solução
Use os dados da nossa última operação de armazenamento e remova gcarlin_test do feed de dados:
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|FIRSTNAME|LASTNAME
testPerson1|aanderson_test|changeme|Alpha|Anderson
testPerson2|bbrown_test|changeme|Beta|Brown
Se outros registros pessoais forem gerenciados por esta integração, eles serão desativados ou removidos devido à sua ausência no feed de dados acima.
Pós-condições
O registro de PESSOA para aanderson_test é retido e não é afetado.
O registro de PESSOA para bbrown_test é retido e atualizado para incluir o endereço de e-mail
O registro de PESSOA para ccarlin_test é marcado como desativado ou está pronto para remoção de acordo com a configuração de integração.
Pessoa: Operação de atualização completa pela fonte de dados
A atualização completa pela fonte de dados executa uma operação de atualização completa, mas restringe os dados afetados àqueles que só estão associados à fonte de dados da integração.
Exemplo: Atualização completa pela fonte de dados
Os dados fornecidos pelo SIA contêm um instantâneo completo de pessoas que devem ter acesso ao Learn. Esses dados contêm registros PERSON a serem adicionados, registros de PERSON atualizados e que foram removidos desde as operações anteriores de REFRESH, que devem ser manipuladas corretamente por configuração (desativar ou remover). Além disso, todos os dados nessa atualização são direcionados usando a mesma fonte de dados definida na integração e você quer que APENAS os dados relacionados a essa chave de fonte de dados sejam afetados.
Pré-requisito
Nenhum.
Requisitos mínimos do feed de dados
EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
Solução
Usar os dados da nossa última operação de armazenamento e remover gcarlin_test do feed de dados:
EXTERNAL_PERSON_KEY|USER_ID|PASSWD|firstname|lastname
testPerson1|aanderson_test|changeme|Alpha|Anderson
testPerson2|bbrown_test|changeme|Beta|Brown
Pós-condições
O registro de PESSOA para aanderson_test é retido e não é afetado.
O registro de PESSOA para bbrown_test é retido e atualizado para incluir o endereço de e-mail
O registro de PESSOA criado anteriormente para ccarlin_test é marcado como desativado ou está pronto para remoção de acordo com a configuração de integração.
Se outros registros pessoais forem gerenciados por esta integração, eles NÃO serão desativados ou removidos devido à sua ausência no feed de dados acima, a menos que tenham a mesma fonte de dados especificada pela integração.
Disponibilidade da conta pessoal
A configuração de disponibilidade da conta pessoal permite que uma conta do Learn fique conectada (disponível) ou não (indisponível). Observe que isso não é o mesmo que desativar uma conta, o que não apenas torna a conta indisponível, mas também significa que ela não está disponível para outras operações, como gerenciamento de associação. A adição desse cabeçalho do feed de dados não afeta o uso acima demonstrado de armazenamento, atualização completa, atualização completa pela fonte de dados para criar registros pessoais.
As configurações de integração padrão quando uma configuração de disponibilidade não é fornecida para que o objeto seja disponibilizado em operações de criação/atualização.
Exemplo: Disponibilidade da conta pessoal
Seus controles de SIA aprendem a acessar a disponibilidade dos usuários e seu feed de dados indica se os usuários têm acesso individual ao Learn. Você quer fazer alterações no acesso do usuário individual usando a criação/atualização de PESSOAS.
Pré-requisito
Nenhum.
Requisitos mínimos do feed de dados
EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
AVAILABILITY_IND
Solução
Adicione o cabeçalho AVAILABLE_IND ao feed de dados e forneça o único caractere de Y para disponível e N para indisponível.
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
Pós-condições
ARMAZENAMENTO
Apenas os registros de PESSOA para aanderson_test, bbrown_test e ccarlin_test são atualizados (eles foram criados anteriormente) e ddarling_test é criado.
Atualização completa
Os registros de PESSOA para aanderson_test, bbrown_test e ccarlin_test são atualizados (eles foram criados anteriormente) e ddarling_test é criado. Todos os outros registros serão desativados ou marcados para remoção devido à sua ausência no feed de dados acima.
Atualização completa pela fonte de dados
Os registros de PESSOA para aanderson_test, bbrown_test e ccarlin_test são atualizados (eles foram criados anteriormente) e ddarling_test é criado.
Se outros registros pessoais forem gerenciados por esta integração, eles NÃO serão desativados ou removidos devido à sua ausência no feed de dados acima, a menos que tenham a mesma fonte de dados especificada pela integração. A atualização completa pela fonte de dados opera apenas nos registros da fonte de dados da integração.
Desativar registros pessoais
Desativar um registro pessoal no Learn faz com que ele fique inacessível para logon (o status desativado substitui a configuração de disponibilidade) e também torna o registro inacessível para operações de IU. Por exemplo, não é possível adicionar um registro de pessoa desativado a um curso por meio da IU. Além disso, para remover um registro do Learn, é preciso primeiro desativá-lo.
Desativar um registro e descartar na sequência remove todas as referências a esse registro do Learn. A Blackboard recomenda que a remoção de registros desativados só seja realizada após um período determinado pelo seu negócio e/ou por práticas jurídicas que possam exigir um registro de atividade.
A desativação dos registros pode seguir dois modelos: Desativação pela exclusão de dados do feed em operações de atualização e desativação pelo uso do cabeçalho do feed ROW_STATUS.
As operações pessoais acima que usam as operações de atualização demonstram como desativar por exclusão. O caso e o exemplo a seguir demonstram por meio do uso de ROW_STATUS.
Exemplo: Desativar registros pessoais
Os alunos se matricularam ou não precisam mais ter acesso ao Learn. É necessário remover completamente o acesso e a presença no Learn (ao contrário de tornar o registro indisponível, o que apenas restringe o logon). Se você estiver usando operações de armazenamento, para desativar os usuários será necessário desativar explicitamente o usuário usando o cabeçalho ROW_STATUS. Isso também é útil em operações manuais fora do escopo dos feeds do SIA.
Pré-requisito
Os registros direcionados existem no sistema do Learn.
Requisitos mínimos do feed de dados
EXTERNAL_PERSON_KEY
USER_ID
PASSWD
FIRSTNAME
LASTNAME
ROW_STATUS
Solução
Adicionar o cabeçalho ROW_STATUS ao feed de dados e fornecer uma entrada de ENABLED para ativado e DISABLED para desativado.
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
Pós-condições
ARMAZENAMENTO
Apenas os registros de PESSOA para aanderson_test, bbrown_test, ccarlin_test e ddarling_test são criados ou atualizados com ROW_STATUS atualizado explicitamente.
Atualização completa
Os registros de PESSOA para aanderson_test, bbrown_test, ccarlin_test, e ddarling_test são criados ou atualizados; Todos os outros registros são desativados ou marcados para remoção por causa da ausência deles no feed de dados acima.
Atualização completa pela fonte de dados
Os registros de PESSOA para aanderson_test, bbrown_test e ccarlin_test são atualizados (eles foram criados anteriormente) e ddarling_test é criado.
Se outros registros pessoais forem gerenciados por esta integração, eles NÃO serão desativados ou removidos devido à sua ausência no feed de dados acima, a menos que tenham a mesma fonte de dados especificada pela integração. A atualização completa pela fonte de dados opera apenas nos registros da fonte de dados da integração.
Atualização completa pela fonte de dados
Os registros de PESSOA para aanderson_test, bbrown_test, ccarlin_test e ddarling_test são criados ou atualizados, com ROW_STATUS atualizado explicitamente.
Se outros registros pessoais forem gerenciados por esta integração, eles NÃO serão desativados ou removidos devido à sua ausência no feed de dados acima, a menos que tenham a mesma fonte de dados especificada pela integração. A atualização completa pela fonte de dados opera apenas nos registros da fonte de dados da integração.
Gerenciar funções na instituição secundária do usuário
Como um licenciado da Comunidade, você tem acesso a funções adicionais que podem ser atribuídas aos usuários. Elas são úteis para gerenciar o acesso aos materiais e guias no Portal da comunidade.
O gerenciamento de funções secundárias é uma atividade separada da criação ou atualização de usuários e, como tal, o gerenciamento de funções secundárias não faz parte do feed de dados de criação/atualização pessoal.
Exemplo: Adicionar funções na instituição secundária do usuário
Você precisa fornecer conteúdo do portal específico para alunos e corpo docente da escola de engenharia.
Pré-requisito
Você criou uma nova função institucional usando a IU do administrador do sistema (consulte...) denominada "ENGINEERING_STUDENT"
Requisitos mínimos do feed de dados
EXTERNAL_PERSON_KEY
ROLE_ID
Solução
Criar um feed de Institutional_Role que contenha os registros a serem criados/atualizados.
EXTERNAL_PERSON_KEY|ROLE_ID
testPerson1|engineering_student
testPerson2|engineering_faculty
testPerson3|engineering_faculty
testPerson4|engineering_student
Assim como com outros objetos de dados, você também pode fornecer o ROW_STATUS para ativar ou desativar o acesso pessoal ao conteúdo associado à função secundária. Por exemplo:
EXTERNAL_PERSON_KEY|ROLE_ID|ROW_STATUS
testPerson1|engineering_student|enabled
testPerson2|engineering_faculty|enabled
testPerson3|engineering_student|disabled
Pós-condições
ARMAZENAMENTO
Apenas os registros da função na instituição secundária para aanderson_test, bbrown_test, ccarlin_test e d são criados ou atualizados com a função na instituição secundária.
Atualização completa
Os registros da função na instituição secundária para aanderson_test, bbrown_test, ccarlin_test e d são criados ou atualizados. Todos os outros registros são desativados ou marcados para remoção por causa da ausência deles no feed de dados acima.
Atualização completa pela fonte de dados
Os registros da função na instituição secundária para aanderson_test, bbrown_test, ccarlin_test e d são criados ou atualizados.
Se outros registros pessoais forem gerenciados por esta integração, eles NÃO serão desativados ou removidos devido à sua ausência no feed de dados acima, a menos que tenham a mesma fonte de dados especificada pela integração. A atualização completa pela fonte de dados opera apenas nos registros da fonte de dados da integração.
Observadores
Os observadores são um usuário de caso especial em que a conta está vinculada a outra conta de usuário em uma supervisão ou capacidade de observação. O observador pode fazer logon e ver seus cursos e atividades de usuário associados.
Uma conta de observador requer as mesmas informações que um usuário para a criação da conta e tem uma camada adicional de "gerenciamento de associação do usuário", em que o observador é associado a uma conta de usuário ao vincular o external_person_keys das duas contas.
A conta do observador é criada exatamente como você criaria qualquer conta de usuário seguindo os requisitos de processamento de dados da sua instituição.
Exemplo 1: Criar associação do observador
Você deseja associar um aluno à sua conta de pai (ou outro usuário adequado) para que a atividade possa ser observada.
Pré-requisito
Você criou um aluno identificado por um external_person_key (test_student_100 neste exemplo) e um observador identificado por um external_person_key (test_student_100_observer e test_student_200_observer neste exemplo).
Requisitos mínimos de dados
A external_person_key do observador: EXTERNAL_OBSERVER_KEY
external_person_key dos alunos observados: EXTERNAL_USER_KEY
Solução
Criar um arquivo de dados que contenha a external_person_key do observador e a chave pessoal externa do aluno.
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_100
Use a IU para carregar este arquivo por meio do tipo de dados de associação do observador usando a operação de armazenamento. A associação será criada e você poderá fazer logon como o observador e visualizar a atividade do curso do aluno.
Exemplo 2: Atualizar um registro de associação do observador
Você precisa alterar uma associação.
Pré-requisito
Você criou uma associação entre test_student_200_observer e test_student_100, mas a conta de aluno associada deve ser test_student_200.
Solução
Criar um arquivo que contenha a revisão.
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_200_observer|test_student_200
Use a IU para carregar este arquivo por meio do tipo de dados de associação do observador usando a operação de armazenamento.
Pós-condições
A associação será atualizada e você poderá fazer logon como observador e visualizar a atividade do curso do aluno correto.
Exemplo 3: Desativar registros de associação do observador
Uma associação do observador não é mais necessária e você deseja desativá-la.
Pré-requisito
Você criou associações entre alunos e observadores.
Solução
(Utilizando os dados usados neste exemplo de linha de discussão)
Você criou anteriormente associações usando o método de armazenamento e o seguinte arquivo:
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_200
Existem dois padrões relacionados ao feed para atender ao requisito de desativar uma associação do observador, dependendo de seus requisitos:
- Você deseja desativar um subconjunto de associações de observador associado à integração/fonte de dados atual.
- Você deseja desativar um subconjunto de associações de observador ao armazenar ou atualizar registros adicionais.
Desativar um subconjunto de associações de observador
Para desativar um subconjunto de dados, você pode criar um feed de associação e carregá-lo na operação de exclusão. Por exemplo:
Para excluir a associação entre test_student_100_observer|test_student_100 no conjunto de dados de trabalho, você pode criar um arquivo de feed que contenha o seguinte e carregá-lo usando a operação de exclusão:
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_200_observer|test_student_200
Desativar um subconjunto de associações de observador ao armazenar associações novas/existentes
Para desativar um subconjunto de dados que também permita a atualização existente ou o armazenamento de novas associações, você pode criar um arquivo de associação que contenha associações existentes e novas, removendo aquelas que você deseja desativar e carregar usando a operação de atualização completa. Por exemplo, usando o conjunto de trabalho de:
EXTERNAL_OBSERVER_KEY|EXTERNAL_USER_KEY
test_student_100_observer|test_student_100
test_student_200_observer|test_student_200
Queremos desativar a associação do test_student_200_observer | test_student_200, portanto, o arquivo conterá somente a associação test_student_100_observer | test_student_100. Se também quiséssemos adicionar duas novas associações (desde que as contas de usuários tenham sido criadas), poderíamos carregar o seguinte:
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
Pós-condições
O registro para test_student_200_observer|test_student_200 é desativado.
Saiba mais
Visão geral da estrutura do SIA
Descrições de cabeçalho do arquivo simples de instantâneo
