2009-09-29 23 views
7

Digamos que está creando una aplicación web basada en Python que requiere alguna gestión de flujo de trabajo, como la de jBPM o Windows Workflow Foundation. ¿Hay una biblioteca que ofrece esto en el mundo de Python?Biblioteca de flujo de trabajo/BPM incrustable para Python?

+0

Por sugerencia de Lennart a continuación, voy a ampliar lo anterior. El sistema consistirá en múltiples clientes que interactúan con una capa intermedia, que, en parte, debe tener un subsistema de flujo de trabajo de algún tipo. El subsistema de flujo de trabajo existe para crear un "BPM incorporado" que puede gestionar de forma flexible los requisitos de procesamiento cambiantes. El primer "cliente" de la capa superior probablemente sea un cliente web que involucre CherryPy y AJAX en el navegador. El backend probablemente será PostGRES. Esto es algo mutable ¿Qué otra información puedo agregar? – alphadogg

+0

Para agregar, digo "primer cliente" porque eventualmente habrá más, y no necesariamente estarán basados ​​en la web, por lo que algo demasiado relacionado con Zope o algún otro marco de trabajo no funcionará. Tiene que poder estar solo. – alphadogg

+1

El sistema de flujo de trabajo debe estar claramente en la capa intermedia, no en los clientes. Luego, los clientes deben preguntar a la capa intermedia sobre qué transacciones de flujo de trabajo están disponibles en función del artículo y la seguridad. Si quiere almacenar cosas en postgres, le recomiendo que use sqlalchemy, y luego SpiffWorkflow puede funcionar, pero no lo he usado y no sé si es bueno. Busque el flujo de trabajo en PyPI, pero tenga en cuenta la mayoría de los productos que existen para Plone. :) –

Respuesta

3

Oh sí, toneladas. Pero la mayoría de ellos depende de un marco específico. DCWorkflow está integrado con Zopes CMF, por ejemplo. hurry.workflow es para Zope 3, etc. SpiffWorkflow supone sql-alquimia, etc. Esto se debe a que necesita tener algo para aplicar el flujo de trabajo, y eso significa que necesita hacer algunas suposiciones básicas sobre los objetos que usa.

Hurry.workflow es probablemente uno de los más independientes, pero aún asume que utiliza la biblioteca Persistence (y por lo tanto en la práctica ZODB) y el modelo de seguridad de zope3.

Así que es probable que tenga que ampliar un poco en sus requerimientos aquí ...

+2

SpiffWorkflow parece ** no ** presumir sql-alquimia, o al menos, no encuentro ninguna referencia apuntando en esa dirección. Podría ser algo que ha cambiado desde esta publicación ... Una búsqueda rápida en la lista de correo parece indicar que [el actual mecamismo de persistencia usa pickle] (http://groups.google.com/group/spiff-devel/browse_frm/ hilo/448348770062f96). –

+1

Solía ​​requerir SQLAlchemy, sí. El escabeche solo es igual de limitante. –

Cuestiones relacionadas