# GNU Health/Guia de Sincronização

Esta seção se aplica à versão 2.8 do GNU Health.
Aviso!!! O sistema de sincronização atual é obsoleto. Ele será substituído pelo modelo de Federação do GNU Health, a partir de GNU Health 3.2.

## Escopo desse Documento

Este guia tenta cobrir o processo de sincronização entre instâncias GNU Health e sua relação com a instância central. O público-alvo são gerentes de projeto e administradores de sistemas. É bastante geral, e evita ficar muito técnico, embora alguns tópicos e tarefas exigem conhecimento de sistemas operacionais, redes, administração de banco de dados e programação Python.

### Definições

* Instância GNU Health: Instalação independente e autônoma do GNU Health. Ela contém a base de dados, o kernel Tryton e, pelo menos, o módulo de saúde do núcleo.
* Instância Satélite: Cada instância do GNU Health, que faz parte da sincronização.
* Central da Instância: Principal instância do GNU Health (no Ministério da Saúde, por exemplo). Esta é a instância que contém a informação agregada, e recebe as solicitações de sincronização dos casos pela instância satélite.
* RabbitMQ: Entregador de mensagem. Ele é executado no sistema operacional e executado como um daemon.
* Celery: Gerenciador de tarefas/trabalho assíncrono usado pelo Tryton. Ele usa RabbitMQ como aplicação intermediária. As tarefas de sincronização são periodicamente lançadas a partir do sistema operacional em um intervalo fixo pré-definido.

## Instalação de Instâncias Satélites e Centrais
### Satélites

Instalar servidor de sistema de mensagens RabbitMQ:
Instalar Celery-Tryton (localmente, como usuário "gnuhealth" do sistema operacional do servidor). Ele irá instalar Celery como uma dependência.
No GNU Health v2.6, a variável PYTHONPATH está inclusa no ambiente do utilizador.
Faça o download do módulo tryton_synchronization mais recente:
Nota: Você deve usar hg clone somente na primeira vez. Em seguida, use os comandos hg pull e update.
Instale o pacote de sincronização Tryton para os Satélites:
Instalar Proteus:
Adicione o synchronisation_id e synchronisation_url em trytond.conf:
então:
Nota: Substitua user:password pelas credenciais de login reais.

### Executando o Mecanismo de Sincronização em Instâncias Satélites

(Notas tomadas a partir do FreeBSD. As especificações variam de acordo com os sistemas operacionais)
1) Inicie o serviço Rabbit-mq
2) Crie o arquivo de configuração celeryconfig.py com as seguintes entradas
O arquivo celeryconfig.py deve ser guardado em algum lugar disponível em $PYTHONPATH. Vamos usar /home/gnuhealth/gnuhealth/tryton/server/config (o qual é o mesmo valor que $PYTHONPATH).
3) Crie ser módulo personalizado health_synchro
Você precisa especificar o tipo de sincronização que você deseja para sua instância. Nós incluímos um modelo de módulo sincronizado na pasta de documentação ( $ HOME / GNU Health / doc / samples ). Você pode copiar e vincular este módulo no seu diretório de módulos local e personalizá-lo para atender às suas necessidades.
4) Inicie a instância GNU Health Tryton
5) Inicie o gerenciador Celery
6) Execute as tarefas
ou
ou
Estas tarefas serão chamadas de um agendador cron. Você pode ajustar o período para melhor atender suas necessidades.

## Documentação Técnica

Nota: Esta documentação é feita principalmente a partir da documentação original B2CK na sincronização Tryton.
Cada instância de servidor tem uma única identificação (`synchronisation_id`) definida no arquivo de configuração.
A instância Celery oferece três tarefas principais:
* synchronise_push_all: Envia para o servidor principal todas as instâncias modificadas desde a sua última sincronização.
* synchronise_pull_all: Recebe todos os casos conhecidos que foram alterados no servidor principal.
* synchronise_new: Busca todas as instâncias não sincronizados a partir do servidor principal.
As tarefas comunicam com o servidor principal usando o protocolo XML-RPC definido por synchronisation_url no arquivo de configuração. O "celery_synchronisation" usa "celery_tryton" para se integrar com Celery.

### "Mini-Guia" de Desenvolvedores para Mecanismo de Sincronização

O módulo health_synchro contém algumas das seguintes classes.

#### Modelos de Sincronização

Existem dois principais modelos utilizados para sincronizar os registros dos objetos.
* SyncMixin: Sincroniza usando uma chave única existente sobre o modelo.
* SyncUUIDMixin: Usa um Único Identificador Universal (UUID) em cada registro.
SyncMixin
Se o modelo tem um código único, então devemos usar o método SyncMixin para sincronizar os registros. Um bom exemplo para SyncMixin seria o gnuhealth.patient ou os modelos party.party. Ambos têm um atributo de identificação única (campo) e este é o campo que será utilizado pelo mecanismos de sincronização.
Exemplo de utilização do SyncMixin:
Note-se que no modelo SyncMixin, o unique_id_column deve estar sempre presente, e atribuído um campo que é único (neste caso, code).
SyncUUIDMixin
Este método de sincronização é utilizado para eventos que representam modelos dinâmicos. Por exemplo, uma consulta de paciente:
Note-se que não há nenhuma unique_id_column na classe usando o SyncUUIDMixin.