1.3.3. Поиск

Общее описание настройки формы расширенного поиска.

На форме расширенного поиска (Рис.1) представлены разделы «Области поиска», «Искомый объект» и набор поисковых параметров. Содержимое разделов формируется системой на основании персональных настроек областей поиска CMJ БД Портал (поле «Области поиска в WEB-клиенте» в персональном профиле) и общих настроек в конфигурационном XML-файле applicationContext-config-search.xml серверной части СМ (далее xml-файл поиска).

рис 1

На форме расширенного поиска можно выбрать одну или несколько областей поиска. Для каждой области поиска свой набор искомых объектов иначе бандлов (определение бандла см. ниже), для каждого бандла определен свой набор параметров. Один бандл может входить в несколько областей поиска. Один параметр может входить в несколько бандлов. При выборе более одной областей поиска система формирует пересечение бандлов этих областей для отображения в разделе «Искомый объект», т.е. используются общие бандлы. Набор параметров также формируется как пересечение параметров бандлов различных областей поиска. Например, в областях поиска соответствующих БД "ОРД" и "Поручения", может быть общий набор параметров, характерных бандлу "резолюция", входящего в обе эти области поиска. Пользователь имеет возможность выбрать такой набор, и в результаты должны попасть только объекты соответствующего класса из всех выбранных областей, исключив при этом объекты других классов.
В текущей реализации модуля «Расширенный поиск» действует ограничение - количество выбранных искомых объектов (бандлов) не более одного.

Результат поиска отображается в формате коллекции (см. Рис.2). Перечень атрибутов (колонки на рис.2) объектов в результирующей коллекции настраивается в xml-файле поиска.

Правило формирования областей поиска (скоупов).

Введем определения некоторых сущностей, участвующих в конфигурации поиска.

Настройка области поиска CMJ

Определяет набор прикладных модулей для области поиска через идентификатор модуля + комплект. Данная настройка также определяет отображаемое название области поиска, которое локализуется и участвует в отображении элементов раздела «Области поиска» (см .Рис.1). Задается через настройку «Область поиска» Профили иерархии

Бандл

Бандл определяет набор поисковых параметров для класса искомых объектов, встречающихся в разных областях поиска. Набор параметров и отображаемое название параметров настраивается в xml-файле поиска. В типовой конфигурации используются такие бандлы как Ркк, Резолюция, Исполнение, Основной документ, Заседание, Договор и др. На рис.1 бандлы представлены в разделе «Искомый объект».

Поисковик (Searcher)

Поисковик выполняет поиск по PostgreSQL средствами Solr.

Область поиска (Скоуп)

Определяет логическую область поиска, поисковые формальные параметры и имена наборов параметров, специфичные данной области. На рис.1 скоупы представлены в разделе «Области поиска». Скоуп задается через настройки области поиска CMJ , наборы бандлов, наборы поисковиков

Билдер области поиска

Построитель скоупа. Задается через настройки в xml-файл поиска. На вход принимает идентификатор БД, набор бандлов, набор поисковиков. Все эти параметры задаются в xml-файле поиска для каждого билдера свои.
Правило формирования областей поиска (скоупов) для текущего пользователя:
Скоуп формируется в режиме run-time билдером на основании

настроек областей поиска CMJ в профиле иерархии, указанных в профиле пользователя
иерархии билдеров областей поиска, указанной в xml-файле поиска

Система для каждой настройки области поиска CMJ в портальном профиле текущего пользователя ищет свой билдер области поиска по идентификатору БД.

Детальное описание настроек

Настройки

Настройка области поиска CMJ

Данная настройка определяет набор прикладных модулей для области поиска через иденификатор БД СМ, комплект. Идентификатор БД и комплект задаются через выбор БД, в которой производится поиск. Отображаемое имя задается в поле Наименование и имеет возможность локализации в секции Локализация. Для создания новой настройки области поиска CMJ в БД Портал в виде «Области поиска CMJ» нажмите кнопку «Новая область поиска CMJ».

