django - viewflow - python workflow gui




Cadres de workflow pour Django (4)

J'ai cherché un framework pour simplifier le développement de workflows raisonnablement complexes dans les applications Django. J'aimerais pouvoir utiliser le framework pour automatiser les transitions d'état, les permissions, et peut-être quelques extras comme la journalisation d'audit et les notifications.

J'ai vu des informations plus anciennes sur le même sujet, mais pas trop au cours des 2-3 dernières années. Les principaux choix dont j'ai entendu parler sont GoFlow (pas mis à jour depuis 2/2009) et django-workflow (semble plus actif).

Quelqu'un at-il utilisé ces paquets? Sont-ils matures et / ou compatibles avec Django moderne (1.3)? Existe-t-il d'autres options valant la peine d'être envisagées qui pourraient être mieux ou mieux prises en charge?


Existe-t-il d'autres options valant la peine d'être envisagées qui pourraient être mieux ou mieux prises en charge?

Oui.

Python.

Vous n'avez pas besoin d'un produit de workflow pour automatiser les transitions d'état, les permissions, et peut-être certains extras comme la journalisation d'audit et les notifications.

Il y a une raison pour laquelle peu de projets le font.

  • Le modèle de conception d' état est assez facile à mettre en œuvre.

  • Les règles d'autorisation ("permissioning") sont déjà une partie de première classe de Django.

  • La journalisation est déjà une partie de première classe de Python (et a été ajoutée à Django). L'utilisation de cette fonction pour la journalisation d'audit est soit une table d'audit, soit un autre enregistreur (ou les deux).

  • Le framework de message ("notifications") fait déjà partie de Django.

De quoi d'autre avez-vous besoin? Vous avez déjà tout.

L'utilisation de définitions de classes pour le modèle de conception d' état et de décorateurs pour l'autorisation et la journalisation fonctionne si bien que vous n'avez besoin de rien au-dessus et au-delà de ce que vous avez déjà.

Lisez cette question connexe: Implémentation d'un "moteur de règles" en Python


C'est marrant parce que j'aurais été d'accord avec S.Lott sur l'utilisation de Python comme pour un moteur de règles. J'ai une perspective complètement différente maintenant l'ayant fait.

Si vous voulez un moteur de règles complet, il a besoin de quelques parties mobiles. Nous avons construit un moteur de règles Python / Django complet et vous seriez surpris de voir ce qu'il faut faire pour avoir un moteur de règles génial. J'expliquerai plus loin, mais d'abord le site Web est http://nebrios.com .

Un moteur de règles devrait au moins avoir:

  • Listes de contrôle d'accès - Voulez-vous que tout le monde voit tout?
  • API de paire clé / valeur - Les KVP stockent l'état et toutes les règles réagissent aux états modifiés.
  • Mode de débogage - Être capable de voir chaque changement d'état, ce qui l'a changé et pourquoi. Primordial.
  • Interaction via les formulaires Web et les e - mails - Etre capable de scripter rapidement un formulaire Web est un atout considérable, tout en analysant régulièrement les e-mails entrants.
  • ID de processus - Ils suivent un "fil" de valeur commerciale. Sinon, les processus se chevaucheraient continuellement.
  • Sooo beaucoup plus!

Alors, essayez Nebri, ou les autres que je liste ci-dessous pour voir si elles répondent à vos besoins.

Voici le mode de débogage

Un formulaire généré automatiquement

Un exemple de règle de workflow:

class task_sender(NebriOS):
# send a task to the person it got assigned to
listens_to = ['created_date']

def check(self):
    return (self.created_date is not None) and (self.creator_status != "complete") and (self.assigned is not None)

def action(self):
    send_email (self.assigned,"""
        The ""{{task_title}}"" task was just sent your way!

        Once you finish, send this email back to log the following in the system:

        i_am_finished := true

        It will get assigned back to the task creator to look over.

        Thank you!! - The Nebbs
        """, subject="""{{task_title}}""")

Donc, non, il n'est pas simple de construire un moteur de workflow basé sur des règles basé sur des règles en Python seul. Nous y sommes allés depuis un an! Je recommanderais d'utiliser des outils comme


Permettez-moi de donner quelques notes ici car je suis l'auteur de django-fsm et de django-viewflow, deux projets qui pourraient être appelés "bibliothèques de flux de travail".

Mot de flux de travail lui-même est un peu surfait. Différents types de bibliothèques et de logiciels peuvent s'appeler «workflow» mais ont des fonctionnalités variables. Le point commun est qu'un workflow relie les étapes d'un processus dans un ensemble.

Classification générale

