Search Driven Development (III): El WebPart de Refinamiento

Muy buenas a todos de nuevo,

Antes de nada, os deseo una Feliz Navidad a todos. Hoy quiero seguir profundizando un poco más en el concepto de Search Driven Development. Vamos a trabajar con el WebPart de refinamiento. Al igual que el Content Search WebPart, el de refinamiento es completamente configurable de una forma muy sencilla. Mucho más que lo era el WebPart de refinamiento en SharePoint 2010.

Además, y aunque no es objeto de este post, también se pueden crear plantillas para estos refinadores de búsqueda, tal y como hacíamos con los tipos de resultado.

Para explicar como trabajar con el WebPart de refinamiento he planteado un escenario en el que dispongo de un catálogo de formaciones y he creado al igual que hacía en los anteriores post, su respectiva página de catálogo y elementos de catálogo, configurando posteriormente el Content Search WebPart de cada uno.

Primeros Pasos con SharePoint OnLine: Search Driven Development

Search Driven Development en SharePoint (II): Catálogos y Elementos de Catálogo

El tipo de Contenido que he creado para el catálogo es el siguiente:

Una vez creado el catálogo y su funcionalidad, añadimos a la página del catálogo el WebPart de refinamiento, dándonos un aspecto como el siguiente.

El caso es que para nuestro catálogo, no es suficiente con los refinadores por defecto que nos carga el WebPart de refinamiento, queremos establecer nuestros propios refinadores, basados en el tipo de contenido que hemos definido. En nuestro caso queremos poder refinar nuestro catálogo por: Tipo de Formación, Autor, Temática y Valoración.

Definiendo las propiedades administradas para el refinamiento

Todas las opciones de refinamiento de nuestro WebPart se basan en propiedades administradas de nuestro esquema de búsqueda. Pero lo harán en unas propiedades especiales que en nuestro esquema aparecen con el nombre de: RefinableString, RefinableInt, RefinableDouble, RefinableDate, en función del tipo de dato que representa cada una, disponiendo de un número elevado de cada una de ellas para poder configurar correctamente nuestras propiedades administradas de refinamiento.

Lo que tendremos que hacer es, asociar las propiedades rastreadas que queramos usar en el refinamiento a las propiedades administradas correspondientes. Vamos a ver como hacer esto.

Para empezar vamos a Configuración del sitio->Esquema de Búsqueda de la administración de la colección de sitios (a nivel de sitio no tenemos permisos para hacerlo) y accederemos al esquema de búsqueda de la colección de sitios.

Lo que haremos ahora, es ir a las distintas propiedades administradas para asociarlas adecuadamente. En mi ejemplo, quiero añadir cuatro refinadores, tres pueden ser mapeados como cadena y uno como número. Las propiedades administradas de refinamiento tienen números correlativos asignados (por ejemplo RefinableString00 a RefinableString99), así que seleccionamos la propiedad que queremos mapear y entramos a ella.

Una vez dentro, tenemos que asignar las propiedades rastreadas. Para ello, hacemos click en asignar propiedades.

Buscamos la propiedad rastreada que queramos mapear, por defecto SharePoint, para cada columna que hayamos definido crea dos propiedades rastreadas, como las que vemos a continuación:

Para el refinamiento, tenemos que seleccionar la propiedad que tiene la forma ows_<nombre de la propiedad>. Seleccionamos ésta y damos a aceptar, luego guardamos los cambios hechos en la propiedad administrada y, en nuestro caso, como queríamos crear cuatro refinadores personalizados, repetimos la tarea para el resto de refinadores.

Personalizando el WebPart de refinamiento

Una vez que ya hemos definido los refinadores personalizados que vamos a utilizar, podemos ir a la página del catálogo para configurar el WebPart de refinamiento. Para ello nos iremos a las propiedades de dicho WebPart y la opción de «Elegir refinadores».

Por defecto nos aparecen los refinadores que vemos en la imagen anterior. En nuestro caso, queremos cambiarlos por los que habíamos definido en el paso anterior. Por lo que cambiamos los refinadores por defecto por los siguientes: RefinableString01, RefinableString02, RefinableString03, RefinableInt01.

Si hacemos click sobre cada uno de los refinadores podemos cambiar algunos aspectos de la visualización de los mismos. Entre otras cosas, nombre de ese refinador a  la hora de mostrarlo, tipo de plantilla (en función del tipo de refinador), y aspectos de configuración que varían en función del tipo de refinador que hayamos seleccionado.

Cuando hayamos configurado todos los refinadores, pulsamos aceptar y guardamos los cambios en el WebPart, con lo que ya tendremos nuestra página de Catálogo con unos refinadores personalizados y ajustados a nuestras necesidades. Es posible, que cuando se hayan definido los mismos, inicialmente, si no se ha realizado todavía una re-indexación de la lista posterior al mapeo adecuado de todas la propiedades administradas, no aparezca nada, esto se subsanará en cuestión de minutos, cuando la re-indexación se complete correctamente. Este es el aspecto que sin nada de diseño, nos queda del Content Search WebPart y el WebPart de refinamiento.

Y nada más por hoy, espero que toda esta serie de artículos relacionados con el Search Driven Development, os estén siendo de utilidad. Os dejo algunos enlaces que me han servido a la hora de preparar el post.

http://blogs.technet.com/b/tothesharepoint/archive/2013/06/19/stage-14-configure-refiners-for-faceted-navigation.aspx

http://blogs.technet.com/b/tothesharepoint/archive/2013/11/11/how-to-add-refiners-to-your-search-results-page-for-sharepoint-2013.aspx

Un saludo.

SharePoint 2013 – Read List Items using REST API

Aquí tenemos otro interesante artículo sobre cómo utilizar los servicios REST para leer listas de SharePoint. En un post anterior veíamos el acceso a listas de SharePoint 2013 a través de la API de cliente y AngularJS, el ejemplo de hoy utiliza JQuery y las opciones de Ajax de esta librería. Un saludo. Espero ya, poder dedicar algo de tiempo a hacer un ejemplo usando todo esto que vemos aquí.

