Содержание

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

• Использование специализированных CAS-потребителей в OmniFind
• Экстернализованные сообщения в специализированных анализирующих компонентах
• Изменение значений таймаута pear
• Изменение размера кучи для специализированных аннотаторов
• Просмотр сообщений журнала специализированных аннотаторов в OmniFind
• Специфические UIMA-дескрипторы для коллекции OmniFind
• Расширение системы типов OmniFind

В начало

Использование специализированных CAS-потребителей в OmniFind

Кроме специализированных аннотаторов (custom annotator) в OmniFind можно исполнять также специализированные CAS-потребители (CAS consumer). Чтобы запустить такой анализирующий компонент в OmniFind, его необходимо упаковать в PEAR-файл аналогично любому другому специализированному аннотатору. PEAR-файл можно загрузить в OmniFind в качестве механизма анализа и затем ассоциировать его с одной или несколькими коллекциями (collection). Процесс загрузки в OmniFind в данной статье подробно не описывается. Дополнительная информация по данной теме приведена в документации по OmniFind "Администрирование системы корпоративного поиска" в разделе "Специализированная обработка текста" в основной главе "Работа с коллекциями и внешними источниками данных и администрирование синтаксического анализатора системы корпоративного поиска".

Упаковка CAS-потребителя в pear-файл

При упаковке компонента CAS-потребителя в PEAR-файл необходимо вложить этот компонент в дескриптор агрегированного механизма анализа. Это необходимо делать всегда, даже если в PEAR-пакете есть всего один CAS-потребитель. Это действие необходимо для того, чтобы UIMA-компоненты могли вызывать и обрабатывать дескриптор CAS-потребителя. Пример дескриптора агрегированного механизма анализа, содержащего один компонент CAS-потребителя, приведен в листинге 1.

				
<?xml version="1.0" encoding="UTF-8" ?>
<taeDescription xmlns="http://uima.watson.ibm.com/resourceSpecifier">

   <frameworkImplementation>com.ibm.uima.java</frameworkImplementation>
   <primitive>false</primitive>
   <delegateAnalysisEngineSpecifiers>
       <delegateAnalysisEngine key="myCASConsumer">
          <import location="./casConsumer.xml"/>
       </delegateAnalysisEngine>
    </delegateAnalysisEngineSpecifiers>

   <analysisEngineMetaData>
      <name>CAS consumer wrapper</name>
      <description>sample CAS consumer wrapper</description>
      <version>1.0</version>
      <vendor>IBM Corporation</vendor>

      <flowConstraints>
         <fixedFlow>
             <node>myCASConsumer</node>
         </fixedFlow>
      </flowConstraints>

      <operationalProperties>
          <modifiesCas>false</modifiesCas>
          <multipleDeploymentAllowed>false</multipleDeploymentAllowed>
      </operationalProperties>

   </analysisEngineMetaData>
</taeDescription>
      

Для корректного вызова CAS-потребителя необходимо использовать fixedFlow в качестве ограничения потока работ (flowConstraint), как показано в приведенном выше примере дескриптора). В противном случае CAS-потребитель не вызывается, поскольку отсутствуют функциональные возможности, которые может предоставить CAS-потребитель. Дополнительная информация о различных ограничениях потока работ, доступных для UIMA, приведена в документации "Справочное руководство пользователя UIMA SDK" в главе 4.5.5 "Настройка спецификации результатов".

Другими важными разделами приведенного выше примера агрегированного дескриптора являются рабочие свойства (operationalProperties). Эти свойства должны устанавливаться в соответствии с настройками дескриптора CAS-потребителя. Дополнительная информация о рабочих свойствах приведена в документации "Справочное руководство пользователя по UIMA SDK" в главе 18.3.1 "Дескрипторы примитивного механизма анализа".

В листинге 1 агрегированный механизм анализа содержит только один компонент CAS-потребителя, но есть возможность добавить несколько компонентов аннотаторов к одному и тому же агрегированному механизму анализа. Важно только, чтобы CAS-потребитель был вложен в дескриптор агрегированного механизма анализа и чтобы поток, в котором вызывается CAS-потребитель, имел ограничение fixedFlow. Примеры, в которых агрегированные механизмы анализа содержат CAS-потребителей и аннотаторы, приведены в документации "Справочное руководство пользователя по UIMA SDK" в главе 4.3.2 "Агрегированные механизмы могут включать в себя CAS-потребителей".

