Transferência de ficheiros e EDI

O ficheiro não chegou, e ninguém reparou até segunda-feira.

A transferência de ficheiros é o processo mais antigo da empresa e normalmente o menos vigiado: um script shell no cron, sem novas tentativas, sem alertas, sem registo do que circulou. O Dagu mantém os comandos de transferência e acrescenta à sua volta a espera pela chegada, a verificação, as novas tentativas e o histórico.

Instalar o Dagu Ver receitas

Esperar por um ficheiro é um passo, não um ciclo de sondagem que tem de manter

Novas tentativas e alertas de falha em cada transferência

Corre dentro da rede, por isso os ficheiros não dão a volta por um serviço na nuvem

Auto-alojamento gratuito, sem licença por ligação

A integração que ninguém moderniza

Ficheiros de encomendas, faturas, extrações de salários, dados bancários e feeds de stock continuam a circular como ficheiros, a horas certas. A transferência em si é um problema resolvido. O que costuma faltar é tudo o resto à sua volta.

O script sabe enviar o ficheiro. Não sabe o que fazer quando o outro lado está em baixo
A falha é descoberta por alguém a jusante, muitas vezes dias depois, porque um ficheiro em falta é indistinguível de um dia calmo
Ninguém consegue dizer que ficheiro circulou, quando, nem se estava completo, porque nada o registou

Esperar por um ficheiro é um passo

A maioria dos agendadores obriga a escrever um ciclo de sondagem com sleep e contador, e depois a mantê-lo. O Dagu tem uma ação de espera, por isso a janela de chegada é declarada em vez de programada, e um ficheiro que nunca aparece faz a execução falhar em vez de a deixar pendurada.

wait.file sonda o aparecimento, ou o desaparecimento, de um caminho no intervalo que escolher
Um tempo-limite transforma uma entrega falhada numa execução falhada com alerta, em vez de uma tarefa parada até alguém reparar
A verificação corre como passo próprio, por isso um ficheiro truncado ou corrompido trava a importação em vez de a alimentar

Entrada: esperar, verificar, importar, arquivar

# edi-inbound.yaml
schedule: "0 * * * *"
max_active_runs: 1

s3:
  bucket: corp-edi-archive
  region: ap-northeast-1

steps:
  - id: wait_for_delivery
    action: wait.file
    with:
      path: /var/spool/edi/orders.csv
      poll_interval: 30s
    timeout_sec: 1800

  - id: verify
    run: |
      cd /var/spool/edi
      sha256sum -c orders.csv.sha256
    depends: wait_for_delivery

  - id: import
    run: /opt/core/import-orders.sh /var/spool/edi/orders.csv
    depends: verify
    retry_policy:
      limit: 2
      interval_sec: 300

  - id: archive
    action: s3.upload
    with:
      key: edi/inbound/orders.csv
      source: /var/spool/edi/orders.csv
    depends: import

  - id: mark_done
    action: file.move
    with:
      source: /var/spool/edi/orders.csv
      destination: /var/spool/edi/done/orders.csv
      create_dirs: true
    depends: archive

handler_on:
  failure:
    run: /opt/edi/notify-failure.sh

mail_on:
  failure: true

O silêncio é o modo de falha

Uma transferência que falha ruidosamente é um problema pequeno. Uma transferência que falha em silêncio torna-se um projeto de reconciliação. A camada operacional é a parte que vale a pena acrescentar.

retry_policy cobre a indisponibilidade breve do outro lado, que é a maioria das falhas de transferência
mail_on.failure e handler_on.failure fazem chegar uma entrega falhada a alguém na mesma hora
max_active_runs: 1 impede que uma transferência lenta se sobreponha à seguinte e envie o mesmo ficheiro duas vezes

As duas pontas ficam dentro do seu perímetro

Ficheiros que não podem sair da rede são o caso normal na banca, na saúde e no setor público. Um único binário no seu próprio servidor alcança o parceiro por SFTP e o sistema central localmente, sem serviços de terceiros no caminho.

sftp.upload e sftp.download transferem com autenticação por chave e, se necessário, através de um bastião
O mesmo fluxo alcança um sistema local por SSH e um armazenamento de objetos para a cópia de arquivo
Nada passa pela nuvem de um fornecedor, por isso as questões de residência de dados e auditoria mantêm-se simples

Saída: extrair, calcular soma de controlo, enviar

# edi-outbound.yaml
schedule: "30 18 * * 1-5"
max_active_runs: 1

ssh:
  user: edi
  host: sftp.partner.example.com
  key: ~/.ssh/edi_key

