Compartir a través de


Descripción de los controladores de protocolo

Algunas aplicaciones almacenan sus elementos en bases de datos o en tipos de archivo personalizados. Aunque Windows Search puede indexar el nombre y las propiedades del archivo, Windows no tiene conocimiento del contenido del archivo. Como resultado, estos elementos no se pueden indexar ni exponer en el shell de Windows. Al crear un controlador de protocolo, puede hacer que estos elementos estén disponibles para la indexación. También puede indexar un formato de archivo compuesto, como un archivo .zip.

Este tema se organiza de la siguiente manera:

Indexación de almacenes de datos con controladores de protocolo

Cuando los usuarios necesitan buscar en bases de datos heredadas, almacenes de correo electrónico u otras estructuras de datos que no son compatibles con Windows Search, primero debe determinar si ya existe un controlador de protocolo para ese almacén de datos, quizás para su uso con otra aplicación como SharePoint Server. Si es así, puede instalar ese controlador de protocolo en el sistema. Los controladores de protocolos de Windows Search usan especificaciones de diseño similares a SharePoint Server y a menudo se pueden usar indistintamente.

Para más información sobre la implementación de Search Server 2008 con Office SharePoint Server 2007, consulte Búsqueda federada [Search Server 2008].

Almacenes de datos de shell

Antes de que un desarrollador de terceros de nuevos formatos de archivo y almacenes de datos pueda obtener esos formatos y almacenes para que aparezcan en los resultados de la consulta en el Explorador de Windows, el desarrollador debe implementar un origen de datos de shell. Un origen de datos de shell es un componente que se usa para ampliar el espacio de nombres de shell y exponer elementos en un almacén de datos. Un almacén de datos es un repositorio de datos. Un almacén de datos se puede exponer al modelo de programación de shell como un contenedor que usa un origen de datos de shell. El sistema de Windows Search puede indexar los elementos de un almacén de datos mediante un controlador de protocolo. El controlador de protocolo implementa el protocolo para acceder a un origen de contenido en su formato nativo. Las interfaces ISearchProtocol e ISearchProtocol2 se usan para implementar un controlador de protocolo personalizado para expandir los orígenes de datos que se pueden indexar.

Si quiere que los resultados de la consulta aparezcan en el Explorador de Windows, debe implementar un origen de datos de shell para poder crear un controlador de protocolo y ampliar el índice. Sin embargo, si todas las consultas van a ser mediante programación (por ejemplo, a través de OLE DB) e interpretadas por el código de la aplicación en lugar del shell, un espacio de nombres de shell, aunque todavía se prefiere, no es estrictamente necesario.

Nota:

A veces, un origen de datos de shell se conoce como una extensión de espacio de nombres de shell. A veces, un controlador se conoce como una extensión de shell o un controlador de extensión de shell.

 

Si quiere que los usuarios vean los resultados de búsqueda desde el Explorador de Windows, debe crear un controlador de protocolo y uno o varios de los siguientes complementos:

  • Controlador de menú contextual
  • Controlador de iconos
  • Otro tipo de controlador de archivos

Para obtener una lista de los controladores identificados por el escenario de desarrollador que está intentando lograr, consulte "Introducción a los controladores" en Windows Search como plataforma de desarrollo. Para más información sobre cómo crear controladores, consulte Registro de controladores de extensiones de shell, Menú contextual y Controladores de tipos de archivo.

Controladores de protocolo

Si el almacén de datos también es un contenedor (como una carpeta del sistema de archivos), debe implementar un filtro para enumerar las direcciones URL del contenedor. Si el almacén de datos contiene tipos de datos o archivos distintos de uno de los 200 tipos de archivo admitidos por Windows Search, debe implementar un filtro para acceder e indexar el contenido de los elementos del almacén. Windows Search usa el controlador de protocolo y la tecnología IFilter similar a la usada por SharePoint Server. Si ya tiene filtros para un almacén específico y un tipo de archivo instalados en el sistema que se está indexando, Windows Search puede usar las interfaces existentes para indexar estos datos.

Para más información general sobre el proceso de indexación, consulte Proceso de indexación en Windows Search. Para obtener información conceptual sobre los controladores de filtro, consulte Desarrollo de controladores de filtro para Windows Search.

