Ir para o conteúdo
ou

Software livre Brasil

0 comunidades

Nenhum(a)

 Voltar a TI&Guri
Tela cheia

Datasul via wine em clientes remotos

8 de Junho de 2010, 0:00 , por Software Livre Brasil - 1Um comentário | 1 pessoa seguindo este artigo.
Visualizado 1261 vezes

Bom, aqui vai um pouco da experiência da AAPG pra colocar nosso ERP (Datasul) rodando em nossas regionais.

O problema

É complicado depender de software proprietário. Como se não bastasse todos os problemas que as plataformas closed source carregam a tiracolo (virus, bugs que duram mais que a vida útil do software, flexibilidade de modificação próxima de zero, CUSTO e por aí afora), ainda temos que lidar com as inúmeras restrições que os consultores tentam nos enfiar goela abaixo, visando maximizar o lucro deles e minimizar a nossa inteligência. Um exemplo claríssimo (e caríssimo) é o mundo dos ERPs ou SGIs, os famosos Sistemas de Gerenciamento Integrado. Os SAPs e Totvs da vida.

Só que na hora de a empresa onde vc trabalha contratar uma solução dessas, a última coisa que se vai ouvir no mercado é Software Livre. Motivos? Uma listinha básica:

  1. Estamos falando do DINHEIRO da empresa. Se o sistema de contabilidade tem uma falha, ALGUÉM tem que pagar o pato (e as multas) pela encrenca. No caso de um pacote comprado, uma falha de sistema vai doer no bolso da empresa que comercializa o produto. Se você usa software livre, aos olhos de uma diretoria financeira, não há quem culpar fora da empresa, e isso significa arcar com o ônus do problema.
  2. Empresas ganham e gastam dinheiro. Gastar dinheiro para garantir seus negócios é um "bom negócio" para a empresa, enquanto esse gasto não for maior que o lucro obtido direta ou indiretamente em função desse gasto. E olha que estamos falando de produtos que custam milhares ou milhões de reais apenas para implantar, fora a manutenção mensal...
  3. Uma questão de mercado: apesar de existirem iniciativas opensource com bastante fôlego para pequenas e médias empresas (como por exemplo, o OpenBravo), no segmento de médio-grande para grande porte o mercado é SAP e Datasul. E ninguém está muito disposto a arriscar a grana da empresa com um sistema que não te garanta um SLA altíssimo e várias cláusulas em contrato que digam que se der merda, a culpa é do sistema e não sua...

Bom, isso posto, lá estava eu com um grande problema na mão: tenho um pátio de 13 regionais e mais de 360 polos, todos rodando Ubuntu, lindos e maravilhosos, mas que precisavam acessar o Datasul (SGI rodando na sede). A solução que os consultores me ofereciam é bem conhecida do mercado: Citrix. Só que Citrix é caro pra dedéu, eu ia ter um monte de problemas com a plataforma das pontas (os consultores eram unânimes: "Datasul não vai rodar no linux") e o meu orçamento já estava bem estourado com o custo só do Datasul.

Possibilidades

Pra sair dessa encrenca, o primeiro passo era instalar o cliente Datasul no wine. Existem alguns tutoriais na rede sobre como fazer isso, como em http://www.trudelmer.com.br/blog/?p=326. Curiosamente, esse tutorial foi publicado uns 3 meses DEPOIS que eu eu quebrei a cabeça pra fazer funcionar o Datasul... Bom, pelo menos está mais fácil agora!

Resolvido o problema da instalação, surgiu outro, esse mais grave: minhas estações remotas não teriam como acessar o Datasul, já que para ele funcionar eu precisei mapear uma pasta do servidor na máquina cliente, e fazer isso pela internet seria por demais inseguro, sem falar do tempo que iria demorar para carregar o sistema. Por outro lado, a interface gráfica do Datasul não é das mais complexas, e me lembrei do bom e velho "export DISPLAY". Bom, abrir a porta de telnet não é uma opção exatamente confiável, mas o "ssh -X" daria conta tranquilamente do recado!

A Solução

Agora eu precisava definir o meu ambiente de trabalho. Eu tenho 13 regionais que precisavam acessar o Datasul para lançar solicitações. Então montei um computador quad-core com 4 gb de ram (rodando Ubuntu Server 64 bits) e instalei o wine (exatamente a mesma versão que eu tinha utilizado em meu teste). Em seguida, criei 13 usuários (um para cada regional) e em cada um deles copiei a pasta .wine do sistema teste (tá, fui mais esperto que isso: copiei a pasta .wine para dentro de /etc/skel, assim toda vez que eu criava um usuário novo, o próprio adduser já copiava a pasta .wine para mim...). Faltava só o script de execução.

O script inicial ficou assim:

#!/bin/sh
xhost +
echo Liberando Xhost para conexão

echo conectando ao servidor datasul

ssh -X <usuario>@XXX.XXX.XXX.XXX wine c:/dlc101c/bin/prowin32.exe -pf "Z:/scripts/pems206b.pf" -basekey "ini" -ininame "Z:/scripts/pems206bl.ini" -p "Z:scripts/alias-ems2.p" -param TEC

Esse script funciona, mas é lento. Pesquisando o ssh, descobri o parâmetro -C, que ativa a compactação de dados. Melhorou uns 30% a performance.

Mas ainda podia ser melhor.

Pesquisando um pouco mais, encontrei o sistema NX, desenvolvido pela No Machine (http://www.nomachine.com). Os caras da No Machine foram espertos! Considere uma plataforma de jogo 3D multiplayer qualquer: O que é que trafega na rede durante um jogo? Imagens? Vetores? Cores? Coisa nenhuma! Apenas coordenadas, eventos de teclado e cliques de mouse! O resto quem desenha é o cliente, baseado nessas informações! E se isso pode funcionar bem com um jogo, por que não com um Desktop? Então o que eles fizeram? Embutiram um servidor X com gerenciador de janelas num cliente de SSH, criaram um server que intercepta a comunicação da aplicação com a camada X (compactando e transmitindo essa informação para a camada X do cliente) e desenvolveram uma série de rotinas para otimizar ao máximo a troca de dados cliente-servidor-cliente. Essa gracinha, pra variar, tem uma versão free (que tem uma limitação idiota de 2 usuários simultâneos, e que não me incomoda nem um pouquinho) e outra BEM paga, mas que pode interessar empresas por aí...

Resumindo o coreto: segui o tutorial da Nomachine em http://www.nomachine.com/documents/client/install.php para instalar o servidor NX em meu servidor wine, configurei os clientes com o nxclient e rodei vários testes. A parte legal é que o NXclient permite configurar a conexão escolhendo o tipo de sessão que vc quer abrir, entre Gnome, KDE, CDE e personalizada. Escolhendo essa última, consegui executar o cliente Datasul via wine diretamente na máquina remota, consumindo cerca de 40kbps de banda e com um desempenho bastante razoavel!

Bom, em linhas gerais foi isso. Se alguém quiser mais detalhes, escreva para mim!

Abraço a todos, e até o fisl!


Tags deste artigo: rede wine datasul

1Um comentário

  • F576d235055c8387535a3a7d0232f574?only path=false&size=50&d=wavatarChaves
    17 de Junho de 2014, 21:23

    Datasul

    Amigo,

    você ainda usa essa solução? Ela está funcionando a contento?


Enviar um comentário

Os campos são obrigatórios.

Se você é um usuário registrado, pode se identificar e ser reconhecido automaticamente.