Интеграция метаданных о людях в поиски контента с помощью правил запросов в SharePoint 2013

Дата публикации исходной статьи: понедельник, 20 августа 2012 г.

Согласен, это довольно длинное и запутанное название, так о чем здесь говорит Стив? Что ж, позвольте мне перефразировать — несколько дней назад я увидел следующий вопрос. Есть сотрудники, работающие на разные отделы организации, такие как отдел продаж, финансов и т. д. Когда кто-то вводит запрос наподобие "управление продажами", то хотелось бы иметь возможность показывать людей, которые работают в отделе продаж. Хорошо, звучит как удобное применение новых правил запроса в SharePoint 2013.

Для начала сделаем шаг назад и рассмотрим активацию компонента, который мы будем использовать. При импорте профилей из Active Directory в SharePoint 2013 система автоматически заполняет специальный набор терминов в службе управляемых метаданных. К слову, создается основная группа "Люди (People)" и заполняются три набора терминов: "Отдел (Department), "Должность (Job Title)" и "Расположение (Location). (ПРИМЕЧАНИЕ. Я не могу гарантировать, что все три набора будут существовать после начала поставки продукта, в итоге может остаться всего два набора). Во время импорта профилей каждый набор терминов заполняется уникальными значениями для всех пользователей и для всех свойств. Это действительно позволяет устранить большую часть проблему, так как, смотря на MMS, я вижу, что в списке отделов есть "Отдел продаж", поскольку у меня есть пользователи с таким значением в атрибуте "Отдел (Department)" в AD:

