Фреймворки рабочих процессов для Django - PullRequest
43 голосов
/ 22 июля 2011

Я искал платформу для упрощения разработки достаточно сложных рабочих процессов в приложениях Django. Я хотел бы иметь возможность использовать среду для автоматизации переходов между состояниями, разрешений и, возможно, некоторых дополнительных функций, таких как ведение журнала аудита и уведомлений.

Я видел более старую информацию по той же теме, но не слишком много за последние 2-3 года. Основные варианты, о которых я слышал, - это GoFlow (не обновляется с 2/2009) и django-workflow (кажется более активным).

Кто-нибудь использовал эти пакеты? Являются ли они зрелыми и / или совместимыми с современным (1.3) Django? Есть ли другие варианты, которые стоит рассмотреть, которые могут быть лучше или лучше поддерживаются?

Ответы [ 7 ]

81 голосов
/ 08 сентября 2014

Позвольте мне сделать несколько замечаний, поскольку я являюсь автором django-fsm и django-viewflow, двух проектов, которые можно назвать "библиотеками рабочих процессов".

Само слово рабочего процесса немного переоценено. Различные виды библиотек и программного обеспечения могут называть себя «рабочим процессом», но имеют различную функциональность. Общность заключается в том, что рабочий процесс соединяет этапы какого-либо процесса в единое целое.

Общая классификация

Как я вижу, подходы к реализации рабочих процессов можно классифицировать следующим образом:

  • Один / несколько пользователей - автоматизирует ли библиотека рабочего процесса задачи одного пользователя или имеет параметры проверки прав доступа / назначения задач.
  • Последовательный / Параллельный - Последовательный рабочий процесс является просто реализацией шаблона конечного автомата и позволяет в одно мгновение иметь одно активное состояние. Параллельные рабочие процессы позволяют иметь несколько активных задач одновременно и, возможно, имеют некоторую параллельную функциональность синхронизации / объединения.
  • Явный / неявный - Представлен ли рабочий процесс как отдельная внешняя сущность или объединен в какой-то другой класс, эта основная ответственность отличается.
  • Статический / Динамический - Статические рабочие процессы реализуются в коде Python один раз и затем выполняются, динамические рабочие процессы обычно могут настраиваться путем изменения содержимого таблиц базы данных рабочих процессов. Статические рабочие процессы обычно лучше интегрированы с остальной частью инфраструктуры django как представления, формы и шаблоны, и поддерживают лучшую настройку с помощью обычных конструкций Python, таких как наследование классов. Динамические рабочие процессы предполагают, что у вас есть универсальный интерфейс, который можно адаптировать к любым изменениям среды выполнения рабочего процесса.

Из них первые два можно считать постепенными различиями, но два других являются фундаментальными.

Специальные пакеты

Вот краткое описание того, что мы имеем в настоящее время в django, djangopackages и список проектов awesome-django в разделе рабочего процесса:

  • django.contrib.WizardView - неявный, однопользовательский, последовательный, статический простейшая реализация рабочего процесса, которую мы могли иметь. Он хранит промежуточное состояние в скрытой форме данных поста.
  • django-потоки - явный, однопользовательский, последовательный, статический рабочий процесс, который сохраняет состояние потока во внешнем хранилище, чтобы позволить пользователю закрыть или открыть страницу на другой вкладке и продолжить работа.
  • django-fsm - неявный, многопользовательский, последовательный, статический рабочий процесс - самая компактная и легкая библиотека конечных автоматов. События изменения состояния представлены как вызовы методов Python класса модели. Имеет элементарную поддержку наследования потоков и переопределений. Предоставляет слоты для связанного разрешения с переходами состояний. Позволяет использовать оптимистическую блокировку для предотвращения одновременных обновлений состояния.
  • django-состояния - явный, многопользовательский, последовательный , статический рабочий процесс с отдельным классом для конечного автомата и переходов состояний. Переходы, сделанные путем передачи строкового имени перехода в метод make_transition. Предоставляет способ связать разрешение с переходами состояний. Имеет простую общую конечную точку REST для изменения состояний модели с помощью вызовов AJAX. государственный Поддержка наследования компьютеров не упоминается в документации, но определение состояния класса делает это возможным без каких-либо или нескольких модификаций базовой библиотеки.
  • django_xworkflows - явный, последовательный, статический рабочий процесс без поддержки проверки прав пользователя, отдельный класс для конечного автомата. Использует кортежи для определений состояний и переходов, затрудняет поддержку наследования рабочих процессов.
  • django-рабочие процессы - явный, многопользовательский, последовательный, динамический рабочий процесс сохранения состояния в библиотеке, предоставленной моделями django. Есть способ прикрепить разрешение к переходу рабочего процесса, и в основном это все.

Ни одна из этих библиотек конечных автоматов django не поддерживает параллельные рабочие процессы, что сильно ограничивает область их применения.Но есть два, которые делают:

  • django-viewflow - явный, многопользовательский, параллельный, статический рабочий процесс, с поддержкой параллельноговыполнение задач, сложное разбиение и объединение семантических.Предоставляет помощников для интеграции с функциональными представлениями django и представлениями на основе классов, а также с различными запросами на выполнение фоновых задач и различными пессимистичными и оптимистичными стратегиями блокировки для предотвращения одновременных обновлений.

  • GoFlow упомянутый в вопросе, как правило, является явным, многопользовательским, параллельным, динамическим рабочим процессом , но он был оставлен автором в течение многих лет.