.Net Goodies

SharePoint 2013 introduced Rich REST endpoints, we can use this to query data asynchronously using jQuery/JavaScript.

Here is a sample code which can be used to read items from a SharePoint list

We are dynamically forming the site url using various tokens.

First we need to get the SharePoint list, for that we use REST method GetByTitle and pass the list title. Then we are selecting the item Title. You can add more fields by separating with comma.

The result is then converted to JSON object using JSON.Parse method.

Finally a loop is used to iterate through the items.

Ver la entrada original

Manejo de Excepciones en aplicaciones de varias capas

Cuando desarrollamos aplicaciones, es habitual dividir la lógica de nuestra aplicación en varias capas. Normalmente un mínimo de 3 capas (las conocidas como three-tier applications) que separan: Capa de presentación, capa de lógica de negocio y capa de acceso a datos.

Un tema importante en este tipo de implementaciones es, que approach utilizar para el manejo de excepciones, para ello hoy he tenido la oportunidad de leer un artículo muy interesante en c-sharpcorner que quiero compartir con vosotros en el que hablan de cómo tratar el manejo de excepciones en aplicaciones de este tipo y dan una serie «reglas» que hay que tener en cuenta. Este es el artículo en cuestión:

http://www.c-sharpcorner.com/Blogs/46991/standard-way-of-exception-handling-in-3-tier-or-n-tier-appli.aspx

En el artículo destacan los siguientes aspectos a tener en cuenta a la hora de implementar el manejo de excepciones en este tipo de aplicaciones:

1. Encapsular la excepción que se ha lanzado en una excepción personalizada
2. Almacenar en un log los detalles de la excepción (o hacerlo en la base de datos)
3. Si la excepción proviene de una capa anterior, trasladar las excepción hasta la capa superior sin grabar la excepción, ya que esto se ha hecho en la capa de origen
4. Si estamos en la capa visual mostrar un mensaje amigable al usuario

Además en el artículo comparten una imagen que ayuda a aclarar la implementación de excepciones que también quiero compartir.

Lo que quiero hacer a continuación es mostraros con un ejemplo de código cómo podríamos hacer la implementación que nos sugieren en el artículo anterior, o al menos tal y como yo lo he entendido. El ejemplo está hecho para .NET, aunque se puede aplicar en cualquier lenguaje de programación.

Ejemplo de implementación del manejo de errores en aplicaciones de varias capas

Para el ejemplo en cuestión, se tratará de una aplicación en tres capas, por lo que contaremos con una clase que representaría a cada una de las capas: Acceso a datos, Lógica de Negocio y Presentación, y otras tantas clases personalizadas de excepciones.

Vamos a empezar definiendo las Clases de Error Personalizadas

public class DataAccessException: Exception
{
    public DataAccessException(){}
    public DataAccessException(string message) : base(message){}
    public DataAccessException(string message, Exception inner) : base(message, inner){}
}

public class BusinessLogicException: Exception
{
    public BusinessLogicException(){}
    public BusinessLogicException(string message) : base(message){}
    public BusinessLogicException(string message, Exception inner) : base(message, inner){}
}

Podríamos tener en cada capa más clases de excepciones personalizadas en función del tipo de error, forma de almacenamiento del mismo y posibles acciones a llevar a cabo en cada caso, al pasar de una capa a otra encapsularíamos estas excepciones en la genérica de cada capa.

Vamos a ver ahora como se implementarían las distintas clases de cada capa.

public class ExampleDataAccess : DataAccess
{
    public function List<Data> GetSomeData()
    {
        try
        {
            //Do DataAccess Work
        }
        catch(Exception ex)
        {
            LogError(ex);
            throw new DataAccessException("Some friendly Message", ex);
        }
    }
}

public class ExampleBusinessLogic : BusinessLogic
{
    public function bool DoSomeBusinessProcess()
    {
        try
        {
            //Do Business Work
        }
        catch(DataAccessException dae)
        {
            throw dae;
        }
        catch(Exception ex)
        {
            LogError(ex);
            throw new BusinessLogicException("Some Friendly Message", ex);
        }
    }
}

public class ExampleView : View
{
    public function void InitializeView()
    {
        try
        {
            //Do View Work
        }
        catch(DataAccessException dae)
        {
            ShowFinalFriendlyMessageToUser();
        }
        catch(BusinessLogicException ble)
        {
            ShowFinalFriendlyMessageToUser();
        }
        catch(Exception ex)
        {
            LogError(ex);
            ShowFinalFriendlyMessageToUser();
        }
    }
}

Y esto es todo, aquí tenéis el ejemplo, yo lo estaba empezando a usar en cierta medida en mis últimos desarrollos, pero con esto creo que mi manejo de errores quedará mucho más completo y me permitirá tener una mejor traza y seguimiento de los mismos.

Espero que vosotros lo podáis utilizar igualmente.

Un saludo

Tipos de Resultados en Búsquedas de SharePoint OnLine

Muy buenas a todos,

Seguimos hoy con las búsquedas en SharePoint OnLine, y por ende, también aplicable a la versión On-Premises de SharePoint 2013.

En el último post que he publicado recientemente, «Introducción al uso de Display Templates en SharePoint OnLine», hablaba de cómo usar los Display Templates dentro de una solución guiada por las búsquedas en SharePoint OnLine. Hoy, vamos a ver más sobre como podemos usar estos Display Templates, en las búsquedas de SharePoint. En este caso, vamos a ver como hacer uso de los mismos dentro de nuestra central de búsquedas.

