Статус

КомментарийДополнительный комментарий

Общее описание настройки поиска

Расширенный поиск

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

рис 1

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

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

Простой поиск

Однострочный поиск

Поиск по связям

Простой

Расширенный

Контекстный поиск


Поиск в представлениях

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

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

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

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

Бандл

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

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

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

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

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


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

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

  1. настроек областей поиска CMJ в профиле иерархии, указанных в профиле пользователя
  2. иерархии билдеров областей поиска, указанной в 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-файле задаются следующие атрибуты:

  1. Идентификатор (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) объединятся. 

  2. Локализованное наименование параметра (name)

    c:name="%{cmj-AF.search.param.name.subject}"


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

    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" />
  4. Ссылка на служебный бин cmj_af_search_messageSource
  5. Ссылка на бин классификатора (настройка классификаторов см. ниже)
  6. Опция isAllowCustomValue:
    true - разрешены ли произвольные значения,
    false - только значения, выбранные из классификатора
  7. Опция searchWithAsterisk - используется для поиска различных вхождений. По умолчанию опция отключена. Используется только для параметра regFullNumber
  8. Ссылка на бин зависимости условия отображения от значения других полей (используется когда нужно скрывать/отображать поле не всегда, а при определенном значении какого либо другого поля данной формы).
    • Бин зависимости выглядит следующим образом: <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="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>

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

  1. 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 по неименным БД
  2. cmAppSystemId - идентификатор модуля, по которой нужно выполнить поиск.
  3. isNamed - признак "именная"
  4. searchArea - область поиска
  5. targetCollectionName
  6. class="ru.intertrust.cm_sochi.srv.connector.sochi.search.DefaultContextualSearchFilterCreator
  7. class="ru.intertrust.cm_sochi.srv.connector.sochi.search.InternalDocsSearchFilterCreator
  8. key="rkkContextual" value="F_DP_IntRkk"
  9. class="ru.intertrust.cm_sochi.srv.connector.sochi.search.docinfo.ContextualSochiModuleInfoExtractor
  10. ref="cmj_af_search_messageSource
  11. value="InternalDocs"
  12. value="rkkContextualSearchResObject"
  13. <list>
    <value>hyperLinkCustomized</value>
    <value>rkkContextualSearchResObject</value>
    </list>
  14. <constructor-arg ref="identifiableObjectSearchResultItemFactory" />
  15. Класс DominoRequestBuilderImpl - формирует строку поискового полнотекстового запроса Domino. Данный класс используется для всех поисковиков. В конструктор класса DominoRequestBuilderImpl передается ключ модуля, который участвует в настройке связи «поисковый параметр - поле документа». Задача ключа модуля идентифицировать правило соответствия «поисковый параметр –> поле/формула/форма-документа». Данное правило настраивается в xml-файле (см. ниже). Обычно в качестве ключа используется идентификатор БД. В примере ключ равен InputDocs. Например, что для модуля ВхД текущего и прошлого периодов используется один ключ InputDocs, так как правило соответствия «поисковый параметр - поле документа» для данных БД одно.
  16. Класс реализации интерфейса 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>


Пример
Для формирования скоупа в класс билдера передаются парамтеры:

  1. Уникальный префикс для идентификатора области. Должен быть уникальным в рамках иерархии областей одной;
    <constructor-arg name="idPrefix" value="contracts" />
  2. Идентификатор БД;
    <constructor-arg name="systemId" value="ContractsLite"
  3. Параметры дефолтного бандла. Обычно указывается один параметр – subject.
    <ref local="subject" />
  4. Набор бандлов
    <constructor-arg name="bundles"> …
  5. Набор поисковиков
    <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>


В конструктор бина передаются параметры:

  1. <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]="Руднев-Шиляев"))).
  2. property name="nsFieldsByParamByBundleID"> - карта соответствий «параметр-> формула». Ключ элемента карты имеет такой же формат, который описан в п. 1). Значение элемента карты представляет собой выражение для FT-запроса. Например, <entry key="rkk#isControl" value="[ExtContr_Flag]="1"" />. К общему запросу данное выражение добавляется через оператор AND.
  3. <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}'