Novembro azul: exames preventivos podem auxiliar no diagnóstico precoce de câncer de próstata
14 de novembro de 2019
O que há de novo no RHEL 8.1: correção de kernel, mais informações e na hora certa
22 de novembro de 2019A comunidade Apache NiFi fez um trabalho incrível na versão 1.10. Entre melhorias e novos recursos, foram mais de 360 tickets Jira fechados. Além disso, vários bugs foram corrigidos, o que torna o NiFi ainda mais robusto e estável.
Confira as principais mudanças:
Melhor manipulação de erros
O NiFi 1.10 possui um novo processador chamado RetryFlowFile que simplifica e facilita o tratamento de erros. Na prática, esse novo processador substitui a combinação dos processadores UpdateAttribute e RouteOnAttribute para o controle das tentativas de execução em caso de falha.
Os FlowFiles transmitidos pelo processador RetryFlowFile adquirem um atributo responsável pelo número de tentativas de execução (inicialmente, 1). O nome desse atributo pode ser definido na propriedade “Retry Attribute”, sendo o seu valor padrão “flowfile.retries”. Durante a execução, o valor desse atributo é comparado com o valor configurado na propriedade “Maximum Retries”. Se tal valor for menor que o máximo configurado, o FlowFile será direcionado para o relacionamento “retry”. Do contrário, o FlowFile será direcionado para o relacionamento “retries_exceeded”.
O processador RetryFlowFile também pode penalizar o FlowFile para que este aguarde um determinado tempo antes de ser executado novamente. Isso é muito útil, pois o problema responsável pela falha pode levar alguns segundos para se resolver.
Abaixo demonstramos como o processador RetryFlowFile deve ser configurado para implementar um caso de uso no qual o número máximo de tentativas é 3
Notem que também definimos uma penalização de 30 segundos, configuração essa realizada na aba “Settings”, propriedade “Penalty Duration”:
Veja nesse exemplo que fluxo de ponta a ponta agora é mais limpo e simples de desenvolver:
Arquitetura NiFi Site-to-Site em qualquer nível
O NiFi 1.10 trata as portas de entrada e saída remotas e os grupos de processadores locais como componentes completamente diferentes, o que possibilita o recebimento de dados através do protocolo Site-to-Site (S2S) em qualquer nível.
Quando o DataFlow Manager adiciona uma porta de entrada a um grupo de processadores, o NiFi pergunta explicitamente se essa porta é local ou deve ser usada para uma comunicação S2S com o mundo externo.
A comunicação S2S é um ótimo recurso que suporta a troca de dados entre várias instâncias NiFi/MiNiFi de maneira segura e eficiente. É a base de vários casos de uso, como a migração de dados IoT e Cloud/On-Premises.
As versões anteriores do NiFi obrigavam que a porta de entrada fosse definida no nível raiz, o que tornava a organização e a segurança dos fluxos mais complexas. A versão mais recente do Apache NiFi 1.10 desbloqueia o potencial do protocolo Site-to-Site aceitando a conexão remota direta em qualquer nível de hierarquia do fluxo de dados.
Suporte a parametrização de fluxos por contexto
Para que um componente faça referência a um parâmetro, o seu grupo de processadores deve primeiro receber um contexto de parâmetro. Uma vez atribuído, os processadores e os serviços controladores do grupo de processadores em questão visualizam todos os parâmetros do contexto.
Um grupo de processadores pode ser atribuído apenas a um contexto de parâmetro por vez, enquanto um determinado contexto de parâmetro pode ser atribuído a vários grupos de processadores.
Referência de Componentes agrupados por Grupo de Processadores
Ao atualizar um parâmetro é possível visualizar todos os componentes, e seus respectivos grupos de processadores, que o referenciam, possibilitando assim a identificação da sua cadeia de dependência.
FetchSFTP e FetchFTP a nível de LOG configurável
Em versões anteriores, quando os processadores FetchSFTP/FetchFTP enviavam um FlowFile para o relacionamento “not.found“, também era gerado um erro no log e no Bulletin Board.
Como “not.found” é um relacionamento dedicado ao cenário em que o processador não encontra o arquivo no diretório, não há necessidade de apresentar erro, pois isso afeta o monitoramento baseado no boletim do NIFI (ou em logs).
Agora é possível configurar nos processadores FetchSFTP/FetchFTP o nível de log (ERROR, WARN ou INFO) gerado por tais processadores ao encaminhar FlowFiles para o relacionamento “not.found”.
Expressões padRight e padLeft
Suporte a dois novos métodos da linguagem de expressão (NiFi Expression Language):
padLeft:
-
padLeft (int n) precederá um caractere padrão da sequência de entrada até atingir o comprimento n;
-
padLeft (int n, char c) precederá os caracteres c na string de entrada até atingir o comprimento n.
padRight:
-
padRight (int n) acrescentará um caractere padrão à string de entrada até atingir o comprimento n;
-
padRight (int n, char c) acrescentará o caractere c na string de entrada até atingir o comprimento n.
O caractere padrão deve ser um caractere renderizável, como sublinhado (underscore).
A sequência de entrada já for maior que o comprimento do preenchimento, nenhuma operação deve ser executada.
Exemplo: Se o atributo “example” possuir o valor “foo”, as seguintes expressões fornecerão os seguintes resultados:
|
Expressão |
Valor |
|
${example:padRigth(10)} |
foo_______ |
|
${example:padRigth(10,’@’)} |
foo@@@@@@@ |
|
${example:padRigth(10,’xy’)} |
fooxyxyxyx |
Parar, Configurar e Estado do Processador
Na versão 1.10 do NiFi é possível visualizar em qual estado o processador se encontra (Running ou Stoped), facilitando ainda mais o desenvolvimento e os ajustes no processador.
A lista completa de bugs corrigidos, novos recursos e melhorias do NiFi 1.10 pode ser conferida no link abaixo:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12344993
Links de referência:
