Рамки рабочего процесса для Django

Ответ 1

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

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

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

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

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

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

Конкретные пакеты

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

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

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

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

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

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

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

Ответ 2

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

Да.

Python.

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

Есть причина, по которой не так много проектов.

• Конструктивный шаблон State довольно прост в реализации.

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

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

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

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

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

Прочитайте этот связанный вопрос: Реализация "механизма правил" в Python

Ответ 3

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

Ответ 4

Это смешно, потому что я согласился бы с S.Lott о просто использовании Python, как для механизма правил. Теперь у меня есть ПОЛНОСТЬЮ другая перспектива.

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

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

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

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

Здесь режим отладки

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

Пример правильного правила работы:

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. Мы были у него уже год! Я бы рекомендовал использовать такие инструменты, как

• http://nebrios.com
• http://pyke.sourceforge.net (это тоже Python!)
• http://decisions.com
• http://clipsrules.sourceforge.net

Ответ 5

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

Посмотрите django-river

Ответ 6

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

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

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

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'