WebService em Python

Tive uma necessidade estes dias de criar um webservice em um servidor linux que retornasse os logs de emails do postfix, fazendo um grep (find) pelo usuário, tipo de protocolo e data.

Pesquisei um pouco, e achei uma solução muito boa, fazer o desenvolvimento do webservice em Python, o que é muito simples e de muito rápida execução.

O servidor que eu estava trabalhando usa CentOS e vinha com as bibliotecas padrões do python instalado, caso o seu sistema não venha, um apt-get install python ou um yum install python deve resolver o problema. Mas eu ainda precisava de mais duas bibliotecas que não vinham com a minha distro: fpconst e SOAPpy. Procurei as duas aqui: http://rpm.pbone.net/, achei a que se enquadrava para o meu sistema operacional i586.

Segue as versões de como eu usei:

mkdir /home/pacotes
cd /home/pacotes/
wget http://pypi.python.org/packages/source/f/fpconst/fpconst-0.7.2.tar.gz#md5=10ba9e04129af23108d24c22c3a698b1
wget http://downloads.sourceforge.net/project/pywebsvcs/SOAP.py/0.12.0_rc1/SOAPpy-0.12.0.tar.gz?use_mirror=ufpr
tar -cvf fpconst-0.7.2.tar.gz
tar -cvf SOAPpy-0.12.0.tar.gz
cd fpconst-0.7.2
python setup.py install
cd ../home/SOAPpy-0.12.0
python setup.py install

Pronto, minhas duas bibliotecas já estavam funcionando.

Agora vamos ao webservice:

#!/usr/bin/python
#import das bibliotecas necessarias
from SOAPpy import SOAPServer
import os
import commands
 
#caminho dos arquivos de logs
caminho = '/root/cirolini/'
 
#identifica se o protocolo for pop ou imap e direciona para a pasta solicitada
def protocolo(protocolo):
        if protocolo == 'popper':
                return 'popper/popper.log'
        if protocolo == 'imap':
                return 'imap/imap.log'
 
#literalmente da um grep nos logs que estao no formato popper.log.2010-03-16T08:00-03:00
def buscaLogs(usuario, proto, data):
        proto = protocolo(proto)
        busca = "zgrep " + usuario + " " + proto + "." + data +"*"
        var = commands.getoutput(busca)
        return var
 
#instancia o webservice para rodar na porta 8081 e responder para pesquisas como localhost
server = SOAPServer(('localhost',8081))
#registra a funcao que vamos chamar no nosso cliente
server.registerFunction(buscaLogs,'ns-buscalogs','buscaLogs')
#indica para o webservice nao parar de executar
server.serve_forever()

Acredito que já deixei tudo bem comentado de como funciona.

E segue o nosso cliente:

#!/usr/bin/python
#importa a biblioteca para fazer o webservice via SOAP
from SOAPpy import SOAPProxy
 
#parametro do webservice para ele saber a porta e o namespace (funcao) que vamos chamar
url = 'http://localhost:8081'
namespace = 'ns-buscalogs'
 
#conecta no webservice
server = SOAPProxy(url,namespace)
#isto para dar um dump das informacoes de entrada e saida
server.config.dumpSOAPOut = 1
server.config.dumpSOAPIn = 1
 
#escreve na tela o retorno da funcao do webservice buscaLogs
print server.buscaLogs('rafael','popper', '2010-03-16')

Os retornos ficaram mais ou menos desta forma:

[root@dsv cirolini]$ python cliente.py
*** Outgoing SOAP ******************************************************
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:buscaLogs xmlns:ns1="ns-buscalogs" SOAP-ENC:root="1">
<v1 xsi:type="xsd:string">rafael</v1>
<v2 xsi:type="xsd:string">popper</v2>
<v3 xsi:type="xsd:string">2010-03-16</v3>
</ns1:buscaLogs>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
************************************************************************
*** Incoming SOAP ******************************************************
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<buscaLogsResponse SOAP-ENC:root="1">
<Result xsi:type="xsd:string">Mar 16 08:46:19: end session - user rafael from 127.0.0.1: time=1 inbox=0/0 quit=1/4/138 stat=1/19/9 auth=1/150099/111 </Result>
</buscaLogsResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
************************************************************************
Mar 16 08:46:19: end session - user rafael from 127.0.0.1: time=1 inbox=0/0 quit=1/4/138 stat=1/19/9 auth=1/150099/111

