Suds

SOAP (o Simple Object Access Protocol) és un protocol de comunicació dissenyat per a intercanviar missatges en format XML entre una xarxa d’ordinadors, utilitzant el protocol HTTP. Normalment s’utilitza per accedir a Serveis web.  Suds és una llibreria de Python que fa la funció de client d’un servei SOAP per a facilitar la connexió amb un Web service.


Aquests darrers dies a l’oficina hem desplegat un projecte nou a l’entorn per mostrar-lo per primera vegada als clients. El cas és que aquest projecte és que es connecta amb un PMS, del qual consulta disponibilitat i li envia les reserves que es realitzin. Per això, s’utilitza un paquet on es troba el servei per la connexió. Aquest paquet utilitza la llibreria Suds, concretament la versió 0.6 del fork suds-jurko, ja que la llibreria original no està mantinguda.


Quina va ser la nostra sorpresa en veure que quan s’instanciava el client per la connexió amb el PMS es produïa un error 500 (Internal Server Error), cosa que no ens havia passat a desenvolupament. La sorpresa va ser més gran en veure que aquest 500 es produïa perquè la llibreria intentava escriure a un fitxer en el qual no tenia permisos, ja que pertanyia a una altre aplicació desplegada al mateix servidor.


Després d’una primera recerca, varem trobar que aquest fitxer era utilitzat com una petita “cache” per la pròpia llibreria i que s’indicava arrel d’un altre fitxer, el “version”. Aquest fitxer “version” la llibreria suds l’escriu per defecte al directori “/tmp/suds/”. Que passava, que quan s’utilitzava la llibreria al client d’aquest projecte, aquesta veia que el fitxer ja estava creat a “/tmp/suds/version” i que aquest l’indicava el fitxer de “cache” de l’altre projecte. Per això, quan anava a escriure en aquest segon fitxer fallava ja que no tenia permisos d’escriptura sobre ell.


Arrel d’això, un company que ja s’hi va trobar fa estona ens va indicar que dos desplegaments diferents que utilitzessin suds al mateix servidor tenien conflictes per aquest motiu però que hi havia una solució: a l’hora de instanciar el client indicar-li quina “cache” ha d’utilitzar, de forma que si no existeix, la crea de vell nou i no es confon agafant la ja existent d’una altre aplicació.


A la vegada que el client de suds, s’ha d’importar l’ObjectCache, al qual se li ha d’indicar a on es situarà la nova “cache” i el temps de durada que es vol que tingui. Per seguir amb com ho fa la llibreria per defecte, el path de la nova “cache” l’indicarem con “/tmp/suds/APP_SLUG”. D’aquesta forma, cada desplegament diferent utilitzarà la seva pròpia “cache”. Llavors, quan se instància el client de suds, se li ha de passar per paràmetre la nova “cache”. Internament, la llibreria tindrà en compte aquesta nova configuració i no entrarà en conflicte amb els altres desplegaments que utilitzin suds.
from suds.client import Client, ObjectCache

cache_path = "/tmp/suds/{}".format(APP_SLUG)
cache = ObjectCache(location=cache_path, days=1)
client = Client(url, cache=cache)
blog comments powered by Disqus