Рис.3 (Настройка Тип документа поиска в БД Портал)

Настройка в портальном профиле пользователя

В портальном профиле пользователя в поле «Области поиска в Web-клиенте» задаются настройки области поиска CMJ, доступные текущему пользователю для поиска через модуль расширенного поиска СМ4. Данная настройка обычно наследуется с корневого профиля.

Настройки в конфигурационном файле applicationContext-config-search.xml серверной компоненты.

Настройка «Параметр»

Параметры поиска представлены на форме расширенного поиска в разделе параметров.
Настройка параметра выполняется через формирование бина вида:

<bean id="subject" class="ru.intertrust.cmj.af.search.dp.CmParameter"
	c:id="subject" c:name="%{cmj-AF.search.param.name.subject}"
	c:type-ref="tstring" c:messageSource-ref="cmj_af_search_messageSource"
	c:classifier-ref="clSubject" c:dependency-ref="vdependency"/>

Для параметра в xml-файле задаются следующие атрибуты:

Идентификатор (id)
```
c:id="subject"
```
При формировании пересечения множеств параметров от разных областей поиска параметры объединяются по идентификатору.
Например,
Для области поиска по ВнД есть настройка параметра «Вид документа»:
```
<bean id="reqType" class="ru.intertrust.cmj.af.search.dp.CmParameter"
	c:id="reqType" c:name="%{cmj-AF.search.param.name.reqType}"
	c:type-ref="tstring" c:messageSource-ref="cmj_af_search_messageSource"
	c:classifier-ref="clReqType" /> 
```
Для области поиска по Договорам настройка параметра «Вид документа» выглядит иначе из-за использования другого классификатора:
```
<bean id="reqTypeContractDoc" class="ru.intertrust.cmj.af.search.dp.CmParameter"
	c:id="reqType" c:name="%{cmj-AF.search.param.name.reqType}"
	c:type-ref="tstring" c:messageSource-ref="cmj_af_search_messageSource"
	c:classifier-ref="clReqTypeContractDoc" />
```
Но оба параметра имеют общий id= reqType. Поэтому при выборе обеих областей поиска на форме (Внд, Договоры) параметр с id= reqType попадет в пересечение и будет отображен на форме в секции параметров. При этом значения обоих классификаторов (clReqType, clReqTypeContractDoc) объединятся.
Локализованное наименование параметра (name)
```
c:name="%{cmj-AF.search.param.name.subject}"
```

Ссылка на тип параметра

c:type-ref="tstring"

Тип параметра задается отдельным бином. На текущий момент имеются следующие типы параметров :

<!-- Типы параметров -->
<bean id="tstring" factory-bean="clTypeFactory" factory-method="getType" c:_0="string" />
<bean id="tboolean" factory-bean="clTypeFactory" factory-method="getType" c:_0="boolean" />
<bean id="tvcard" factory-bean="clTypeFactory" factory-method="getType" c:_0="vcard" />
<bean id="tdateinterval" factory-bean="clTypeFactory" factory-method="getType" c:_0="dateInterval" />
<bean id="tnumber" factory-bean="clTypeFactory" factory-method="getType" c:_0="number" />
<bean id="tfullQuestion" factory-bean="clTypeFactory" factory-method="getType" c:_0="fullQuestion" />
<bean id="treqTypeEDM" factory-bean="clTypeFactory" factory-method="getType" c:_0="reqType" />

