Jobs - pasta /Home/eid/cafe

full-job-atualizacao-diaria

Limpa a base EID ( tabelas do EID e tabelas de Stage)

Importa todos os registros da base de origem validando os CPFs e emails inválidos, carrega vínculos, emails e contas.

Exporta todos estes dados para o LDAP, comparando o que já existe para remover usuários que tenham sido desativados.

Caso apenas um vinculo do usuário seja desativado e a pessoa continue ativa, este vinculo não é apagado do LDAP, apenas do EID.

Usuários encontrados com CPFs duplicados são unificados sempre preservando o registro mais recente e/ou a base mais confiável (base com baseOrigem=1) e evidenciando a unificação no relatório de "Pessoas Duplicadas".

Contas duplicadas são unificadas escolhendo de acordo com o parâmetro configurado e/ou de acordo com o critério da base mais confiável. A unificação é evidenciada no relatório de "Contas duplicadas".

full-job-atualizacao-diaria-truncate

Faz exatamente as mesmas cargas que o full-jobs-atualizacao=diaria, porém antes de inserir os dados no LDAP, ele faz um truncate em toda a base LDAP para só então inserir os dados na base.

Lembrando que por apagar todos os usuários da base LDAP, este job deixa o serviço indisponível enquanto faz a nova carga dos usuários na base.

Por isso recomenda-se que este Job seja executado em horários que o uso dos serviços seja mínimo, por exemplo durante a madrugada.

atualizacao-contas-intradia

Um job mais leve e rápido para ser executado com pouco intervalo de tempo, por exemplo de hora em hora.

Este Job faz a carga apenas de Identificação e Conta. Para garantir que novos alunos, ou pessoas que trocaram a senha tenham esta mudança refletida no diretório LDAP rapidamente.

eid-truncate-logs

Limpa todas as tabelas de logs existentes na base EID.

Este Job pode ser executado para liberar armazenamento e melhorar o desempenho do Servidor Pentaho.

eid-truncate-tables

Limpa todas as tabelas da Base EID exceto os logs.

Pode ser executado quando se deseja zerar toda as exportações realizadas.

estatisticas-cubos

Limpa todas as tabelas de estatísticas do EID.

O EID PDI realiza a integração do cadastro de usuários das instituições que fazem parte da CAFe por meio da leitura de suas bases de dados e posterior sincronização com o servidor LDAP da comunidade.

A configuração padrão desse serviço realizar a integração das seguintes entidades:

• Identificação

• Conta

• Email

• Aluno

• Professor

• Técnico

Para cada entidade listada acima, a instituição precisa disponibilizar uma VIEW no seu banco de dados com as seguintes características:

OBS. : Caso a sua instituição não deseje importar para a base LDAP os dados de alguma das Views como por exemplo Professor, a estrutura da View deve ser criada mesmo assim e deverá ficará vazia sem nenhum dado.

01. IDENTIFICAÇÂO

Nome da view: Pessoas

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão"

02. CONTA

Nome da view: Conta

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

03. EMAIL

Nome da view: Email

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

04. ALUNO

Nome da view: Aluno

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

05. PROFESSOR

Nome da view: Professor

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

06. TÉCNICO

Nome da view: Tecnico

Todos os campos acima precisam existir na view. Caso a instituição não deseje informar os campos não obrigatórios, ainda assim deve criá-lo na view, com o seu conteúdo como definido na coluna "Valor Padrão".

Abaixo é exibida a tela para configuração dos parâmetros disponíveis no PDI/EID:

Para chegar a esta tela é necessário abrir um job e clicar duas vezes na área em branco, depois selecionar a aba "Parâmetros":

OBS: Estes parâmetros precisam ser configurados nos seguintes jobs:

• full-job-atualizacao-diaria

• full-job-atualizacaoo-diaria-truncate

• job-atualizacao-contas-intradia

Antes de executar estes jobs no PDI é necessário preencher os parâmetros obrigatórios.

Os parâmetros configuráveis nesta tela se dividem em :

Parâmetros para configuração de envio de email com alertas e erros na execução dos Jobs:

• indicadorEnvioEmailAtivo - Quando informado com o valor "True" os alertas gerados serão enviados para o email configurado, caso configurado com o valor "False" nenhum email de alertas será enviado. Obrigatório.

• AuthenticationPassword - Senha do usuário no servidor SMTP em texto plano.

• pentahoAddress - Ip público e porta do servidor pentaho. Ex.: 138.121.71.89:8080 , necessário para enviar o link do relatório de inconsistências encontradas durante o processamento no email de alerta.

• serverSMTPPort - Porta do servidor SMTP da Instituição. Ex.: 587

• serverSMTPServer - Endereço do servidor SMTP da Instituição. Exemplo: smtp.rnp.br Estes parâmetros informados acima serão obrigatórios apenas se o parâmetro "indicadorEnvioEmailAtivo" for informado com o valor "True".

Parâmetros para conexão com a base LDAP:

• host_address_ldap - Incluir o IP ou nome do servidor LDAP. Ex.: 138.121.71.89 ou ldap.rnp.br. (Obrigatório)

• host_port_ldap - Incluir a porta do servidor LDAP. Ex.: 389 (Obrigatório)

• raiz_base_ldap - Incluir a raiz do LDAP configurada no servidor. Ex.: dc=rnp,dc=br (Obrigatório)

• admin_ldap - Usuário configurado na base Ldap com permissão de leitura e escrita na base. Ex: cn=admin,dc=rnp,dc=br (Obrigatório)

• senha_admin_ldap - Senha em texto plano do usuário configurado no parâmetro "admin_ldap". (Obrigatório)

