Сохранение параметров расширенного поиска в БД

[guenberg]

Цитата:

Сообщение от Артем Enot Грунин

Не важно где хранить коды запросов: внутри кастомного объекта, или ссылаться на готовый UserQuery/SavedQuery. Речь шла о том что вам нужно разобраться как работают внутренние механизмы системы. Поясните все же для чего нужен поиск? Не на XXX, а на конкретных примерах и задачах. Есть ощущение, что вы хотите производить назначение объекта на основании того, попадает ли он под критерии поиска для конкретного пользователя.

Задача: у сущьности YYY надо при её создании,а также при изменении её состояния (состояния у нас свои, их порядка 15) определить владельца (ownerID)... В рамках бизнес-процесса, при помощи стандартной функциональности - невозможно. Определение OwnerID зависит от множества произвольных факторов (в частности аттрибутов) сущьности ХХХ, а также аттрибутов связанных сущьностей. Например, если XXX это:
1. XXXID
2. CustomerID
3. Name
4. OwnerID
5. и др.

то примером не умещающегося в стандартный функционал бизнес-процессов может быть случай, когда надо определить того или иного пользователя как владельца в зависимости от принадлежности пользователя к тому или иному подразделению и количества выполненных за последние 365 дней действий под объектом XXX, от результатов и этих дейтсвий и т.д. Пользователей, которые могут быть назначены в качестве владельцев может быть много и в случае ухода кого либо в отпуск или увольнения не хотелось бы перенастраивать бизнес-процесс. В общем видится что настройку определения владельцев надо вынести из бизнес-процессов, а вот в самом бизнес-процессе оставить только метод, который на основании этой настройки будет искать и присваивать ownerID... Вот такая механика...
Соответственно хотел бы где либо почитать и посмотреть код в котором сохраняют, модифицируют и запускают сохранённый поиск... Ну или запускают сохранённый в UserQuery...

[Артем Enot Грунин]

Цитата:

Сообщение от guenberg

Задача: у сущьности YYY надо при её создании,а также при изменении её состояния определить владельца... В рамках бизнес-процесса, при помощи стандартной функциональности - невозможно.

Может все-таки начнете изучать систему? Один и тот же БП легко может срабатывать и на событие создание записи и на событие смены состояния. Есть стандартный шаг проверки условий например "текущее состояние = состояние N" после которого можно выполнять дальнейшие проверки или запускать дочерний процесс - очень удобно для декомпозиции сложных правил.
Если не хватит стандартных опций, например, проверка загруженности или отпуск пользователя - всегда можно дописать свои шаги для процесса. Вот бы только почитать в sdk как это делает, верно? Я думаю что уже очевидно, что всем лень писать для вас код который делает неведомую хреновину. Прислушайтесь уже к совету профессионала и идите в указанном мной направлении.

p.s. Неправильный путь (ваш): запросом Retrive вычитать id нужной вам сущности UserQuery (понятия не имею как вы поймете какая вам нужна в конкретном случае) , после чего сообщением ExecuteByIdUserQuery выполнить его и обработать результат.

[guenberg]

Цитата:

Сообщение от Артем Enot Грунин

Может все-таки начнете изучать систему? Один и тот же БП легко может срабатывать и на событие создание записи и на событие смены состояния. Есть стандартный шаг проверки условий например "текущее состояние = состояние N" после которого можно выполнять дальнейшие проверки или запускать дочерний процесс - очень удобно для декомпозиции сложных правил.
Если не хватит стандартных опций, например, проверка загруженности или отпуск пользователя - всегда можно дописать свои шаги для процесса. Вот бы только почитать в sdk как это делает, верно? Я думаю что уже очевидно, что всем лень писать для вас код который делает неведомую хреновину. Прислушайтесь уже к совету профессионала и идите в указанном мной направлении.

p.s. Неправильный путь (ваш): запросом Retrive вычитать id нужной вам сущности UserQuery (понятия не имею как вы поймете какая вам нужна в конкретном случае) , после чего сообщением ExecuteByIdUserQuery выполнить его и обработать результат.

SDK давно установили и при необходимости обращаемся туда... После анализа стало понятно, что функциональности описания условий в бизнес-процессах не хватает для данной задачи, поэтому и возникла мысль использовать сохраненный поиски... А кастомный шаг для БП уже делаем... тут ни куда не деться... Спасибо за подсказки в неправильном пути