Настройка «Поисковик»
<!-- ВНУТРЕННИЕ -->
<bean id="internalContextualSearcher" class="ru.intertrust.cm_sochi.srv.connector.sochi.search.SochiSolrSearcher">
<constructor-arg name="cmAppSystemId" value="InternalDocs"/>
<constructor-arg name="isNamed" value="true"/>
<constructor-arg name="searchArea" value="InternalDocs_context"/>
<constructor-arg name="targetCollectionName" value="(searchContextualWithSchema)"/>
<constructor-arg>
<bean class="ru.intertrust.cm_sochi.srv.connector.sochi.search.DefaultContextualSearchFilterCreator">
<constructor-arg>
<bean class="ru.intertrust.cm_sochi.srv.connector.sochi.search.InternalDocsSearchFilterCreator"/>
</constructor-arg>
<property name="bundleMap">
<map merge="true">
<entry key="rkkContextual" value="F_DP_IntRkk" />
</map>
</property>
</bean>
</constructor-arg>
<constructor-arg>
<bean class="ru.intertrust.cm_sochi.srv.connector.sochi.search.docinfo.ContextualSochiModuleInfoExtractor">
<constructor-arg index="0" ref="cmj_af_search_messageSource"/>
<constructor-arg index="1" value="InternalDocs"/>
<constructor-arg index="2" value="rkkContextualSearchResObject"/>
<constructor-arg index="3" >
<list>
<value>hyperLinkCustomized</value>
<value>rkkContextualSearchResObject</value>
</list>
</constructor-arg>
</bean>
</constructor-arg>
<constructor-arg ref="identifiableObjectSearchResultItemFactory" />
</bean> |
Для Поисковика задается:
- class - класс реализации. Данный класс выполняет полнотекстовый поиск средствами Solr.
- ru.intertrust.cm_sochi.srv.connector.sochi.search.SochiSolrSearcher - поиск средствами Solr
- ru.intertrust.cm_sochi.srv.dispatcher.beans.SearcherSD - полнотекстовый поиск средствами Domino и Solr. Работает в смешенном режиме.
- ru.intertrust.cmj.af.search.dp.DominoDbFTSearcher - полнотекстовый поиск средствами Domino по именным БД
- ru.intertrust.cmj.af.search.dp.DominoDbFTSearcherNotNamed - полнотекстовый поиск средствами Domino по неименным БД
- cmAppSystemId - идентификатор модуля, по которой нужно выполнить поиск.
- isNamed - признак "именная"
- searchArea - область поиска
- targetCollectionName
- class="ru.intertrust.cm_sochi.srv.connector.sochi.search.DefaultContextualSearchFilterCreator
- class="ru.intertrust.cm_sochi.srv.connector.sochi.search.InternalDocsSearchFilterCreator
- key="rkkContextual" value="F_DP_IntRkk"
- class="ru.intertrust.cm_sochi.srv.connector.sochi.search.docinfo.ContextualSochiModuleInfoExtractor
- ref="cmj_af_search_messageSource
- value="InternalDocs"
- value="rkkContextualSearchResObject"
- <list>
<value>hyperLinkCustomized</value>
<value>rkkContextualSearchResObject</value>
</list> - <constructor-arg ref="identifiableObjectSearchResultItemFactory" />
- Класс DominoRequestBuilderImpl - формирует строку поискового полнотекстового запроса Domino. Данный класс используется для всех поисковиков. В конструктор класса DominoRequestBuilderImpl передается ключ модуля, который участвует в настройке связи «поисковый параметр - поле документа». Задача ключа модуля идентифицировать правило соответствия «поисковый параметр –> поле/формула/форма-документа». Данное правило настраивается в xml-файле (см. ниже). Обычно в качестве ключа используется идентификатор БД. В примере ключ равен InputDocs. Например, что для модуля ВхД текущего и прошлого периодов используется один ключ InputDocs, так как правило соответствия «поисковый параметр - поле документа» для данных БД одно.
- Класс реализации интерфейса InfoExtractor. Данный класс отвечает за преобразование документа в объект Entry строку коллекции. Для каждого поисковика задается свой класс реализации InfoExtractor в зависимости от типа модуля. В классе обязательно должен быть реализован метод String getMapKey(), который возвращает ключ. Данный ключ идентифицирует правило соответствия «поле документа элемент коллекции», которое настраивается с этом же xml-файле поиска. Обычно в качестве ключа используется идентификатор БД
Варианты поиска
Простой поиск
<bean id="dpQueryFormSimple_custom" class="ru.intertrust.cmj.af.search.dp.CmQueryForm" c:scopeBuilder-ref="rootScopeBuilderSimple"/> |
Расширенный поиск
<bean id="dpQueryForm_custom" class="ru.intertrust.cmj.af.search.dp.CmQueryForm" c:scopeBuilder-ref="rootScopeBuilder"/> |
Однострочный поиск
<bean id="dpQueryFormOneLine_custom" class="ru.intertrust.cmj.af.search.dp.CmQueryForm" c:scopeBuilder-ref="oneLineRootScopeBuilder"/> |
Расширенный поиск по связям
<bean id="dpQueryFormAdvansedForLinks_custom" class="ru.intertrust.cmj.af.search.dp.CmQueryForm" c:scopeBuilder-ref="rootScopeBuilderLinks"/> |
Простой поиск по связям
<bean id="dpQueryFormSimpleForLinks_custom" class="ru.intertrust.cmj.af.search.dp.CmQueryForm" c:scopeBuilder-ref="rootScopeBuilderSimple"/> |
<bean id="singleLineSearchSettings" class="ru.intertrust.cmj.rest.search.SingleLineSearchSettings">
<constructor-arg name="queryFormId" value="dpQueryFormOneLine_custom"/>
<constructor-arg name="regNumParameter" value="regNumberExact"/>
<constructor-arg name="searchOnEverywhereParameter" value="searchOnEverywhere"/>
<constructor-arg name="resultParamMapping">
<map>
<entry key="regNumberExact" value="regFullNumber"/>
</map>
</constructor-arg>
</bean>
<bean id="ddpQueryFormSimpleominoDocumentSearchResultItemFactory" class="ru.intertrust.cmj.af.search.dp.DocumentSearchResultItemFactory" />
<!-- Контекстный поиск -->
<bean id="dpQueryFormContextual_custom" class="ru.intertrust.cmj.af.search.dp.CmQueryFormTunable"
c:scopeBuilder-ref="contextualSearchRootScopeBuilder">
<description>Потребители поискового механизма должны получать из
спринг-контекста данный бин, а остальные бины через его св-ва
</description>
</bean> |
Иерархия билдеров областей поиска
Иерархия билдеров задается в бине rootScopeBuilder в свойстве childs.
Пример, настройка области поиска «Договоры»:
<bean class="ru.intertrust.cmj.af.search.dp.CmDocTypesScopeBuilder">
<constructor-arg name="idPrefix" value="contracts" />
<constructor-arg name="systemId" value="ContractsLite" />
<constructor-arg name="params">
<list>
<ref local="subject" />
</list>
</constructor-arg>
<constructor-arg name="bundles">
<set>
<ref local="rkkContractsBundle" />
<ref local="addAgrBundle" />
<ref local="docToContractBundle" />
<ref local="financeBundle" />
<ref local="resolutionBundle" />
<ref local="reportBundle" />
<ref local="mainDocBundle" />
</set>
</constructor-arg>
<constructor-arg name="searchers">
<list>
<ref local="contractsSearcher" />
<ref local="contractsArc" />
</list>
</constructor-arg>
<constructor-arg name="builder">
<ref local="cmSearchScopeCompositExBuilder" />
</constructor-arg>
</bean> |
Пример
Для формирования скоупа в класс билдера передаются парамтеры:
- Уникальный префикс для идентификатора области. Должен быть уникальным в рамках иерархии областей одной;
<constructor-arg name="idPrefix" value="contracts" /> - Идентификатор БД;
<constructor-arg name="systemId" value="ContractsLite" - Параметры дефолтного бандла. Обычно указывается один параметр – subject.
<ref local="subject" /> - Набор бандлов
<constructor-arg name="bundles"> … - Набор поисковиков
<constructor-arg name="searchers"> …
Настройка соответствия «поисковый параметр - > поле/формула/форма документа»
Данная настройка используется при формировании полнотекстового запроса к Domino БД. Настройка задается в бинах наследниках класса ru.intertrust.cmj.af.search.dp.request.DominoRequestConfig. id бина задается по правилу: «dominoRequestConfig»+ключ модуля (см. 3) в 3.2.4). Например, dominoRequestConfigInputDocs :
<!-- Конфигурация параметров запроса (ВхД) -->
<bean id="dominoRequestConfigInputDocs" parent="dominoRequestConfigSuper">
<!-- Отображение ID параметров запроса на поля notes документа -->
<property name="nsFieldsByParamByBundleID">
<map merge="true">
<entry key="rkk#regDate" value="rdate" />
<entry key="rkk#docDate" value="outdate" />
<entry key="rkk#correspondent" value="UserFrom#From" />
<entry key="rkk#docNumber" value="OutNumber" />
<entry key="rkk#corrExecutor" value="Mast" />
</map>
</property>
<!-- Отображение ID бандла на имя формы notes документа -->
<property name="formsByBundleID">
<map merge="true">
<entry key="rkk" value="Input" />
<entry key="mainDoc" value="Input" />
</map>
</property>
</bean> |
В конструктор бина передаются параметры:
- <property name="nsFieldsByParamByBundleID"> - карта соответствий «параметр-> notes-поле». Ключ элемента карты имеет формат: id бандла# id параметра. Например, key="rkk#regDate". Значение элемента карты в простом случае представляет собой имя соотв. Notes-поля, которое участвует в формировании строки поиска в Domino. Например, value="rdate". Далее рассмотрим следующие случаи:
- Параметр с типом vcard (сотрудник) и в Domino идет поиск не только по открытому имени сотрудника, но и по названию организации сотрудника. В этом случае в поисковом запросе нужно указать два поля – поле, в котором хранится имя сотрудника, и поле с названием организации. Оба поля передаются в формате: поле сотрудника # поле организации. Например, value="UserFrom#From". Запрос по параметру будет выглядеть следующим образом:
([UserFrom]="Петров В. А." AND [From]="Руднев-Шиляев")). - Случай, когда для одного параметра необходимо выполнить поиск по двум полям. В данном случае в поисковом запросе используется оператор ИЛИ. Оба поля передаются в формате: поле1% поле2. Например,
value="Executor%execpeoples#ORGANISATIONNAME".
Запрос по параметру будет выглядеть следующим образом:
(([Executor]=" Петров В. А." OR ([execpeoples]=" Петров В. А." AND [ORGANISATIONNAME]="Руднев-Шиляев"))).
- property name="nsFieldsByParamByBundleID"> - карта соответствий «параметр-> формула». Ключ элемента карты имеет такой же формат, который описан в п. 1). Значение элемента карты представляет собой выражение для FT-запроса. Например, <entry key="rkk#isControl" value="[ExtContr_Flag]="1"" />. К общему запросу данное выражение добавляется через оператор AND.
- <property name="formsByBundleID">- карта соответствий «id бандла-> имя notes-формы, соответствующей бандлу». Например, <entry key="rkk" value="Input" />.
Конфигурация отображения результатов поиска
Результат поиска отображается в формате коллекции (см. Рис.2). Перечень атрибутов (колонки на рис.2) объектов в результирующей коллекции настраивается в xml-файле поиска и в БД Каталог через настройку области поиска CMJ в БД Портал. Для каждого модуля в xml-файле поиска представлен свой бин, наследник класса ru.intertrust.cmj.af.search.dp.docinfo ModuleExtractorConfig. В данном бине задаются настройки соответствий, необходимые для формирования результирующей коллекции. id бина задается по правилу: «moduleExtractorConfig»+ключ модуля (см. 3) в 3.2.4). Например, moduleExtractorConfigRequests:
<!-- Конфигурация отображения результатов поиска (ОГ) -->
<bean id="moduleExtractorConfigRequests" parent="moduleExtractorConfigSuper">
<!-- Отображение формы документа на имя корневого типа -->
<property name="rootTypesByBundleID">
<map merge="true">
<entry key="rkk" value="rkk-search-result" />
</map>
</property>
<!-- Отображение имя формы документа на ID бандла -->
<property name="bundleIDsByForm">
<map merge="true">
<entry key="Input" value="rkk" />
</map>
</property>
<!-- Настройка соответствий «элемент коллекции - системное поле» -->
<property name="nsFieldsByClTypeByBundleID">
<map merge="true">
<entry key="rkk#regDate" value="RDate" />
<entry key="rkk#to" value="S" />
<entry key="rkk#from" value="CorrBeard%LNameCorp" />
<entry key="mainDoc#regDate" value="RDate" />
<entry key="mainDoc#signer" value="CorrBeard%LNameCorp" />
</map>
</property>
<!-- Сортировка -->
<property name="sortingsByFields">
<set>
<ref bean="sortingParamsMainDocDate" />
</set>
<property name="sortingsByFields">
</bean> |
Настройка соответствий «форма – id бандла»
Данное соответствие передается в свойство bundleIDsByForm бина и связывает форму Notes-документа с id бандлом. Формат соответствия - <entry key=Форма документа value=id бандла />.
Например,
<entry key="Input" value="rkk" />
Здесь форма Input -Ркк ОГ, rkk - id бандла Ркк.
Настройка соответствий «id бандла – представление типа объекта»
Данное соответствие передается в свойство rootTypesByBundleID бина и связывает бандл c представлением типа объекта.
Представлением типа объекта – это настройка в Палитра XML, определяющая состав атрибутов-колонок для документа коллекции.
Формат соответствия - <entry key= id бандла value=представление типа объекта />.
Например,
<property name="rootTypesByBundleID">
<map merge="true">
<entry key="rkk" value="rkk-search-result" />
</map>
</property> |
Настройка соответствий «элемент коллекции - системное поле»
Данное соответствие передается в свойство nsFieldsByClTypeByBundleID бина и задает правило получения атрибута документа коллекции из notes-документа. Формат соответствия - <entry key= id бандла#тип элемента коллекции value=поле документа/>.
Например,
<entry key="rkk#regDate" value="RDate" /> , здесь для получения атрибута regDate считывается значение из поля RDate notes-документа.
Тип элемента коллекции - это настройка в БД Каталог, описывающая атрибут-колонку для документа коллекции.
Настройка соответствий «элемент коллекции - вычисляемое поле»
Данное соответствие передается в свойство formulasByClTypeByBundleID бина и задает правило получения атрибута документа коллекции из notes-документа путем использования @формулы. Формат соответствия - <entry key= id бандла#тип элемента коллекции value=JS-формула />.
Например,
<property name="formulasByClTypeByBundleID">
<map merge="true">
<entry key="decisionProject#created" value="Created)" />
</map>
</property> |
Параметры сортировки поиска
<property name="sortingsByFields">
<set>
<ref bean="sortingParamsMainDocDate" />
</set>
<property name="sortingsByFields"> |
Список параметров, которые используются при создании бинов SortingParams:
- columnName - имя колонки, при клике на которую будет происходить сортировка
- sortingFieldName - имя поля в Notes, по значению которого будет идти сортировка nodes из ресурса. Если sortingFieldName = null, то сортировка будет идти по значению поля columnName в ресурсе.
- sortingFieldType - тип значения в сравниваемом поле. Если sortingFieldType = Integer, то при сортировке значения сравниваются как числа, иначе - как строки. Предполагается, что тип DateTime не нужен, т.к. маловероятно, что при клике на колонку, в которой отображается дата/время, будет идти сортировка по какому-то значению, отличному непосредственно от дата/время, а в JSON дата/время всегда будут в формате yyyy-mm-ddThh:mm:ssZ (такие значения можно сортировать, сравнивая как строки).
- default - указывает будет ли совершена эта сортировка по умолчанию (может быть только одна сортировка по умолчанию для бандла, для добавления другой необходимо разнести по бандлам сортировки)
- defaultSortingDirection - Указывает направление сортировки по умолчанию (descendant/ascendant)
- bundleId - указывает id бандла для которого применяется сортировка, для каждого бандла надо делать свою, так как поля у объектов и имена колонок могут отличаться. id бандлов: rkk-search-result, mainDoc-search-result и др. По умолчанию rkk-search-result
- sortingDirections - выбранное направление сортировки (по убыванию/по возрастанию) - принимает <set> -->
<bean id="sortingParamsMainDocDate"
class="ru.intertrust.cmj.af.search.dp.docinfo.SortingParams">
<property name="columnName" value="regDate" />
<property name="sortingFieldName" value="regDate" />
<property name="sortingFieldType" value="String" />
<property name="default" value="true" />
<property name="defaultSortingDirection" value="descendant" />
<property name="bundleId" value="<Cell-View>" />
<property name="sortingDirections">
<set>
<value>descendant</value>
<value>ascendant</value>
</set>
</property>
</bean> |
Хардкод
К сожалению, не для всех параметров поисковой формы можно задать соответствия из п.3.2.6 в xml-файле поиска. К таким параметрам относится, например, параметр Тематика Ркк ОГ (fullQuestion), значение которого представляет собой элемент многоуровневого тематического классификатора. В таких случаях необходимо реализовать специальную обработку параметра. Например, см. класс ru.intertrust.cmj.af.search.dp.request.DominoRequestBuilderImpl, функция String getFormulaSearchFullQuestion(Map<?, ?> mapObject).
Также допускается хардкод для задачи формирования атрибутов результирующей коллекции. Например, см. классы наследники класса ModuleExtractorImpl.
Актуализация xml-файл поиска из настройки
Для кастомизации настроек поиска была разработана альтернативная загрузка настроек поиска из внешнего файла. Файл хранится в клиенте Системного администратора\Структура системы\Настройка web-поиска.
Переиндексация модуля
select fdr.id from F_DP_IntRkk
natural join f_dp_rkkbase fdr
join ss_module ss_module on fdr.module = ss_module.id and ss_module.id_type = fdr.module_type
join ss_moduletype ss_moduletype on ss_module.type = ss_moduletype.id and ss_moduletype.alias ='{Module}' |