steps:
  - id: extract
    run: /opt/core/export-invoices.sh ./outgoing/invoices.csv
    retry_policy:
      limit: 2
      interval_sec: 120

  - id: checksum
    run: |
      cd ./outgoing
      sha256sum invoices.csv > invoices.csv.sha256
    depends: extract

  - id: send_file
    action: sftp.upload
    with:
      source: ./outgoing/invoices.csv
      destination: /inbound/invoices.csv
    depends: checksum
    retry_policy:
      limit: 3
      interval_sec: 60

  - id: send_checksum
    action: sftp.upload
    with:
      source: ./outgoing/invoices.csv.sha256
      destination: /inbound/invoices.csv.sha256
    depends: send_file

handler_on:
  failure:
    run: /opt/edi/notify-failure.sh

mail_on:
  failure: true

Guarde a prova, não apenas o ficheiro

Depois de um incidente, a pergunta raramente é sobre o conteúdo do ficheiro. É sobre quando chegou, se estava completo e quem o voltou a correr.

Cada execução guarda registos por passo, estado, tempos e número de novas tentativas
Arquivar para armazenamento de objetos como passo do fluxo transforma a retenção num agendamento em vez de num hábito
As reexecuções seguem o mesmo caminho registado, por isso uma recuperação manual é tão visível quanto a execução automática

Preço por servidor, não por ligação

Os produtos de transferência gerida de ficheiros são normalmente licenciados por ligação, por parceiro ou por servidor de transferência, e é por isso que a fatura cresce a cada novo parceiro de negócio.

O auto-alojamento Community é gratuito, com servidores e workers ilimitados
O nível licenciado é cobrado por servidor Dagu e acrescenta SSO, separação de perfis e registo de auditoria
Acrescentar um parceiro é acrescentar um ficheiro de fluxo, o que não altera a contagem de licenças

Quando um produto MFT é a melhor resposta

O Dagu agenda e supervisiona transferências. Não é uma plataforma MFT completa, e há requisitos que exigem mesmo uma.

Abrangência de protocolos: se precisa de AS2, OFTP2 ou de uma ligação certificada a uma VAN EDI, use um produto feito para isso
Portais de autosserviço para parceiros, rotação de credenciais por parceiro e recibos de não-repúdio são funcionalidades de MFT, não de um agendador
Regimes de conformidade que exigem um produto de transferência certificado não aceitarão um orquestrador genérico, faça ele o que fizer tecnicamente

FAQ

Practical questions before adopting

O Dagu substitui um produto de transferência gerida de ficheiros?

Para SFTP agendado e integração baseada em ficheiros, normalmente sim: executa a transferência, espera pelas chegadas, verifica, repete, alerta e guarda histórico. Para AS2, OFTP2, ligação certificada a uma VAN EDI, portais de autosserviço para parceiros ou recibos de não-repúdio, não. Essas são funcionalidades de plataforma MFT e um agendador não deve fingir o contrário.

Como disparar com a chegada de um ficheiro em vez de por agendamento?

Corra o fluxo com um agendamento curto e comece-o com um passo wait.file, que sonda o caminho e avança assim que o ficheiro aparecer. Dê um tempo-limite ao passo para que uma entrega que nunca chega falhe e alerte em vez de esperar para sempre. Uma execução também pode ser iniciada externamente por webhook, quando o lado emissor consegue chamar um.

Que protocolos são suportados?

SFTP sobre SSH está integrado como sftp.upload e sftp.download, e as transferências para armazenamento de objetos estão integradas para pontos de acesso compatíveis com S3. Tudo o resto corre como um passo de comando normal, por isso as ferramentas existentes para FTPS, rsync ou um cliente de fornecedor continuam a funcionar, com agendamento e supervisão à volta.

Como são tratadas as credenciais?

A autenticação SSH por chave é a predefinição, com suporte para bastião quando o parceiro está atrás de um. Os segredos são declarados ao nível do fluxo e resolvidos a partir de um fornecedor, como variáveis de ambiente, ficheiro, Vault ou um gestor de segredos na nuvem, e os seus valores são ocultados nos registos de execução.

Funciona onde não há acesso à internet?

Sim. O Dagu é um binário autónomo que não exige base de dados externa nem broker, por isso corre em instalações locais e em redes fechadas. A execução distribuída usa um coordenador e workers por gRPC dentro da sua própria rede.

Next step

Start with one workflow.

Install Dagu, move one script that runs on cron today into YAML, and decide from a real run history.

Instalar o Dagu Ver receitas