Transforme seu Magic Batch Server num Magic Windows Service

Imagem_001

Batch Server é uma técnica utilizada com Magic xpa para a programação de processos de negócio que devem executar no servidor, em paralelo às atividades dos demais usuários do sistema, e sem a interação destes.

O caminho natural (mais correto) para este tipo de programação no Magic xpa seria a criação de rotinas ‘batch’ para execução pelo Magic xpa Enterprise Server (licenças MGENT1 ou MGENT2) ou ter estas rotinas como um ‘fluxo’ de um projeto Magic xpi.

Na prática, porém, para simplificar o processo ou até aproveitar um ambiente Magic xpa já existente,  muitos desenvolvedores partem mesmo para uma solução “alternativa” do modelo Batch Server, que se resume a dedicar uma máquina (estação ou servidor) para ficar executando uma rotina ‘batch’ ininterruptamente, e sem exigir interação do usuário:

Imagem_002

É o famoso “inicie o sistema e deixe ele executando”.

Esta arquitetura permite a utilização de um Magic xpa Open Client (licença MGCSRT) ou Magic xpa XPress (licença MGXRT) padrão.

Contudo, a não interação com o usuário não é 100%.

Ao menos para iniciar o projeto, é necessário alguém (um usuário) que ‘dê o start’ manualmente no Magic xpa.

E isso precisa ser feito através de uma sessão interativa, ou seja, este usuário precisa antes ter efetuado o seu ‘login’ no sistema operacional. E por conta disso, se efetuar o ‘logoff’ o  Magic xpa para de executar (pois estava atrelado a esta sessão interativa do SO).

E caso a máquina seja reiniciada, todo o processo (‘login’ + ‘start’) precisa ser repetido.

Esta pode não ser uma solução ‘elegante’ para sistemas desta natureza.

Este tipo de aplicação deve idealmente ser definida com um ‘serviço’ do sistema operacional, para evitar estes transtornos. Os ‘serviços’ já são desenhados para executar automaticamente na inicialização da máquina, em segundo plano (background), sem requerer ação de pessoas.

Mas nem o Magic xpa Open Client (licença MGCSRT) ou Magic xpa XPress (licença MGXRT) podem ser executados como um serviço, segundo a sua arquitetura. Apenas o Magic Broker (usado no Magic xpa Enterprise Server e Magic xpa RIA Server) está tecnicamente preparado para isso, já que os softwares precisam ficar trocando mensagens especiais (CONTROL CODES) com o gerenciador de serviços, a respeito do seu funcionamento.

Entretanto, é possível contornar isto com um utilitário chamado Non-Sucking Service Manager ( nssm ).

Ele permite executar sistemas interativos como se fossem serviços não interativos. É desenvolvido para interagir com o gerenciador de serviços do SO (rodar como serviço) e sua única lógica é ativar (abrir) outro sistema para executar debaixo dele.

Como isso, podemos fazer os Batch Servers Magic xpa executarem como um serviço do sistema operacional.

Vejamos como:

Descompacte o NSSM num pasta qualquer, no mesmo servidor onde está instalado o Magic xpa que irá executar o sistema Batch Server:

Imagem_003

Através da linha de comando (cmd), vá até a pasta ‘win32(porque o Magic xpa é um sistema 32 bits) e digite nssm install:

Imagem_004

 

Isso nos dá acesso à interface de instalação do serviço.

Na pasta ‘Application’, teremos: 

Path: Caminho completo do Magic xpa 

Startup directory: Normalmente é a mesma pasta do Magic xpa, mas pode também ser a pasta onde está o MAGIC.INI. 

Arguments: Todos os parâmetros que passaríamos ao Magic xpa no atalho podem ser informados aqui. Por exemplo:

/LicenseName=MGCSRT /DeploymentMode=O /InputPassword=N /StartApplication=C:\\MSE\\Magic\\xpa\\2.5a\\Projects\\BatchServerDEMO\\BatchServerDEMO.ecf /USER=BATCHSERVER

NOTA: O parâmetro /USER é para fazer logon automático no Magic xpa, quando as rotinas a serem executadas dependem de direitos (função RIGHTS) específicos, associados a um usuário. O logon automático só é possível quando o usuário está cadastrado sem senha.

Service name: É o nome do serviço que será criado no SO. Exemplo: MgcXpaBatchSrv.

Imagem_005Na pasta ‘Details’, teremos:

Display name e Description: Informações adicionais do serviço, que irão aparecer no gerenciador de serviços do SO.

Startup type: Tipo de inicialização do serviço (manual, automática, etc…).

Imagem_006

Na pasta ‘Shutdown’, devemos controlar os timeouts de encerramento do processo Magic xpa, quando for realizado o STOP do nosso serviço. A intenção é dar tempo suficiente ao  Magic xpa para encerrar seus programas, sem ultrapassar os valores default do SO (ex: 20s no MS-Windows).

Imagem_007

Na pasta ‘Exit actions’, devemos controlar o que fazer caso o Magic xpa, termine (aborte) sua execução inesperadamente (sem ser por um comando STOP do nosso serviço).  Em geral, escolhemos entre ‘Restart application(reiniciar o Magic xpa) ou ‘Stop service(fazer o serviço parar também). Vai depender da sua conveniência.

Imagem_008

Na pasta ‘Logon’, podemos controlar as credenciais a serem usadas para a execução deste serviço.

Imagem_009

 

Na pasta ‘Environment’, podemos acrescentar ou alterar variáveis de ambiente especificamente para o contexto deste serviço.

Imagem_010

E existem ainda outros ajustes finos, disponíveis nas demais pastas.

Após a instalação do serviço (Install service):

Imagem_011

Veremos que ele estará disponível no gerenciador de serviços do SO:

Imagem_012

Se futuramente algumas das configurações precisarem ser alteradas, isso também pode ser feito diretamente pelo Registro do Sistema, na chave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<seu_servico>

Imagem_013

Quando este serviço é iniciado, veremos que o Magic xpa é executado como um sub processo do NSSM, com todos os argumentos eventualmente definidos:

Imagem_014

Observe que nesta modalidade, nenhuma das janelas das rotinas ‘batch’ serão exibidas, mesmo que definidas como Open=YES. Isso porque todo serviço é executado pelo SO em sessões não interativas.

As rotinas ‘batch’ do sistema Batch Server devem estar sempre preparadas para resolverem sozinhas todas as exceções, sem apresentar MessageBox, InputBox ou qualquer outra interface interativa.

É importante também atentar para outras características específicas dos contexto de execução de serviços, como o fato que por padrão, serviços não conseguem acessar drives de rede mapeados (G:, J:, M:, etc). Estes drives de rede só conseguem ser acessados através do seu nome UNC, exemplo: \\<Servidor>\<SharedFolder>\<ResourceName>.

Manoel Frederico Silva – Gerente de Produto e Evangelista de Tecnologia – Magic Brasil
Manoel Frederico Silva – Gerente de Produto e Evangelista de Tecnologia – Magic Brasil

Para receber os artigos do Blog Magic Brasil em primeira mão no seu email registre-se aqui

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *