Я написал механизм документооборота, потому что мой работодатель хотел иметь IP, смоделированный по образцу jBPM.Теперь причина, по которой вы используете такой инструмент вместо того, чтобы создавать свой собственный конечный автомат, заключается в том, чтобы приспосабливать изменения без изменения постоянства и поддерживать крайние случаи процессов рабочего процесса, как я объясню.
Адаптация изменений без изменения стойкости
Ваша типичная, или, возможно, лучше сказать, «наивная» реализация с конечным автоматом состоит из набора таблиц базы данных, тесно связанных с управляемыми данными и обработкой их.протекает через.Может быть способ сохранить прошлые версии и отследить, кто предпринял какие действия в течение этого процесса.Где это сталкивается с проблемами изменения данных и структуры процесса.Затем эти тесно связанные таблицы необходимо изменить, чтобы отразить новую структуру, и они могут быть несовместимы со старой.
Механизм документооборота преодолевает эту проблему двумя способами, используя сериализацию для представления данных и процесса и абстрагируя точки интеграции, в частности безопасность.Аспект сериализации означает, что данные и процессы могут перемещаться вместе через систему.Это позволяет экземплярам данных одного типа следовать совершенно разным процессам до такой степени, что процесс может быть изменен во время выполнения, например, путем добавления нового состояния.И ничего из этого не требует изменения основного хранилища.
Точки интеграции - это средство внедрения алгоритмов в процесс и связи с хранилищами аутентификации (т. Е. Пользователи, которые должны предпринять действия).Внедренные алгоритмы могут включать в себя определения того, завершено ли состояние или нет, тогда как примером хранилища аутентификации является LDAP.
Теперь компромисс - это сложный поиск.Например, поскольку данные сериализуются, обычно невозможно запрашивать историческую информацию, кроме как извлекать записи, десериализовать и анализировать с использованием кода.
Edge Cases
Другим аспектом инструмента рабочего процесса является опыт, встроенный в его дизайн и функциональность, который вы, скорее всего, даже не подумаете о том, чтобы катиться по собственной инициативе, и можете пожалеть о том, что вам это понадобится.Два случая, которые приходят мне в голову, это временные задачи и параллельные пути выполнения.
Временные задачи назначают субъекта ответственности за данные по истечении определенного периода времени.Например, скажем, пресс-релиз написан и представлен для одобрения, а затем заседает неделю без рассмотрения.То, что вы, вероятно, хотите, чтобы ваша система делала, - это идентифицируйте этот затянувшийся документ и привлеките внимание соответствующих сторон.
Пути параллельного выполнения в моем опыте встречаются редко (системы управления контентом), но все еще возникают достаточно часто.Идея состоит в том, что данный фрагмент данных отправляется по двум различным путям просмотра или обработки, но для повторного объединения на более позднем этапе.Проблема такого типа требует наличия полезных алгоритмов слияния и умения представлять данные одновременно.Вставить это в домотканое решение по факту намного сложнее, чем может показаться, особенно если вы хотите отслеживать исторические данные.
Заключение
Если ваша система вряд ли изменится, переход на другую может оказаться более простым решением, особенно если изменения могут испортить старую информацию.Но если вы подозреваете, что нуждаетесь в таком типе долговечности или столкнетесь с некоторыми из этих необычных, но непростых сценариев, инструмент рабочего процесса обеспечивает гораздо большую гибкость и страховку, чтобы вы не загнали себя в угол в качестве данных и бизнес-процессов.менять.