SharePoint Online: Como añadir sugerencias de consulta al motor de búsquedas

En SharePoint Online tenemos la posibilidad de añadir sugerencias de consulta al motor de búsquedas al igual que podemos añadirlas en la Administración Central de SharePoint 2013:
  • Utilizando el bloc de notas, creamos un documento de texto en el que vamos a incluir las sugerencias de consultas a añadir.
  • Añadimos el siguiente contenido al archivo de texto y lo guardamos con el nombre QuerySuggestions_Informe. De esta forma, añadiremos sugerencias de consulta para la palabra Informe.
  • Es importante que al guardar el archivo de texto especifiquemos como tipo de codificación UTF-8.
image image
  • Navegamos a la Administración de SharePoint Online para poder importar las sugerencias de consultas en la configuración de las búsquedas. Hacemos clic en “Sugerencias de consulta”.
  • En la página que se abre, seleccionamos como idioma Español (España) y hacemos clic en el enlace “Importar desde archivo de texto” y cargamos el archivo de sugerencia de consultas creado.
image image
  • En la página que se abre, seleccionamos el archivo QuerySuggestions_Informe.txt y hacemos clic en “Aceptar”.
  • Finalmente, realizamos una búsqueda y comprobamos que las sugerencias están operativas.
  • De nuevo en la página de configuración de sugerencia de consultas hacemos clic en “Guardar configuración” y tendremos disponibles las sugerencias de consultas una vez que se ejecute el correspondiente Timer Job que en instalaciones On-Premise tiene una frecuencia de ejecución diaria.
image image




Servicio de traducción automática en SharePoint 2013

Una nueva aplicación de servicio que trae consigo SharePoint 2013 es la de traducción automática. En este post vamos a ver un ejemplo de uso, partimos de la base de que ya la tenemos configurada y lista para usar.
¿Cómo funciona? 
Microsoft nos proporciona un servicio de traducción automática alojado en la nube, este servicio es el que realmente realizará la traducción. Por lo tanto la aplicación de servicio simplemente lo que hace es reenviar esta petición de traducción al servicio de traducciones de Microsoft.
NOTA: El servidor donde se ejecutan las traducciones automáticas debe ser capaz de conectarse a internet.
Tendremos 2 tipos de traducción automática:

  • Síncrona: Se procesan en cuanto se envían.
  • Asíncrona: El proceso es realizado por un Timer Job llamado “SharePoint Translation Services” que está puesto a 15 minutos por defecto.