Ссылка на служебный бин cmj_af_search_messageSource
Ссылка на бин классификатора (настройка классификаторов см. ниже)
Опция isAllowCustomValue:
true - разрешены ли произвольные значения,
false - только значения, выбранные из классификатора
Опция searchWithAsterisk - используется для поиска различных вхождений. По умолчанию опция отключена. Используется только для параметра regFullNumber
Ссылка на бин зависимости условия отображения от значения других полей (используется когда нужно скрывать/отображать поле не всегда, а при определенном значении какого либо другого поля данной формы).
- Бин зависимости выглядит следующим образом: <bean id=" vdShowIfNormativeISS" class="ru.intertrust.cmj.af.search.dp.CmVisibleDependency "
  c:field="docCategoryEDMISS" c:value="Нормативные документы" c:visible="true" />
  где:
  - fileld – id параметра, в зависимости от значений которого определяется необходимость отображения текущего параметра.
  - Value – значение поля, при котором надо скрывать/отображать поле ткущего параметра.
  - Visible – признак определяющий скрываем или отображаем поле текущего параметра, при значении «value» в поле «field».

Настройка «Классификатор параметра»

Настройка «Классификатор параметра» позволяет задать для параметра на форме расширенного поиска возможность выбора значений из справочника. Классификатор определяется в xml-файле поиска. Связь параметра с классификатором задается в в настройке бина параметра.
Модулем «Расширенный поиск» поддерживаются следующие виды классификаторов:

Простой классификатор по виду и ключу

Данный классификатор считывает набор значений по заданным в параметрах настройки виду и ключу. Классификатор реализует класс ru.intertrust.cmj.af.search.dp.CmClassifierByKey.
Пример, классификатор «Вид документа»

<bean id="clReqType" parent="clByKey_class">
	<property name="keys">
		<list>
			<value>CmClassifierByKey#Вид документа</value>
		</list>
	</property>
</bean> 
<bean id="clByKey_class" class="ru.intertrust.cmj.af.search.dp.CmClassifierByKey" c:notesView="(class)" />

Бин clReqType наследует с базового бина clByKey_class , который настроен на поиск по виду (class). В бин clReqType передается алиас типа классификатора – CmClassifierByKey и ключ Вид документа, по которому ведется поиск значений по виду (class) в тех БД СМ, которые определены областью поиска. Аналогично можно задать поиск по другому виду.

Статический классификатор

Данный классификатор задает жесткий набор значений. Классификатор реализует класс ru.intertrust.cmj.af.search.dp.StaticClassifier.
Пример,

<bean id="clCorType" class="ru.intertrust.cmj.af.search.dp.StaticClassifier">
	<property name="keys">
		<list>
			<value>StaticClassifier#Тип обращения</value>
		</list>
	</property>
	<property name="values">
		<list value-type="ru.intertrust.cmj.af.search.dp.CmClassifierValue">
			<bean class="ru.intertrust.cmj.af.search.dp.CmClassifierValue">
				<property name="value" value="Индивидуальное" />
				<property name="id" value="0" />
			</bean>
			<bean class="ru.intertrust.cmj.af.search.dp.CmClassifierValue">
				<property name="value" value="Коллективное" />
				<property name="id" value="1" />
			</bean>
			<bean class="ru.intertrust.cmj.af.search.dp.CmClassifierValue">
				<property name="value" value="Без ФИО и адреса" />
				<property name="id" value="2" />
			</bean> 
		</list>
	</property>
	<property name="type">
		<ref local="tstring" />
	</property>
</bean>

Для данного типа классификатора характерно то, что каждый его экземпляр необходимо указать в бине сmClassifierService в списке классификаторов. Бин сmClassifierService находится в этом же xml-файле. Значение для каждого такого классификатора задаются в бине в свойстве values (см. пример выше). Значение (реализация класса CmClassifierValue) состоит из отображаемого названия и идентификатора. Например,
<property name="value" value="Коллективное" /> - отображаемое название
<property name="id" value="1" /> - идентификатор
Отображаемое название используется при выборе на форме, идентификатор - при поиске по БД. Если значения классификатора не имеют идентификатора и в БД хранятся также, как и отображаются, то в идентификатор прописываем то же значение, что и в отображаемое.
Например,
<property name="value" value="Коллективное" /> - отображаемое название
<property name="id" value=" Коллективное " /> - идентификатор

