Categoría: Search

Una de las grandes novedades que trajo SharePoint 2013 fue la renovación de su Arquitectura de búsqueda y consigo una sería de funcionalidades como los Content by Search WebParts, Cross-Site Publishing y Continuous Crawl.

Como sabemos el uso de escenarios de publicación en Portales web de SharePoint basados en el motor de búsqueda tiene muchas ventajas, sin embargo también tiene sus retos. Uno de los principales retos está relacionado al tiempo en que se presentan los contenidos en el Portal. Debido a que los contenidos se presentan en base al motor de búsqueda, el tiempo en que este configurado el rastreo de contenidos es uno de los criterios que determinará el tiempo en que se presentarán los contenidos.

Para este escenario SharePoint 2013 proporciona un mecanismo de rastreo mucho mas eficiente y rápido que rastrea los contenidos en menos tiempo que el tradicional rastreo incremental. Este es el rastreo continuo!

El rastreo continuo por defecto se realiza cada 15 minutos, este se encarga de verificar si existen nuevos contenidos para añadirlos al índice, a diferencia de un rastreo incremental, el rastreo continuo no tiene que esperar a que un rastreo anterior finalice para iniciar uno nuevo, esto permite siempre tener los contenidos mas recientes actualizados en el Portal.

Aún así estos 15 minutos pueden resultar mucho tiempo para los requerimientos de algunas empresas. En este caso es posible reducir el tiempo del rastreo continuo ejecutando los siguientes comandos de PowerShell:

1. Primer obtenemos la propiedad «ContinuousCrawlInterval» para ver el valor actual. Por defecto este es 15 minutos.

2. Ahora establecemos el valor de la propiedad a 5 minutos.

3. Para que se apliquen los cambios debemos ejecutar el método Update.

4. Finalmente verificamos que efectivamente se haya realizado el cambio.

Lo que notaremos ahora es que los resultados de búsqueda se presentan con muchas mas rapidez. Si ejecutamos una búsqueda desde los sitios de búsqueda podremos apreciar eso, sin embargo también nos daremos cuenta de que los Content by Search WebParts no refrescan los datos inmediatamente. Estos se demoran unos 15 minutos aproximadamente, esto debido a que los WebParts también manejan una configuración de Cache de 15 minutos.

Esto también se puede cambiar mediante la ejecución de unos comandos en PowerShell:

Como podemos apreciar, la propiedad «SearchResultsCacheTTL» es la que nos permite expresar en segundos el tiempo en que se manejará en cache el contenido y no se verá refrescado. En este caso lo configuré para 5 minutos.

Y listo! a través de la ejecución de estos comandos podemos presentar la información de manera mas rápida. Sin embargo, es importante tomar en cuenta que tanto el tiempo destinado para el continuous crawl como el tiempo empleado para el cache al verse reduciendo, consumen mas recursos de los servidores tanto Web Front End (Por el manejo del cache) como los servidores de la topología de búsqueda.