Filtros y controladores de protocolo

Los controladores de protocolo proporcionan al indexador de Windows Search acceso a los almacenes de datos, lo que permite al indexador rastrear los nodos de un almacén de datos y extraer información relevante para el índice. Windows Search, por ejemplo, se incluye con controladores de protocolo para almacenes del sistema de archivos y para algunas versiones de ambos almacenes de datos de Microsoft Outlook. Al indexar el correo electrónico de Outlook, el controlador de protocolo rastrea todos los mensajes de un conjunto de carpetas de Outlook y extrae información de cada mensaje y datos adjuntos. Esta información se pasa al indexador para su inclusión en el catálogo de Windows Search.

Para obtener información general sobre el Administrador de catálogos y el Administrador de ámbitos de rastreo (CSM), consulte Uso del Administrador de catálogos y Uso del Administrador de ámbitos de rastreo.

Indexación de un formato de archivo compuesto

Se puede indexar un formato de archivo compuesto para que los elementos individuales del archivo se puedan devolver como resultados individuales. Un formato de archivo compuesto, como un archivo comprimido con una extensión de nombre de archivo .zip, es básicamente un almacén de datos y se puede tratar como tal con fines de indexación. En el ejemplo siguiente se muestra un archivo .zip en el espacio de nombres del sistema de archivos (FILE://c:/test/test.zip) en el que hay subcarpetas y elementos individuales.

Test.zip 

    |-folder1 

    |    |-folder2 

    |           |- FileX.txt 

    |- FileY.doc

El controlador de protocolo FILE detecta cuándo cambia FILE://c:/test/test.zip al supervisar los registros de cambios del sistema de archivos e invocará un IFilter registrado para archivos .zip en ese archivo cuando cambie el archivo, pero no tiene conocimiento de la estructura interna del propio archivo .zip.

Debe informar al indexador de que el formato de archivo compuesto es un almacén de datos. Es necesario hacerlo para que los elementos individuales se indexen y recuperen como entidades únicas. Después de implementar un origen de datos de shell y de realizar los pasos siguientes, tendrá un controlador de protocolo que puede procesar y exponer los datos desde un formato de archivo compuesto (un archivo .zip) como elementos individuales.

Para informar al indexador de que un archivo compuesto es un almacén de datos:

  1. Cree un controlador de protocolo (mediante ISearchProtocol o ISearchProtocol2) para archivos .zip que tenga la capacidad de enlazar con el archivo de origen. Para más información, consulte Instalación y registro de controladores de protocolo.

    Por ejemplo, podría usar una ruta de acceso de escape al archivo .zip como nombre de carpeta raíz y, a continuación, usar una sintaxis de jerarquía como cualquier otro formato de archivo.

    .zip:///escapedPathTo.zipFile/.zipfolder/.../.zipfile
    

    Con los datos de ejemplo anteriores para c:\test\test.zip, las direcciones URL únicas serían las siguientes. Con estas direcciones URL, el controlador de protocolo tiene la información necesaria para enlazar con el archivo .zip y enumerar las direcciones URL secundarias, incluidos los archivos internos, para que se puedan enlazar e indexar mediante los filtros .doc y .txt.

    
    
    .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ 
    
    .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/FileY.Doc 
    
    .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1 
    
    .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1/folder2 
    
    .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/folder1/folder2/FileX.txt
    
  2. Asegúrese de que el controlador de protocolo cumpla las dos condiciones siguientes:

    • Las direcciones URL raíz de un archivo .zip deben emitir PKEY_Search_IsClosedDirectory (System.Search.IsClosedDirectory) en las direcciones URL que son las direcciones URL del archivo .zip raíz. Por ejemplo, .zip:///FILE:%2f%2f%2fc:%2ftest%2ftest.zip/ debe emitir IsClosedDirectory = TRUE. Esto indica al indexador que si la fecha de esta dirección URL no ha cambiado, no es necesario procesar ninguna de las direcciones URL secundarias.
    • Cada dirección URL secundaria de esa dirección URL debe emitir PKEY_Search_IsFullyContained (System.Search.IsFullyContained) en las direcciones URL secundarias de la dirección URL raíz .zip. Normalmente, al final de un rastreo incremental, el indexador trata todas las direcciones URL no vistas como elementos que se deben eliminar. Pero el archivo .zip raíz no debe procesar las direcciones URL raíz porque no ha cambiado nada. Si emite esta propiedad como TRUE, se indica al indexador que, si esta dirección URL no se ha procesado al final de un rastreo incremental, no se debe eliminar. Solo se eliminará si el elemento raíz ha cambiado y no se visita.

Windows Search requiere una página de inicio para un protocolo con el fin de saber qué direcciones URL rastrear incrementalmente y qué direcciones URL deben omitirse cuando se encuentran. Pero no podemos empezar con una dirección URL para cada archivo .zip, ya que no sabemos dónde está cada archivo .zip. Por lo tanto, la dirección URL de la página de inicio del controlador de protocolo .zip debe ser capaz de enumerar todo en la raíz de las rutas de acceso de escape de todos los archivos .zip. Esos archivos .zip no son necesariamente en el espacio de nombres FILE: y podrían ser una dirección URL de tipo MAPI que apunte a un archivo .zip como datos adjuntos, por ejemplo.

Para registrar una raíz como página de inicio:

  1. Registre una raíz como .zip:/// como una página de inicio para que todos los archivos .zip comiencen allí, en efecto. Al procesar la dirección URL del .zip raíz, el controlador de protocolo debe generar la lista de direcciones URL secundarias que se van a emitir consultando Windows Search para todas las direcciones URL con System.FileExtension = ".zip".

  2. Escape esas direcciones URL para quitar las barras diagonales y devolverlas como direcciones URL secundarias. Una consulta de ejemplo para recuperar los tipos que desee podría tener el siguiente aspecto.

    SELECT system.itemurl, System.DateModified FROM SystemIndex 
    WHERE System.FileExtension='.zip' OR System.MimeType='mimetypefor.zip'
    
  3. Cuando Windows Search realiza periódicamente un rastreo incremental en la dirección URL raíz de .zip:///, debe reflejar la lista de direcciones URL que Windows Search ya mantiene y que son direcciones URL .zip. Si se detecta una eliminación en el almacén nativo donde se almacena el archivo .zip, no aparece en la enumeración y se quita esa rama del árbol en el archivo .zip.

  4. Para enlazar a los datos .zip para otro controlador de protocolo, lo ideal es pasar por IShellFolder para esa dirección URL para enlazar con el almacenamiento del objeto y no suponer que siempre es un archivo. Si lo hace, le ofrece la flexibilidad de trabajar con datos adjuntos en almacenes de correo, por ejemplo.

  5. Al emitir direcciones URL secundarias para cada archivo .zip, debe usar PKEY_Search_UrlToIndexWithModificationTime (System.Search.UrlToIndexWithModificationTime) para pasar PKEY_DateModified (System.DateModified) del archivo .zip real para que el indexador rastree el archivo .zip solo si ha cambiado.

Para que las direcciones URL de .zip se indexen inmediatamente después de que se creen o modifiquen, y no tenga que esperar a que un rastreo incremental detecte su nuevo estado, puede supervisar el sistema de archivos usted mismo para ver los cambios en el archivo .zip. Sin embargo, este enfoque no funcionaría para otros almacenes de datos, como MAPI.

Para que las direcciones URL de .zip se indexen cuando se crean o modifican:

  1. Cree un filtro (e implementación de la interfaz IFilter) para el tipo de archivo .zip. Para más información, consulte Desarrollo de controladores de propiedades para Windows Search.
  2. Cada vez que se llama a la implementación de IFilter, se debe a que esa dirección URL se ha detectado o cambiado. A continuación, genere un evento para la dirección URL de .zip adecuada para la dirección URL de origen, a través de la interfaz IGatherNotifyInline. Si lo hace, puede indicar inmediatamente al indexador que hay nuevos datos que se van a indexar sin tener que esperar al rastreo incremental.

Desarrollo de controladores de protocolo

Instalación y registro de los controladores de protocolo

Notificación del índice de cambios

Adición de iconos y menús contextuales

Ejemplo de código: Extensiones de shell para controladores de protocolo

Instalación y registro de los controladores de protocolo

Creación de un conector de Search para un controlador de protocolo

Depuración de controladores de protocolo