BPMN за 9 минут: Контекст

Рет қаралды 4,213

BPMN, Бизнес-процессы и котики

Күн бұрын

Пікірлер: 10

@outvook 10 ай бұрын

Отличный информативный видос!

@ruslangabitov5202 10 ай бұрын

Спасибо за видео. Как раз сейчас работаю над моделью процееса в библиотеке для Golang - gobpm. Согласно Стандарта, есть несколько объектов для описанию данных процесса -- видимых и невидимых. К видимым относятся DataObjects, к невидимым - Properties (свойства процессов, событий и активностей). Как раз DataObject можно использовать для передачи контекстной информации между задачами связывая их через DataAssociations. И --если-- когда вы его реализуете в Шторме -- это будет очень серьезным дополнением в сторону красивых процессов, не обремененных дополнительнмы зависимым сторонним элементами вроде электронных таблиц, описательных документов и прочей шелухи.

@BPMN2ru 10 ай бұрын

Привет! Вот пока не придумал как бы их именно удобно реализовать, а не просто по стандарту. То что видел, вроде у trisotech, было не юзабельным. Но мысль. Меня не покидает, одежды доберёмся до этих вопросов)

@ruslangabitov5202 10 ай бұрын

@@BPMN2ru , я бы делал частную реализацию как на 212 странице Cтандарта (там где начинается описание DataInput). И делать обязательными источник и потребителя этих DataObject. Единственная сложность -- это навороченный механизм маппинга, описанных в DataAssociation. В своей версии я его упрощу и унифицирую с механизмом маппинга свойств. Думаю и для вас это будет подходящим стартом. Основное преимущество DataObject перед Property, что он также имеет время жизни области действия (scope), но его видно на диаграмме и не нужно лазить по атрибутам объектов. С точки зрения реализации, на первый взгляд, они не сложнее свойств, также будут нужны маппинги между ними и входными/выходными значениями активностей. А дальше уже процедура маппинга либо успешно свяжет, либо срубится с ошибкой по недостаточности данных.

@ruslangabitov5202 10 ай бұрын

@@BPMN2ru , на сон грядущий пришла мысль в голову, что все наследники ItemAwareElements (DataObject, Property, DataInput, DataOutput) имеют через своего предка ссылку на ItemDefinition, который собственно и хранит данные. Получается, что в случае, если они будут ссылаться на один и тот же ItemDefinition, обмен данными между ними будет проистходить мгновенно. Единственное, что должно приниматься в учет -- это DataState используемого ItemAwareElemnt. А DataState должен контролироваться объектом, который в теме про область видимости (scope) -- какой-то ScopeController. Если все организовать таким образом, то приходим к унификации и простоте маппинга передаваемых между узлами процесса (ввод/вывод), данными процесса (объекты данных) и свойствами узлов процесса и самого процесса.