Puede darse el caso de que tengamos varios tipos de resultados distintos, que queramos que se diferencien en su aspecto cuando nos los muestre el buscador. Para ello vamos a usar lo que se conoce como Tipos de resultados. Por medio de esta opción que nos ofrece SharePoint, vamos a poder indicar qué plantilla de las que hayamos definido, queremos aplicar a los distintos resultados de la búsqueda que hayamos realizado. Para hacerlo previamente deberemos haber creado las plantillas y haberlas subido al sitio (En el post mencionado anteriormente podréis encontrar como crear y subir una plantilla). Una vez que lo hayamos hecho vamos a ir a la opción de Tipos de resultados de la configuración del sitio para definir los mismos.

Una de las posibilidades que nos ofrece SharePoint, es definir estos tipos de resultado a nivel de colección de sitios o exclusivamente nivel de sitio, dependerá de nuestro planeamiento de las búsquedas donde definir los Tipos de resultados, lo que si es claro, que esta nueva posibilidad de trabajar con las búsquedas, no solo a nivel de Administración Central, nos ofrece una cantidad de nuevas oportunidades a la hora de trabajar con ellas, lo que las hace más atractivas y versátiles que en las versiones anteriores.

Cuando accedemos a la opción de Tipos de resultados, vemos todos los que ya hay definidos y tenemos la opción de crear nuevos. Lo que haremos al definir un tipo de resultado es: Indicar para que origen de resultados queremos que se aplique, la condición que tiene que tener ese resultado y la plantilla que se va aplicar para el resultado que satisfaga la condición. Para ver como hacer esto, pulsamos en «Nuevo tipo de resultado».

Esto nos llevará a la pantalla que vamos a ver a continuación y que nos permite definir el tipo de resultado, indicando los apartados que ya hemos comentado.

En el formulario que se nos muestra tendremos que indicar primero el nombre del Tipo de resultado. A continuación, indicaremos las condiciones que harán que se aplique el tipo de resultado. Estas condiciones pueden ser o aplicables a uno de los tipos de contenido por defecto de SharePoint o en función de las propiedades administradas y sus valores. Para ver la posibilidad de indicar condiciones relacionadas con las propiedades administradas tenemos que hacer click en «Mostrar más condiciones».

En el caso de ejemplo, queremos que se aplique el tipo de resultado a un Tipo de contenido definido previamente. Para ello, se selecciona la propiedad ContentType e indicaremos que el valor sea igual al nombre del Tipo de contenido. Lo que nos queda en la tercera parte del formulario es indicar la plantilla que queremos aplicar cuando se satisfagan las condiciones. Una vez indicados todos los datos, pulsamos sobre Aceptar y ya tendremos nuevo Tipo de resultado creado y se comenzará a aplicar inmediatamente en nuestros resultados de búsqueda.

Vamos a ver ahora lo que pasa cuando creamos distintos Tipos de resultados para los tipos de contenido que tenemos en nuestro sitio.

Aunque como siempre, ya sabéis que no me paro mucho en los diseños para el ejemplo, se ve como un resultado que pertenece a un tipo de contenido tiene un estilo y otro que pertenece a otro distinto tiene un estilo diferente.

El uso de los Tipos de resultado, a mi particularmente, me parece muy interesante y de gran utilidad. La oportunidad de usar las Display Templates, en lugar de las plantillas XSL de anteriores versiones y poder de una manera organizada y reutilizable crear plantillas creo que aporta muchas mejoras a la forma en que tratar los resultados de búsqueda de SharePoint.

Lo próximo sobre lo que me gustaría centrarme es en la parte de ordenación y reglas de consulta que nos ofrece SharePoint, pero para ello, habrá que esperar a futuros post, XD.

Espero que hayáis encontrado útil lo que os he contado hoy.

Saludos a todos

Introducción al uso de Display Templates en SharePoint OnLine

Muy buenas de nuevo a todos,

En mis anteriores entradas he estado hablando sobre como podríamos usar los Content Search Web Part para hacer personalizaciones de nuestros sitios sin escribir ninguna línea de código. Habíamos conseguido una página que nos mostraba un catálogo de elementos y enlaces a la página donde podíamos ver el detalle de los elementos de dicho catálogo.

Primeros Pasos con SharePoint OnLine: Search Driven Development

Search Driven Development en SharePoint (II): Catálogos y Elementos de Catálogo

En ambas entradas os hablaba de la posibilidad de personalizar el diseño de esos resultados para hacerlos más atractivos e integrarlos con el branding de nuestro sitios. Para los que hayáis trabajado con la personalización de los resultados de búsqueda en SharePoint 2010, os habréis topado seguro con las plantillas XSL que nos obligaban a saber manejar XSLT para la creación de las mismas. Con SharePoint OnLine y 2013 todo este approach ha cambiado, dentro de toda la renovación de la plataforma para hacerla más ligera y cercana a las nuevas tecnologías. Ahora vamos a poder trabajar directamente con HTML y Javascript, lo que seguro que nos va a resultar muy interesante. Todo esto es lo que vamos a ver al hablar de los Display Templates. Nuestro objetivo va a ser, pasar de esto:

A una visualización de los resultados de nuestro Content Search Web Part como estos:

Aunque no se trata de un diseño muy elaborado, si que nos va a servir para ver que de una forma muy sencilla vamos a poder modificar la visualización de los resultados de búsqueda. Antes de nada, os voy a mostrar algunos enlaces que he utilizado para saber como usar los Display Templates.

http://blogs.technet.com/b/tothesharepoint/archive/2013/05/28/stage-11-upload-and-apply-display-templates-to-the-content-search-web-part.aspx

http://www.compartimoss.com/revistas/numero-17/introduccion-plantillas-elementos-contenido-display-templates

La información de nuestros Display Templates la vamos a encontrar en dos sitios. Si queremos editar las propiedades de las plantillas ya subidas, iremos al administrador de diseños al que podemos acceder de la siguiente manera, donde en el apartado de «Editar plantillas para mostrar», encontraremos las plantillas ya cargadas:

Si por el contrario queremos añadir nuevas plantillas lo haremos a través de Configuración del sitio->Páginas maestras y diseños de página->Display Templates->Content Web Parts

