CM. Руководство разработчика
Дерево страниц
Skip to end of metadata
Go to start of metadata

Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 42 Следующий »

Корневой элемент beans. Пространство имен: <beans lxmlns="http://www.springframework.org/schema/beans">

Краткое описание

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

Структура XML 
<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:c="http://www.springframework.org/schema/c"
       xmlns="http://www.springframework.org/schema/beans"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
 
    <!-- {Модуль} -->
    <bean id="newModuleSearcher" class="ru.intertrust.cm_sochi.srv.connector.sochi.search.SochiSolrSearcher">
        <constructor-arg name="cmAppSystemId" value="{Module}"/>
        <constructor-arg name="isNamed" value="true"/>
        <constructor-arg name="searchArea" value="{Module}"/>
        <constructor-arg name="targetCollectionName" value="(search)"/>
        <constructor-arg>
            <bean class="ru.intertrust.cm_sochi.srv.connector.sochi.search.InternalDocsSearchFilterCreator"/>
        </constructor-arg>
        <constructor-arg>
            <bean class="ru.intertrust.cmj.af.search.dp.docinfo.CustomModuleInfoExtractor" c:messageSource-ref="cmj_af_search_messageSource" c:ident="{Module}"/>
        </constructor-arg>
    </bean>
    <!-- Модуль end-->
 
    <!-- {Модуль} -->
    <!-- Иерархия билдеров областей поиска -->
    <bean id="rootScopeBuilder" class="ru.intertrust.cmj.af.search.ScopeTreeBuilder">
        <property name="childs">
            <list>
                <!-- {Модуль} -->
                <bean class="ru.intertrust.cmj.af.search.dp.CmDocTypesScopeBuilder">
                    <constructor-arg index="0" value="{module}"/>
                    <constructor-arg index="1" value="{Module}"/>
                    <constructor-arg index="2">
                        <list>
                            <ref bean="subject"/>
                        </list>
                    </constructor-arg>
                    <constructor-arg index="3">
                        <set>
                            <ref bean="rkkInternalBundle"/>
                            <ref bean="resolutionBundle"/>
                            <ref bean="reportBundle"/>
                            <ref bean="mainDocBundleForCustom"/>
                        </set>
                    </constructor-arg>
                    <constructor-arg index="4">
                        <list>
                            <ref bean="{Module}Searcher"/>
                        </list>
                    </constructor-arg>
                    <constructor-arg index="5">
                        <ref bean="cmSearchScopeCompositExBuilder"/>
                    </constructor-arg>
                </bean>
                <!-- {Модуль} end-->
            </list>
        </property>
    </bean>
 
    <!-- Иерархия билдеров простого поиска -->
    <bean id="rootScopeBuilderSimple" class="ru.intertrust.cmj.af.search.ScopeTreeBuilder">
        <property name="childs">
            <list>
                <!-- {Модуль} -->
                <bean class="ru.intertrust.cmj.af.search.dp.CmDocTypesScopeBuilder">
                    <constructor-arg index="0" value="{module}"/>
                    <constructor-arg index="1" value="{Module}"/>
                    <constructor-arg index="2">
                        <list>
                            <ref bean="subject"/>
                        </list>
                    </constructor-arg>
                    <constructor-arg index="3">
                        <set>
                            <ref bean="mainDocBundleSimple"/>
                        </set>
                    </constructor-arg>
                    <constructor-arg index="4">
                        <list>
                            <ref bean="{Module}Searcher"/>
                        </list>
                    </constructor-arg>
                    <constructor-arg index="5">
                        <ref bean="cmSearchScopeCompositExBuilder"/>
                    </constructor-arg>
                </bean>
                <!-- {Модуль} end-->
            </list>
        </property>
    </bean>
 
    <!-- Иерархия билдеров однострочного поиска. Однострочный поиск повторяет структуру расширенного поиска, но урезан по бандлам -->
    <bean id="oneLineRootScopeBuilder" class="ru.intertrust.cmj.af.search.ScopeTreeBuilder">
        <property name="childs">
            <list>
                <!-- {Модуль} -->
                <bean class="ru.intertrust.cmj.af.search.dp.CmDocTypesScopeBuilder">
                    <constructor-arg index="0" value="{module}"/>
                    <constructor-arg index="1" value="{Module}"/>
                    <constructor-arg index="2">
                        <list>
                            <ref bean="subject"/>
                        </list>
                    </constructor-arg>
                    <constructor-arg index="3">
                        <set>
                            <ref bean="mainDocBundleOneLine"/>
                        </set>
                    </constructor-arg>
                    <constructor-arg index="4">
                        <list>
                            <ref bean="{Module}Searcher"/>
                        </list>
                    </constructor-arg>
                    <constructor-arg index="5">
                        <ref bean="cmSearchScopeCompositExBuilder"/>
                    </constructor-arg>
                </bean>
                <!-- {Модуль} end-->
            </list>
        </property>
    </bean>
 
    <!-- Конфигурация параметров запроса ({Модуль}) -->
    <bean id="dominoRequestConfig{Module}" parent="dominoRequestConfigSuper">
        <!-- Отображение ID параметров запроса на поля notes документа -->
        <property name="nsFieldsByParamByBundleID">
            <map merge="true">
                <entry key="rkk#regDate" value="outdate"/>
                <entry key="rkk#addressees" value="To"/>
                <entry key="rkk#signer" value="UserFrom"/>
                <entry key="rkk#executor" value="Mast"/>
                <entry key="resolution#regDate" value="outdate"/>
                <entry key="mainDoc#regDate" value="outdate"/>
                <entry key="mainDoc#signer" value="UserFrom"/>
                <entry key="mainDoc#docDate" value="outdate"/>
                <entry key="mainDoc#docDateSimple" value="outdate"/>
                <entry key="report#regDate" value="outdate"/>
            </map>
        </property>
        <!-- Отображение ID бандла на имя формы notes документа -->
        <property name="formsByBundleID">
            <map merge="true">
                <entry key="rkk" value="Input"/>
                <entry key="mainDoc" value="Input"/>
            </map>
        </property>
    </bean>
 
    <!--Параметры сортировки результатов поиска ({Модуль}) -->
    <bean id="sortingParams{Module}Date" class="ru.intertrust.cmj.af.search.dp.docinfo.SortingParams">
        <property name="columnName" value="regDate"/>
        <property name="sortingFieldType" value="String"/>
        <property name="default" value="true"/>
        <property name="defaultSortingDirection" value="descendant"/>
        <property name="sortingDirections">
            <set>
                <value>descendant</value>
                <value>ascendant</value>
            </set>
        </property>
    </bean>
 
    <!-- Конфигурация отображения результатов поиска ({Модуль}) -->
    <bean id="moduleExtractorConfig{Module}" 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="outdate"/>
                <entry key="rkk#to" value="S"/>
                <entry key="rkk#from" value="S2"/>
                <entry key="mainDoc#regDate" value="outdate"/>
                <entry key="mainDoc#signer" value="S2"/>
            </map>
        </property>
        <property name="formulasByClTypeByBundleID">
            <map merge="true">
                <entry key="rkk#hasAttachments" value="doc.getItemValueString('IsHasContent').trim() == '1'"/>
                <entry key="rkk#id" value="ctx.getString('Links_DocReplID').trim() == '' ? '' : (ctx.getString('Links_DocReplID').trim() + ':' + ctx.getString('Links_DocUNID').trim())"/>
            </map>
        </property>
    </bean>
</beans>

beans

nameclass

Параметр поиска

ru.intertrust.cmj.af.search.dp.CmParameter

Пример
<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"/>

Классификатор по ключу

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)" />

Классификатор по представлению

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>
Пример
<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>

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

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>

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

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>

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

ru.intertrust.cmj.af.search.dp.SOClassifier


<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="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>#<Модуль системы>#<Название кастомной коллекции>



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

Данный классификатор позволяет выбрать субъект из справочника Структура организации, Справочник организаций, Справочник персон. Классификатор реализует класс 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}'


  • Нет меток