Теперь перейдем к созданию правила запроса. Как я упоминал в первой записи о правилах запросов (https://blogs.msdn.com/b/sharepoint_ru/archive/2012/09/20/custom-search-sales-report-sharepoint-2013.aspx), сначала мы установим условие срабатывания правила. В этом случае мы используем параметр "Расширенное сопоставление текста запроса (Advanced Query Text Match)" и выберем последнее выделение, Запрос содержит запись из этого словаря (Query contains an entry in this dictionary): . Теперь нам доступен раскрывающийся список, что не очень удобно, так как он немного все путает. Мы хотим выбрать ссылку Импорт из таксономии (Import from taxonomy) непосредственно под списком. Когда мы это сделаем, мы увидим стандартное средство выбора MMS, поэтому я просто разверну локальный экземпляр MMS и выберу набор терминов "Отдел (Department)", поскольку я хочу, чтобы правило срабатывало, если текст запроса содержи слово, представляющее отдел в моей организации.

Для следующей части правила я устанавливаю все три флажка для поиска в терминах запроса. Если весь запрос представляет собой название отдела или запрос начинается с названия отдела или заканчивается на него, правило должно срабатывать. Наконец, если есть совпадение, я хочу назначить его {subjectTerms}, а оставшиеся термины — {actionTerms}. Поэтому если использовать пример выше для поиска "управление продажами", то так как запрос заканчивается на "продажами", что является допустимым значением отдела в MMS, мой запрос должен дать совпадение — "продажами" будет добавлено в {subjectTerms}, а "управление" — в {actionTerms}. Вот как выглядит такая конфигурация:

Когда срабатывает мое правило, я хочу добавить некоторых сотрудников отдела продаж в верхнюю часть результатов запроса. Поэтому я начинаю работать над следующей частью моего правила запроса, определяющей действие, которое я буду выполнять. Я выбираю ссылку "Добавить блок результатов (Add Result Block)", после чего открывается диалоговое окно. В этом случае я хочу добавить блок результатов, который будет отображать результаты для людей, поэтому сначала я открываю раскрывающийся список Искать в этом источнике (Search this Source) и меняю параметр Первоначальный источник запроса (Query’s orginal source) на Локальные результаты поиска людей (Система) (Local People Results (System)) . то я делаю первым, поэтому построитель запросов будет использовать этот источник при изменении и тестировании запроса. После этого с помощью сработавшего правила я буду знать, что найденные отделы будут в специальном термине "{subjectTerms}". Чтобы использовать это, я нажимаю кнопку "Запустить построитель запросов (Launch Query Builder)", чтобы изменить запрос. Я удаляю существующий текст в области редактирования текста запроса и открываю раскрывающийся список фильтра свойств и выбираю параметр "Показать все управляемые свойства (Show All Managed Properties). При этом список заполняется всеми управляемыми свойствами. Из списка я выбираю "Отдел (Department)". В определяющем раскрывающемся списке я меняю параметр "Содержит (Contains)" на "Равно (Equals)", а затем в списке Выберите значение (Select value) выбираю {subjectTerms} (совпадающую запись словаря из отдела) и нажимаю кнопку Добавить фильтр свойств (Add property filter) . Вот как это выглядит:

Все получается довольно хорошо. Теперь я хочу добавить немного личных настроек, а для этого открываю вкладку "Сортировка (Sorting)" в построителе запросов. В этом случае вместо применения модели сортировки по умолчанию (поскольку будут отображаться люди), я буду сортировать по социальной дистанции. Поэтому не только люди будут показаны в результатах, но и список людей будет упорядочен по кратчайшему социальному расстоянию от меня. Для этого я открою раскрывающийся список "Модель ранжирования (Ranking Model)" и выберу параметр Модель социального расстояния для поиска людей (People Search Social Distance Model) , как показано далее:

Теперь я могу открыть вкладку "Тестирование (Test)" и опробовать новый запрос. По умолчанию должны отображаться нулевые результаты, так как значения для переменной {subjectTerms} нет. Чтобы выполнить проверку с реальными критериями, щелкните ссылку "Дополнительно (Show More)", введите "продажи" в поле редактирования {subjectTerms}*:, а затем нажмите кнопку "Проверить запрос (Test query)". Я пробую запрос с разными моделями ранжирования, чтобы убедиться, что все работает, как ожидалось. Все работает, поэтому я нажимаю кнопку "ОК", чтобы сохранить изменения запроса.

Последнее, что я хочу сделать с правилом запроса — показать ссылку в нижней части блока, чтобы пользователи могли щелкнуть его и найти всех людей, которые работают в найденном отделе. Перед продолжением я хочу рассказать кое-что в целях всего повествования — у меня есть рисунок, который я покажу в окончательных результатах, и вы увидите ссылку "ДОПОЛНИТЕЛЬНО (SHOW MORE)". Для этой записи я объединил два рисунка (один с ссылкой "ДОПОЛНИТЕЛЬНО (SHOW MORE)" и один без такой ссылки). Это связано с тем, что ссылка "ДОПОЛНИТЕЛЬНО (SHOW MORE)" работает несогласованно в бета-версии 2. Все проблемы должны были быть устранены в RTM-версии, но иногда они возникают у меня, хотя и редко. Я создал снимок экрана с результатами на ранней стадии с иллюстрацией этого поведения. Я говорю об этом здесь, чтобы вы не сильно расстраивались, если работаете в бета-версии 2 и иногда эта ссылка отображается, а иногда — нет.

В итоге, для реализации описанной ранее функциональности я выбрал параметр, при использовании которого ссылка "Еще (More)" переходит по следующему URL-адресу, и ввел следующее: peopleresults.aspx?k=Department:{subjectTerms} . Я также решил показать три совпадения и, как описано выше, они отображаются в верхней части результатов поиска. Поэтому теперь диалоговое окно блока результатов будет выглядеть следующим образом:

Теперь я могу выполнить проверку. Поэтому я запрашиваю "управление продажами", а результаты будут выглядеть следующим образом:

(Учтите, что здесь вы увидите ссылку "ДОПОЛНИТЕЛЬНО (SHOW MORE)", которую пришлось вставить). Здорово, что Rocky отображается в верхней части результатов поиска, так как в моей организации я являюсь руководителем, поэтому мы видим, что алгоритм ранжирования по социальному расстоянию работает. Если навести указатель на любого сотрудника в результатах, я увижу список документов, которые он или она опубликовали за последнее время:

Наконец, если щелкнуть ссылку "ДОПОЛНИТЕЛЬНО (SHOW MORE)", откроется страница результата поиска людей со всеми сотрудниками, которые работают в отделе продаж. Если навести указатель на одного из них, я увижу, все что они сделали, страницу их профиля и т. д..

На этом наше упражнение завершается. Мы использовали реальное требование заказчика и применили новые правила запросов и функции импорта профилей в SharePoint 2013 для создания решения без какого-либо кода, которое предоставляет МНОЖЕСТВО удобных функций. Надеюсь, что вы продолжите работу с правилами запросов.

Это локализованная запись блога. Исходная статья доступна по адресу Integrating People Metadata In Content Searches Using Query Rules in SharePoint 2013