Cuando accedemos al lugar que nos permitirá añadir nuevas plantillas, vemos que cada una de las plantillas ya subidas tiene dos archivos, uno .html y otro .js. Nosotros solo tendremos que crear el .html con la plantilla, el archivo con extensión .js se crea automáticamente al subir el anterior y es transparente para nosotros, este archivo contiene la sustitución que hace SharePoint de una serie de etiquetas especiales que se usan en las plantillas, por las correspondientes que haya que usar.

En nuestro caso, para lograr el objetivo que os he mostrado, vamos a crear dos plantillas, una para los elementos cuando están dentro del catálogo y otra para la página que muestra el detalle de uno de los elementos del catálogo

¿Como creamos una plantilla personalizada?

Como hemos dicho antes, una plantilla es un archivo .html con una serie de etiquetas especiales. Voy a mostraros como es una plantilla y después os explicaré algunos aspectos que hay que tener en cuenta.

<html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882">
<head>
    <title>Plantilla de Ejemplo</title>
  
    <!--[if gte mso 9]><xml>
    <mso:CustomDocumentProperties>
    <mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden>
    <mso:ManagedPropertyMapping msdt:dt="string">
        'Title'{Título}:'Title',
        'Skills'{Capacidades}:'CapacidadesOWSTEXT',
        'SecondaryFileExtension',
        'ContentTypeId'
    </mso:ManagedPropertyMapping>
    <mso:MasterPageDescription msdt:dt="string">Este es el ejemplo de una plantilla para resultados de elementos de busqueda</mso:MasterPageDescription>
    <mso:ContentTypeId msdt:dt="string">0x01006BCAA0AD8F40D041AD8D1579799074B6</mso:ContentTypeId>
    <mso:TargetControlType msdt:dt="string">;#Content Web Parts;#SearchResults;#</mso:TargetControlType>
    <mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated>
    </mso:CustomDocumentProperties></xml><![endif]-->
</head>
  
<body>
  
    <div id="ExampleSearchDrivenSolution">
  
<!--#_
    var encodedId = $htmlEncode(ctx.ClientControl.get_nextUniqueId() + "_exampleTemplate_");
  
    var linkURL = $getItemValue(ctx, "Link URL");
    linkURL.overrideValueRenderer($urlHtmlEncode);
  
    var title = $getItemValue(ctx, "Title");

  
    var skills = $getItemValue(ctx, "Skills");
  
    var containerId = encodedId + "container";
  
 _#-->
  
        <div id="_#= containerId =#_" style="float:left;width:25%;margin-left:0.5em;border:1px solid #CCC; min-height:25em;background-color:#EEE;cursor:pointer;position:relative;" onclick="window.location.href = '/sites/organizer/autores/_#= title =#_'">
            <span style="color:red;">_#= title =#_</span>
            <p style="text-decoration:underline;position:absolute;bottom:0.5em;">_#= skills =#_</p>
        </div>
  
    </div>
</body>
</html>

• El primer aspecto importante se encuentra entre las líneas 5 y 18. Aquí se define un XML donde se definirán los parámetros de la plantilla. Lo más importante tiene que ver con lo que se define en la etiqueta «mso:ManagedPropertyMapping», que es donde se definen las propiedades administradas que serán mapeadas en la plantilla y que usaremos después en la misma para mostrar los distintos campos del elemento devuelto por la búsqueda.
• Con las etiquetas «<!–#_» y «_#–>» podremos escribir todo el código Javascript que queramos dentro de nuestra plantilla.
• Haciendo uso de las etiquetas «_#=» y «=#_» podremos hacer uso de variables de Javascript que hayamos definido previamente
• Es importante tener en cuenta que solo el contenido que aparezca en el primer »
  <div>» será visible dentro de nuestra plantilla.

Este es el código que he usado para la plantilla de los elementos que forman parte del catálogo. A continuación os muestro la que he usado para el detalle de los elementos. La diferencia, a parte del diseño, se encuentra en las propiedades administradas que se mapearán en cada caso.

<html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882">
<head>
    <title>Plantilla de Ejemplo para elementos</title>
  
    <!--[if gte mso 9]><xml>
    <mso:CustomDocumentProperties>
    <mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden>
    <mso:ManagedPropertyMapping msdt:dt="string">
        'Link URL'{Dirección URL del vínculo}:'Path',
        'Title'{Título}:'Title',
        'Skills'{Capacidades}:'CapacidadesOWSTEXT',
        'Email'{Email}:'EmailOWSTEXT;,
        'WebSite'{Sitio personal}:'PersonalWebsiteOWSURLH;,
        'SecondaryFileExtension',
        'ContentTypeId'
    </mso:ManagedPropertyMapping><mso:MasterPageDescription msdt:dt="string">Este ejemplo se utiliza para el elemento de la lista</mso:MasterPageDescription>
    <mso:ContentTypeId msdt:dt="string">0x01006BCAA0AD8F40D041AD8D1579799074B6</mso:ContentTypeId>
    <mso:TargetControlType msdt:dt="string">;#Content Web Parts;#SearchResults;#</mso:TargetControlType>
    <mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated>
    <mso:HtmlDesignConversionSucceeded msdt:dt="string">True</mso:HtmlDesignConversionSucceeded>
    </mso:CustomDocumentProperties></xml><![endif]-->
</head>
  
<body>
  
    <div id="ExampleSearchDrivenSolution">
  
<!--#_
    var encodedId = $htmlEncode(ctx.ClientControl.get_nextUniqueId() + "_exampleTemplate_");
  
    var title = $getItemValue(ctx, "Title");
  
    var skills = $getItemValue(ctx, "Skills");

    var mail = $getItemValue(ctx, "Email");
  
    var website = $getItemValue(ctx, "WebSite");
  
    var containerId = encodedId + "container";
  
 _#-->
        <h2>Nombre: _#= title =#_</h2>

        <span style="display:block;margin-top:1em;font-weight:bold;font-size:1.2em;">Descripción de las habilidades</span>
        <p>_#= skills =#_</p>

        <span style="display:block;margin-top:1em;font-weight:bold;font-size:1.2em;">¿Deseas ir a su web para conocer más sobre este autor?</span>
        <a href="_#= website =#_">_#= website =#_</a>

        <span style="display:block;margin-top:1em;font-weight:bold;font-size:1.2em;">¿Quieres ponerte en contacto con este autor?</span>
        <a href="mailto:_#= mail =#_">_#= mail =#_</a>
  
    </div>
