Arquivo da tag: webservice

WebService em Python

Blog, 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

URL do WebService dinâmico

Blog, , , ,

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