Wikilivros

GNU Health/Guia de Sincronização

< GNU Health
Não existem edições revistas desta página, por isso pode ainda não ter sido verificada a sua aderência aos padrões de qualidade.

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

editar

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

editar
  • 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

editar

Satélites

editar

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

editar

(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

editar

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

editar

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

Modelos de Sincronização

editar

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.

Obtido em "https://pt.wikibooks.org/wiki/GNU_Health/Guia_de_Sincronização"