Histórico da Página

As funcionalidades do componente de FTP são executadas por um microsserviço (ipass-ftp) que é chamado via API REST pela Engine.

Esse microsserviço contém contém um schema de banco de dados próprio.
Além disso ele possui 3 escopos principais:

1. Gestão do Cadastro de Configurações
Toda vez que é criada, alterada ou removida alguma configuração de componente (conta) de FTP no Core, essa atualização é repassada para o ipaas-ftp. O banco do ipaas-ftp não é um espelho fiel do Core, nele contém somente os dados necessário para efetuar a conexão com os servidores FTP, enquanto que no Core possui mais detalhes.

2. Gestão do Cache das Conexões com o servidores FTP
Por questões de performance e consumo de recursos, o ipaas-ftp possui um cache com as conexões com os servidores FTP. O cache de cada conexão possui um TTL de 24 horas, e após esse prazo ele é invalidado. A invalidação do cache ocorre também nos casos onde o cadastro da configuração usada na conexão sofre alguma alteração.

3. Execução do componente FTP
Atualmente o ipaas-ftp suporta os protocolos FTP e FTPS, mas está previsto o suporte a SFTP.
As funcionalidades disponíveis para cada protocolo são:

• Listar arquivo de uma pasta;
• Efetuar o download de 1 arquivo por vez, com a possibilidade de remover ele o arquivo do servidor FTP após o download ou não;
• Efetuar o upload de 1 arquivo por vez.

Escalabilidade
O ipaas-ftp está preparado para funcionar com 1 ou mais nós simultâneamente.
Justamente por isso que é utilizado o RabbitMQ em sua arquitetura, para que todos os nós fiquem cientes de qualquer alteração que ocorra nas configurações de componente, garantindo assim uma gestão eficiente do cache de conexões.

Particularidades do FTP
Durante testes de carga notamos que os servidores de FTP não permitem que seja efetuada 2 ações com o mesmo usuário em paralelo. Por algum motivo o protocolo é single thread nesse quesito.
Para evitar problemas de concorrência nos servidores FTP dos clientes, e consequentemente erro na execução dos diagramas, foram aplicados blocos de código com synchronized e também foram implementado retry nos métodos críticos. Essa solução tem uma boa margem para melhorias, mas por enquanto é a solução viável que identificamos.

Uma outra particularidade é que a operação de download com remoção do arquivo, pode demorar mais de 5 minutos para concluir, gerando assim um timeout na Engine. O problema disso é que a Engine finaliza a execução do diagrama acusando timeout no FTP, enquanto que o ipaas-ftp vai continuar executando até concluir o download e eliminar o arquivo. Nesse cenário teremos a perda de arquivos, pois ao concluir a execução, o ipaas-ftp simplesmente limpa a memória e o arquivo se perde.
Para evitar esse problema, foi implementado um timeout de 4 minutos na operação de download com remoção de arquivo e em todos os uploads. Dessa maneira o ipaas-ftp irá ativamente reportar o timeout para a Engine, evitando assim que o arquivo baixo não chegue até e Engine e nem se perca.