</body>
</html>

¿Cómo subimos una plantilla personalizada?

Una vez que ya hemos definido nuestras plantillas, vamos a añadirlas a nuestro sitio de SharePoint para poder usarlas. Para ello, seguimos la ruta que ya indicamos antes, para entrar al sitio donde podremos subirla. En nuestra Ribbon, desplegamos la opción de «Nuevo Documento» y hacemos click en «Plantillas para mostrar de elementos»:

A continuación seleccionamos la plantilla a subir,

Por último se carga la pantalla de propiedades de la plantilla, donde vemos precargadas las propiedades que ya definimos en el código de la misma. Si no lo hemos hecho en el código de la plantilla, aquí deberemos indicar el Tipo de Contenido asociado, el título de plantilla, el tipo de control de destino y el Archivo Asociado.

Una vez hecho esto, veremos que la plantilla se ha añadido correctamente a nuestra lista de plantillas y que efectivamente se ha creado asociado al .html el .js . Para que esté disponible para ser usada, tenemos que ir al administrador de diseños y aprobar la plantilla que acabamos de subir que estará en estado «Borrador» en ese momento.

Tras esto la plantilla ya estará disponible para usarla en nuestro Content Search WebPart. El proceso para subir una nueva plantilla lo repetiremos para las dos plantillas de nuestro sitio.

Usando la plantilla en el Content Search WebPart

El último paso que nos queda es cargar las plantillas en cada uno de los Content Search WebPart, por un lado el que se encuentra en la página que muestra el catálogo y por otro el de la página que nos muestra los elementos del catálogo, usando en cada caso la plantilla deseada

Para ello, editamos el web part de la página correspondiente, seleccionando la plantilla que queremos usar como vamos a ver a continuación.

En el apartado de plantillas para mostrar de las propiedades del webpart, marcamos Usar una plantilla única para mostrar elementos y ahí seleccionamos nuestra plantilla

Una vez hagamos esto con las dos plantillas, ya tendremos las mismas funcionando y podremos ver los resultados de búsqueda con el diseño que queríamos.

Espero que os resulte interesante la información. Un saludo a todos

Search Driven Development en SharePoint (II): Catálogos y Elementos de Catálogo

Hola de nuevo a todos, en mi anterior entrada, hablaba sobre como podíamos usar algunos de los elementos de las búsquedas en SharePoint 2013 y SharePoint OnLine para evitar tener que hacer desarrollos. En el ejemplo vimos como podíamos crear una página que nos mostrara los elementos de una lista sin escribir una sola línea de código.

Primeros Pasos con SharePoint OnLine: Search Driven Development

Hoy quiero avanzar un poco más en ese ejemplo. Al final del mismo teníamos una url /autores que nos mostraba una lista con los autores que habíamos creado, teníamos una página con el catálogo de autores. Pero, ¿Y si quisiéramos acceder a un autor concreto?, es decir, acceder a una URL del tipo /autores/nombre-del-autor. ¿Es necesario crear un término de navegación para cada elemento del catálogo?, ¿tenemos que hacer algún desarrollo para esto?. La respuesta a ambas preguntas es no. Evidentemente, seguiremos con la premisa de hacerlo sin escribir ninguna línea de código. ¿Cómo vamos a hacerlo entonces?, nuevamente, haremos uso del Content Search WebPart.

Creando la página de elementos de catálogo

Lo primero que vamos a hacer es crear una nueva página en la biblioteca Páginas con el nombre autor-view.aspx.

Modificando el término de navegación por metadatos

Una vez creada la página, vamos a modificar el término de navegación Autores que tenemos creado y al que asociamos la página autores.aspx para poder acceder a la URL /autores y que nos devolviera el resultado esperado. Para ello vamos a Configuración del sitio->Administración de almacenamiento de términos para el sitio en que estamos, es decir, en la Administración del sitio y seleccionamos el término Autores del almacén de metadatos de navegación.

En la pestaña Página basada en términos, en la parte inferior, tenemos la sección Configuración de la página de elementos del catálogo. Es ahí donde vamos a indicar a qué página queremos que nos lleve SharePoint cuando accedamos a un elemento del catálogo. En esta sección marcamos las dos casillas Cambiar la página de elemento de catálogo para esta categoría y Cambiar la página de elemento de catálogo para los elementos y pulsando en el botón Examinar en ambos casos, nos aparecerá la opción donde indicar la página a donde queremos ir. Aquí indicaremos la página que creamos en el apartado anterior.

Cuando lo hayamos hecho, el término quedará de la forma que vemos en la siguiente imagen, lo guardaremos y ya habremos indicado, a la página que debe ir cuando accedamos a un elemento del catálogo, sin tener que crear un término manualmente para cada uno ni hacer ningún desarrollo.

Añadiendo el Content Search WebPart a la página

Si ahora usamos una URL del tipo /autores/1, veremos que nos redirige efectivamente a la página que deseamos, pero como no habíamos hecho nada sobre ella, esta aparece en blanco. Para que en cada caso nos devuelva el resultado deseado vamos a hacer nuevamente uso del Content Search WebPart. Lo primero que vamos a hacer por tanto es añadirlo a la página. En las propiedades del mismo, accedemos nuevamente a la opción Cambiar consulta.

