Please enable JavaScript.
Coggle requires JavaScript to display documents.
AGENT - Importação Usuários (Validações Gerais: (Consumo AWS (Qual o…
AGENT - Importação Usuários
Do Agent para o RPortal
Na tabela USER possui nova coluna lastUpdate para atualizar a data e hora que houve tentativa de enviar o crachá do banco local para a nuvem;
Deve atualizar essa coluna quando o crachá for inserido ou editado.
Com Domínio Cadastrado:
Qual o tratamento do sistema se o usuário do AD tiver seus dados alterados;
Deve atualizar os dados no RPortal (Nome, Ativo, Login, Pin, Crachá, Domain, E-mail, isactivedirectory).
Qual o tratamento do sistema caso o tenant tenha domínio cadastrado, mas o servidor está configurado para não realizar comunicação com o AD;
Não deve buscar os dados do AD.
Não deve atualizar ou criar usuários do domínio no gerenciamento. Deve manter os registros atuais sem alteração.
Qual o tratamento do sistema caso o usuário já importado para a nuvem seja inativado no AD;
Deve inativar o usuário no banco local e na nuvem.
A importação de novos usuários do AD somente está sendo realizada para os usuários ativos no AD;
Deve buscar do AD para o banco local e consequentemente enviar para a nuvem somente usuários ativos no AD.
Sem Domínio Cadastrado:
Qual o tratamento do sistema caso o usuário cadastre o crachá pelo embarcado;
Deve armazenar o código do crachá cadastrado na coluna "nametag" da tabela USER.
Deve importar o código do crachá no banco local para a nuvem no gerenciamento de usuários.
Qual o tratamento do sistema caso um usuário não existente no banco local e RPortal realize uma impressão no servidor monitorado pelo Agent;
Deve adicionar o usuário no banco de dados local sem idAws, apenas com as informações de name e login.
Deve adicionar o idAws após o usuário ser importado para a nuvem.
Qual o tratamento do sistema caso exista um usuário no banco local sem idAws;
Deve enviar o mesmo para a nuvem e depois enviar o id para o banco local.
Do RPortal para o Agent
Sem Domínio Cadastrado:
Qual o tratamento do sistema caso o crachá do usuário seja alterado no gerenciamento de usuários;
Deve atualizar o crachá no banco local, tabela USER coluna "nametag".
Qual o tratamento do sistema caso o e-mail do usuário seja alterado no gerenciamento de usuários;
Deve atualizar o e-mail no banco local, tabela USER coluna "mail".
Qual o tratamento do sistema caso o pin do usuário seja alterado no gerenciamento de usuários;
Deve atualizar o pin no banco local, tabela USER coluna "pin".
Qual o tratamento do sistema caso o usuário seja unificado a outro no gerenciamento de usuários;
Deve atualizar no banco local as colunas "unified" e "unifiedUserId" da tabela USER.
Coluna "unified": Deve mostrar o status de ativado "1".
Coluna "unifiedUserId": Deve mostrar o ID do usuário que o mesmo está unificado.
Qual o tratamento do sistema caso o login do usuário seja alterado no gerenciamento de usuários;
Deve atualizar o login no banco local, tabela USER coluna "login".
Qual o tratamento do sistema caso o nome do usuário seja alterado no gerenciamento de usuários;
Deve atualizar o nome no banco local, tabela USER coluna "name".
Qual o tratamento do sistema ao inativar o usuário no gerenciamento de usuários;
Deve inativar no banco local, tabela USER coluna "active" status "0".
Qual o tratamento do sistema quando novos usuários são cadastrados no gerenciamento de usuários;
Deve enviar os dados do novo usuário para o banco local na tabela USER.
Deve enviar todas as informações name, enable, login, email, pin e nametag.
Com Domínio Cadastrado:
Qual o tratamento do sistema quando houver os campos do AD para pin e crachá configurados para importar do AD;
Deve retornar para o gerenciamento de usuário ou valor encontrado.
Validar retorno em branco.
Validar retorno alfabético no campo pin.
Validar o envio para o banco local dessas informações.
Qual o tratamento do sistema caso o tenant tenha domínio cadastrado, mas o servidor está configurado para não realizar comunicação com o AD;
Deve enviar apenas os dados dos usuários criados/editados manualmente.
Qual o tratamento do sistema caso o crachá do usuário do AD seja alterado no gerenciamento de usuários;
Deve atualizar o crachá no banco local, tabela USER coluna "nametag".
Deve atualizar apenas para os servidores com a configuração "Realizar comunicação com o Active Directory" ativa.
Qual o tratamento do sistema caso o usuário seja unificado a outro no gerenciamento de usuários;
Deve atualizar no banco local as colunas "unified" e "unifiedUserId" da tabela USER.
Coluna "unified": Deve mostrar o status de ativado "1".
Coluna "unifiedUserId": Deve mostrar o ID do usuário que o mesmo está unificado.
Qual o tratamento do sistema caso o pin do usuário do AD seja alterado no gerenciamento de usuários;
Deve atualizar o pin no banco local, tabela USER coluna "pin".
Deve atualizar apenas para os servidores com a configuração "Realizar comunicação com o Active Directory" ativa.
Qual o tratamento do sistema caso o campo do AD com o crachá e pin não estejam configurados no domínio;
Não deve buscar essa informação.
Deve atualizar apenas as informações configuradas no domínio.
Qual o tratamento do sistema ao editar as propriedades de um usuário criado automaticamente;
Deve atualizar as informações inseridas no banco local.
Qual o tratamento do sistema na importação de usuários cadastrados do gerenciamento de usuários para o agent;
Deve enviar para o banco local: Nome, Ativo, Login, PIN, Crachá e E-mail.
Validações Gerais:
Qual o tratamento do sistema na sincronização de usuários do AD, caso exista para um tenant mais de um servidor rodando, onde um possui a configuração de sincronização com AD ativa e outro inativo;
As tabelas no banco de dados local deve respeitar a regra de acordo com o status da coluna isBlockSyncAD na tabela GENERAL_SETTING .
Se Ativo, deve carregar as informações nas tabelas: DOMAIN_CONFIG, USER (Mostra os usuários do AD, os usuários criados manualmente ou pela multifuncional), GENERAL_SETTING e LAST_UPDATED (Coluna: TRACKER_SERVER_EQUIPMENT).
Se Inativo, deve manter as informações inalteradas nas tabelas: DOMAIN_CONFIG (Sem informação), USER (Mostra somente os usuários criados manualmente ou pela multifuncional) GENERAL_SETTING e LAST_UPDATED (Coluna: TRACKER_SERVER_EQUIPMENT).
Caso o servidor inativo teve em algum momento a sincronização com o AD ativo, deve manter as informações nas tabelas: DOMAIN_CONFIG e USER, mas as tabelas GENERAL_SETTING e LAST_UPDATED (Coluna: TRACKER_SERVER_EQUIPMENT) não devem ser atualizadas.
Consumo AWS
Qual o tratamento na comunicação com o SQS, caso o tenant tenha todos os seus servidor configurado com sincronização com o AD;
No relatório a AWS deve haver consumo da fila SQS para todos os servidores com AD.
Qual o tratamento na comunicação com o SQS, caso o servidor que tenha a configuração de sincronização com o AD seja inativado;
Quando for inativada a sincronização do servidor com o AD, deve parar de consumir a fila de SQS.
Ao ativar novamente a sincronização de AD no servidor, a fila de SQS deve voltar a ser consumida.
Qual o tratamento na comunicação com o SQS, caso o tenant não tenha nenhum servidor configurado com sincronização com o AD;
No relatório a AWS não deve haver consumo da fila SQS.
Qual o tratamento do sistema caso exista mais de um servidor no mesmo tenant e com configurações para sincronização com AD diferentes;
Deve mostrar na tabela GENERAL_SETTING somente a informação do servidor do banco de dados local que está sendo acessado.
Cada banco local terá a configuração do seu servidor.
A sincronização deve ser apenas da Nuvem para o Agent.
Qual o tratamento do sistema caso o servidor onde o Agent está instalado tenha a configuração de sincronização com o AD ativado;
Deve alterar no banco de dados local a coluna isBlockSyncAD colocando o status ativo 1.
A informação deve ser alterada ao reiniciar o Agent ou quando o timer de 30 minutos for alcançado.
Deve atualizar a tabela DOMAIN_CONFIG com as informações do domínio configuração para sincronização com AD.
A tabela em questão deve ser atualizada levando em consideração o comparativo da data da última atualização na coluna TRACKER_SERVER_EQUIPMENT da tabela LAST_UPDATED.
Validar as atualizações nas tabelas: GENERAL_SETTING e LAST_UPDATED (Coluna: TRACKER_SERVER_EQUIPMENT).
Qual o tratamento do sistema ao reiniciar o Agent ou o timer de 30 minutos da última atualização for alcançado, mas nenhuma alteração foi realizada na configuração do AD por servidor;
Não deve alterar o registro no banco de dados local e nem atualizar a tabela LAST_UPDATED.
Qual o tratamento do sistema ao reiniciar o Agent ou o timer de 30 minutos for alcançado, mas o servidor em questão não possui a configuração de sincronização com o AD ativa;
Não deve realizar a comunicação com o AD e as tabelas GENERAL_SETTING e LAST_UPDATED não devem ser alteradas.
A coluna isBlockSyncAD deve manter o status inativo 0(zero).
Qual o tratamento do sistema caso o servidor onde o Agent está instalado tenha a configuração de sincronização com o AD inativado ;
Deve alterar no banco de dados local a coluna isBlockSyncAD colocando o status inativo 0(zero).
A informação deve ser alterada ao reiniciar o Agent ou quando o timer de 30 minutos for alcançado.
A tabela em questão deve ser atualizada levando em consideração o comparativo da data da última atualização na coluna TRACKER_SERVER_EQUIPMENT da tabela LAST_UPDATED.
Validar as atualizações nas tabelas: GENERAL_SETTING e LAST_UPDATED (Coluna: TRACKER_SERVER_EQUIPMENT).
Qual o tratamento do sistema com os dados dos usuários trazidos do AD;
Não deve permitir alterar no gerenciamento de usuários os dados encontrados nos campos configurados no domínio.
Usuários criados manualmente poderão ter todas as informações alteradas.