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:

# pkg install 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.

$ pip install --user "celery_tryton"

Faça o download do módulo tryton_synchronization mais recente:

$ hg clone http://hg.b2ck.com/tryton_synchronisation

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:

$ cd tryton_synchronisation
$ python ./setup.py install --user

Instalar Proteus:

$ pip install --user "proteus==3.8"

Adicione o synchronisation_id e synchronisation_url em trytond.conf:

$ editconf

então:

synchronisation_id = the_id_of_your_satellite_instance
synchronisation_url = http://user:password@health.gnu.org:7500/name_of_the_central_instance_database

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

 # service rabbitmq onestart

2) Crie o arquivo de configuração celeryconfig.py com as seguintes entradas

TRYTON_DATABASE = "name_of_your_satellite_instance"
TRYTON_CONFIG = "/home/gnuhealth/gnuhealth/tryton/server/config/trytond.conf"

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.

cdmods
cd local
cp -a $HOME/gnuhealth/doc/samples/health_synchro .
ln -si $HOME/gnuhealth/tryton/server/modules/local/health_synchro $PYTHONPATH/trytond/modules

4) Inicie a instância GNU Health Tryton

 $ cdexe
 $ ./trytond

5) Inicie o gerenciador Celery

 ~/.local/bin $ ./celery --app=celery_synchronisation worker --config=celeryconfig

6) Execute as tarefas

 ./celery call celery_synchronisation.synchronise_new --config=celeryconfig

ou

 ./celery call celery_synchronisation.synchronise_pull_all --config=celeryconfig

ou

 ./celery call celery_synchronisation.synchronise_push_all --config=celeryconfig

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:

class Party(SyncMixin):
    __name__ = 'party.party'
    __metaclass__ = PoolMeta
    unique_id_column = 'code'

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:

class Appointment(SyncUUIDMixin):
    __name__ = 'gnuhealth.appointment'
    __metaclass__ = PoolMeta

Note-se que não há nenhuma unique_id_column na classe usando o SyncUUIDMixin.