A Plataforma Digibee utiliza um motor que não somente interpreta os pipelines construídos através da interface, mas também os executa. Esse motor é chamado de Pipeline Engine. 

               
Dê uma olhada nos conceitos e na arquitetura de operação do Pipeline Engine.

Tenha a visão em alto nível do Pipeline Engine em relação aos nossos demais componentes da Plataforma:

Cada fluxo (pipeline) criado é convertido em um container Docker, executado com a tecnologia Kubernetes - base da plataforma Digibee. Veja as principais garantias desse modelo de operação:

                               
​Tamanhos de Pipeline

Utilizamos o conceito serverless, ou seja, você não precisa se preocupar com detalhes de infraestrutura para a execução dos seus pipelines. Dessa forma, cada pipeline deve ter o seu tamanho definido durante a implantação. A Plataforma permite que os pipelines sejam utilizados em 3 tamanhos distintos:

                               
​Execuções Simultâneas

Além do tamanho de cada pipeline, você define o número máximo de execuções simultâneas que o pipeline permite. Dependendo do tamanho, um número máximo de execuções simultâneas podem ser configuradas para a execução. Assim, um pipeline com 10 execuções simultâneas pode processar 10 mensagens em paralelo, enquanto um pipeline com 1 execução simultânea pode processar somente 1 mensagem.

                             
​Recursos (CPU e Memória)

Além do mais, o tamanho do pipeline também define o desempenho e a quantidade de memória que ele tem acesso. O desempenho é dado pela quantidade de ciclos de uma CPU a qual o pipeline tem acesso. Por outro lado, a memória é dada pelo espaço endereçável para tratamento de mensagens e consumo de informações.

                           
​Réplicas

As mensagens são enviadas ao mecanismo de filas da Plataforma através de triggers, que são a porta de entrada para a execução dos pipelines. Existem triggers para diferentes tipos de tecnologia, assim como REST, HTTP, Scheduler, Email, etc. Assim que as mensagens chegam ao mecanismo de filas, elas ficam disponíveis para serem consumidas pelos pipelines. Durante a implantação do pipeline, você deve definir seu o número de réplicas. Um pipeline SMALL com 2 réplicas tem o dobro do poder de processamento e assim por diante. Além de prover mais poder de processamento e escalabilidade, as réplicas garantem maior disponibilidade - se uma das réplicas falha, há outras para atender. 

De maneira geral, as réplicas entregam escalabilidade horizontal, enquanto o tamanho do pipeline entrega escalabilidade vertical. Por isso, mesmo que 1 pipeline de tamanho LARGE seja equivalente a 4 pipelines de tamanho SMALL pela lógica da infraestrutura, não significa que eles sejam equivalentes para todos os tipos de cargas de trabalho. Em muitas situações, principalmente naquelas que envolvam o processamento de mensagens grandes, somente a utilização de pipelines "verticalmente" maiores traz o resultado esperado. 

                               
​Timeouts e Expiração

Os triggers podem ser configurados com os seguintes tipos principais de controle de tempo para o processamento de mensagens:

                                           
A configuração de timeout é possível para todos os triggers, mas apenas alguns permitem a configuração da expiração. Isso ocorre porque a característica do trigger pode ser síncrona ou assíncrona.

O trigger de eventos realiza execuções de forma assíncrona e pode manter mensagens em fila por um bom tempo até que sejam consumidas. Por essa razão, faz sentido definir o tempo de expiração das mensagens produzidas por esse tipo de trigger.

Contudo, REST Trigger depende da resposta do pipeline para dar um retorno. Nesse caso, a configuração da expiração não faz sentido. Mesmo assim, internamente, os triggers síncronos estimam o tempo de expiração, não configurável, para as mensagens. Isso garante que as mensagens não se percam no processo de enfileiramento. 

                           
​Controle de Execução

O processamento de mensagens é feito de forma sequencial para cada execução simultânea. Logo, se um pipeline é implantado com 1 execução simultânea, mensagens 1-a-1 são processadas sequencialmente. Enquanto a mensagem é processada, ela recebe uma marca e nenhuma outra réplica de pipeline vai poder recebê-la para processamento. Se um pipeline enfrentar qualquer problema na execução e precisar de um restart (ex.: OOM, crash, etc.), então as mensagens em execução serão devolvidas para o mecanismo de fila.

                               
​Mensagens devolvidas para a fila de processamento

Mensagens devolvidas para a fila de processamento ficam disponíveis para o consumo de outras réplicas de pipeline ou até mesmo pela mesma réplica que teve algum problema e precisou ser reiniciada. 

Nesse caso, é possível configurar o pipeline para definir a abordagem em casos de reprocessamento de mensagens. 

Todos os triggers da Plataforma possuem uma configuração denominada "Allow Redeliveries". Quando essa opção estiver ativada, o pipeline aceita que a mensagem seja reprocessada. Quando desativada, o pipeline recebe a mensagem, detecta que se trata de um reprocessamento e a recusa por meio de um erro.

Também é possível detectar se a mensagem em execução é reprocessada ou não. Para fazer isso, basta utilizar a linguagem Double Braces acessando o escopo de metadados. Exemplo: