Desde 2016, a Netflix abriu o código do Netflix Conductor. E, desde a sua abertura, eles têm inserido novas funcionalidades, melhorado a interface do usuário para monitorar os fluxos de trabalho e uma solidificação do sistema como um todo. Graças a essas melhorias, eles têm percebido um aumento na utilização pela comunidade, além de novos casos de uso e solicitações de funcionalidades. Este artigo traz mais algumas funcionalidades importantes adicionadas no último trimestre.

IoC no Conductor

O Conductor possibilita reutilizar os fluxos de trabalho e embuti-los como sub fluxos. Sub fluxos são uma ótima maneira de promover o a reutilização e modularização dos processos. Conforme a adoção do Netflix Conductor cresceu, foram observados alguns casos de uso interessantes onde os processos de negócio eram iniciados baseados nos eventos e mudanças de estado em outros fluxos de trabalho.

Tradicionalmente, as aplicações implementavam tais casos de uso utilizando sistemas de publicação e assinatura (Pub/Sub) e publicando os eventos conforme os estados das aplicações se alteravam e assinando para os eventos de interesse iniciarem as ações.

Assim, os engenheiros da Netflix buscaram uma solução dentro das seguintes características:

1. Fácil integração entre fluxos de trabalho;
2. Permitir iniciar um fluxo de trabalho baseado nas mudanças de estado em outros fluxos;
3. Fornecer a integração com sistemas externos de produção/consumo de eventos via SQS/SNS.

Entra a Inversão de Controles – para fluxos de trabalho. A ideia é poder encadear as ações dos fluxos de trabalho, tais como começar um fluxo, completar uma tarefa etc., baseando-se nas mudanças de estados nos outros fluxos.

Aqui segue um exemplo. Vamos pensar em duas soluções para acionar um “Fluxo QC” depois de um arquivo ser consumido. Assim que o arquivo for consumido, múltiplos fluxos serão acionados (fluxos de aplicações separadas); um deles é um fluxo de verificação de arquivo (Fluxo QC), que é acionado para identificar o tipo do arquivo (Áudio, Vídeo etc.), executar as verificações apropriadas e começar o processo para codificar o arquivo.

Com o Conductor, existem duas maneiras separadas de fazer isso: ambas as soluções realizam a tarefa, mas existem diferenças sutis entre as duas abordagens.

Iniciando outro fluxo como um sub fluxo

Dado que sub fluxos são tarefas, suas saídas podem ser consumidas por outras tarefas no fluxo de consumo do arquivo subsequente ao fluxo QC, por exemplo, o retorno do processo QC. Os sub fluxos, dessa maneira, são úteis quando existe dependência e acoplamento entre os processos.

Iniciando um fluxo em um evento

 

Na abordagem acima, o fluxo de consumo do arquivo produz um evento “Consumo Completo”. Esse evento pode ser consumido por um ou mais manipuladores de eventos para executar as ações – incluindo iniciar um fluxo.

• O fluxo de consumo de arquivos não tem nenhuma dependência direta com outros fluxos;
• Os fluxos podem ser acionados baseados em eventos promovendo uma união simples;
• O retorno da tarefa do fluxo de QC não impacta o fluxo de consumo de arquivos;
• Múltiplos fluxos ou ações podem ser executadas para cada evento.

Tarefa EVENTO

Foi introduzido um novo tipo de tarefa chamado EVENTO. Uma tarefa “evento” pode ser adicionada à definição do fluxo. Quando executada, produz um evento no “tanque” especificado. Um “tanque” é um sistema de eventos como o SQS, Conductor ou qualquer outro sistema suportado. Eles seguem uma arquitetura conectável, na qual sistemas como o JMS, Kafka etc. podem ser adicionados implementando as interfaces necessárias e tornando a implementação disponível no classspath do servidor JVM do Conductor.

Abaixo está um exemplo de uma tarefa “evento” que publica um evento para uma fila SQS identificada pelo nome.

{
    "name": "example_event",
    "taskReferenceName": "event0",
    "input": {
        "filename": "${workflow.input.filename}",
        "location": "${anothertask.output.location}"
    },
    "type": "EVENT",
    "sink": "sqs:sqs_queue_name"
}

Manipuladores de eventos

Os manipuladores de eventos são ouvintes que são executados com a chegada de um evento específico. Os manipuladores acompanham várias fontes de eventos, incluindo o Conductor e o SQS/SNS, e permitem que os usuários conectem outras fontes via APIs. O Conductor suporta múltiplos manipuladores de eventos por tipo de evento. Os manipuladores de eventos são gerenciados com o Conductor utilizando os pontos finais das APIs de eventos. É possível ter múltiplos manipuladores de eventos para uma única fonte de eventos.

Evento “Condition”

Condition é uma expressão JavaScript na carga útil, que DEVE ser avaliada como “Verdadeira” para que o manipulador de eventos execute as ações. O condition atua com um filtro para tomar as ações seletivamente em um subconjunto de eventos que corresponda com os critérios. Filtros condicionais são opcionais e quando não forem especificados, todos os eventos da fonte são processados.

Ações do evento

Cada manipulador de eventos tem uma ou mais ações associadas a ele. Quando a condição associada com um evento for avaliada como “Verdadeira”, as ações serão executadas. As ações suportadas são:

• Iniciar um fluxo;
• Completar uma tarefa como fracassada ou bem sucedida.

Exemplo

Abaixo está uma amostra de um manipulador de eventos que acompanha uma fila SQS e inicia um fluxo baseado na condição:

{
    "name": "conductor_event_test",
    "event": "sqs:example_sqs_queue_name",
    "condition": "$.file_type == 'image'",
    "actions": [
        {
            "action": "start_workflow",
            "start_workflow": {
                "name": "workflow_name",
                "input": {
                    "file_name": "${filename}",
                    "file_type": "${file_type}"
                }
            }
        }
    ],
    "active": true
}

Interface de Usuário do Conductor

Todos os manipuladores de eventos registrados podem ser inspecionados na interface do usuário. Atualizações podem ser realizadas via APIs REST ou através da página do API swagger.

Transformação de dados JSON

O Conductor agora suporta transformação de dados baseada em JSONPath. Utilizando o JSON Path na configuração de entrada para as tarefas permite a transformação de dados complexos e reduz a necessidade de escrever tarefas pontuais que de outra forma fariam a transformação dos dados. Veja mais em https://netflix.github.io/conductor/metadata/#wiring-inputs-and-outputs.

O caminho à frente

Embora os engenheiros da Netlfix tenham realizado todas estas melhorias, eles ainda têm interesse em melhorar o processo. O foco agora é facilitar os testes dos fluxos para os desenvolvedores e suportar o registro do contexto de execução das tarefas, facilitando assim o entendimento e a resolução dos problemas dos fluxos que abrangem múltiplos executores e aplicações.

***

Fonte: http://techblog.netflix.com/2017/04/netflix-conductor-inversion-of-control.html