Простой классификатор по виду.

Данный классификатор считывает набор значений из заданного вида в тех БД СМ, которые определены областью поиска. Классификатор реализует класс ru.intertrust.cmj.af.search.dp.CmClassifierByView.
Пример, классификатор видов заседаний

<bean id="clMeetingType" class="ru.intertrust.cmj.af.search.dp.CmClassifierByView" c:notesView="(MeetingTypeSettings)">
	<property name="keys">
		<list>
			<value>CmClassifierByView</value>
		</list>
	</property>
</bean>

Классификатор по заданной БД и виду

Система позволяет настроить классификатор, который будет выбирать значений из заданной БД и вида независимо от области поиска. Например, выбор тематики из БД Каталог для БД Документы использует классификатор:
Реализация данного классификатора представлена в классе ru.intertrust.cmj.af.search.dp.CmClassifierEDM. Аналогично можно разработать другие реализации классификатора для поиска по другим БД независимо от выбранных областей поиска.

<bean id="clTheme_EDM" class="ru.intertrust.cmj.af.search.dp.CmClassifierEDM" c:notesView="ReadyTematika">
	<property name="keys">
		<list>
			<value>CmClassifierEDM</value>
		</list>
	</property>
</bean>

Классификатор по кастомной коллекции

Данный инструмент позволяет построить свой перечень значений на базе SQL-запроса

Вызов справочника

<bean id="clMettingSettings" class="ru.intertrust.cmj.af.search.dp.CmClassifierByView"c:notesView="Meetings_(vw_cmj_settings_search)">
	<property name="keys">
		<list>
			<value>CmClassifierByView#Meetings#Meetings_(vw_cmj_settings_search)</value>
		</list>
    </property>
</bean>

Параметры:

- атрибут c:notesView - название коллекции в которой формируется SQL-запрос

- тег value = <Вызов класса ru.intertrust.cmj.af.search.dp.CmClassifierByView>#<Модуль системы>#<Название кастомной коллекции>

Кастомная коллекция

collection name="Meetings_(vw_cmj_settings_search)" idField="id" replace="runtime">
	<prototype>
		<![CDATA[
                SELECT
                  id
                  ,Module
                  ,self_1
                  ,self_2
                  ,self_3
                  ,created_date
                  ,meetingType
                  ,name
                FROM (
                	SELECT
                	  	settings.id 			     AS id
                        ,settings.Module             AS Module
                        ,'<name>' AS name
                        ,'<id>' 			         AS self_1
                        ,':' 				         AS self_2
                        ,'</>' 				         AS self_3
                        ,settings.created_date		 AS created_date
                        ,settings.subject            AS meetingType
               		FROM
                         f_meetings_settings settings
                    WHERE settings.isdeleted <> 1
                     ) s
                WHERE
                  1 = 1
                    ::where-clause]]>
	</prototype>
	<counting-prototype>
		<![CDATA[
                 SELECT
                  COUNT(1)
                FROM (
                	SELECT
                	  settings.id 			     AS id
                        ,settings.Module             AS Module
                        ,'<meetingType>' AS meetingType_1
                        ,'<id>' 			         AS self_1
                        ,':' 				         AS self_2
                        ,'</>' 				         AS self_3
                        ,settings.created_date		 AS created_date
                        ,settings.subject            AS meetingType
               		FROM
                         f_meetings_settings settings
                    WHERE settings.isdeleted <> 1
                     ) s
                WHERE
                  1 = 1
                    ::where-clause]]>
	</counting-prototype>
	<filter name="MODULE">
		<criteria placeholder="where-clause">
			<![CDATA[
                    Module = {0}
                ]]>
		</criteria>
	</filter>
	<filter name="meetingType">
		<criteria placeholder="where-clause">
			<![CDATA[
                    meetingType = {0}
                ]]>
		</criteria>
	</filter>