Fonte: Rafael Cirolini/NerdHead

Tags | desenvolvimento, IRC Skype PCs Linux, python, webservice

URL do WebService dinâmico

Hoje vamos falar sobre um código importante para quem usa URL dinâmica no WebService. Para quem trabalha com vários ambientes de software, essa solução pode valer muito a pena.

Usado:

Ferramenta de desenvolvimento: Visual Studio.NET (qualquer versão)

Linguagem: C#.NET

Framework 3.5 pra cima

Para quem tem os ambientes devidamente separados, é necessário utilizar alguns dados dinâmicos para evitar retrabalho no momento da compilação. Isto é, alterar só no arquivo de configuração de acordo com o ambiente de desenvolvimento, homologação e produção.

Imagine que exista um webservice dentro da ferramenta referenciada, na pasta Web References. A URL desse webservice aponta diretamente para o ambiente de desenvolvimento, porém, é necessário publicar a aplicação no ambiente de homologação.

O webservice já está no ambiente de homologação e a ideia não é referenciar uma nova URL dentro da ferramenta. (Figura 1)

É preciso que esse apontamento de URL seja dinâmico e esteja de acordo com o ambiente que o aplicativo for publicado, isto é, para homologação pegar a URL de “hom”, para “produção” e assim por diante.

Se não for colocado dinamicamente, para cada ambiente é necessário alterar a URL na ferramenta, compilar novamente e publicar no ambiente. Veja a URL (Figura 2). Esse ambiente é de desenvolvimento.

No terceiro campo (Web Reference URL) está o que é preciso mudar. A primeira coisa é declarar a variável no início do código. (Tabela 1)

private WSRetaguarda.Retaguarda wsRetaguarda; //variavel do webservice

Tabela 1

O próximo passo é gerar um método para verificar a variável e atribuir o valor. (Code 1)

private void InicialzarWebService()

{

if (wsRetaguarda == null)

{

wsRetaguarda = new WSRetaguarda.Retaguarda();

wsRetaguarda.Url = pathWebService;

}

else

wsRetaguarda.Url = pathWebService;

}

Esse code 1 verifica primeiramente se a variável é null. Se for, ele gera uma nova instância e atribui a variável URL passando o path do webservice dinâmico. Esse path dinâmico pode estar dentro do arquivo web.config.

Para quem usa a ferramenta Visual Studio .NET 2010, fica bem simples, porque o arquivo de configuração é dinâmico para cada ambiente. Veja o vídeo abaixo e se informe mais.

Vídeo:

link do vídeo

Depois de criar o método e colocar a variável pegando do web.config, basta chamar sempre este método (inicializarWebService()) antes de chamar qualquer outro método do webservice. Veja o exemplo Code 2.

private void carregarDados()

{

try

{

InicialzarWebService();

DataTable dtResultado = wsRetaguarda.buscaModeloHardware();

cmbScanner.DataSource = dtResultado;

cmbScanner.ValueMember = "mhaId";

cmbScanner.DisplayMember = "mhaNome";

if (dtResultado.Rows.Count > 0)

{

foreach (DataRow dtRow in dtResultado.Rows)

{

this._listaMhaUrlInstalacao.Add(Convert.ToInt32(dtRow["mhaId"]), Convert.ToString(dtRow["mhaUrlInstalacao"]));

}

}

}

catch (Exception ex)

{

throw ex;

}

}

É bem simples e fácil, pois agora não é preciso compilar os dados para atribuir a URL de acordo com o ambiente. Caso você use um new chamando o webservice, essa URL se perde, e volta a apontar para desenvolvimento. Isso porque é a primeira da ferramenta do Visual Studio.NET.

Fonte: Mauricio Junior/IMaster

Tags | desenvolvimento, url, Visual Studio .NET 2010, webservice, websites