Комментарии 8
По аналогии с той же камундой — движок или часть его планирует стать опен-сорсом?
1. Как вы синхронизуеете контексты? или шарите данные между блоками?
допустим отработал первый блок, второй должен продолжить работу с данными из первогь блока.
2. как вы управляете конфигурацией блока? начальные variables/env?
3. вы делаете валидацию конфигурафии? перед сохранением к примеру
допустим отработал первый блок, второй должен продолжить работу с данными из первогь блока.
2. как вы управляете конфигурацией блока? начальные variables/env?
3. вы делаете валидацию конфигурафии? перед сохранением к примеру
1. Блок либо выполняется полностью, либо останавливает выполнение, если нужен ответ пользователя. И в том и в другом случае, состояние блока сохраняется в БД. Другое дело, что у нас нет API для доступа к этим данным из другого блока, пока вроде не было необходимости.
2. Конфигурация блока задается в DirectumRX Development Studio. Это делает разработчик бизнес-логики, там же разрабатывается схема процесса. Как работать с этими данными знает только WBS. WPS ничего про это не знает, его задача двигать процесс по схеме.
3. Если имеется ввиду валидация схемы процесса, то да. Срабатывает на этапе разработки при сохранении. Например, проверка на то, что из блока нет 2 и более исходящих ребер с одинаковыми результатами выполнения.
2. Конфигурация блока задается в DirectumRX Development Studio. Это делает разработчик бизнес-логики, там же разрабатывается схема процесса. Как работать с этими данными знает только WBS. WPS ничего про это не знает, его задача двигать процесс по схеме.
3. Если имеется ввиду валидация схемы процесса, то да. Срабатывает на этапе разработки при сохранении. Например, проверка на то, что из блока нет 2 и более исходящих ребер с одинаковыми результатами выполнения.
По п.1 дополню: один блок может обрабатываться только одним WBS, ставится блокировка, а результат работы блока — изменение данных/состояния бизнес-сущностей системы (экземпляры заданий, записей справочников и пр.), поэтому данные между блоками напрямую передавать особого смысла нет, всё берётся из и сохраняется в бизнес-сущности.
И по п.2 дополню: есть параметры «по умолчанию» и есть события старта/окончания/перезапуска блока (это основные события, есть еще), для них пишутся обработчики в прикладном коде которые вызываются из WBS и позволяют эти параметры изменить.
И по п.2 дополню: есть параметры «по умолчанию» и есть события старта/окончания/перезапуска блока (это основные события, есть еще), для них пишутся обработчики в прикладном коде которые вызываются из WBS и позволяют эти параметры изменить.
Ух, ностальгия))
Главная беда WF — низкое качество стора. Отсутствие документации, хранение данных в нечитаемом виде и прочее. Не думали просто стор переписать?
Главная беда WF — низкое качество стора. Отсутствие документации, хранение данных в нечитаемом виде и прочее. Не думали просто стор переписать?
Не туда.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы делали свой движок Workflow