</collection>

Бин коллекции

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-3.2.xsd"
       default-lazy-init="true">

    <bean id="Meetings_(vw_cmj_settings_search)Metadata"
          class="ru.intertrust.cm_sochi.srv.connector.sochi.collections.CollectionMetadataNew"
          p:caseSensitiveFieldNames="true" p:searchArea="Meetings_uicoll_settings">

        <constructor-arg>
            <list value-type="ru.intertrust.cm_sochi.srv.connector.sochi.collections.Field">
                <bean class="ru.intertrust.cm_sochi.srv.connector.sochi.collections.Field" p:name="meetingType" p:filter="meetingType" p:sortOrder="ASCENDING" p:sortPriority="0"/>
                <bean class="ru.intertrust.cm_sochi.srv.connector.sochi.collections.Field" p:name="self">
                    <property name="virtualField">
                        <bean class="ru.intertrust.cm_sochi.srv.connector.sochi.collections.TnUnidVirtualField">
                            <property name="realFields">
                                <list>
                                    <value>self_1</value>
                                    <value>Module</value>
                                    <value>self_2</value>
                                    <value>id</value>
                                    <value>created_date</value>
                                    <value>self_3</value>
                                </list>
                            </property>
                            <property name="separator" value=""/>
                            <property name="emptySeparator" value="true"/>
                        </bean>
                    </property>
                </bean>
            </list>
        </constructor-arg>
    </bean>
</beans>

СО классификатор

Данный классификатор позволяет выбрать субъект из справочника Структура организации, Справочник организаций, Справочник персон. Классификатор реализует класс ru.intertrust.cmj.af.search.dp.SOClassifier. В XML-файле настроено несколько видов СО классификаторов. Один из них – выбор подразделений системной организации:

<bean id="clCurSysDeps" class="ru.intertrust.cmj.af.search.dp.SOClassifier">
	<constructor-arg>
		<set value-type="ru.intertrust.cmj.af.so.SOApplication$BeardsSelection$OrganizationsSet">
			<value>SYS_CURRENT</value>
		</set>
	</constructor-arg>
	<constructor-arg>
		<set value-type="ru.intertrust.cmj.af.so.SOBeard$Type">
			<value>SYS_ORGANIZATION</value>
			<value>SYS_DEPARTMENT</value>
			<value>SYS_HUMAN_HEAD</value>
		</set>
	</constructor-arg>
	<constructor-arg ref="tvcard" />
</bean>

Настойка «Бандл»

Для бандла задаются идентификатор, отображаемое имя и параметры. Например, бандл «Дополнительное соглашение» для БД Договоры:

<bean id="addAgrBundle" class="ru.intertrust.cmj.af.search.dp.CmBundle">
<constructor-arg name="id" value="addAgr" /> - идентификатор
<constructor-arg name="name"
value="%{cmj-AF.search.bundle.name.addAgr}" /> - отображаемое имя.
<constructor-arg name="params" index="2">
<list> - параметры 
<ref local="contractNumber" />
<ref local="contractDate" />
<ref local="reqType" /> 
<ref local="party1" />
<ref local="party2" />
<ref local="contractStatus" />
…
</list>
</constructor-arg>
<constructor-arg name="messageSource" ref="cmj_af_search_messageSource" />
</bean>

Настройка «Поисковик»

Пример

<!-- ВХОДЯЩИЕ ЗА ПРЕДЫДУЩИЙ ПЕРИОД, НЕИМЕННЫЕ -->
<bean id="inputPrevSearcherNotNamed" class="ru.intertrust.cm_sochi.srv.connector.sochi.search.SochiSolrSearcher">
	<constructor-arg name="cmAppSystemId" value="InputDocsPrev" />
	<constructor-arg>
		<bean class="ru.intertrust.cmj.af.search.dp.request.DominoRequestBuilderImpl">
			<constructor-arg value="InputDocs" />
		</bean>
	</constructor-arg>
	<constructor-arg>
		<bean class="ru.intertrust.cmj.af.search.dp.docinfo.InputInfoExtractor" c:messageSource-ref="cmj_af_search_messageSource"></bean>
	</constructor-arg>
