Тексты на тему BPMS в первую очередь акцентируют внимание на бизнес-процессах: схемы, нотации, оркестровка и хореография… Во вторую очередь внимание обычно уделяется разработке экранных форм к шагам процесса и функциональности пользовательского портала. Еще дальше на периферии – бизнес-правила и интеграция. И совсем не в фокусе обычно оказывается моделирование данных на этапе разработки и манипулирование данными в ходе исполнения процесса.
Между тем схема процесса и схема данных – это два ключевых аспекта архитектуры любого процессного приложения, а моделирование процессов и моделирование данных являются для процессного инженера ключевыми компетенциями. Причем не только ключевыми, но и равноправными.
Любой процесс исполняется не в безвоздушном пространстве, а в контексте атрибутов процесса. Которые в любой мало-мальски серьезной задаче, конечно же, представляют собой не просто перечень строк и чисел, а разветвленную структуру данных с мастер-данными, справочниками, связями 1:М и т.п. Поэтому процессный инженер обязан не только владеть нотацией моделирования бизнес-процессов (самой распространенной нотацией сегодня является BPMN), но и уметь проектировать базы данных. А мало говорят о моделировании данных в контексте BPMS не потому, что это не важно, а потому, что база данных и соответствующие умения разработчика подразумеваются.
Так или иначе, это является досадным пробелом. Дело в том, что разные BPMS предлагают существенно различные подходы к моделированию данных, и это заметно отражается на архитектуре результирующей системы управления бизнес-процессами. Поэтому стоит знать заранее, чего вам ждать от той или иной BPMS.
Что же это за подходы?
1. Плоский список атрибутов
Для каждого шаблона бизнес-процесса разработчик может задать список атрибутов, указав для каждого тип – число, строка, дата-время, список значений…
В современных BPMS этот подход не используется в виду крайней примитивности, но его можно встретить в устаревших workflow-системах, которые, однако, могут позиционироваться вендором как BPMS.
2. XML-документ
Разработчику предоставляется возможность определить собственные типы данных и сложные структуры данных. Например, клиентский заказ можно смоделировать как объект, ссылающийся на справочник клиентов и имеющий многострочную часть со списком товаров заказа, в свою очередь ссылающихся на номенклатурный справочник. На физическом уровне все атрибуты процесса сворачиваются в один XML-документ, который записывается в поле TEXT реляционной СУБД.
Такой подход реализован в BPMS от IBM, Oracle, TIBCO, и при первом знакомстве он выглядит очень привлекательно: удобная графическая среда моделирования структуры данных, собственные типы данных. В рамках демонстрации или пилотного проекта можно очень быстро смоделировать процесс данные и представить заказчику работающий прототип.
Однако в дальнейшем, в промышленной эксплуатации, возможны серьезные проблемы:
1) Неудовлетворительное быстродействие
Рассмотрим в качестве примера процесс обработки выписки банка. Получив информацию о поступлении денег на наш расчетный счет, это процесс должен найти экземпляр бизнес-процесса продажи, чтобы послать ему сообщение «платеж поступил». Искать надо по номеру счета, указанного в выписке - он должен совпадать с номером счета в атрибуте искомого экземпляра процесса продажи.
Как будет вестись поиск на физическом уровне? Надо извлечь из база данных XML-документ, содержащий значения атрибутов, разобрать его, найти элемент «номер счета» и сравнить его с искомым. И так перебором по всем активным экземплярам процессов. Хорошо если их десяток. А если десятки тысяч - не затянется ли поиск в этом случае?
Сравниваем с тем, как эту задачу решает обычная реляционная СУБД: индекс на поле «номер счета» и практически мгновенный результат – поиск перебором не используется, время поиска слабо зависит от числа записей.
2) Нарушения ссылочной целостности
Единая и целостная база данных – «святой Грааль» разработчиков информационных систем. Доступ к данным может быть ограничен административно (правами), но технически все со всем надежно провязано. Единая база данных гарантирует, что если, скажем, процесс продажи ссылается на запись клиента, то последняя не может быть удалена – СУБД этого не позволит.
При хранении же данных в виде россыпи XML-документов ссылочная целостность, вообще говоря, не гарантирована.
3) Проприетарные интерфейсы
Данные, хранящиеся в реляционной БД стандартным образом, в виде строк и столбцов, максимально открыты для доступа. Вы можете быть уверены, что сможете при необходимости организовать к ним доступ, например, из корпоративной BI-системы – необходимые коннекторы там гарантированно найдутся.
В ответ вам могут сказать, что у BPMS есть API, через который можно добраться до данных. Это так, но во-первых, чтобы воспользоваться API, придется программировать – сравните с настройкой коннектора, в которой надо просто заполнить несколько полей: тип сервера, адрес, имя базы данных, имя пользователя и пароль.
Во-вторых, что вы будете делать, если сторонняя система, в свою очередь, представляет собой «черный ящик» - механизм взаимодействия со стандартной СУБД в нее заложен, а возможность запрограммировать доступ к произвольному внешнему источнику данных не предусмотрен?
3. Сущность-атрибут-значение
Известно, что любые сколь угодно сложные данные можно представить в виде таблицы из трех столбцов:
- идентификатор объекта
- идентификатор типа атрибута
- значение указанного атрибута для указанного объекта
Как и хранение в виде XML-документа, этот способ вначале привлекает своей универсальностью - вы можете расширять и менять модель данных, не перекраивая структуру базы данных.
Но при широкомасштабном использовании такая организация данных создает серьезные проблемы. Например, если на SQL легко можно реализовать join-запрос, соединяющий десяток таблиц, то в схеме “объект-атрибут-значение” такой запрос и запрограммировать на порядок сложнее, чем написать select в SQL, и быстродействие с ростом числа объектов быстро стремится к нулю.
4. Атрибуты в базе данных по ссылке
Столкнувшись с обозначенными выше проблемами, разработчики процессного приложения в конце концов приходят к выводу, что для хранения данных ничего лучшего, чем честная реляционная БД, не придумано, и добровольно отказываются от богатства возможностей моделирования данных, предоставляемого BPMS.
Наиболее последовательно такой отказ реализуется следующим образом: все атрибуты переносятся в таблицы реляционной БД, и у процесса остается один служебный атрибут – ссылка на первичный ключ записи в реляционной таблице, выделенной под данный процесс.
В результате такой миграции отмеченные выше проблемы с данными решаются, но увы, появляются новые – связанные с пользовательскими интерфейсами.
Дело в том, что встроенные в BPMS средства разработки экранных форм к шагам бизнес-процесса в основном ориентированы на работу с данными, смоделированными собственными средствами BPMS. Перенос данных в стороннюю относительно BPMS базу данных приведет к тому, что разработка форм, как минимум, замедлится, а как максимум, вам придется отказаться от встроенного редактора форм и воспользоваться сторонним фреймворком для разработки веб-приложений.
Причем дело не только в усложнении разработки форм: вместо одного проекта, бесшовно интегрирующего процессы, данные и пользовательские интерфейсы - у вас на руках оказываются три проекта, которые необходимо синхронизировать друг с другом. Например, когда вы меняете схему процесса, соответствующие изменения должны синхронно вноситься в базу данных и в экранные формы. Учитывая, что за разные проекты обычно отвечают разные люди, полностью избежать нестыковок не удается.
Отдельное «удовольствие» – перенос проекта (точнее, трех проектов) из среды разработки в эксплуатационную среду. Пока вы пользовались встроенными средствами BPMS, вы привыкли к тому, что это делается «от одной кнопки». Только отказавшись от встроенных средств, вы сможете по-настоящему оценить эту функциональность.
Все это очень печально с точки зрения методологии: вместо проекта BPM мы пришли к разработке процессно-ориентированного софтверного приложения.
Вы спросите, в чем разница? В вовлеченности бизнеса и в темпе.
Системы BPMS специально спроектированы таким образом, чтобы обеспечивать и то, и другое: логичная, замкнутая среда, органически увязывающая процессы, данные и пользовательские интерфейсы. Это не значит, что бизнес будет сам вести разработку (хотя такое мнение иногда высказывается, это наивное представление) – это и не требуется; достаточно того, что то, что делают в BPMS бизнес-аналитики и разработчики, обозримо и в целом понятно людям бизнеса. А значит, они способны критиковать, давать поправки и генерировать идеи о том, как на самом деле нам следует вести дела. В этом вся суть BPM, его сила.
Отказавшись от встроенных средств моделирования данных и разработки экранных форм, мы эти преимущества теряем.
Если вы отдали процессную работу айтишникам, то по факту они и управляют вашим бизнес-процессом. Не менеджмент, не владелец процесса – программисты! При всем уважении к ним, как к специалистам в своей области, все, на что вы можете в этом случае рассчитывать,– это автоматизация, повышение производительности труда сотрудников, более удобные и эргономичные бизнес-приложения.
Имеет ли это все отношение к итоговым показателям бизнеса - к строке прибылей и убытков? Как правило, нет. Для этого необходимо другое – системный взгляд бизнеса на то, как подразделения компании взаимодействуют друг с другом, а компания в целом – с заказчиком в рамках сквозного бизнес-процесса. Только бизнес – менеджмент, ключевые специалисты – может и должен сказать, как наша компания должна вести дела, чтобы соответствовать ожиданиям клиентов и превосходить конкурентов. Не стоит ожидать этого от программистов.
Кроме того, вовлеченность невозможна без поддержания темпа разработки. Вы можете рассчитывать на заинтересованное участие бизнеса в проекте BPM только в том случае, если интервал времени от идеи по усовершенствованию процесса, высказанной бизнесом, до ее реализации, занимает дни, максимум недели. Месяцы – это уже все равно что никогда, потому что энтузиазм бизнеса за это время неминуемо угаснет.
Простота - это один аспект, обеспечивающий вовлеченность, темп - второй. Сменив встроенные в BPMS средства быстрой разработки на более трудоемкие, мы проигрываем и там, и тут.
5. Прямое использование реляционной базы данных
Хранение атрибутов в XML или в виде триплетов объект-атрибут-значение представляют собой попытку построить “СУБД поверх СУБД”. Спрашивается: не проще ли использовать реляционную СУБД напрямую, без надстроек?
Пример реализации такого подхода - система Bizagi BPM Suite. Как и в любой BPMS, в ней реализованы встроенные средства моделирования данных и разработки экранных форм. Точно так же вы моделируете бизнес-объекты, задавая атрибуты и связи между ними, и точно так же потом «набрасываете» атрибуты на холст, размечая экранные формы.
На физическом уровне все совершенно прямолинейно: сущности отображаются в таблицы, атрибуты - в столбцы таблиц. Каждому шаблону процесса соответствует таблица базы данных, а экземпляру процесса – запись в этой таблице. Помимо этих “процессных” таблиц, в базе данных есть справочники, мастер-данные,… - в общем, все, что мы обычно видим в БД корпоративной информационной системы.
Особенно преимущества этого подхода проявляются, когда вы переходите от первого процесса ко второму, третьему и т.д. При хранении данных в виде XML обращение к данным другого процесса приходится программировать, и объем этого программирования все возрастает, так как чем больше у вас процессов, тем больше взаимодействий между ними. В случае Bizagi, наоборот, добавление каждого следующего процесса обходится дешевле, так как он использует уже имеющиеся мастер-данные и справочники.
При таком подходе разработчики процессного приложения не сталкиваются ни с одной из отмеченных выше проблем.
Можно предположить, что проблемы могли быть у разработчиков Bizagi: им пришлось встроить в BPMS функциональность средств разработки логических схем базы данных, реализовать отображение логической схемы в физическую, автоматизировать перенос схемы базы из среды разработки в эксплуатационную с сохранением данных. Но так или иначе, им это удалось – все работает достаточно стабильно.
Мне лично решение это представляется настолько удачным и притом лежащим на поверхности, что я не понимаю, почему его не взяли на вооружение все разработчики BPMS.
Заключение
Автор изложил взгляд на проблему взаимодействия процессов и данных, основанный на знакомстве приблизительно с десятком BPMS. Но во-первых, знакомство с некоторыми системами было поверхностным, и автор не может по отношению к ним претендовать на звание эксперта, а во-вторых, эта выборка может не представлять весь спектр BPMS. Поэтому автор был бы крайне признателен за поправки и альтернативные мнения со стороны настоящих экспертов в тех или иных BPMS или ссылки на таковые мнения.
Но в любом случае, способ организации взаимодействия процессов и данных в системе BPMS является одним из важнейших аспектов ее архитектуры. Заранее просчитывайте плюсы и минусы выбранного вами решения – способы так или иначе компенсировать проблемы можно найти всегда. Хуже всего, когда архитектурные проблемы застают вас врасплох в середине проекта, и вам приходится перекраивать архитектуру в авральном режиме, ставя проект под угрозу провала.
Anatoly, just curious, how do they handle entities that are nested?
do they store an identifier to refer from, say, an organization entity to a member of the organization (which in turn has its own attributes)? Or do they deal with storage of a list or a nested entity (containment)?
The tool i’m most familiar with is a bit of hybrid, in the environment it is all XML but there’s a straightforward mapping to flat relational tables. An attempt to get best of both worlds
In practice there are still some issues which we’re used to working around.
Scott
Thank you for asking, hope I’ve got your question right.
They operate at the logical level of design: entities and relations, not tables and columns. A subtile nuance but it makes difference in master-details scenario:
- at the physical level there are always two tables linked by primary/foreigh key
- at the logical level there are two distinct scenarios: reference vs. collection
So if you have say a customer’s order that has multi-line part (specification) then you model it as Order entity having a *reference* to Customer entity and *collection* of OrderItem entities. Although references and collections are implemented identically in the database, they are treated differently by UI builder: dropping a collection on a web form canvas produces a grid.
So if Order-Customer link is implemented as a reference, it’s be impossible to display a list of all Customer’s Orders on a web form. If we do need it then the collection should be used, not reference. Maybe tricky at first glance but it soon becomes a natural view.
Анатолий, спасибо за интересную заметку. Мне кажется я даже догадываюсь под влиянием кого и чего эта заметка была написана))). Для поддержания дискуссии постараюсь привести несколько своих соображений на этот счет. Заранее извиняюсь за путанную речь, это импровизация…
Модель хранения VS модель представления данных.
За то время, которое я проработал с BPMS я стал выделять для себя несколько различных моделей описания информационной составляющей исполнения бизнес-процессов:
а) модель хранения данных - это структура данных в среде которых существует процесс. Данная модель отвечает на вопрос как и где хранятся данные, которые могут понадобится для инициирования процесса и сохранения результатов его выполнения. На мой взгяд, модель хранения данных имеет весьма отдаленное отношение к исполняемой модели процесса (и возможно даже не входит в нее). Это объясняется тем, что модель хранения данных может, как вы совершенно справедливо заметили, использоваться для выполнения разных процессов, а следовательно в разных моделях процессов.
б) модель представления данных - это формализованное представление информационного потока, сопровождающего выполнение процесса. Эта модель полностью входит в состав исполняемой модели процесса и содержит в себе только те данные, которые нужны для его выполнения. Эта модель не отвечает на вопрос как и где хранятся данные. Аналитика это совершенно не беспокоит. Главная цель данной модели сделать удобной работу аналитика по описанию процесса и максимально эффективно поддерживать работу с различными версиями процесса. ЖЦ модели представления данных совпадает с моделью процесса.
в) модель переменных процесса - это структура данных, необходимая для временного хранения информации, которая обрабатывается в процессе. По сути, модель переменных процесса есть экземпляр модели представления данных, хотя так говорить достаточно грубо, так как одна переменная процесса может вообще не ссылаться на модель представления (в случае использования примитивных типов данных), либо ссылаться только на часть модели представления (наиболее распространенный случай).
Концептульно я себе представляю эти три модели в виде пирамиды, в основании которой лежит модель хранения, а вершиной является модель переменных. Несмотря на то, что для успешного функционирования BPMS эти модели должны быть хорошо связанны между собой, их существование и изменение происходит достаточно независимо друг от друга. Я хочу сказать, что изменение модели хранения данных, не должно вообще повлиять (или крайне мало) на остальные две модели и наоборот.
ВЫВОД: я хочу согласится с Анатолием, что для хранения данных лучше всего подходят реляционные БД. Однако, я совершенно не согласен с Анатолием, что реляционная БД эффективна для описания модели представления и модели переменных процесса. Постараюсь объяснить свою точку зрения.
В поисках “святого Грааля”.
Действительно, работать с единой структурой данных, покрывающей все области функционирования организации, возможно очень удобно. Почему возможно? Потому что я этого ни разу не встречал. Обычной в реальной жизни в любой организации есть свой зоопарк из ИТ-систем, каждая из которых имеет свою БД. Мне кажется, что строить еще одну БД под BPMS не имеет смысла. Это приведет только к хранению очередной копии данных и к излишней сложности синхронизации данных между системами. Если на вход процесс берет информацию из внешней системы, то логично туда ее и положить после завершения выполнения процесса? А если такого места для хранения результативных данных нет, то может быть стоит задуматься над тем, что мы в рамках BPMS занимаемся разработкой очередного функционального программного приложения? Чтобы меня потом не очень сильно били, я хочу сразу отметить, что я разделяю для себя информацию, генерируемую процессом в среде BPMS на два типа: аналитическая и контекстная. Так вот сейчас речь идет как раз об контекстной информации.
Возвращаясь обратно к своей мысли, мне кажется невозможно создать единую модель хранения информации для всей организации. Во-первых потому, что в момент создания BPMS в организации уже используется много других систем с накопленной информацией, во-вторых, потому что единая БДполучится слишком сложной и запутанной для эффективной работы с ней.
Вывод: далеко не вся информация, которая используется в процессе должна сохраняться в внешней БД. Аналитическая информация наверное вся. И кстати для этого есть отдельных класс информационных систем: BI, аналитические ИС. Использование слоя представления данных между процессом и БД позволяет выборочно сохранять только нужную для будущего контекстную информацию.
В защиту объектно-ориентированных моделей представления данных. После того, как мы разобрались с хранением информации можно поговорить об ее представлении в модели процесса. Я согласен с Анатолием, что хранение информационных объектов в XML-формате влияет на производительность движка-BPMS. Однако, хочу обратить на следующие преимущества такого подхода.
а) гибкость. Объектно-ориентированных подход к описанию данных дает возможность разработчику создавать сложные отношения между отдельными объектами без необходимости создания “лишних” сущностей (связь “многие к многим” в СУБД).
б) функциональность. Объектно-ориентированная модель данных это не только структура информации, это еще и методы по ее обработке. Возможность создавать функции и процедуры обработки данных непосредственно в модели процесса повышает работу разработчика. Да, BPMN позволяет создавать скрипты прямо в активностях процесса, но зададим себе вопрос: там ли это должно размещаться? Я считаю, что сам скрипт есть часть модели данных, а вот доступ к нему (вызов и указание входных выходных параметров) должен осуществляется внутри соответствующих активностей в BPMN. Кстати, сохранение информации в внешние системы (в том числе в SQL БД), на мой взгляд, так же должно являться частью модели представления данных в BPMS системе.
в) версинонность. Анатолий как-то умолчал о том, насколько легко-сложно поддерживать реляционную модель данных: вносить новые атрибуты, удалять не нужные….да, есть специализированные средства для этого. Тот же Power Designer. Но это уже не входит в BPMS и аналитика с этим работать будет научить тяжело…да и не нужно я думаю…В случае объектно-ориентированного подхода, мы можем сколь уогдно и главное как угодно менть модель представления данных, не задумываясь о целостности данных. В это случае, BPMS будет создавать отдельные версии моделей процессов.
г) удобство. Вопрос к Анатолию. Каким образом осуществляется в Bizagi распараллеливание процесса не несколько потоков? Как это моделируется на уровне данных. В случае использования модели переменных это делается элементарно. Автоматически, в случае необходимости, создается отдельная переменная нужного нам типа, и каждая ветка работает с своей переменной. В точке синхронизации вся накопленная информация консолидируется в одной главной переменной.
Пока писал текст, вспомнил наш опыт работы с Bonita BPM. Это к вопросу об XML-формате. В Bonita мы создавали модель представления данных, используя UML activity diagram. После этого генерировали классы Java. В ходе этого обнаружилось, что можно указать отдельно как будут хранится данные в оперативной памяти, в XML-документе или в SQL-БД. Так что XML- это не панацея.
Анатолий наступил мне на мозоль, когда упомянул про поиск нужного процесса. Это действительно было проблемой, пока мы не научились правильно моделировать модель перменных. Большинство переменных имеют тип - ссылку на модель представления данных. Это есть XML-документ. Для данных, по которым потенциально может производится поиск в процессе создаются отдельные переменные примитивных типов. В случае необходимости можно даже хранить их напрямую в SQL БД, минуя встроенные средства BPMS. То есть решать обратную ситуацию, описанную Анатолием про ссылку на запись данных. В данном случае БД хранит ссылки на ЭП. Насколько мне известно каждый ЭП имеет свой уникальный ключ. И этот ключ хранится в реляционной БД. Поиск процесса тогда производится не через чтение XML-документов, а через поиск записи в БД. Так что найти нужный нам процесс будет очень легко и быстро.
Вывод: использование объектно-оринетированных технологий для реализации модели представления данных является обоснованным и эффективным. Однако, для того, чтобы не потерять производительность BPMS системы необходимо правильно проектировать данную модель. Это уже отдельный разговор. Единственное, что можно сейчас сказать точно, это то, что нужно стремится минимизировать отдельные переменные в процессе. Я не могу говорить про все BPMS, но в Oracle BPM каждая переменная представляет собой отдельный XML-документ. Таким образом “читать” нужно не весь XML-ЭП.
Общий вывод: я согласен с Анатолием о том, что для хранения данных лучше SQL БД сложно что-то представить. Однако я считаю, что нельзя применять такую вот уравниловку, что SQL и все, больше ничего не нужно. Нужно. И нужно разделять модели. И работать с каждой из них отдельно и выбирать наиболее адекватные технологии. И я не согласен с Анатолием, что для модели представления данных лучше всего использовать SQL. Я считаю, что тут эффективнее всего выглядят объектно-ориентированные технологии. Но пользоваться ими нужно аккуратно))
PS. Я еще раз прошу прощения за сумбурный текст. Я так же прошу прощения, если где-то жестко отстаивал свою точку зрения. Я преследовал только одну цель - дискуссия, так как известно, что в споре рождается истина;)
Кирилл
Спасибо за содержательный и развернутый ответ. Никакой жесткости в аргументации не увидел.
Некоторые комментарии к комментарию:
1. Объектная модель - это замечательно, по сравнению с ней реляционная модель - это такой “наименьший общий делитель”. Другими словами, полное убожество. Но у реляционной модели есть одно достоинство, которое перевешивает все недостатки - открытость. Для объектной модели нет стандартных механизмов доступа - получаем “черный ящик”. С точки зрения BPMS это проблемой не является, так как мы сидим внутри этого черного ящика. С точки же зрения корпоративной архитектуры это проблема, и большая.
2. Реляционную модель проектировать сложно, для этого нужен профессионал, а объектную - легко, это может делать кто попало (вольное цитирование). Извини, но это караул. Легкость проектирования - это ловушка, позволяющая одному ламеру наворотить такого, что потом десять профессионалов не разгребут. Проектирование любой модели данных - хоть объектной, хоть реляционной - требует профессионализма. В обязательном порядке. Иначе катастрофа гарантирована. Это даже ответственнее, чем проектирование схемы процесса.
3. Про единую базу данных организации. Это недоразумение - я за нее не агитировал. Мой выбор - честная реляционная БД в противовес “черному ящику” любого сорта, будь то объектному, будь то какому другому. Но наличие нескольких баз внутри любой организации - это еще один аргумент в мою пользу: современные СУБД научились обращаться к “чужим” базам данных, как к своим. Можно в MS-SQL сказать: мол, есть у меня таблица, только физически она находится в Oracle, там-то и там-то. И после этого премилым образом строить join-ы. Bizagi поддерживает два механизма: реплиацию и виртуализацию. Аналитик работает как бы с локальной таблицей, а на уровне “физики” она смапирована на внешнюю БД. По-моему очень изящное решение. А вот со своеобычной объектной базой (а они все своеобычны, так как стандарта наподобие SQL там нет) этот номер не пройдет.
4. По поводу комбинированного хранения. Да, на первый взгляд, какие могут быть возражения против того, чтобы взять лучшее из двух миров? Но дело в том, что ни один атрибут “не даст честного слова”, что он не превратится из процессного короткоживущего в персистентный. Поэтому - нафиг!
5. Версионность схему данных. Если я и умолчал, то не специально. Bizagi встроил в свой инструмент полноценный моделер БД наподобие PowerDesigner. Это очень удачное решение, так как система отслеживает все зависимости между разными частями проекта - процессом, моделью данных и пользовательскими интерфейсами. В том числе он совершенно “прозрачно” переносит изменения схемы данных из разработки в эксплуатацию.
6. Распараллеливание процесса на несколько потоков. Насколько я понимаю, имеется в виду цикл по объектам? Если есть цикл по объектам, значит должно быть какое-то конкретное множество объектов, по которым мы в цикле будем запускать подпроцесс. У нас есть запись в таблице, соответствующая текущему экземпляру процесса верхнего уровня, и некая другая таблица, связанная с ней соотношением М:1. Опционально фильтруем какие именно записи, ссылающиеся на текущую, надо обработать, и запускаем по ним подпроцесс. Во втором мастер-классе по Bizagi я это демонстрировал, в числе прочего: http://www.youtube.com/watch?v=ikV3VUAqbK4
Анатолий, спасибо за ответ. К сожалению, видимо я не очень хорошо выразился, в связи с чем произошла путаница. Отвечу на каждый Ваш комментарий.
1. “С точки зрения BPMS это проблемой не является, так как мы сидим внутри этого черного ящика. С точки же зрения корпоративной архитектуры это проблема, и большая.” Почему? Во-первых, в своем комментарии я говорил, что данные, которые могут понадобиться после завершения процесса, должны хранится в внешней структуре данных (например SQL СУБД, здесь никаких запретов нет). Во-вторых, промежуточные, временные данные, которые хранятся в “черном ящике” так же могут быть доступны из вне. Про современные ИТ-системы с огромным кол-вом адаптеров, я умолчу. Скажу только, что для универсальной взаимосвязи приложений есть XML, есть Web Service, наконец есть ESB, если у какой-то ИТ-системы есть проблемы подключения с выходом в большой свет….И, кстати, учитывая SOA, хранение данных в XML формате наиболее обосновано, чем SQL. Действительно, если надо быстро и на коленке, то прочитать SQL из внешней ИТ-системы это самый простой и удобный вариант. Но где гарантия, что вас туда пустят? Да и тем более, любая БД (как например та, которая стоит 1C) имее закрытый формат, где все таблицы надо расшифровывать…
Вывод: интеграция двух и более систем через SQl не является на мой взгляд верным подходом, с точки зрения корпоративной IT-архитектуры…
2. Тут Анатолий, я полностью с Вами согласен. Сожалею, что Вы меня не верно поняли. В своем комментарии у говорил, что “Я считаю, что тут эффективнее всего выглядят объектно-ориентированные технологии. Но пользоваться ими нужно аккуратно”. Другими словами, заставь дурака молится, он себе лоб расшибет. Это одинаково справедливо как для SQL, так и для ОТ. Кстати, в защиту ОТ нашел несколько хороших слов (http://intersystems.ru/cache/technology/techguide/cache_tech-guide_01.html): Объектная технология - это опыт отражения того, как в действительности человек думает об информации и использует ее. Преимущества ОТ:
* Объектная технология прекрасно сочетается с графическими пользовательскими интерфейсами (GUI). (!!!!) -> пример UML CD
* Объекты упрощают взаимодействие с различными технологиями и приложениями.
* Принцип “черного ящика” (или инкапсуляция) позволяет программистам совершенствовать внутреннее устройство объекта, не нарушая работу других частей приложения.
* Структура данных объекта более емкая, за счет чего можно естественным образом описывать данные реального мира.
* Версии классов, настроенные под определенного клиента, могут легко заменить стандартные версии. Это облегчает индивидуальную настройку приложения и гарантирует ее сохранение в следующих версиях.
3. Анатолий, мне кажется этот пункт - повтор 1 Вашего комментария. Соответственно я ответил на него в своем 1 тезисе. Еще раз повторю - интегрировать на уровне SQL мне кажется не верным подходом. Кину ложку дегтя. Как быть при реализации supply chain management (SCM), реализации B2B? Кстати, BPMN, насколько я понимаю это отлично поддерживает. А вот как это реализовать на уровне данных??Неужели через единую SQL БД???
4. Это самое интересное. Действительно, требования к СУБП постоянно меняются. Меняется и состав атрибутов, которые нужно хранить после завершения выполнения процесса. Но данный факт никак не противоречит использованию ОТ для моделирования данных в СУБП. Просто в какой-то момент сохраните нужный атрибут в внешнюю структуру данных. В чем проблема? По сути в Bizagi происходит тоже самое, насколько я понимаю. Другой вопрос, куда сохранить данный атрибут. В отдельную СУБД, созданную для того, чтобы закрыть провал, который появился после того, как была реализована СУБП и выяснилось, что существующие функциональные IT-системы не хранят в себе половину важной информации??? Или все же в внешнюю ИТ-систему?
5. Очень рад за Bizagi…надеюсь, что у остальных BPMS это так же хорошо реализовано. Кстати, Анатолий, немного в сторону вопрос. Я помню, что Вы показывали, как вы обращаетесь к данным, типа var1.client.avto.number…Это ведь сугубо объектный подход. Не понимаю, как это может быть реализовано на табличном уровне? Получается, что все параметры в запросы подставляются автоматически? Не кажется ли Вам, что это попытка Bizagi все же реализовать элементы ОТ?
6. Понятно. Спасибо. Посмотрел. Хотел добавить, что в Oracle BPM это же реализуется так:
var1 as Object = Object() //перменная процесса, которая ссылается на произвольный объект в модели представления данных в BPMS
copy = clone(this) // создаем клон нашего процесса (с всем необходимыми переменными)
copy.var1 = …. //совершаем действия уже над отклонированной переменной var1
….//при слиянии потоков
if var1 copy.var1 then ….//если копия переменной в каком-то конкретном потоке была изменена по отношению к главной переменной процесса var1, то производим необходимые действия.
Я прошу прощения за свою активность в обсуждении данного вопроса, но для меня эта тема крайне важна. Анатолий, хотел Вам задать вопрос, как к эксперту в области BPMN. Изучая спецификацию (правда с точки зрения организационной перспективы), я обратил внимание, что в BPMN 2.0 выделены отдельные элементы “Data Object”, “Data Store” и др. Для каждого из этих элементов есть отображение на уровне диаграммы классов, с помощью которых описывается семантика их выполнения. Так вот, насколько я понимаю, что следуя спецификации BPMN, каждая модель процесса, описанная в BPMN 2.0 может быть интегрирована с помощью объектов “Data Object” с соответствующей моделью данных. Учитывая, что BPMN разработан на основе объектно-ориентированных технологий, то и модель данных так же должна быть выполнена соответственно. Вопрос. Правильно ли я понимаю значение диаграммы классов в BPMN 2.0? Не получается ли, что в Bizagi действительно можно выделить объектную прослойку между схемой процесса и SQL-таблицами? Заранее спасибо. Прошу прощения, если где-то написал глупость…
>> 1. …данные, которые могут понадобиться после завершения процесса, должны хранится в внешней структуре данных (например SQL СУБД, здесь никаких запретов нет).
Тут мы серьезно расходимся во взглядах.
Как это предложение реализовать практически - после завершения процесса сбрасывать данные в реляционную БД? А схему этой БД делать так, чтобы она была эквивалентна объектной? А до того, как процесс завершится, в эту базу лезть нельзя? И зачем тогда весь этот зоопарк: двойная разработка, дублирование данных… Вот я и прихожу к выводу: сразу нормализовать в реляционную БД и не мучиться.
>> Во-вторых, промежуточные, временные данные, которые хранятся в “черном ящике” так же могут быть доступны из вне. Про современные ИТ-системы с огромным кол-вом адаптеров, я умолчу. Скажу только, что для универсальной взаимосвязи приложений есть XML, есть Web Service, наконец есть ESB, если у какой-то ИТ-системы есть проблемы подключения с выходом в большой свет….
Хорошо. Представим себе корпоративную систему OLAP/BI/MDM. 100% у нее не будет проблем с извлечением процессных данных из реляционной БД. Несколько кликов мыши - и готово, данные всосали. А вебсервисы (любые) - это изучение API и программирование с заранее неизвестным результатом.
>> И, кстати, учитывая SOA, хранение данных в XML формате наиболее обосновано, чем SQL.
Стоп! А что, хранение данных в реляционной БД как-то отменяет представление ее в виде вебсервиса? Да не боже мой. Хоть WS-*, хоть REST-ом отдадим, без проблем.
Из реляционной БД сделать сервисы - элементарно. Представить вебсервисы или объектный “черный ящик” в виде реляционной модели - проблематично.
>> Действительно, если надо быстро и на коленке, то прочитать SQL из внешней ИТ-системы это самый простой и удобный вариант. Но где гарантия, что вас туда пустят? Да и тем более, любая БД (как например та, которая стоит 1C) имее закрытый формат, где все таблицы надо расшифровывать…
“та, которая стоит в 1С” - это совсем не “любая”. Это извращение, если называть вещи своими именами. Именно за него 1С так страстно “любят” все, кому приходится с ней интегрироваться. Более корректно выражаясь, это еще одна вариация на тему “СУБД поверх СУБД”. “Прямое использование реляционной СУБД”, о которой я говорю в статье, этого не допускает.
>> 4. … Просто в какой-то момент сохраните нужный атрибут в внешнюю структуру данных. В чем проблема?
Проблема в дублировании разработки и хранения.
>> По сути в Bizagi происходит тоже самое, насколько я понимаю.
Нет, у Bizagi нет другого хранения кроме реляционных таблиц.
>> 5. Вы показывали, как вы обращаетесь к данным, типа var1.client.avto.number…Это ведь сугубо объектный подход.
Эх, молодежь
Вообще-то это называется навигацией. Которая появилась она в СУБД намного раньше, чем появилась реляционная алгебра и реляционные СУБД, не говоря уже об ООП.
>> BPMN разработан на основе объектно-ориентированных технологий
Впервые слышу.
>> Правильно ли я понимаю значение диаграммы классов в BPMN 2.0?
Диаграммы классов в стандарте описывают не атрибуты процесса, о которых мы сейчас говорим, а атрибуты модели процесса.
Anatoly, I’m a BPEL developer and XML is all I know of when it comes to data representation and the challenges with storage is completely abstract to me. All I care of is the consistency of the data I request and the quality of the services I call. Manipulating XML is sometimes awkward, but most tools support schema mappings and query building.
My concerns regarding process data is most related to how service developers tends to think in terms of object-orientation instead of process-orientation. The message types gets over designed and focus is set on reuse instead of having that particular service request supported. This is also common for process developers with a OO background.
Thanks for an interesting topic.
Thank you for the input, Jonas.
That is the key point: “I as a service developer”, “I as a BPEL developer”, “I as a CRM developer” is one type of thinking and “I as an enterprise architect” or “I as a database administrator” is another.
Many application developers tend to believe that implementing a client part - the ability to call external webservices or to access external relational data means being “open”. In too many cases the services API is incomplete and/or data access is not available. They can “call” but hardly can be “called” - this is the way to the “information zoo”.
XML and XML-based services are great: abstract, platform-independent. But even the greatest things have a domain where they are effective; we can’t afford storing all enterprise data in XML or abandoning integration at data level.
“XML and XML-based services are great: abstract, platform-independent. But even the greatest things have a domain where they are effective; we can’t afford storing all enterprise data in XML or abandoning integration at data level.”
Anatoly, that’s what I meant by having an abstract relationship to storage. XML is just a way of package data, SOAP is how we wrap it in, and a web service is how we deliver it between parts in a SOA eco-system. Data needs a durable storage, by all means, and I believe we all can agree that a business process implementation isn’t a good choice - even though a BPMS is secure in terms of reliability. That said, I think that some data (such as an Order instance) should be accessed from a predictable business process (Order Process) since it’s valuable to have centralized control over data from a process perspective. That doesn’t necessarily mean a BPMS should be the place of storage for the Order data, but more of an event handler. The Order data shouldn’t be accessed without knowing why it’s being accessed. This approach is possible for most business processes, but for the rest I guess we have things like Adoptive Case Management, plain collaboration, and such.
Cheers!
Jonas
Well said!
Would you comment on the approach taken by Drools jBPM5, please?
If I only new what it is…