Я вижу способ реализации функциональности построения динамического рабочего процесса поверх django-viewflow .Как только он будет завершен, if закроет последний и самый сложный пример реализации рабочего процесса в мире django.

Надеюсь, если кто-то мог читать до сих пор, теперь лучше понимает термин рабочего процесса и можетсделать сознательный выбор для библиотеки рабочего процесса для своего проекта.

7 голосов
/ 22 июля 2011

Есть ли другие варианты, которые стоит рассмотреть, которые могут быть лучше или лучше поддерживаются?

Да.

Python.

Вы нене требуется продукт рабочего процесса для автоматизации переходов состояний, разрешений и, возможно, некоторых дополнительных функций, таких как ведение журнала аудита и уведомления.

Существует причина, по которой не так много проектов делают это.

  • Шаблон проектирования State довольно прост в реализации.

  • Правила авторизации («разрешения») уже являются первоклассной частью Django.

  • Регистрация уже является первоклассной частью Python (и была добавлена ​​в Django).Использование этого для ведения журнала аудита является либо таблицей аудита, либо другим регистратором (или обоими). ​​

  • Структура сообщений ("уведомления") уже является частью Django.

Что еще тебе нужно?У вас уже есть все.

Использование определений классов для шаблона проектирования State и декораторов для авторизации и ведения журнала работает так хорошо, что вам не нужно ничего сверх того, что вы уже сделалиhave.

Прочтите этот связанный вопрос: Реализация «движка правил» в Python

6 голосов
/ 24 сентября 2011

Пакет, написанный моим партнером, django-fsm , похоже, работает - он достаточно легкий и достаточно функциональный, чтобы быть полезным.

5 голосов
/ 28 сентября 2013

Забавно, потому что я бы согласился с С.Лоттом об использовании Python, как и для механизма правил.У меня совершенно другая точка зрения, теперь, сделав это

Если вам нужен полноценный движок правил, ему нужно немало движущихся частей.Мы создали полный движок правил Python / Django, и вы будете удивлены тем, что нужно встроить, чтобы запустить отличный движок правил.Я объясню дальше, но сначала веб-сайт http://nebrios.com.

Механизм правил должен по крайней мере иметь:

  • Списки контроля доступа - Есть ли у васхотите, чтобы все видели все?
  • API пары ключ / значение - KVP сохраняет состояние, и все правила реагируют на измененные состояния.
  • Режим отладки - Возможность видеть каждое измененное состояние, что изменило его и почему.Paramount.
  • Взаимодействие с помощью веб-форм и электронной почты - Возможность быстрого создания сценариев веб-формы является огромным плюсом, наряду с постоянным анализом входящих электронных писем.
  • Идентификаторы процесса - Они отслеживают «поток» деловой ценности.В противном случае процессы будут постоянно перекрываться.
  • Ооочень много!

Так что попробуйте Небри или других, перечисленных ниже, чтобы увидеть, отвечают ли они вашим потребностям.

Вот режим отладки

enter image description here

Автоматически сгенерированная форма

enter image description here

Пример правила рабочего процесса:

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}}""")

Итак, нет, не просто построить основанный на правилах механизм обработки событий на одном только Python.Мы были на этом больше года!Я бы рекомендовал использовать такие инструменты, как

4 голосов
/ 13 июня 2016

Я могу добавить еще одну библиотеку, которая на лету поддерживает изменения компонентов рабочего процесса в отличие от ее эквивалентов.

Посмотрите на река Джанго

1 голос
/ 25 июля 2016

ActivFlow : универсальный, легкий и расширяемый механизм рабочего процесса для гибкой разработки и автоматизации сложных операций бизнес-процессов.

Вы можете смоделировать весь рабочий процесс в кратчайшие сроки!

Шаг 1: регистрация приложения рабочего процесса

WORKFLOW_APPS = ['leave_request']

Шаг 2: настройка активности

from activflow.core.models import AbstractActivity, AbstractInitialActivity
from activflow.leave_request.validators import validate_initial_cap

class RequestInitiation(AbstractInitialActivity):
    """Leave request details"""
    employee_name = CharField(
        "Employee", max_length=200, validators=[validate_initial_cap])
    from = DateField("From Date")
    to = DateField("To Date")
    reason = TextField("Purpose of Leave", blank=True)

    def clean(self):
        """Custom validation logic should go here"""
        pass

class ManagementApproval(AbstractActivity):
    """Management approval"""
    approval_status = CharField(verbose_name="Status", max_length=3, choices=(
        ('APP', 'Approved'), ('REJ', 'Rejected')))
    remarks = TextField("Remarks")

    def clean(self):
        """Custom validation logic should go here"""
        pass

Шаг3: Определение потока

FLOW = {
'initiate_request': {
    'name': 'Leave Request Initiation',
    'model': RequestInitiation,
    'role': 'Submitter',
    'transitions': {
        'management_approval': validate_request,
    }
},
'management_approval': {
    'name': 'Management Approval',
    'model': ManagementApproval,
    'role': 'Approver',
    'transitions': None
    }
}

Шаг 4: Бизнес-правила

def validate_request(self):
    return self.reason == 'Emergency'
0 голосов
/ 08 августа 2018

Я переношу django-goflow из django 1.X-python 2.X, чтобы приспособить его для django 2.X - python 3.x, проект на django2-goflow

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...