Показать сообщение отдельно
Старый 10.06.2010, 13:20   #9  
guenberg is offline
guenberg
Участник
 
41 / 11 (1) +
Регистрация: 24.05.2010
Цитата:
Сообщение от Артем Enot Грунин Посмотреть сообщение
Не важно где хранить коды запросов: внутри кастомного объекта, или ссылаться на готовый UserQuery/SavedQuery. Речь шла о том что вам нужно разобраться как работают внутренние механизмы системы. Поясните все же для чего нужен поиск? Не на XXX, а на конкретных примерах и задачах. Есть ощущение, что вы хотите производить назначение объекта на основании того, попадает ли он под критерии поиска для конкретного пользователя.
Задача: у сущьности YYY надо при её создании,а также при изменении её состояния (состояния у нас свои, их порядка 15) определить владельца (ownerID)... В рамках бизнес-процесса, при помощи стандартной функциональности - невозможно. Определение OwnerID зависит от множества произвольных факторов (в частности аттрибутов) сущьности ХХХ, а также аттрибутов связанных сущьностей. Например, если XXX это:
1. XXXID
2. CustomerID
3. Name
4. OwnerID
5. и др.

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