Execução, ciclos e fases do cenário

Artigo histórico da Make (data não indicada na fonte). Este texto reproduz uma página de documentação da Make. As descrições de recursos e as capturas de tela são da Make no momento da sua publicação; não são uma afirmação deste site nem garantia de que essa documentação continue igual hoje. Para o estado atual da plataforma, consulte as fontes oficiais da Make.

A Make é um sistema transacional, semelhante aos bancos de dados relacionais, em que todas as operações dentro de um cenário são executadas como parte de um processo controlado. Cada execução de cenário passa pelas seguintes fases:

• Inicialização

• Um ou mais ciclos

• Finalização

Fase de inicialização

Durante a fase de inicialização, todas as conexões necessárias são criadas e verificadas. A Make também verifica se cada módulo pode executar a(s) operação(ões) prevista(s).

Ciclos

A fase de inicialização é seguida por pelo menos um ciclo, que consiste em:

• F****ase de operação (leitura ou escrita)

• F****ases de commit/rollback (finalizar ou descartar alterações).

Cada ciclo representa uma unidade de trabalho indivisível composta por uma série de operações. É possível definir o número máximo de ciclos nas configurações do cenário. O número padrão é 1.

Fase de operação

Durante a fase de operação, a Make executa operações de leitura e escrita.

• As o****perações de leitura consistem em obter dados de um serviço, que serão então processados por outros módulos de acordo com um cenário predefinido. Por exemplo, o módulo Dropbox > Watch files retorna novos bundles (arquivos) criados desde a última execução do cenário.

• As o****perações de escrita consistem em enviar dados a um determinado serviço para processamento adicional. Por exemplo, o módulo Dropbox > Upload a file envia um arquivo para uma pasta do Dropbox.

Fases de commit e rollback

Após a fase de operação, a Make faz commit ou rollback das operações:

• Se as operações forem bem-sucedidas em todos os módulos, a fase de commit começa. Durante essa fase, todas as operações executadas pelos módulos são confirmadas. A Make envia a todos os serviços envolvidos na fase de operação a informação sobre o sucesso.

• Se ocorrer um erro durante a fase de operação ou de commit em qualquer módulo, a fase é abortada e a fase de rollback é iniciada, anulando todas as operações daquele ciclo.

Nem todos os módulos permitem rollback. Os módulos que suportam rollback são marcados com a tag ACID. Módulos sem essa tag não suportam rollback e não podem ser revertidos ao seu estado inicial em caso de erro em outros módulos. No contexto de rollbacks, definir o número máximo de ciclos pode ser particularmente útil ao processar vários bundles de um trigger em uma única execução. Por exemplo, considere um cenário em que:

• Você usa um polling trigger para verificar novos dados.

• Você não precisa que o cenário execute a cada minuto, então o agenda para rodar uma vez por hora.

• Há vários bundles para processar em uma execução.

Nesse caso, você tem duas opções:

1. Aumentar o limite do trigger nas configurações do módulo: eleve o número máximo de resultados que o trigger recupera por ciclo (por exemplo, de 2 para 10). O cenário ainda usará um único ciclo, mas processará mais dados de uma vez.

2. Aumentar o número máximo de ciclos nas configurações do cenário: mantenha o limite do trigger baixo (por exemplo, 1), mas configure o cenário para executar em múltiplos ciclos (por exemplo, de 1 para 10).

Se ocorrer um erro ao processar o 10º bundle, por exemplo:

• Com a primeira opção (um ciclo, limites de trigger mais altos), todo o ciclo sofre rollback. Nenhum dos bundles processados é salvo e tudo precisa ser reprocessado na próxima execução.

• Com a segunda opção (múltiplos ciclos, limites de trigger mais baixos), apenas o último ciclo (o bundle que falhou) sofre rollback. Como os ciclos anteriores já foram confirmados, apenas o bundle com falha precisa ser reprocessado na próxima execução. Essa abordagem pode economizar tempo e evitar o reprocessamento desnecessário de trabalho concluído com sucesso.

Fase de finalização

Durante a fase de finalização, as conexões abertas (por exemplo, conexões FTP, conexões de banco de dados etc.) são fechadas e a execução do cenário é concluída.

Exemplo

Transferência de bundles entre bancos de dados O exemplo a seguir mostra como conectar três módulos ACID. O objetivo do cenário é obter novas linhas de um banco de dados MySQL, inseri-las (transferi-las) em um banco de dados MSSQL e, em seguida, inserir os IDs das linhas do banco MSSQL em um banco de dados PostgreSQL.

Quando o cenário inicia, a fase de inicialização é executada primeiro. A Make verifica as conexões com os bancos de dados MySQL, MSSQL e PostgreSQL uma de cada vez. Se tudo correr bem e as conexões forem bem-sucedidas, a Make passa para a fase de operação. Se ocorrer um erro, a fase de finalização começa no lugar da fase de operação e o cenário é encerrado. Se não houver erro, a fase de operação começa. Um procedimento predefinido seleciona (lê) as linhas da tabela (bundles) do MySQL. Essas linhas são então passadas ao próximo módulo, que as grava em uma tabela selecionada do banco de dados MSSQL. Se tudo estiver em ordem, o último procedimento PostgreSQL é chamado para inserir na tabela os IDs de linha retornados pelo módulo anterior. Se a fase de operação for concluída com sucesso, a fase de commit começa. A Make chama o comando SQL COMMIT para cada banco de dados e as operações de escrita são confirmadas. No entanto, se a fase de operação ou de commit falhar devido a um erro (por exemplo, falha de conexão), a Make aciona um rollback. Durante a fase de rollback, a Make percorre todos os módulos e executa o comando SQL ROLLBACK em cada um para reverter cada banco de dados ao seu estado inicial. Por fim, durante a fase de finalização, cada módulo fecha sua conexão com o banco de dados.