¿Qué vamos a poder traducir?
Con esta aplicación de servicios vamos a ser capaces de traducir archivos y sitios.
¿Cómo lo vamos a utilizar?
Para hacer uso del servicio de traducción automática de SharePoint 2013 podremos utilizar Modelo de Objetos de Servidor, Modelo de Objetos de Cliente y API REST.
¿Un ejemplo?
Para comprobar que la traducción funciona, voy a poner todo el contenido de este mismo post en un archivo de Microsoft Word y haremos que el servicio traduzca este contenido al inglés.
Por lo tanto para realizar esta comprobación, crearemos una aplicación de consola y realizaremos la traducción de forma síncrona.
El código que aparece a continuación coge el documento llamado “Traducción.docx”, lo traduce y lo pone en otra biblioteca que he utilizado para guardar las traducciones realizadas. El archivo traducido se llamará  “TraduccionIngles.docx”
SPServiceContext spContext = SPServiceContext.GetContext(spSite);
SyncTranslator timerJobTranslate = new SyncTranslator(spContext, CultureInfo.GetCultureInfo(1033));
timerJobTranslate.OutputSaveBehavior = SaveBehavior.AlwaysOverwrite;
timerJobTranslate.Translate(“http://xxxxxxx/Documents/Traduccion.docx” , “http://xxxxxxx/DocumentsTranslate/TraduccionIngles.docx”);

Como podéis ver, la forma síncrona usa la clase SyncTranslator, pasándole el contexto y la cultura nos bastaría para realizar la traducción instantánea, en cambio la forma asíncrona utilizaría la clase TranslationJob.
Con este simple bloque de código ya podríamos realizar una traducción del documento de español a inglés.
Por último solo nos queda ver el resultado de la traducción.
Inicialmente el documento tenía este aspecto
traduccionEspañol
y el resultado final después de la traducción es este
traduccionIngles
fuente: solidq




Sharepoint 2010 – Consideraciones para la configuración del servicio de búsqueda

El proceso de configuración del servicio de búsqueda en Sharepoint involucra los siguientes pasos generales:

  1. Crear una cuenta de usuario, dominio o local, que tenga privilegios de acceso sobre todo el contenido de Sharepoint que se va a incluir en el proceso de indexación y búsqueda.
  2. Con la cuenta de usuario creada, registrarla como cuenta administrada de Sharepoint.
  3. Crear una aplicación de servicio de búsqueda, Search Service Application, en donde se crean las bases de datos respectivas y adicionalmente se registra la cuenta de servicio respectiva que debe ser la misma de los puntos anteriores.
  4. Configurar las fuentes de contenido, content sources, de acuerdo a la configuración de los sitios de Sharepoint.
  5. Ejecutar una tarea de “full crawling” sobre el contenido y verificar que la base de datos se ha alimentado con los registros encontrados.


Ahora bien, cuando el sitio web es configurado con soporte para autenticación Windows (NTLM) y FBA, y adicional a esto fue configurado con un nombre diferente al configurado por defecto, por ejemplo intranet.midominio.com, el proceso varía. Me encontré con las siguientes novedades:
– Por defecto cuando se configura la aplicación del servicio de búsqueda se agrega como fuente de contenido al URL que se encuenta configurada en la zona AAM como por defecto, en nuestro caso sería intranet.midominio.com.
– Al intentar ejecutar la tarea de “full crawling” sobre esta configuración se puede presentar el siguiente error:

The SharePoint server was moved to a different location. ( Error from SharePointsite: HttpStatusCode Found The request failed with the error message:  <html><head><title>Object moved</title></head><body> <h2>Object moved to<a href=“%2f_LAYOUTS%2fSharePoint.POC%2fLogin.aspx%3fReturnUrl%3d%252f_vti_bin%252fsitedata.asmx”>here</a>.</h2> </body></html> –. )

De acuerdo a algunos blogs revisados, para solucionar este problema se debería crear una regla de “crawl” que especifique la página personalizada de inicio de sesión (FBA) y adicionalmente las credenciales de acceso. En mi caso este proceso no funcionó.

– Como alternativa adicional, en otros sitios, proponía extender el sitio con autenticación FBA + NTLM a un sitio que solo soporte NTLM, en mi caso por ejemplo intranet.midominio.com:555 sería el sitio extendido con soporte únicamente para autenticación -NTLM.

– En la configuración de fuentes de contenido especificar este nuevo sitio, intranet.midominio.com:555.
Al configurar estas opciones en efecto la tarea de “crawling” finalizó exitosamente y se indexaron todos los items del sitio, sin embargo, al probar el cuadro de búsqueda que se encuentra en la barra de navegación (superior derecha) y colocar una palabra para buscarla, la página de resultados no mostró resultado alguno.
Para identificar el error procedí a habilitar los logs del servicio de búsqueda en nivel “verbose” y adicionalmente descargar la herramienta ULS Viewer (http://archive.msdn.microsoft.com/ULSViewer).
Al revisar los archivos de log, posterior a hacer algunas pruebas de búsqueda para identificar el error, encontré el siguiente mensaje:


Esto implica que aparentemente no existen “Query Processors” habilitados en la granja de Sharepoint para atender las búsquedas enviadas. En específico un Query Processor dentro de la granja de Sharepoint se habilita iniciando el servicio de “Search Query and Site Settings Service” en la sección “Services on Server”.

Adicionalmente se debe habiliar la característica de colección de sitios “Elementos web de Search Server” en: Acciones del Sitio > Configuración del sitio > Administración de la colección de sitios > Características de la colección de sitios.
Posterior a configurar estas opciones no hubo cambios, el cuadro de búsqueda no presentaba ningún resultado.
Finalmente, en la página de administración de la aplicación del servicio de búsqueda, en la barra lateral izquierda, se encuentra la opción “Server name mappings” (http://altfo.wordpress.com/2010/07/08/this-site-this-list-sharepoint-search-not-working-or-returns-nothing/). En esta opción agregué un item con las siguientes opciones:
– Address for indexing: http://intranet.midominio.com:555
– Address for display in search results: http://intranet.midominio.com
Ejecuté una nueva tarea de “full crwaling” y finalmente funcionó el cuadro de búsqueda y resultados.
Fuente: msmvps.com


www.asociacionaepi.es



Habilitar la depuración remota de eventos en las app de SharePoint

Cuando estamos desarrollando apps para SharePoint, es posible depurar las app de tipo autohosted o provider hosted aunque no se encuentren en el servidor de SharePoint. Al utilizar un Service bus de Windows Azure, Visual Studio se comunica con el mismo servicio de Windows Communication Foundation (WCF) que los manejadores de evento remotos (remote event receivers y app event receivers) usan. De esta forma, se evitan problemas de red entre la app guardada en la nube y la app local y es posible depurar los eventos remotos.
Para crear el service bus, necesitamos una cuenta de Windows Azure. Una vez hayamos entrado en la cuenta, en “Service bus”, le daremos a “crear”: 


Habrá que escribir un nombre para el namespace del bus de datos y aceptar: 

Hay que esperar un rato, mientras el Service bus se está activando: 

Una vez que esté creada, hay que pinchar en ella y pinchar en “Información de conexión”: 


Copiamos la “Cadena de conexión”: 

En Visual Studio, hacemos clic derecho en el proyecto de la app y vamos a propiedades. En la pestaña de SharePoint, en la parte inferior, hay que marcar la casilla “Enable remote event debugging” y pegar la cadena de conexión: 

Una vez hayamos hecho esto, podremos depurar eventos remotos en nuestra app. 

www.asociacionaepi.es