[pyar] Enviar y consumir mensajes hacia y desde Django y .NET

[Emiliano Dalla Verde Marcozzi]

El 23 de febrero de 2015, 10:22, Filly <lady.filly en gmail.com> escribió:

> ¡Buenos días! Estoy medio trabada con algo en que quizás me puedan ayudar.
>
> Tengo un formulario en Django con checkboxes de objetos (los values son
> IDs, los objetos son completamente ajenos a la aplicación de Django).
> Cuando se "submittea" el formulario, debería enviarse a una cola el primer
> ID de la lista.
>
> Del otro lado, .NET debería recibir este mensaje y procesar *stuff* usando
> ese ID. Cuando termine, tendría que enviar un mensaje de confirmación.
> Django, una vez que lea la confirmación, enviaría un nuevo mensaje
> conteniendo el siguiente ID de los que se seleccionaron en el formulario, y
> etc., etc. hasta que ya no queden IDs por procesar.
>
> O al menos de esa forma estaba pensado. Es la primera vez que uso queues
> para conectar aplicaciones completamente separadas, así que estoy medio
> perdida.
>
> Estoy utilizando RabbitMQ para desarrollo local, y en producción se va a
> utilizar Amazon SQS.
>
> Por ahora tengo algo codeado usando Kombu: se crea un Publisher cuando se
> submittea el formulario, y un Consumer que lo utiliza cuando recibe
> mensajes de confirmación... en teoría, porque todavía no lo pude hacer
> andar. Pero antes de seguir renegando con el Consumer quería saber si estoy
> bien encaminada.
>
> Preguntas:
>
> - Teniendo en cuenta que en realidad todo el proceso es sincrónico, ¿es
> correcto este aproach?
>
Entiendo que si ocurren los siguientes pasos, no deberias tener problemas:
1- Django encola #mensaje1 y no encola nada mas hasta tener un response
para #mensaje1
2- .Net consume #mensaje1, lo procesa, y le encola respuesta de #mensaje1 a
Django
3- Django consume respuesta a #mensaje1 , procesa y terminado todo, encola
#mensaje2


>
> - Hasta donde entiendo, Celery sirve para Celery Tasks, es decir, no me
> sería útil en este caso que utiliza mensajes """raw""", ¿me equivoco?
>
Depende del punto de vista del programador :-P. Celery te abstrae de usar
kombu a pelo, y te da facilidades a la hora de escribir
código ('app.send_task('routing_key' ...). Ahora en tu caso en que precisas
sea sincrónico, creo deberías setear a celery para que
solo use un worker, si tenes dos o mas workers laburando, se te complica lo
de sincrónico.
En su momento esta doc me vino muy bien, por ahí te sirve:
http://abhishek-tiwari.com/post/amqp-rabbitmq-and-celery-a-visual-guide-for-dummies

-¿Recomendaciones? ¿Correcciones? ¿Experiencias?
>
Si lo que precisas es que al hacer post del formulario, el request quede
colgado esperando el response, publicas los mensaje y
te quedas esperando con tu consumer la respuesta, hasta que todo termine y
finalmente mandas response, me parece lo mas
piola es que uses kombu a pelo y celery con toda la bola te queda grande.
Saludos!

-- 
Broken code @ https://github.com/edvm

<edvm en python.org.ar>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20150223/4dfdda12/attachment.html>