Nuevamente seleccionaremos como origen de los resultados de búsqueda el de Autores que habíamos creado en el ejemplo anterior. Vamos a añadir un filtro de propiedades. Lo haremos por el valor que queremos posteriormente indicar como parámetro de la URL. Por ejemplo, si queremos una URL del tipo /autores/1 indicaremos el filtro por el campo ID, si por ejemplo lo queremos hacer para el Título del elemento lo haremos por el campo Title, en nuestro caso esta será la opción. En la opción, Seleccionar valor indicamos Valor de un token de dirección de URL y le damos a Agregar filtro de propiedades.

Al agregarlo ya tendremos configurado el Content Search WebPart para que funcione como deseamos.

Lo guardamos y volvemos a la página, en mi caso por ejemplo /autores/JCRA para acceder a uno de los elementos que tenía guardados en la lista y el resultado es el que esperábamos.

Las oportunidades que nos ofrecen las funcionalidades descritas en estos dos tutoriales nos permiten eliminar una gran cantidad de desarrollos en SharePoint. Imaginaros un «Sitio» con categoría de productos, la facilidad para gestionar el acceso a los catálogos de productos y el acceso al detalle de cada producto con este sistema es enorme.

Y esto es todo por hoy. Sigue quedando pendiente ver como personalizar los resultados de búsqueda, espero poder hablar sobre el tema en breve, pero me parecía interesante hablaros sobre esto antes.

Espero que os resulte útil.

Un saludo a todos

Primeros Pasos con SharePoint OnLine: Search Driven Development

Hola a todos,

Este tema, es uno de los que más interés han estado despertando en mi desde que empecé a trabajar con SharePoint OnLine y 2013 y tenía muchas ganas de ver cómo funcionaba, y empezar a hacer algo con esto. Como ya dije cuando empecé a hablar de SharePoint 2013, una de las mejoras más importantes que veía era todo lo relacionado con las búsquedas y las posibilidades que ofrecían.

Dentro de estas mejoras, encontramos la oportunidad de trabajar con el concepto que se conoce como Search Driven Development (Desarrollo dirigido por búsquedas). Utilizando todas las posibilidades que nos ofrecen las búsquedas podemos personalizar nuestros sitios de SharePoint sin escribir una sola línea de código, usando solo adecuadamente el Content Search WebPart y añadiendo algo de HTML y Javascript.

En muchas ocasiones, las personalizaciones que queremos hacer a nuestros sitios consisten en mostrar en pantalla los elementos de una lista o una biblioteca y maquetarlos de una forma personalizada. Para ello, no necesitaremos hacer ningún desarrollo en SharePoint 2013, como vamos a ver a continuación. Paso a describiros el objetivo del ejemplo que voy a llevar a cabo:

1. Crear una lista personalizada
2. Crear una página que nos muestre los elementos de esta lista
3. No utilizar ninguna línea de código

Para un segundo post sobre este tema dejaré la personalización de los elementos de la lista usando las oportunidades de las búsquedas. Vamos a ello entonces.

Creando el Tipo de Contenido

En primer lugar, vamos a crear el Tipo de Contenido que vamos a utilizar como base en todo el ejemplo. Para ello vamos a la Configuración del Sitio y Tipos de Contenido de Sitio.

Vamos a la opción Crear y añadimos un Tipo de Contenido de nombre Autor

Una vez creado añadimos columnas de sitio existentes hasta dejarlo con el siguiente aspecto

Creando la lista Autores

Lo primero que vamos a hacer es crear la lista Autores. Para ello iremos a Contenidos del sitio->Agregar una aplicación->Lista personalizada. Lo que haremos en este caso es asociar a la lista, el Tipo de Contenido que hemos definido previamente. Para ello, iremos a Configuración de la Lista, para habilitar la gestión de tipos de contenido. Esto lo haremos en la opción de Configuración avanzada como vemos a continuación.

A continuación asignamos a esta lista el Tipo de Contenido Autor que habíamos creado previamente.

Una vez asociado el Tipo de Contenido a la lista, crearemos algunos elementos de tipo Autor en dicha lista completando los campos correspondientes.

Creando la página

Para la creación de la página, nos vamos a la librería SitePages de nuestro sitio y añadimos una página llamada autores.aspx.

Vamos a crear un enlace de navegación basada en metadatos para asociar esa página a la Url /autores. Para ello vamos a seguir el tutorial del post que publiqué hace un tiempo sobre este tema.

URLs amigables en SharePoint OnLine

Creando la Fuente de Resultados

A partir de aquí empieza la parte más interesante. Vamos a sentar las bases para poder hacer lo que nos hemos propuesto. Vamos a crear una fuente de resultados. Para ello, nos vamos a la configuración del sitio y en la sección buscar vamos a Fuentes de Resultado

Una vez dentro, pulsamos la opción de Crear un nuevo origen de resultado. Lo que nos llevará a la pantalla de creación. Ahí elegimos el nombre y lo llamamos Autores.

A continuación vamos a la casilla de Transformación de consulta y pulsamos sobre el botón de Iniciar Generador de Consultas. Esto nos llevará a una pantalla como la que vemos a continuación. Aquí podremos configurar la consulta que queremos que nos devuelva este origen de resultado.

En el caso de nuestro ejemplo, lo que queremos es que nos muestre todos los autores. Para poder hacer esto, vamos a añadir un Filtro de propiedades que nos permita filtrar de los resultados de búsqueda, seleccionando aquellos cuyo Tipo de Contenido es de tipo Autor. De la lista que se despliega, seleccionamos Tipo de Contenido y después indicamos que queremos que sean los de tipo Autor. Tras esto pulsamos sobre Agregar Filtro de Propiedades y el filtro se agregará a nuestra consulta. Podemos probarla para saber que los resultados son correctos antes de Aceptar. En la siguiente imagen se puede ver como en la prueba de la consulta, se devuelven los resultados esperados, por lo que Aceptamos.

Y con esto ya tenemos nuestro Origen de resultados creado correctamente. Ahora solo nos queda añadir a la página el Content Search WebPart y asignarle este Origen de Resultados.

Añadiendo y configurando el Content Search WebPart

