Texts about BPMS tend to focus at first hand on business process notations and diagrams. User interfaces to process tasks and web portal functionality are usually next topics, followed by business rules and integration. Such topics as data modeling at the design phase and data manipulation during the process execution are often out of sight.
Yet process model and data model are the key aspects of any process application architecture. Therefore, process modeling and data modeling are equally important core competencies of a process engineer.
Any process is executed not in a vacuum but in the context of process attributes. For any serious process application it’s not a plain list of strings and numbers but rather complex data structure containing reference and master data, 1:M relationships etc. Hence a process engineer must not only know a business process modeling notation (BPMN is the most common choice today), but also be a professional database developer. It’s not always articulated not because it’s unimportant but because it’s implied.
Anyway, this is a blind spot worth to investigate. Different BPM Suites utilize significantly different approaches to data modeling, affecting the resulting architecture of a process application, so it’s better to know in advance what to expect from a particular BPMS.
Now what are these approaches?
1. A flat list of attributes
A list of attributes can be specified for a process template - integers, strings, date/times, lists of values…
This approach is not used in modern BPMS because of its primitiveness but it can be found in legacy workflow systems. Such a system however may be positioned as a BPMS by the vendor.
2. XML document
Custom data types and complex data structures can be defined within a process application. E.g. a client’s request can be modeled as an object referring to a directory of clients and including a multiline part containing the list of goods and quantities. At the physical level all process attributes are rolled up into an XML document which is stored in a TEXT field of a relational DBMS.
This approach is implemented in BPMS from IBM, Oracle, TIBCO. It looks very attractive at the first sight: a comfortable graphical modeling environment, complex data structures, custom data types. One can model process data rapidly for a demonstration or a pilot project and present a working prototype to the customer.
However this approach may lead to serious problems in production:
1) Performance issues
Let’s consider a bank statement processing as an example. When the bank informs us about money income the current process should identify an instance of sales process and send it a message “payment received.” The right instance of the sales process should be searched by the invoice number stored as the sales process attribute - it must match the invoice number of the income record.
How would this search work at the physical level? The XML document containing process attributes should be extracted from the database, then parsed and finally the “invoice” element should be compared to the target. Now repeat for every active process instances. It’s OK if there are ten of them but how would it work if there are tens of thousands?
Just compare it with the standard way a relational DBMS does the job: an index on the field “invoice” and almost instant results - no sequential search, the elapsed time depends only slightly on the number of records.
2) Referential integrity
Uniform and consistent data base is the “holy grail” of business applications developers. Data access may be restricted by administrative rights, but technically all information is properly interlinked. Unified database grants that if, say, the sales process refers to a customer’s record, the latter won’t be removed.
When storing the data as XML documents placer the referential integrity is not guaranteed.
3) Proprietary Interfaces
A relational database stores data in a standard way, by rows and columns, and is fully open for access and manipulation (technically yet may be not by administrative rights). So you may be sure that you would be able to grant access to the process data e.g. from the corporate BI system if necessary - a connector will be there for sure.
You may be told that a BPMS provides API for the data access. It’s true, but utilizing API means writing a program code - compare it with configuring a connector by simply filling a few fields: server type and address, database name, login and password.
Secondly, a third-party system may be a “black box”. Such system most likely will support a standard mechanism of data access like e.g. ODBC but won’t provide ability to program arbitrary data source access.
3. Entity-attribute-value
It is known that any arbitrarily complex data can be presented as three-column table:
- object identifier
- attribute identifier
- value of the specified attribute belonging to the specified object
The benefit is the same as XML storage: one can expand and change the data model without touching the database schema.
Once again, the production use of this approach may lead to serious problems. For example, it’s relatively easy to implement an SQL join linking a dozen of tables. By contrast, it’s much harder to write similar request for EAV storage and performance of the request would degrade fast with a growing number of entities involved.
4. The database by reference attribute
Faced with the challenges outlined above, developers finally come to the conclusion that there is nothing better than native relational database storage and voluntarily abandon the richness of data modeling capabilities provided by BPMS.
The most consistent refusal is as follows: all attributes are transferred to a relational database tables, keeping a single attribute referencing the root record in a relational table dedicated for the process.
Such migration resolves the issues mentioned above but unfortunately create others - this time related to user interfaces.
The root cause is user interface development tools built-in into BPMS - they are designed primarily to interact with process attributes, not arbitrary data stored in DBMS. Therefore data transformation results in UI development slow-down at least. In the worst case one has to abandon built-in UI development tool and switch to some third-party web development framework.
And it’s not just about UI development complexity - instead of one project, seamlessly integrating processes, data, and user interfaces - you’ve got three projects that need to be synchronized. For example, when one changes the process schema, appropriate changes should be made simultaneously in the database and user forms. Given that different projects are usually managed by different people, it’s hard to fully avoid inconsistencies.
Transfer of a project from development to production environment also becomes “fun”. As long as built-in BPMS functionality is used, it’s a one-button operation. One can appreciate this functionality best when it’s not available.
All this is not good from the standpoint of methodology: instead of a BPM project, we fall into process-oriented software application development.
One may ask, what’s the difference? It’s business involvement and pace.
BPMS software is specifically designed to support both: it’s a logical, closed-loop environment that link processes with data and user interfaces in a natural way. It doesn’t mean that business will do all the job (this is naive yet not uncommon belief) - it’s enough for them to understand what analysts and developers are doing and to be able to criticize, make corrections and generate ideas on how we really should do business. That’s the essence of BPM, its strength.
We will lose these benefits when built-in data modeling and forms development are abandoned.
If you delegated a process work to IT, then it’s IT who manages your business processes. Not management, not the process owner - programmers! With all due respect, one can’t expect more than employee productivity improvements based on more comfortable and ergonomically designed business applications.
Does it relate to the bottom line? Hardly so. The business target can be reached from other direction - by a systematic view of how business units interact with each other and the company as a whole with a customer in the context of end-to-end business process. Only the business people - management and key specialists - can and should tell how the company should do business to meet customers’ expectations and win the competition. Do not expect it from programmers.
In addition, business involvement is impossible without maintaining the pace of the process development. One may count on business ownership of the BPM project only if the time from an idea of process improvement suggested by the business to the implementation takes days or weeks at maximum. Months is the same as never because the enthusiasm of the business will inevitably fade away.
Simplicity is one aspect of business involvement, pace is another. We lose both by replacing the rapid development tools built into BPMS with more labor-intensive ones.
5. Native relational database
Storing attributes in XML or EAV is a kind of “database over the database” approach. It raises the obvious question: why not using a relational database natively?
Bizagi BPM Suite is an example of such approach. As any BPMS it provides built-in data modeling and UI development tools. Business objects are designed in the usual way by defining attributes and relations, then attributes are put at the canvas to compose a screen form.
Everything is quite straightforward at the physical level too: entities correspond to relational tables, attributes to columns. Each process template is linked to a database table and a process instance corresponds to a row in this table. Apart from these “process” tables there are master data, reference data… in short, everything that we normally see in a corporate applications database.
Advantages of this approach double when one goes from the first process to second, third, etc. In case of data stored as XML, access to another process’ data should be programmed and the amount of programming is growing because the more processes, the more interactions between them. In the case of Bizagi, on the contrary, the addition of the following process becomes cheaper because it reuses existing master data and reference tables.
With this approach developers of a process application don’t meet any of the above-mentioned issues.
I guess Bizagi developers did have some issues: they had to build a database design tool into the product (ER diagramming tool, to be precise), implement mapping from logical design to physical database layout and automate schema changes transfer from development to production preserving operational data. Anyway they did it, everything works stable enough.
To me personally this solution looks so straightforward and beneficial that I don’t understand why all BPMS developers didn’t choose this way.
Conclusion
This post expressed the author’s view of approaches to process and data interaction based on experience with nearly a dozen of BPMS products. Yet the experience with some products was not very extensive so the author doesn’t pretend to be an expert towards them and secondly, this sample may not represent the full spectrum of BPMS. Therefore the author would be extremely grateful for corrections and alternative views from experts in various BPMS or links to such opinions.
But anyway, the method of processes interaction with data is one of the most important aspects of BPMS architecture. Evaluate the pros and cons of the chosen solutions in advance - there is always one way or another to compensate a deficiency. The worst case is when architectural problems hit you in the middle of a project, forcing a developer team to reengineer the application and putting the project at gross risk of failure.
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…