Примечание. Необязательные методы CAS-потребителя collectionProcessComplete() и batchProcessComplete() не будут вызываться для специализированных CAS-потребителей в OmniFind, развернутых как PEAR-файл и выполняющихся в огражденном блоке (fenced box).

Доступ к метаданным документа OmniFind в специализированных CAS-потребителях

В специализированном CAS-потребителе может понадобиться обратиться к метаданным документа OmniFind, называемым esDocumentMetaData. В приведенном ниже листинге 2 показано, как можно это осуществить при помощи UIMA CAS API. В листинге 2 URL-адрес документа и его идентификатор извлекается из метаданных документа OmniFind. Дополнительная информация о свойствах esDocumentMetaData приведена в разделе "Расширение системы типов OmniFind" данной статьи.

				
try {
   // получить DocumentAnnotation из CAS
   AnnotationFS documentAnnotation = aCAS.getTCAS().getDocumentAnnotation();
     
   // получить тип DocumentAnnotation для извлечения свойства esDocumentMetaData
   Type documentAnnotType = documentAnnotation.getType();
     
   // получить свойство esDocumentMetaData 
   Feature esDocumentMetaDataFeature = documentAnnotType
       .getFeatureByBaseName("esDocumentMetaData");
     
   // получить структуру свойства esDocumentMetaData для текущего документа
   FeatureStructure esDocumentMetaData = documentAnnotation
       .getFeatureValue(esDocumentMetaDataFeature);

   String documentURL = null;
   int documentId = -1;

   if (esDocumentMetaData != null) {
      // для извлечения некоторых свойств из структуры свойств 
      // esDocumentMetaData нам необходим тип esDocumentMetaData
      Type esDocumentMetaDataType = esDocumentMetaData.getType();

      // получить свойство url 
      Feature urlFeature = esDocumentMetaDataType.getFeatureByBaseName("url");
      // получить значение свойства url 
      documentURL = esDocumentMetaData.getStringValue(urlFeature);

      // получить свойство  document ID 
      Feature documentIdFeature = esDocumentMetaDataType
          .getFeatureByBaseName("documentId");
      // получить значение свойства document ID 
      documentId = esDocumentMetaData.getIntValue(documentIdFeature);
   }
      

Строки в примере кода, относящиеся к созданию объектов свойств и типов, можно перенести в метод typeSystemInit() анализирующего компонента, поскольку они не меняются в каждом документе.

Информация об URL, извлекаемая в листинге 2, аналогична используемой интерфейсом SIAPI (Search and Index API) и продемонстрирована в приложении для поиска в OmniFind. Она может использоваться для связывания результатов анализа текста документа с результатами поиска. Простым способом выполнить это - является выдача запроса url:<строка url, возвращенная из примера>.

В начало

Экстернализованные сообщения в специализированных анализирующих компонентах

При написании специализированного анализирующего компонента для OmniFind можно принять решение, будут экстернализоваться сообщения об исключительных ситуациях и регистрируемых событиях или нет. В OmniFind возможны и прекрасно работают оба варианта.

Если сообщения экстернализуются, в исходном коде на них дается только ссылка по ключу и пакету ресурсов, а сами сообщения размещаются в файле ресурсов вне кода. В некоторых случаях, при использовании экстернализованных сообщений об исключительных ситуациях, эти сообщения могут разрешиться из файла пакета ресурсов не так, как ожидается. Причиной такого поведения является стратегия загрузки классов, применяемая в OmniFind для процесса огражденного блока, который динамически загружает специализированные анализирующие компоненты. Для решения этой проблемы следуйте приведенным ниже рекомендациям, и ваш компонент будет корректно работать как внутри, так и вне OmniFind.

Примечание. При использовании экстернализованных сообщений только о регистрируемых событиях без сообщений об исключительных ситуациях нет необходимости следовать приведенным ниже рекомендациям. В этом случае интегрированная среда UIMA способна корректно разрешить экстернализованные сообщения без каких-либо проблем.

Как использовать экстернализованные сообщения об исключительных ситуациях

Ошибочное разрешение сообщения возникает тогда, когда в исходном коде анализирующего компонента для генерирования исключительной ситуации с текстом экстернализованного сообщения используется подход, приведенный в листинге 3. В примере генерируется исключительная ситуация в методе process() аннотатора с использованием стандартного типа исключительной ситуации, определенного интегрированной средой UIMA.

				
public void process(TCAS aTCAS, ResultSpecification aResultSpec)
  throws AnnotatorProcessException {

  String text = aTCAS.getDocumentText();

  //проверить, равен ли текст документа значению null
  if(text == null) {
    //если да, сгенерировать исключительную ситуацию
    //AnnotatorProcessException(ResourceBundle, MessageKey, MessageArguments)
    throw new AnnotatorProcessException("com.ibm.uima.annotator.ExceptionMessages",
      "SAMPLE_EXCEPTION_MESSAGE_KEY", null);
  }
}
	

Чтобы решить эту проблему, просто определите свой собственный класс исключительной ситуации, расширяющий класс UIMA, генерируемый в вашем методе. Для примера из листинга 3 можно создать класс SampleAnnotatorProcessException, расширяющий AnnotatorProcessException, который определяется интегрированной средой UIMA.

				
public class SampleAnnotatorProcessException extends AnnotatorProcessException {
   
   public SampleAnnotatorProcessException(String aResourceBundleName,
     String aMessageKey, Object[] aArguments) {
     super(aResourceBundleName, aMessageKey, aArguments);   
   }
}
	

При использовании в примере класса SampleAnnotatorProcessException вместо AnnotatorProcessException все работает хорошо, и все тексты экстернализованных сообщений об исключительных ситуациях разрешаются корректно.

				
public void process(TCAS aTCAS, ResultSpecification aResultSpec)
  throws AnnotatorProcessException {	
  String text = null;
     
  //выполнить какую-либо обработку тестовой строки
  processText(text);
     
  //после обработки текста проверить, не равен ли text значению null  
  if(text == null) {
    //если текст равен null, сгенерировать исключительную ситуацию 
    //SampleAnnotatorProcessException(ResourceBundle, MessageKey, MessageArguments)
    throw new 
      SampleAnnotatorProcessException("com.ibm.uima.annotator.ExceptionMessages",
      "SAMPLE_EXCEPTION_MESSAGE_KEY", null);
  }
}	
	

В начало

Изменение значений таймаута PEAR

Специализированные аннотаторы в OmniFind выполняются в отдельном процессе, называемом "огражденный блок аннотаторов" (annotator fenced box). В данном сценарии используется таймаут, при помощи которого механизм анализа текста OmniFind может обнаружить, работает ли специализированный аннотатор должным образом или следует аннулировать документ, если аннотатор не реагирует в заданном интервале времени. В некоторых ситуациях может быть нужно изменить стандартные настройки конфигурации таймаута. Например, если аннотатор выполняет очень сложный анализ текста, значения таймаута в 30 секунд по умолчанию может оказаться недостаточно. Для изменения этого значения можно использовать фрагмент кода, приведенный в листинге 6 и демонстрирующий настройки специализированного аннотатора в файле EsCpeDescriptor.xml. Этот файл расположен в каталоге <ES_NODE_ROOT>/master_config/<COLID>.parserdriver/specifiers. Найдите CAS-процессор с параметром развертывания deployment="remote" и с именем вашего специализированного аннотатора.

				
<casProcessor deployment="remote" name="<MyCustomAnnotator>">
  <descriptor>
    <include href="/home/esadmin/config/col1.parserdriver/specifiers/
      EsSocketService.xml"/>
    </descriptor>
    <filter/>
    <errorHandling>
      <errorRateThreshold action="continue" value="0/100"/>
      <maxConsecutiveRestarts action="continue" value="3"/>
      <timeout max="30000"/>
    </errorHandling>
    <checkpoint batch="1"/>
    <deploymentParameters>
      <parameter name="transport" type="string"
        value="com.ibm.es.control.casprocessor.server.CasProcessorSocketTransport"/>
    </deploymentParameters>
</casProcessor>

Значение таймаута <timeout max="30000"/> определяется в миллисекундах в разделе обработки ошибок процессора casProcessor. Если обработка занимает время, большее указанного значения, увеличьте таймаут, чтобы активизация события по таймауту происходила позже. После увеличения значения таймаута для специализированного аннотатора необходимо также увеличить значение таймаута для исходящей (output) очереди CPM. Требуемая настройка находится в конце файла EsCpeDescriptor.xml.

				
<cpeConfig>
  <numToProcess>-1</numToProcess>
  <deployAs>single-threaded</deployAs>
  <checkpoint batch="1000" file="" time="100s"/>    
  <outputQueue dequeueTimeout="100000" 
   queueClass="com.ibm.uima.reference_impl.collection.cpm.engine.SequencedQueue"/>
  <timerImpl/>
</cpeConfig>

Увеличьте значение таймаута dequeueTimeout="100000" на то же значение, которое используется для специализированного аннотатора.

В начало

Изменение размера кучи для специализированных аннотаторов

Специализированные аннотаторы в OmniFind выполняются в отдельном процессе, называемом огражденным блоком аннотаторов или CAS-процессором. В некоторых ситуациях может возникнуть потребность увеличить размер кучи для этого процесса (когда аннотатору требуется много памяти или когда коллекция, содержащая специализированный аннотатор, работает в многопоточном режиме). В OmniFind 8.4 размер памяти для огражденного блока по умолчанию зависит от установленной модели памяти OmniFind. Значения размера памяти приведены в таблице 1.

Чтобы изменить размер кучи для огражденного блока, необходимо изменить следующий конфигурационный файл:

<ES_NODE_ROOT>/master_config/<COLID>_config.ini

В этом файле найдите выражение

session<N>.type=casprocessor

для получения номера сеанса <N> для CAS-процессора текущей коллекции. После определения номера сеанса измените размер кучи в следующем параметре:

session<N>.max_heap=<size in MB>

Для того чтобы изменения вступили в действие, OmniFind необходимо перезапустить. При увеличении размера кучи будьте осторожны. Иногда JVM не запускается корректно, если куча слишком велика. Дополнительные рекомендации приведены в руководстве по установке OmniFind. Дополнительные рекомендации приведены в руководстве по установке OmniFind. Дополнительная информация о перезапуске системы OmniFind приведена в документации по OmniFind "Администрирование корпоративного поиска" в разделе "Запуск и останов системы корпоративного поиска".

В начало

Просмотр log-сообщений специализированных аннотаторов в OmniFind

При выполнении специализированного аннотатора в OmniFind log-сообщения аннотатора записываются в журнал аудита (audit log) OmniFind. Файл журнала аудита, в котором находятся log-сообщения, называется <ES_NODE_ROOT>/logs/audit/<COLID>.casprocessor_audit_<current_date>.log. По умолчанию уровень детализации журнала аудита OmniFind для log-сообщений аудита установлен в значение Informational и не может быть изменен. Это означает, что по умолчанию все log-сообщения аудита регистрируются в log-файле.

Система регистрации событий OmniFind предоставляет три различных уровня детализации: Error, Warning и Informational. Архитектура регистрации событий UIMA имеет семь уровней детализации: Severe, Warning, Info, Config, Fine, Finer и Finest. По умолчанию только некоторые из log-уровней UIMA отображаются на систему регистрации событий OmniFind. Они приведены в таблице 2.

При отображении по умолчанию log-сообщения специализированного аннотатора с уровнями Info, Warning и Severe записываются в log-файл. Для изменения отображения по умолчанию можно отобразить на log-уровень Informational OmniFind дополнительные log-уровни UIMA ниже Info. Для этого необходимо выполнить следующие действия:

1. Найдите конфигурационный файл tokenizer.properties в каталоге <ES_NODE_ROOT>/master_config/parserservice/.
2. Внутри файла найдите конфигурационный параметр log-уровня, показанный ниже. Если такого параметра не существует, создайте его согласно указаниям шага 3.
   
   

   trevi.tokenizer.jedii.casprocessor.InformationalLevelMapping=Info

   
   
3. Чтобы увидеть в log-файле более подробные сообщения, чем сообщения UIMA Info, замените значение отображения log-уровней на желаемое значение UIMA. Например, чтобы увидеть все log-сообщения аннотатора UIMA в журнале аудита OmniFind, используйте следующую команду:
   
   

   trevi.tokenizer.jedii.casprocessor.InformationalLevelMapping=Finest

   
   

Примечание. Отображение log-уровней для сообщений Warning и Error изменить нельзя.

В начало

Специфические UIMA-дескрипторы для коллекции OmniFind

Каждая коллекция, созданная в OmniFind, имеет свой собственный набор UIMA-дескрипторов. Эти дескрипторы необходимы для запуска и выполнения компонентов анализа текста, использующихся в синтаксическом анализаторе OmniFind и компоненте системы времени исполнения. Набор дескрипторов расположен в специфичном для коллекции каталоге, называемом спецификатором (specifier) и размещенном в <EsNodeRoot>/master_config/<COLID>.parserdriver/ или <EsNodeRoot>/master_config/<COLID>.runtime.node<N>/. Первое месторасположение (.parserdriver) используется в компоненте синтаксического анализатора OmniFind для анализа документов; второе месторасположение (.runitme.node<N>) используется в системе времени исполнения OmniFind для анализа запросов.

При создании новой коллекции все необходимые дескрипторы копируются из каталога <EsInstallRoot>/default_config/parserdriver/specifiers в специфичные для коллекции каталоги specifier, где они обновляются текущими настройками, указываемыми во время создания коллекции. При изменении настроек коллекции из интерфейса администратора дескрипторы обновляются соответствующим образом.

Примечание. Если дескрипторы изменяются напрямую без использования интерфейса администратора, изменения могут быть утрачены или перезаписаны при их изменении в интерфейсе администратора. Поэтому, если необходимо вручную изменить дескрипторы, нужно либо отказаться от последующего использования графического интерфейса администратора для изменения настроек данной коллекции, либо иметь способ повторного применения ваших изменений после работы в интерфейсе администратора.

Для коллекции важны следующие спецификаторы:

В начало

Расширение системы типов OmniFind

IBM OmniFind Enterprise Edition имеет расширенную систему типов UIMA со специфическими типами и свойствами. Подробная информация о системе типов UIMA, являющейся основой системы OmniFind-типов, приведена в документации по OmniFind "Специализированный текстовый анализ". Основные типы и свойства расширенной системы OmniFind-типов приведены в таблице 4. Полный список типов приведен в файле определений системы OmniFind-типов of_typesystem.xml, расположенном в каталоге <EsInstallRoot>/default_config/parserdriver/specifiers.

Ресурсы

Научиться

• Оригинал статьи "Hints and tips for using the Unstructured Information Management Architecture SDK with OmniFind" (EN).
  
  
• Домашняя страница продукта OmniFind. Дополнительная информация об OmniFind Enterprise Edition.(EN)
  
  
• Страница developerWorks с ресурсами по IBM OmniFind. Статьи и учебные руководства, ссылки на другие ресурсы для повышения квалификации по OmniFind.(EN)
  
  
• "Специализированный текстовый анализ" (документация по OmniFind). Интегрируйте специализированную логику текстового анализа с системой корпоративного поиска, используя консоль администратора (EN).
  
  
• "Администрирование системы корпоративного поиска" (документация по OmniFind). Описание действий по администрированию системы корпоративного поиска (EN).
  
  
• "Установка системы корпоративного поиска" (документация по OmniFind). Инструкции и информация по установке OmniFind Enterprise Edition (EN).
  
  
• "Search and index API" (документация по OmniFind). Программный интерфейс, позволяющий выполнять поиск, просмотр и администрирование коллекций и таксономий (EN).
  
  
• Справочное руководство пользователя UIMA SDK, версия 1.4.4. Дополнительная информация по UIMA SDK (EN).
  
  
• Следите за текущими техническими мероприятиями и web-трансляциями на developerWorks.(EN)
  
  
• Магазин технической литературы. Книги по этой и другим техническим темам.
  
  

Получить продукты и технологии

• Загрузите пакеты исправления ошибок для OmniFind.(EN)
  
  
• Разработайте ваш следующий проект, используя пробное программное обеспечение IBM, доступное для загрузки непосредственно с developerWorks.(EN)
  
  

Обсудить

• Принимайте участие в форумах на developerWorks Россия.
  
  
• Принимайте участие в блогах developerWorks и подключайтесь к сообществу developerWorks.(EN)
  
  

Об авторе

С момента прихода в IBM в 2003 году Майкл Бесслер (Michael Baessler) работает в подразделении Enterprise Search Development, расположенном в г. Беблинген в Германии. Майкл занимается интеграцией архитектуры Unstructured Information Management Architecture (UIMA) с OmniFind. Архитектура UIMA используется в OmniFind для базового лингвистического анализа и позволяет пользователям подключать специализированные анализирующие компоненты. Кроме OmniFind, Майкл работает также над новыми функциональными возможностями и требованиями самой интегрированной среды UIMA.

Оценить эту статью

Комментарии

В начало

Содержание

• Содержание
• Использование специализированных CAS-потребителей в OmniFind
• Экстернализованные сообщения в специализированных анализирующих компонентах
• Изменение значений таймаута PEAR
• Изменение размера кучи для специализированных аннотаторов
• Просмотр log-сообщений специализированных аннотаторов в OmniFind
• Специфические UIMA-дескрипторы для коллекции OmniFind
• Расширение системы типов OmniFind
• Ресурсы
• Об авторе
• Комментарии