Para terminar con el ejemplo, vamos a añadir a la página que habíamos creado previamente un Content Search WebPart, al que le asociaremos el Origen de resultados. Para cualquier usuario de SharePoint que haya llegado hasta aquí, agregar un WebPart a una página le resultará una tarea trivial, así que vamos a obviarlo. Partiremos entonces de la página con el WebPart añadido.

Vamos a ir a las propiedades del elemento web y haremos click en la opción de Cambiar Consulta

La pantalla que se despliega nos permite hacer varias modificaciones sobre los resultados de búsqueda de este WebPart. En nuestro caso, solo vamos a modificar el origen de resultados en el desplegable Selecciona una consulta, donde indicaremos el origen de resultados Autores que creamos en el apartado anterior.

Aceptamos y Voilá!, ya lo tenemos, una página que nos muestra los elementos de la lista autores sin nada de código y de una forma muy sencilla.

Como decía al principio, dejo para el siguiente post, como maquetar esos resultados para modificarlos visualmente, consiguiendo una experiencia mejor si cabe, ahora mismo, está tomando la opción por defecto para mostrar los resultados de búsqueda.

Y nada más, es solo un ejemplo de lo que se puede hacer con las búsquedas que espero que os sea útil.

Un saludo.

Monitorizando desarrollos en SharePoint: SPMonitoredScope, ULS y Developer Dashboard

Hola a todos,

Un tema importante cuando se desarrolla para SharePoint es todo lo relacionado con la monitorización del código desarrollado, para poder hacer seguimiento y el control de las excepciones que se producen en el mismo.

SharePoint nos da muchas herramientas para realizar estas tareas, hoy vamos a ver las que estoy utilizando yo en mis proyectos actualmente. Hace tiempo que he estado leyendo sobre ellas, pero no quería escribir hasta que no las hubiera probado y utilizado por mi mismo.

Developer Dashboard

El Developer Dashboard es una herramienta que aparece a partir de la versión de SharePoint 2010 para permitir, tanto a los administradores como desarrolladores de SharePoint, hacer seguimiento y monitorizar diferentes aspectos de la herramienta como pueden ser WebParts, eventos y llamadas a base de datos entre otra información de utilidad. El Developer Dashboard inicialmente está deshabilitado, aunque se puede activar o bien vía Modelo de objetos, PowerShell o stsadm.exe.

Os dejo unos enlaces sobre cómo activar el Developer Dashboard, y reproduzco cómo hacerlo vía PowerShell, para mí la forma más cómoda de hacerlo.

http://zimmergren.net/technical/sp-2010-developing-for-performance-part-1-developer-dashboard

http://sharepointgroup.wordpress.com/2012/05/04/enbl-sharepoint-developer-dashboard-with-powershell/

Para activarlo vía PowerShell haremos los siguiente

$dashboard = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings;
$dashboard.DisplayLevel = “OnDemand”;
$dashboard.TraceEnabled = $true;
$dashboard.Update()

Hay otras dos posibilidades para la opción DisplayLevel: On, Off.

Esta es una captura de pantalla del Dashboard de SharePoint 2010, el de SharePoint 2013 incluye importantes mejoras, pero aún no he podido probarlo, porque no he tenido oportunidad, aunque hay un rediseño completo del dashboard y una mejora en la forma y cantidad de la información que se muestra.

SPMonitoredScope

La clase SPMonitoredScope nos va a permitir monitorizar partes del código desarrollado. Os dejo el enlace donde se describe esta clase.

http://msdn.microsoft.com/es-es/library/office/ff512758(v=office.14).aspx

El uso de SPMonitoredScope es muy sencillo, solo es necesario encapsular aquella parte del código propio desarrollado que queremos que sea monitorizado. Vamos a ver un ejemplo:

using(SPMonitoredScope scope = new SPMonitoredScope("Ejemplo1"))
{
      //Aquí el código a monitorizar
      SomethingToDo();
}

La información que se genera a partir de este código se puede consultar o bien en el Developer Dashboard o en el ULS (Unified Logging Service).

Unified Logging Service

Otro de los elementos que nos permite monitorizar lo que ocurre con nuestro código es a través del ULS (Unified Logging Service). Éste, proporciona un mecanismo eficaz para escribir información útil para identificar y ayudar en la solución de problemas durante el ciclo de vida de la aplicación. El ULS permite escribir eventos en el Log de SharePoint normalmente almacenado en la siguiente ruta «\14\LOGS\SERVER-YYYmmDD-ID.log».

Desde el modelo de objetos del servidor podemos escribir en ese Log de manera que posteriormente podamos acceder al mismo y analizar lo que ha ocurrido. Voy a mostrar a continuación como podemos usar el ULS en SharePoint.

try
{
  //OwnCode
} 
catch (Exception ex) 
{
  SPDiagnosticsService.Local.WriteTrace(0, new SPDiagnosticsCategory("EXAMPLE", TraceSeverity.Unexpected, EventSeverity.Error), TraceSeverity.Unexpected, ex.Message, ex.StackTrace);
}

Os dejo un enlace donde podréis ver el significado de cada uno de los parámetros del método WriteTrace, aunque básicamente lo que estamos haciendo es escribir una entrada en el Log, con la categoría «EXAMPLE» de tipo Unexpected y con la información del mensaje de la excepción y la traza de la misma.

http://msdn.microsoft.com/es-es/library/microsoft.sharepoint.administration.spdiagnosticsservicebase.writetrace.aspx

En el siguiente artículo de la MSDN se puede ver una forma de crear una clase para encapsular el logging de errores y poder hacerlo de una forma más sencilla y elegante.

http://msdn.microsoft.com/en-us/library/office/gg512103(v=office.14).aspx

Para poder realizar una mejor visualización y análisis del ULS disponemos de la herramienta ULS Log Viewer, que podremos descargar de forma gratuita y usarla para un análisis de los log más sencilla y clara.

