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.