• dominio_Instituicao - Incluir o domínio da instituição. Ex.: rnp.br, utilizado para gerar atributos escolados como "Eppn" por exemplo. (Obrigatório)

Parâmetro para escolher forma de unificação de Conta:

• manterContaMaisRecente - Quando o PDI detecta mais de uma conta cadastrada para o mesmo usuário é necessário escolher apenas uma para ser enviada ao servidor LDAP. Ao preencher este parâmetro com "True" a conta mais recente será enviada ao LDAP, para detectar que a conta é mais recente o PDI verifica o ID do registro importado e compara qual é maior. No caso de mais de uma base de dados é possível também definir a prioridade pela base configurada como mais confiável, que no caso é sempre a primeira a ser importada com o campo "baseOrigem=1" . (Obrigatório)

Parâmetro para converter a senha para base64:

• castToB64 - Em algumas situações, o hash SHA e MD5 das senhas é armazenado como uma sequência de caracteres hexadecimais nas bases institucionais. Para envio da senha para o LDAP via LDIF é necessário que esse hash esteja em base64. Ao informar este parâmetro como "True" um algoritmo é usado durante a importação dos dados para transformar o valor hexa em base64, de forma a preservar o hash original da senha no diretório. Caso a senha já esteja no formato base64, ou esteja em texto plano o parâmetro deve ser informado com o valor "false". (Obrigatório) É importante ressaltar que o campo algoritmoSenha, configurado na transformação de "Conta" deve estar preenchido corretamente:

  • SHA, para senhas com hash SHA

  • MD5, para senhas com hash MD5

  • CRYPT, para senhas crypt

  • vazio, para senhas em texto plano

-Log de execução de Jobs e Transformações:

Todo processo executado no PDI terá informações de saída relacionadas ao log do fluxo de trabalho. Isso fornece detalhes sobre o que está acontecendo durante a execução. Os logs podem ser monitorados através do cliente PDI ou da interface online do PDI via navegador: IP_SERVIDOR:8080

Aqui está uma lista de itens com os quais o log pode ajudar:

• Fornece informações relevantes sempre que uma execução do processo apresenta um erro, como etapas que estão falhando e rastreiam com a descrição principal do erro

• Fornece informações sobre um fluxo de trabalho se houver divisão de decisão

• Detecta gargalos e etapas de desempenho abaixo do padrão com base na duração de um procedimento; por exemplo, os tempos de execução armazenados podem ser usados ​​para detectar se um processo está demorando mais do que habitual

• Mostra o status dos processos atualmente em execução. Os logs fornecem informações sobre quando o processo iniciado, onde está atualmente, e dados relacionados ao seu status.

• Rastreia o que foi feito e quando.

Durante a execução dos jobs e transformações no PDI Cliente conseguimos verificar o log de execução da ferramenta.

Neste log conseguimos visualizar os detalhes sobre a execução como tempo restante, número de registros, erros de conexão com as bases de origem ou destino, erros na transformação de dados, excessões, etc

Para acessar este log basta clicar no ícone de engrenagem disponível logo abaixo a tela de exibição do Job:

Existem 7 configurações possíveis para o detalhamento de logs no Spoon:

Nothing - O log está ativado, mas não registra nenhuma saída.

Error - Mostra apenas linhas de erro.

Minimal - Usa apenas o log mínimo. Fornece informações sobre o status dos fluxos de trabalho.

Basic- Recomendação: Use o nível de log Básico (padrão). Ele mostra informações relacionadas a cada etapa.

Detailed - Use isto para solução de problemas: fornece uma saída detalhada de login.

Debug- Uma saída detalhada para fins de depuração. O nível de log de depuração nunca deve ser usado em um ambiente de produção.

Row Level (Very Detailed) - Registrando em um detalhe no nível da linha. Isso gera uma enorme quantidade de dados de saída de log.

Recomendamos usar o log Basic que registra basicamente as informações mais importantes da execução do Job.

Já quando existem erros no processo o tipo Error pode ser útil para identificar o problema rapidamente, e o tipo Row Level para identificar a linha que gerou o erro.

- Log Tomcat e PDI Server

O PDI Server roda no servidor de aplicação Tomcat. O Tomcat possui logs próprios, desta forma quanto o PDI não está disponível o primeiro log que devemos verificar é o do Tomcat.

/opt/pentaho-server/tomcat/logs

Logs disponíveis:

Catalina.out - Loga a maioria dos erros que acontecem na administração da ferramenta WEB

localhost.log -

localhost_access_log.2020-07-31.txt - Logs de acesso

host-manager.2018-08-07.log

manager.data.log

pentaho.log - O log próprio do PDI Server (pentaho.log) também disponível na pasta pode ser consultado para verificar problemas na ferramenta.

- Log do cliente Spoon:

O Spoon (cliente utilizado para acessar o PDI Server) também possui um log onde é possível verificar problemas que impedem a ferramenta de funcionar. Este log fica localizado em: /opt/dataintegration/logs/spoon.log

-Práticas recomendadas para níveis de log:

Os níveis de log devem ser mais baixos em um ambiente de produção ou controle de qualidade, mas podem ser mais altos em um ambiente de desenvolvimento ou não de produção.

O nível de log de depuração nunca deve ser usado em um ambiente de produção.

Os níveis de log também podem ser especificados quando o processo é executado com o PDI Client ou qualquer outra ferramenta de linha de comando.

O desempenho do processo pode ser afetado se o nível de registro de log form muito detalhado. Isso também aumentara a quantidade de informações armazenadas no log.

- Relatório de Erros:

Acesso via IP:8080