Sincronização de arquivos bidirecionais usando o mecanismo de pooling

Interessado em ter sincronizado vários sistemas para gerenciamento de arquivos como Dropbox, Microsoft OneDrive ou Microsoft SharePoint? Deixe-me introduzir alguns princípios básicos, melhores práticas de sincronização bidirecional de arquivos e documentos, como reduzir o tempo de desenvolvimento e os custos financeiros fora do curso.

Desde o início, você precisa cuidar das Interfaces de Programas de Aplicação (APIs) de cada sistema que você deseja sincronizar. Para lidar com a autenticação, aprender a representação de esquemas e princípios, manipulação de dados e trazê-los para uma linguagem comum. Isto pode ser alcançado tanto com o trabalho duro de um desenvolvedor aprendendo centenas de páginas de documentação, ou com uma plataforma de integração.

Acontece que oferecemos uma plataforma de integração com uma tecnologia bastante única, por isso pode considerar a possibilidade de verificar mais sobre a nossa Connect Bridge. Este software permite a utilização de APIs de vários sistemas com o uso de uma simples SQL (Standard Query Language). E não importa se você é .NET ou Java ou qualquer outro desenvolvedor de linguagens. O esquema é visualizado na ferramenta Query Analyzer do Connect Bridge e o desenvolvedor pode testar sua consulta nesta ferramenta e ver os resultados imediatamente. Então você só precisa controlar a base de dados para acompanhar as mudanças e você está pronto para ir.

O princípio do mecanismo de pooling é bastante simples: os dados dos sistemas alvo são recuperados e processados uma vez por período de tempo especificado ou por ação do usuário. E é isso mesmo.

Nem todos os sistemas oferecem a possibilidade de acionar ações após a mudança do arquivo em tempo real. Se um deles não fornecer este recurso, pode causar sérias complicações. Portanto, a principal vantagem é o controle dos dados e do tempo de sincronização dos arquivos. Ele lhe dá uma visão maior do que está acontecendo e abre a possibilidade de evitar ações desnecessárias.

Quanto maior o tempo entre um pool, maior a chance de conflitos entre arquivos.

Na sincronização bidirecional, quando os sistemas estão se modificando, pode acontecer que o mesmo arquivo tenha sido modificado ao mesmo tempo em sistemas diferentes. Mas o que acontece então? Qual deles é a versão correta? Neste caso você precisa especificar qual sistema é o Master e qual é o Slave, a fim de decidir qual versão será substituída.

Para acompanhar as alterações é necessário ter uma base de dados com itens mapeados dos sistemas de destino que foram sincronizados. O reconhecimento da atualização pode ser feito através do tempo de modificação ou versão ou o que for utilizável e fornecido pelos sistemas de destino. Criar ou eliminar é muito simples: se o registo do item não existe na base de dados, é novo e se o item não existe no sistema de destino, mas tem um registo na base de dados, foi eliminado no sistema de destino. E é isso. Alguns dos sistemas têm a possibilidade de pedir alterações num período de tempo especificado, mas de qualquer forma você teria que rastrear o que foi sincronizado devido a falhas causadas por sistemas de destino ou conexão.

Para a lógica de sincronização principal para trabalhar com sistemas-alvo, é bom criar uma classe Provider para cada um deles e implementar a interface comum especificando as operações básicas CRUD (Create-Read-Update-Delete). Então no algoritmo principal não é preciso tomar cuidado com qual é qual. Você pode apenas criar a lógica geral de sincronização bidirecional e as classes Provider irão lidar com a manipulação em si. Se um bom algoritmo de núcleo for implementado, não importa quantos sistemas você está sincronizando. Você pode simplesmente adicionar a implementação de outros provedores. Este algoritmo precisa seguir a hierarquia de mestres e escravos a fim de lidar corretamente com conflitos. Se você sincronizar por pares ordenados por superioridade, deve ser bom.

Não se pode influenciar muito as operações de criação e modificação, mas a parte mais importante é a recuperação de dados. Não há necessidade de recuperar todos os dados. Você pode manter o tempo de sincronização do último arquivo e pedir ao servidor apenas itens com tempo mais recente de criação e modificação. As operações de exclusão dependem da lógica do servidor. Algumas delas fornecem operações de exclusão em massa. Além disso, se a pasta inteira foi excluída e a lógica do servidor exclui todos os subitens dentro do item excluído, não faz sentido excluí-lo um a um.

Primeiro de tudo, não é uma boa idéia recuperar dados de diferentes lugares em lugares de código porque se você dividi-los entre operações de longa duração como upload de arquivos, enquanto o usuário pode alterar o conteúdo dos sistemas e você estará trabalhando com dados diferentes com o mesmo contexto de programa, o que causará sérios problemas e pode levar à perda de dados.

Durante o processo, podem ocorrer várias exceções que você não pode influenciar, tais como erro do servidor interno dos sistemas alvo ou perda de conexão, etc. A melhor prática é dividir o tratamento de exceções em unidades separadas cobrindo códigos que podem tentar ser executados até que todas as operações estejam concluídas, mas não continuar para a unidade seguinte. É uma espécie de árvore de níveis. Vou dar um exemplo: sua sincronização descobre que existiam 10 arquivos em 5 pastas criadas no primeiro sistema. Então começará a criar essas 5 pastas em outros sistemas, mas uma das operações de inserção lança uma exceção. Pode tentar criar essas outras 4 pastas mas não deve começar a inserir ficheiros porque os caminhos de 2 ficheiros não existem. Pode ser tratado de uma forma diferente e mais complicada, mas confie em mim para mantê-lo o mais simples possível. A contagem de variações de possíveis cenários de erro na sincronização bidirecional de mais sistemas é muito grande e, além disso, recursiva.