Multi File Transfer em BPMN: lógica de sincronização personalizada entre clouds e armazenamentos, com verificação de conteúdo

Lugar na arquitetura

A transferência é executada como processos BPMN versionados no MEF.DEV BPMN Low-code na Enablement & Monetization Platform, e não como uma aplicação separada. Os processos herdam o alinhamento da plataforma com a ODA: as funções de API correspondem ao papel dos componentes ODA, e o Kubernetes com entrega GitOps é o ambiente de operação. O contrato de cada processo é a sua fronteira tipada.

Componentes

• Lista de rotas Uma lista SharePoint com caminho de origem, caminho de destino, modo de preenchimento inicial e um indicador de rota ativa. Um administrador SharePoint edita-a; a plataforma lê-a no início de um ciclo, compara-a com o snapshot armazenado e escreve o estado.
• Processo de ciclo transfer_files serve uma drive durante um ciclo.
• Processo de ficheiro transfer_file move um ficheiro em quatro operações tipadas.
• Plugin de backend Executa as operações sobre o Microsoft Graph e o SFTPGo.
• Task worker Retoma o trabalho inacabado após uma falha.

Contratos

• DriveWorkModel Entrada de um ciclo: chave da drive, posição armazenada (DeltaLink), rotas a servir e memória das rotas.
• FileTransferModel Entrada de uma transferência: operationId, transporte e caminho de origem, transporte e caminho de destino, nome final.
• OperationResult Estado com código de erro, identificador de correlação e retryAfterSeconds. Uma recusa como FinalNameConflict regressa como resultado, e quem chama decide pelo estado.
• Resultados do ciclo COMMITTED, NOT_COMMITTED, NO_DELTA_LINK e, em modo de depuração, PLANNED_ONLY.
• Credenciais O valor de um access token não atravessa a fronteira BPMN: a credencial é aplicada ao contexto da ligação. A aplicação usa Sites.Selected com consentimento do administrador.

Fluxo de um ciclo

1. Uma notificação apenas sinaliza uma alteração. O ciclo lê as alterações através do Microsoft Graph, página a página, a partir da posição armazenada.
2. Uma alteração posterior de um ficheiro substitui a anterior, pelo que um ficheiro é transferido no máximo uma vez por rota num ciclo.
3. O ciclo planeia uma transferência por ficheiro e rota e chama transfer_file para cada uma, sequencialmente.
4. Cada transferência resolve o destino, lê a origem, carrega para uma localização temporária e finaliza com o nome final. O ficheiro só fica visível no destino neste último passo.
5. A nova posição, com a memória das rotas, só é confirmada quando todas as transferências estiverem concluídas; caso contrário, o ciclo seguinte recomeça a partir da posição antiga.

Recuperação

• O estado de cada chamada é guardado: após um reinício, os ficheiros concluídos não são transferidos de novo, e o passo interrompido é executado de novo desde o início.
• Um worker retoma a tarefa inacabada e continua a mesma instância principal; um segundo host assume o trabalho depois de o primeiro parar.
• Um reinício não retoma os bytes a partir de um offset, e uma operação posterior ao último estado guardado pode repetir-se.

Pontos de integração

• Microsoft 365 HTTPS de saída para o Microsoft Graph através de um forward proxy com allowlist; um endpoint HTTPS de entrada no reverse proxy da DMZ (Demilitarized Zone) para as notificações.
• SFTPGo Para cada rota, o administrador do SFTPGo define as zonas staging, published e quarantine, uma conta técnica, uma regra de evento de upload para o message broker e uma verificação ICAP como condição de publicação. Os parceiros veem apenas published.
• Plataforma Um message broker, uma base de dados para o diário de transferências, cursores e subscrições, e um agendador para a renovação de subscrições e um ciclo de controlo diário.

Pessoas no controlo

O administrador SharePoint é o responsável pelas rotas e coloca-as em pausa ou retoma-as. O processo repete automaticamente as transferências falhadas, e um serviço externo controla a quarentena através de ICAP.

Limites

• Uma rota é unidirecional; a direção oposta é uma rota separada, com pastas separadas.
• As eliminações não são propagadas, e um ficheiro renomeado conta como novo.
• As permissões, o histórico de versões e os metadados SharePoint não são transferidos.
• A ordem entre ficheiros não é preservada; o modo de preenchimento inicial é fixado quando a rota é criada.

Âmbito da solução

O âmbito dos ciclos de quarentena e de controlo acima é acordado no projeto.

Profundidade técnica em platform.mef.dev →