En un artículo anterior escribí acerca de la capacidad de Item Scheduling y sus beneficios en cuanto a la gestión de la publicación en Portal web en Internet (http://geeks.ms/blogs/marchena/archive/2016/01/08/empleando-item-scheduling-en-bibliotecas-documentales-de-sharepoint-2013.aspx).

Como sabemos SharePoint 2013 trajo múltiples funcionalidades para optimizar la implementación de Portales web en Internet, entre estas podemos mencionar a los Portales basados en Cross-site Publishing, el uso de Content by Search WebParts y continuous crawl.

Entonces, será posible aprovechar la capacidad de Item Scheduling (funcionalidad disponible desde SharePoint 2007) en Portales modernos basados en Cross-site publishing y content by search webparts?

Esto claro que es posible. Como sabemos el Item Scheduling permite manejar los estados de publicación de un documento, entonces un documento al estar en estado Borrador, En Espera o Programado no podrá ser visto por un usuario anónimo o un usuario lector. Sin embargo, un documento en estado Aprobado si puede ser visto por un usuario anónimo o lector.

Recordemos también que el motor de búsqueda únicamente rastrea aquellos documentos que se encuentren con estado Aprobado, en ese sentido es totalmente posible complementar la funcionalidad de Item Scheduling con los Content by Search WebParts.

A continuación mostrará como configurar este escenario. El resultado final debería ser algo como esto:

1. Primero debemos seguir los pasos descritos en el siguiente artículo (http://geeks.ms/blogs/marchena/archive/2016/01/08/empleando-item-scheduling-en-bibliotecas-documentales-de-sharepoint-2013.aspx). Estos son los pasos fundamentales.

2. Ahora, después de haber ejecutado un Full Crawl iremos al esquema de búsqueda desde el Search Service Application y buscaremos las propiedades rastreadas ows_q_DATE_PublishingStartDate y ows_q_DATE_PublishingExpirationDate.

Nota: Puede que estas propiedades rastreadas no se muestren. Si no se muestran en el siguiente punto se explicará como resolver este inconveniente.

3. En el caso de que no se muestren las propiedades rastreadas esto es debido a que al menos un documento debe tener los datos llenos y este documento debe estar marcado como Aprobado.

4. Ejecutamos un Full Crawl nuevamente.

5. Ahora si podremos apreciar que se crearon las propiedades rastreadas correctamente. 

 

6. Debido a que la Fecha de inicio programada y la Fecha de finalización programada las queremos utilizar para refinar los resultados y ordenarlos. Vamos a crear a continuación unas propiedades administradas nuevas.

Primero vamos a crear la propiedad administrada SPSFechaInicioPublicación, este será de tipo Fecha y hora. Así mismo marcar los checks Permite búsquedas, Consultable, Se puede recuperar.

 

 7. En Restringible seleccionar Sí: activa. y en Se puede ordenar seleccionar Sí: activa. Así mismo marcar Caja fuerte.

8. Ahora debemos seleccionar la propiedad rastreada ows_q_DATE_PublishingStartDate que es la asociada al campo de Fecha de inicio programada.

9. Se puede apreciar que se agregó correctamente.

10. Hacemos el mismo procedimiento para la propiedad Administradad SPSFechaFinPublicacion. La configuración será la misma a excepción de la propiedad rastreada a la cual mapearemos. 

11. Mapearemos a la propiedad rastreada ows_q_DATE_PublishingExpirationDate, esta esta asociada al campo Fecha de finalización programada.

12. Podemos apreciar que se asoció correctamente.

13. Ejecutamos un Full Crawl para ver los cambios aplicados. 

14. Y finalmente podremos configurar nuestro refinamiento con las propiedades administradas antes creadas. No tenemos que hacer nada especial sobre nuestro content by search WebPart ya que por defecto solo muestra los contenidos aprobados.

Nota: Debido a que los resultados en el Content by Search WebPart se muestran en base a la frecuencia del rastreo y a la configuración de cache, el momento en que se presentarán los resultados o dejarán de presentarse tendrá una diferencia de aproximadamente unos 15 minutos. Esto se puede reducir, si queremos reducir esta diferencia, debemos seguir los pasos descritos en el siguiente artículo: http://geeks.ms/blogs/marchena/archive/2016/01/08/reduciendo-el-tiempo-de-presentaci-243-n-de-contenidos-en-un-content-by-search-webpart.aspx 

 

En una topología de búsqueda de SharePoint 2013 uno de los componentes críticos para la ejecución de búsquedas y/o para presentar información en los Content by Search WebParts y Search Results WebParts es el índice de búsqueda.

Desde la página de Administración del Search Service Application podemos constantemente monitorear la salud de nuestra topología de búsqueda. Podremos detectar un problema con el componente de índice si es que se presenta un ícono amarillo de warning como se puede apreciar en la siguiente imagen:

Cuando el índice de búsqueda presenta un ícono de warning esto puede estar relacionado a 2 temas:

a) El disco de índice esta lleno por lo que no es posible seguir almacenando información ahi. Esto genera que un Full crawl o incremental crawl se quede detenido por siempre hasta que el tema se resuelva.

b) Los archivos de índice de uno nodo particular están corruptos. Esto puede deberse a una manipulación indebida de estos archivos, algún problema con disco o algún virus.

Para resolver estos problemas seguir los pasos descritos a continuación:

1. En el Search Service Application dar clic en Restablecer índice. 

2. Clic en Restablecer ahora.

3. Se restablecer el índice (Se limpia por completo).

4. Podremos apreciar que la topología ya se muestra correctamente sin ningún warning. 

5. Finalmente debe ejecutar un Full crawl para poder llenar nuevamente nuestro índice.

IMPORTANTE:

Si el problema era asociado a espacio en disco, entonces previamente debemos hacer un dimensionamiento adecuado del índice y aprovisionar el espacio necesario.

Si el problema tiene que ver con corrupción de archivos es importante diagnosticar la causa raíz (Si fue por virus aplicar antivirus, Si fue problema de disco o manipulación manual tomar las acciones respectivas).