</bean>

ОСТАНОВИЛСЯ ТУТ

Для Поисковика задается:

Класс реализации. Данный класс выполняет полнотекстовый поиск средствами Solr.

ru.intertrust.cm_sochi.srv.dispatcher.beans.SearcherSD

ru.intertrust.cmj.af.search.dp.DominoDbFTSearcher

ru.intertrust.cmj.af.search.dp.request.DominoRequestBuilderImpl

Системой предлагается две реализации данного класса: для поиска по именным - DominoDbFTSearcherNamed, для поиска по неименным БД СМ- DominoDbFTSearcherNotNamed. В примере используется последняя.

Идентификатор БД, по которой нужно выполнить поиск.
Класс DominoRequestBuilderImpl, который формирует строку поискового полнотекстового запроса Domino. Данный класс используется для всех поисковиков. В конструктор класса DominoRequestBuilderImpl передается ключ модуля, который участвует в настройке связи «поисковый параметр - поле notes-документа». Задача ключа модуля идентифицировать правило соответствия «поисковый параметр –> поле/формула/форма notes-документа». Данное правило настраивается в xml-файле (см. ниже). Обычно в качестве ключа используется идентификатор БД. В примере ключ равен InputDocs. Например, что для БД Вхд текущего и прошлого периодов используется один ключ InputDocs, так как правило соответствия «поисковый параметр - поле notes-документа» для данных БД одно. Об использовании данного ключа описано в п. 3.2.6.
Класс реализации интерфейса InfoExtractor. Данный класс отвечает за преобразование notes-документа в объект Entry строку коллекции. Для каждого поисковика задается свой класс реализации InfoExtractor в зависимости от типа модуля. В классе обязательно должен быть реализован метод String getMapKey(), который возвращает ключ. Данный ключ идентифицирует правило соответствия «поле notes-документа элемент коллекции», которое настраивается с этом же xml-файле поиска. Обычно в качестве ключа используется идентификатор БД

Иерархия билдеров областей поиска

Иерархия билдеров задается в бине 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"> …

Настройка соответствия «поисковый параметр - > поле/формула/форма notes-документа»

Данная настройка используется при формировании полнотекстового запроса к 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". Далее рассмотрим следующие случаи:
1. Параметр с типом vcard (сотрудник) и в Domino идет поиск не только по открытому имени сотрудника, но и по названию организации сотрудника. В этом случае в поисковом запросе нужно указать два поля – поле, в котором хранится имя сотрудника, и поле с названием организации. Оба поля передаются в формате: поле сотрудника # поле организации. Например, value="UserFrom#From". Запрос по параметру будет выглядеть следующим образом:
  ([UserFrom]="Петров В. А." AND [From]="Руднев-Шиляев")).
2. Случай, когда для одного параметра необходимо выполнить поиск по двум полям. В данном случае в поисковом запросе используется оператор ИЛИ. Оба поля передаются в формате: поле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>
<!-- Отображение имя формы notes документа на 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>
</bean>

Настройка соответствий «notes-форма – id бандла»

Данное соответствие передается в свойство bundleIDsByForm бина и связывает форму Notes-документа с id бандлом. Формат соответствия - <entry key=Форма документа value=id бандла />.
Например,
<entry key="Input" value="rkk" />
Здесь форма Input -Ркк ОГ, rkk - id бандла Ркк.

Настройка соответствий «id бандла – представление типа объекта»

