Предложить постоянную стратегию для системы документооборота - PullRequest
1 голос
/ 26 января 2011

Я нахожусь в процессе создания инструмента конфигурации пользовательского интерфейса для моего любимого проекта.Один из аспектов этого инструмента позволяет конечному пользователю определить свою оркестровку.Затем мне нужно сохранить это определение оркестровки в базе данных.Будет запущенная версия этого определения в работающей системе.Исполняемая версия создается динамически по требованию.

Идея состоит в том, чтобы отделить DEFINITION от EXECUTABLE версии, чтобы у меня была возможность выбрать версию времени выполнения среди BPMNили JPDL, или решение для рабочих процессов на основе POJO (BeanFlow).

Ограничение : я не могу использовать редакторы BPMN, которые поставляются с такими платформами, как jBPM, Activiti и т. д., поскольку я не хочу использоватьмой собственный пользовательский интерфейс, специфичный для моего домена.

Мне нужны предложения о том, КАК ПЕРЕСМОТРЕТЬ определение.

  1. Должен ли я использовать таблицы rdbms?Если да, есть ли схема БД, которую я могу позаимствовать, которая близка к концепции оркестровки?

  2. Должен ли я сериализовать свое определение в экземплярный документ BPMN / JPDL XML?

  3. Есть ли другие простые форматы, которые я могу использовать?

Ответы [ 4 ]

2 голосов
/ 27 января 2011

Под "оркестровкой" я предполагаю, что вы имеете в виду конечный автомат .Где текущее состояние диктует, какие переходы могут быть выполнены в другие состояния.Представление состояний и переходов в виде ребер и вершин часто приводит к направленному ациклическому графу , однако бывают циклы (например, черновик - отправить на утверждение -> в ожидании утверждения - отклонить -> Черновик).

На практике, отделяя определение от вызовов выполнения для постоянного формата, который может легко приспособить настройку.По мере развития вашей системы вы обнаружите ряд непредвиденных крайних случаев, решение которых не должно требовать изменения схемы постоянства, а только кода.Это подразумевает XML или решение NoSQL - то, чья схема легко изменяется или не существует.

Теперь, написав собственное определение XML для этой цели (по неинтересным причинам, я исключу), я предлагаю использовать JPDL (или BPMN).Причина в том, что их определения, скорее всего, включают в себя все, что вы рассматриваете сейчас, будете в будущем и включите настройку - например, вывешивание произвольных данных или поведения на них в заданной точке.Вы также получаете преимущество уже созданных инструментов - не только пользовательского интерфейса - для работы с обнаружением цикла и обеспечения, например, пути к завершению.

Некоторые интересные функции, которыми я владею в JPDL, - это способность помочьобъединить разветвленные процессы, синхронизированные задачи (в том числе периодически повторяющиеся) и средства для отправки уведомлений.Этот последний пункт - уведомление - имеет некоторое дальнейшее изложение.Одна из вещей, которые я обнаружил в своей собственной системе, - это необходимость отправки настраиваемой электронной почты, содержимое которой основано на данных, проходящих через нее.Эти существующие механизмы делают это относительно легко, предоставляя способ вставлять переменные, например, в текст, который затем динамически оценивается во время выполнения перед передачей.Кроме того, они обеспечивают мосты между механизмом и любым хранилищем пользователей с целью отправки уведомлений группам людей, выполнения их задач и обеспечения соблюдения политики безопасности.

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

1 голос
/ 26 января 2011

Я бы НЕ использовал таблицы rdbms, или, если вы это сделаете, сохраните определения в виде текстовых BLOB-объектов.Попытка сделать записи для определения - плохая идея, потому что это гораздо более негибко и со временем изменить ваше определение.Многие люди использовали бы разные подходы, но я бы использовал JSON или YAML и избегал XML.Мотивация для этого - сделать это как можно более простым.Попытка использовать XML, особенно формализованный конкретный формат XML, заставит вас тратить гораздо больше времени на выполнение точной спецификации, которая на самом деле ничего не делает, чтобы помочь тому, чего вы пытаетесь достичь.С JSON и YAML очень легко работать с точки зрения кода.YAML легче читается людьми и его легче редактировать, и он не так сложен для пунктуации и экранирования, как JSON.JSON более широко используется и меньше, чем YAML.У JSON также есть двоичный аналог, BSON, если важен размер документа.

Как только у вас есть импортер / экспортер, который переходит в / из ваших внутренних объектов в ваш формат данных, затем сохраняется с использованием RDBMS или других механизмовбудет просто.Вы даже можете использовать CouchDB, который может предложить другие преимущества для вашего приложения и может подойти.

1 голос
/ 26 января 2011

Очень хороший вопрос!Вот мои два цента:

  1. RDBMS : если вы сделаете это, вы сможете запрашивать экземпляры рабочего процесса, например, какие токены находятся в «узле X»?
  2. Сохранение XML в виде clob: простота - это правда этого решения, но вы не можете на самом деле запросить их, просто получите их по id
  3. NOSQL : есть много разных решений для разных проблем. MongoDB - популярное решение, обеспечивающее постоянное хранение документов.
0 голосов
/ 26 января 2011

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

...