BPMN за 9 минут: Контекст
HTML-код
- Опубликовано: 16 мар 2024
- В этом видосе разбираемся с тем, что такое контекст в бизнес-процесс и как с ним работать
Шаблон описания : docs.google.com/spreadsheets/...
Подробный видос с тем, как писать ТЗ на процессы: • Разработка ТЗ на проце...
Наше сообщество в телеграмме - t.me/bpmn2group
======
Курс по BPMN - bpmn2.ru/online-course-fast-b...
Бесплатная е-мейл рассылка о BPMN - bpmn2.ru
Сервис для рисования BPMN диаграмм без регистрации и СМС - stormbpmn.com
Блог с кучей статей о Camunda и BPMN - bpmn2.ru/blog
Промкод на скидку 15% на мои онлайн-курсы 15OFFRUclips
Отличный информативный видос!
почаще бы видео)
Спасибо за видео. Как раз сейчас работаю над моделью процееса в библиотеке для Golang - gobpm.
Согласно Стандарта, есть несколько объектов для описанию данных процесса -- видимых и невидимых. К видимым относятся DataObjects, к невидимым - Properties (свойства процессов, событий и активностей). Как раз DataObject можно использовать для передачи контекстной информации между задачами связывая их через DataAssociations.
И --если-- когда вы его реализуете в Шторме -- это будет очень серьезным дополнением в сторону красивых процессов, не обремененных дополнительнмы зависимым сторонним элементами вроде электронных таблиц, описательных документов и прочей шелухи.
Привет! Вот пока не придумал как бы их именно удобно реализовать, а не просто по стандарту. То что видел, вроде у trisotech, было не юзабельным. Но мысль. Меня не покидает, одежды доберёмся до этих вопросов)
@@BPMN2ru , я бы делал частную реализацию как на 212 странице Cтандарта (там где начинается описание DataInput). И делать обязательными источник и потребителя этих DataObject. Единственная сложность -- это навороченный механизм маппинга, описанных в DataAssociation. В своей версии я его упрощу и унифицирую с механизмом маппинга свойств. Думаю и для вас это будет подходящим стартом.
Основное преимущество DataObject перед Property, что он также имеет время жизни области действия (scope), но его видно на диаграмме и не нужно лазить по атрибутам объектов. С точки зрения реализации, на первый взгляд, они не сложнее свойств, также будут нужны маппинги между ними и входными/выходными значениями активностей. А дальше уже процедура маппинга либо успешно свяжет, либо срубится с ошибкой по недостаточности данных.
@@BPMN2ru , на сон грядущий пришла мысль в голову, что все наследники ItemAwareElements (DataObject, Property, DataInput, DataOutput) имеют через своего предка ссылку на ItemDefinition, который собственно и хранит данные. Получается, что в случае, если они будут ссылаться на один и тот же ItemDefinition, обмен данными между ними будет проистходить мгновенно. Единственное, что должно приниматься в учет -- это DataState используемого ItemAwareElemnt. А DataState должен контролироваться объектом, который в теме про область видимости (scope) -- какой-то ScopeController.
Если все организовать таким образом, то приходим к унификации и простоте маппинга передаваемых между узлами процесса (ввод/вывод), данными процесса (объекты данных) и свойствами узлов процесса и самого процесса.
Добрый день. Как всегда очень интересно, большое спасибо. Будет ли что-нибудь про паттерн External Tasks камунды ?
Так уже есть, camunda и не java языки видос называется
@@BPMN2ruспасибо, пошел смотреть
Скажите диджею я просто xuею