Данное соответствие передается в свойство rootTypesByBundleID бина и связывает бандл c представлением типа объекта.
Представлением типа объекта – это настройка в БД Каталог, определяющая состав атрибутов-колонок для документа коллекции. Для просмотра настроек Представлением типа объекта используется вид ~Админ CMJ\Типы элементов коллекций. Для удобства поиска настроек в виде отсортируйте колонку «Предст. Типа объекта».
Формат соответствия - <entry key= id бандла value=представление типа объекта />.
Например,

<property name="rootTypesByBundleID">
<map merge="true">
<entry key="rkk" value="rkk-search-result" />
</map>
</property>

Настройка соответствий « элемент коллекции- notes-поле»

Данное соответствие передается в свойство nsFieldsByClTypeByBundleID бина и задает правило получения атрибута документа коллекции из notes-документа. Формат соответствия - <entry key= id бандла#тип элемента коллекции value=поле notes-документа/>.
Например,
<entry key="rkk#regDate" value="RDate" /> , здесь для получения атрибута regDate считывается значение из поля RDate notes-документа.
Тип элемента коллекции - это настройка в БД Каталог, описывающая атрибут-колонку для документа коллекции.

Настройка соответствий «элемент коллекции - @формула»

Данное соответствие передается в свойство formulasByClTypeByBundleID бина и задает правило получения атрибута документа коллекции из notes-документа путем использования @формулы. Формат соответствия - <entry key= id бандла#тип элемента коллекции value=@формула />.
Например,

<property name="formulasByClTypeByBundleID">
<map merge="true"> 
<entry key="decisionProject#created" value="Created)" />
</map>
</property>

Хардкод

К сожалению, не для всех параметров поисковой формы можно задать соответствия из п.3.2.6 в xml-файле поиска. К таким параметрам относится, например, параметр Тематика Ркк ОГ (fullQuestion), значение которого представляет собой элемент многоуровневого тематического классификатора. В таких случаях необходимо реализовать специальную обработку параметра. Например, см. класс ru.intertrust.cmj.af.search.dp.request.DominoRequestBuilderImpl, функция String getFormulaSearchFullQuestion(Map<?, ?> mapObject).
Также допускается хардкод для задачи формирования атрибутов результирующей коллекции. Например, см. классы наследники класса ModuleExtractorImpl.

Актуализация xml-файл поиска из настройки в БД СО.

Для кастомизации настроек поиска была разработана альтернативная загрузка настроек поиска из внешнего файла. Файл хранится в шаблоне БД СО в настройке «Настройки поиска в web-клиенте». Если система находит в данной настройке файл, то использует его, иначе использует файл из варника. Кастомный файл сформирован на основе типового файла. Таким образом, при изменении классов бинов и прочих настроек, влияющих на инициализацию компонентов из настроечного файла, следует также актуализировать данный файл.

Статус	В РАБОТЕ
Автор	Васильев Антон
Комментарий

Дерево страниц

1.3.3. Поиск

Общее описание настройки формы расширенного поиска.

Правило формирования областей поиска (скоупов).

Настройка области поиска CMJ

Бандл

Поисковик (Searcher)

Область поиска (Скоуп)

Билдер области поиска

Детальное описание настроек

Настройки

Настройка области поиска CMJ

Настройка в портальном профиле пользователя

Настройки в конфигурационном файле applicationContext-config-search.xml серверной компоненты.

Настройка «Параметр»

Настройка «Классификатор параметра»

Простой классификатор по виду и ключу

Статический классификатор

Простой классификатор по виду.

Классификатор по заданной БД и виду

Классификатор по кастомной коллекции

Настойка «Бандл»

Настройка «Поисковик»

Иерархия билдеров областей поиска

Настройка соответствия «поисковый параметр - > поле/формула/форма notes-документа»

Конфигурация отображения результатов поиска

Настройка соответствий «notes-форма – id бандла»

Настройка соответствий «id бандла – представление типа объекта»

Настройка соответствий « элемент коллекции- notes-поле»

Настройка соответствий «элемент коллекции - @формула»

Хардкод

Актуализация xml-файл поиска из настройки в БД СО.