Comme je vois, les approches de mise en œuvre du flux de travail peuvent être classées comme suit:

  • Utilisateurs uniques / multiples - Si la bibliothèque de workflow automatise les tâches d'un seul utilisateur ou possède des options de vérification des autorisations / d'affectation des tâches.
  • Sequential / Parallel - Le workflow séquentiel est juste une implémentation de modèle de machine d'état et permet d'avoir un seul état actif à un instant. Les workflows parallèles permettent d'avoir plusieurs tâches actives à la fois, et ont probablement une sorte de fonctionnalité de synchronisation / jointure parallèle.
  • Explicite / Implicite - Si le flux de travail est représenté comme une entité externe distincte, ou est tissé dans une autre classe, cette responsabilité principale est différente.
  • Statique / Dynamique - Les workflows statiques sont implémentés dans le code python une fois puis exécutés, les flux de travail dynamiques peuvent généralement être configurés en modifiant le contenu des tables de base de données de flux de travail. Les workflows statiques sont généralement mieux intégrés au reste de l'infrastructure django, tels que les vues, les formulaires et les modèles, et permettent une meilleure personnalisation par les constructions python habituelles, comme l'héritage de classe. Les flux de travail dynamiques supposent que vous disposez d'une interface générique capable de s'adapter aux modifications de l'exécution du workflow.

Parmi ceux-ci, les deux premiers pourraient être considérés comme des différences graduelles, mais les deux autres sont fondamentaux.

Forfaits spécifiques

Voici une brève description de ce que nous avons de nos jours dans la liste de projets django, djangopackages et awesome-django sous la section workflow:

  • django.contrib.WizardView - implicite, mono-utilisateur, séquentiel, statique l'implémentation de workflow la plus simple que nous puissions avoir. Il stocke l'état intermédiaire dans la forme cachée après les données.
  • django-flows - django-flows explicite, mono-utilisateur, séquentiel, statique , qui conserve l'état du flux dans le stockage externe, pour permettre à l'utilisateur de fermer ou d'ouvrir une page sur un autre onglet et de continuer à travailler.
  • django-fsm - django-fsm implicite, multi-utilisateur, séquentiel, statique - la bibliothèque de machines d'états la plus compacte et la plus légère. Les événements de changement d'état représentés juste comme les appels de méthodes python de la classe de modèle. A un support rudimentaire pour l'héritage de flux et les remplacements. Fournit des emplacements pour l'autorisation d'associé avec des transitions d'état. Permet d'utiliser un verrouillage optimiste pour éviter les mises à jour d'état simultanées.
  • django-states - django-states explicite, multi-utilisateur, séquentiel , statique avec classe séparée pour les transitions d'état et de machine. Transitions effectuées en transmettant le nom de la chaîne de transition à la méthode make_transition. Fournit un moyen pour l'autorisation d'associé avec des transitions d'état. A un point de terminaison générique REST simple pour changer les états du modèle en utilisant les appels AJAX. La prise en charge de l'héritage des machines d'état n'est pas mentionnée dans la documentation, mais la définition de l'état de la classe le permet sans ou avec quelques modifications de la bibliothèque principale.
  • django_xworkflows - flux de travail explicite, séquentiel et statique sans prise en charge de la vérification des autorisations utilisateur, classe séparée pour la machine d'état. Utilise des tuples pour les définitions d'état et de transition, rend le support d'héritage de workflow difficile.
  • django-workflows - django-workflows explicite, multi-utilisateur, séquentiel, dynamique stockant l'état dans les modèles django fournis par la bibliothèque. A un moyen d'attacher l'autorisation à la transition de flux de travail, et fondamentalement c'est tout.

Aucune de ces bibliothèques de machines d'état django ne prend en charge les workflows parallèles, ce qui limite considérablement leur domaine d'application. Mais il y en a deux qui font:

  • django-viewflow - django-viewflow explicite, multi-utilisateur, parallèle, statique , avec prise en charge de l'exécution de tâches parallèles, de la segmentation complexe et de la jointure de jointure. Fournit des aides à l'intégration avec les vues fonctionnelles et basées sur les classes de django, et différentes requêtes d'exécution des tâches en arrière-plan, ainsi que diverses stratégies de verrouillage pessimistes et optimistes pour empêcher les mises à jour simultanées.

  • GoFlow , mentionné en question, tend à être le flux de travail explicite, multi-utilisateur, parallèle, dynamique , mais il a été abandonné par l'auteur pendant plusieurs années.

Je vois le moyen d'implémenter la fonctionnalité de construction de flux de travail dynamique au-dessus de django-viewflow . Dès qu'il est terminé, si vous fermez le dernier et le cas le plus sophistiqué pour l'implémentation du flux de travail dans le monde django.

L'espoir, si quelqu'un était capable de lire jusqu'à présent, comprend maintenant mieux le terme de flux de travail, et peut faire le choix conscient pour la bibliothèque de flux de travail pour leur projet.


Un paquet écrit par un de mes associés, django-fsm , semble fonctionner - il est à la fois assez léger et suffisamment riche pour être utile.





workflow