Estrutura de projeto e runtime

Esta página mostra como um projeto TunnelHub costuma ser organizado e como o SDK participa da execução.

Estrutura típica

Um template oficial normalmente inclui:

• src/index.ts;
• uma classe de integração em src/core/ ou equivalente;
• metadata;
• tipos e modelos;
• __tests__;
• tunnelhub.yml.

Handler

O handler principal costuma:

• instanciar a classe de integração;
• chamar AutomationExecution.executeAutomation(...);
• retornar sucesso HTTP quando não há erro fatal.

Esse é o ponto de entrada esperado pelo runtime público.

Classe de integração

Essa classe herda um dos flows do SDK e concentra a lógica principal de negócio:

• extração da origem;
• reconciliação com destino, quando houver delta;
• envio, insert, update ou delete;
• definição de metadados.

Payload de execução

Em runtime, a automação recebe um payload que costuma incluir pelo menos:

• identificadores de tenant, ambiente, automação e execução;
• systems associados;
• parameters cadastrados;
• payload do trigger, quando aplicável.

É esse contrato que conecta o produto ao código.

Relação com tunnelhub.yml

tunnelhub.yml define como o projeto será empacotado e publicado. O runtime depende desse arquivo para localizar o artefato e interpretar a configuração básica do serviço.

Fluxo completo

1. a CLI cria a automação e baixa um template;
2. o projeto implementa a integração com o SDK;
3. o build gera o artefato definido em package.artifact;
4. a CLI publica uma nova versão;
5. o produto executa e monitora a automação.