Y hasta aquí lo que quería comentar sobre el tema de monitorización y seguimiento de código en SharePoint, espero que sea de utilidad. Quizá un poco tarde para haber empezado a usarlo, pero como dicen, si la dicha es buena, siempre estamos a tiempo.

Un saludo.

Office 365 – Loading SharePoint List Items using AngularJS and Napa Code Editor

Comparto hoy un artículo muy interesante sobre como combinar AngularJS y SharePoint OnLine. Algo que me resulta muy interesante y sobre lo que indagaré a partir de este post tan útil que he encontrado. En él podemos ver, como cargar los elementos de una lista usando AngularJS. Espero que os resulte útil

Modificando el Web.config al desplegar una solución en SharePoint

Hola a todos,

Últimamente estoy intentando trabajar en la mejora de los desarrollos y de cómo enfocar las soluciones de SharePoint que después se desplegarán en la granja. Un aspecto de los que me quedaba por trabajar tenía que ver con el web.config de una aplicación web. En ocasiones, por diferentes motivos, algunas soluciones requieren de algunos parámetros de configuración para su funcionamiento, como es evidente, el lugar de esos parámetros es en el web.config (en el apartado de appSettings por ejemplo) de la aplicación web, que se encuentra en el caso de SharePoint en la ruta «C://inetpub/wwwroot/wss/VirtualDirectories». Pero, imaginemos que tenemos una granja con varios servidores, ¿Es necesario ir a cada servidor de nuestra granja, acceder a su web.config y establecer esos parámetros de configuración manualmente?, es evidente que no, y que eso se trata de una mala práctica (Lo digo con conocimiento de causa XD). Para modificar el web.config de una aplicación web y añadirle parámetros de configuración que necesite nuestra solución, SharePoint nos proporciona los mecanismos necesarios.

Una buena solución puede ser utilizar el evento de activación y desactivación de una característica en una solución de SharePoint, para crear o borrar esos parámetros de configuración del web.config correspondiente. Para hacer esto disponemos de la clase SPWebConfigModification.

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx

Esta clase nos permitirá establecer las modificaciones que queremos hacer al web.config. Además, también haremos uso de la clase SPWebApplication para añadir los cambios que hayamos definido previamente.

Definiendo las modificaciones del web.config

Como ya he comentado, para definir estas modificaciones, se usa la clase SPWebConfigModification, para la que habrá que definir en cada caso, una serie de propiedades que voy a describir a continuación:

• Name: Esta propiedad no es un nombre interno dado a la modificación. Se debe indicar la etiqueta del XML que se quiere modificar, además de todos los parámetros que se desean establecer del mismo. Esta propiedad posibilita a SharePoint el borrado posteriormente
• Path: Indica el padre del nodo que se está intentando añadir o establecer
• Owner: Esta propiedad es muy importante a la hora eliminar las modificaciones del web.config. Lo que hace es establecer un nombre único para los cambios que se han realizado.
• Type: En la mayoría de las ocasiones se utilizará el valor EnsureChildNode
• Value: La etiqueta XML que se quiere añadir en el web.config

Vamos a ver ahora un ejemplo de la definición de una modificación del web.config usando esta clase y sus propiedades.

SPWebConfigModification entry = new SPWebConfigModification();
entry.Name = @"add[@key='KeyExample'][@value='ValueExample']";
entry.Path = "configuration/appSettings";
entry.Sequence = 0;
entry.Owner = "Owner";
entry.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
entry.Value = @"<add key='KeyExample' value='ValueExample' />";

Añadiendo las modificaciones al web.config

Una vez que ya hemos creado la modificación que queremos hacer, la añadiremos utilizando la clase SPWebApplication de la siguiente manera.

SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;

webApp.WebConfigModifications.Add(entry);

/*Call Update and ApplyWebConfigModifications to save changes*/
webApp.Update();
webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

La parte más reseñable de este código es la última línea, donde se llama a la función ApplyWebConfigModifications, os dejo el enlace a la MSDN donde se explica lo que hace esta función, lo cual me ha resultado interesante.

http://msdn.microsoft.com/es-es/library/microsoft.sharepoint.administration.spwebservice.applywebconfigmodifications.aspx

Eliminando las modificaciones del web.config

Para eliminar las modificaciones que hemos insertado anteriormente, por ejemplo, en el evento de desactivación de la característica correspondiente, usaremos, como ya mencionamos anteriormente la propiedad Owner de la clase SPWebConfigModification. Lo que haremos será obtener todas las modificaciones del SPWebApplication, comprobar aquellas cuyo Owner se corresponde con el de las modificaciones que queremos borrar, y en caso de que coincidan las borramos. Vamos a ver el código de cómo tendríamos que hacerlos.

private void removeConfigModification(SPWebApplication webApp)
{
     SPWebConfigModification entry = null;

     if (webApp.WebConfigModifications.Count > 0)
     {
          for (int i = webApp.WebConfigModifications.Count - 1; i >= 0; i--)
          {
              if (webApp.WebConfigModifications[i].Owner == "Owner")
              {
                  entry = webApp.WebConfigModifications[i];
                  webApp.WebConfigModifications.Remove(entry);
              }
          }

          webApp.Update();
          webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
     }
}

Dejo por último algunos enlaces que me han servido de utilidad relacionados con este tema y donde es posible que haya más información sobre cómo se puede utilizar la modificación del web.config en SharePoint.

http://blogs.perficient.com/microsoft/2013/02/how-to-make-web-config-changes-with-a-feature-and-why-you-should/

http://blog.crsw.com/2007/09/20/how-to-modify-the-web-config-file-in-sharepoint-using-spwebconfigmodification/

http://smindreau.wordpress.com/2013/06/12/finally-the-way-to-add-web-config-modifications-to-sharepoint/

Y esto es todo, espero que os pueda ser de utilidad, a mi me ha venido muy bien en mi trabajo para mejorar la organización y estructuración de los proyectos de SharePoint.

Un saludo a todos