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

[guenberg]

Подскажите как сохранить у себя в БД настроенные параметры расширенного поиска, так же как это делается в UserQuery. Мне необходимо сделать сущность (скажем ХХХ) в записях которой я буду хранить параметру расширенного поиска. Потом надо будет этот поиск еще и запускать ... Кто пробовал?

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

Опишите задачу подробнее, пожалуйста. Хотелось бы услышать не что вам нужно, а для чего. А так реализовывалось подобное: http://www.axforum.info/forums/blog.php?b=40

[guenberg]

Цитата:

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

Опишите задачу подробнее, пожалуйста. Хотелось бы услышать не что вам нужно, а для чего. А так реализовывалось подобное: http://www.axforum.info/forums/blog.php?b=40

Необходимо при массовом создании экземпляров сущьности YYY рассчитывать значение поля OwnerID. Рассчитывать его видится правильным при помощи выполнения заранее настроенных и сохранённых поисков, при этом к каждому такому поиску прикреплен ответоисполнитель, который и назначается найденным записям YYY.
Решение такое обсусловлено тем, что опеределение OwnerID зависит от множества факторов, исвестны которые становятся только при внедрении системы после подготовки соответствующего ТЗ.

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

Прошу прощения, но это звучит как бред. Вы повторно строите то не знаю что. Для отработки на событие создание следует использовать либо воркфлоу, либо плагин. В вашем случае лучше подходит плагин.

[guenberg]

Цитата:

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

Прошу прощения, но это звучит как бред. Вы повторно строите то не знаю что. Для отработки на событие создание следует использовать либо воркфлоу, либо плагин. В вашем случае лучше подходит плагин.

Понятно что к этому надо будет разработать еще и бизнес-правило... Однако инкапсулировать всю настройку распределения ответственных в рамках бизнес-процесса, который будет вызываться при добавлении нет возможности. Это очень не удобно, несопровождаемо, и не надежно. Настройка будет очень большая (много пользователей)... Кроме этого возможности определения условий, которые есть в рамках бизнес-процессов значительно ниже чем в рамках расширенного поиска и этих возможностей явно не достаточно для данной задачи...Так что без поиска не обойтись...

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

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

Прошу прощения, но я не новичок в разработке под эту систему и знаю ее возможности! Поверьте поддерживать какую-то охинею которая гранит в базе готовые fetch запросы (а вы, к примеру, знали что расширенный поиск использует именно этот механизм?) значительно сложнее чем поддерживать стандартный рабочий процесс. Кроме того, этот механизм можно расширять под свои нужды! В том числе для выполнения поиска: http://mscrm4ever.blogspot.com/2009/...ry-wizard.html

[guenberg]

Цитата:

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

Прошу прощения, но я не новичок в разработке под эту систему и знаю ее возможности! Поверьте поддерживать какую-то охинею которая гранит в базе готовые fetch запросы (а вы, к примеру, знали что расширенный поиск использует именно этот механизм?) значительно сложнее чем поддерживать стандартный рабочий процесс. Кроме того, этот механизм можно расширять под свои нужды! В том числе для выполнения поиска: http://mscrm4ever.blogspot.com/2009/...ry-wizard.html

Согласен. Наверное лучше из XXX ссылаться на сохраненный поиск...

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

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

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