Slides. SharePoint OnPremies en la nube

La semana pasada tuve la oportunidad de dar una sesión en un evento de Soluciones Cloud en Microsoft, organizado por Oscar Mozo y su equipo, donde hablamos sobre las posibilidades híbridas de SharePoint y de como aprovechar las capacidades de infraestructura de Azure para desplegar SharePoint.

Cuando hablamos de SharePoint, nos tiene que venir a la cabeza que existe una versión Online en Office 365 que puede cumplir con nuestros requisitos de negocio para ser una opción viable de colaboración en nuestra empresa, sin embargo, existen ciertas limitaciones que nos llevan a hacer uso de la versión OnPremises que implica la instalación de una granja de SharePoint en nuestros datacenters o, cómo explicamos en la sesión, en la capa de infraestructura de Azure.

Os dejo la presentación, publicada en mi Slideshare.

 

SUGES. Webcast de JavaScript para desarrolladores SharePoint

Desde SUGES volvemos con ganas y las pilas cargadas después de las vacaciones y os proponemos un nuevo e interesante WebCast en el que hablaremos sobre JavaScript y SharePoint. En la última versión de SharePoint, JavaScript se ha convertido en una tecnología y plataforma que todo desarrollador de SharePoint debe de conocer. En este WebCast veremos algunas de las características que tiene JavaScript como lenguaje de programación. Repasaremos algunos de los errores más comunes que realizamos los desarrolladores de C# cuando  empezamos a utilizar JavaScript. Además veremos cómo integrarlo en nuestros desarrollos de SharePoint haciendo uso de varios Frameworks como son AngularJS, ExtJS, Knockoutjs, MustacheJ etc.. Y finalmente hablaremos sobre TypeScript  y cómo podemos integrarlo en nuestros desarrollos, veremos ventajas e inconvenientes sobre el mismo.

Será el 23 de septiembre a las 17.00 (GMT +1:00) Madrid

Tendremos a Adrián Díaz, MVP de SharePoint Server desde Enero de 2014. Cofundador del grupo de usuarios de SharePoint de Levante LevaPoint. Lleva desarrollando con tecnologías Microsoft más de 10 años y desde hace 3 años está centrado en el desarrollo sobre SharePoint. Actualmente trabaja en el departamento de desarrollo de ENCAMINA una consultora informática de Valencia que se destaca por realizar soluciones basadas en Tecnología Microsoft, principalmente en SharePoint. Además es colaborador habitual de la revista digital de habla hispana CompartiMOSS dedicada a SharePoint.

Regístrate en https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032595804&Culture=es-ES&community=0 

Azure. Nuevo servicio de búsqueda ¿cómo el de SharePoint?

Recién publicado tenemos el servicio de búsqueda de Azure, un servicio que nos permite indexar documentos y hacer consultas de ellos mediante una API REST. Tened en cuenta que es una Preview y que puede que nos falten funcionalidades, aun así puede ser un servicio que nos permita mejorar nuestras aplicaciones por un coste razonable.

De momento, no ofrece el potencial que nos ofrece el servicio de búsqueda de SharePoint y veo dos funcionalidades claves que por ahora no tenemos en el servicio de Azure:

  • Indexado del contenido de documentos que realiza el servicio de búsqueda de SharePoint, mediante el uso de IFilters. Si, empezamos este post contando que el servicio de Azure nos permite indexar documentos pero esos documentos no son más que estructuras de datos JSON, y, de momento, no permite la inserción o el rastreo de archivos.
  • Rastreo de orígenes externos que tanto valor nos aporta en SharePoint, pudiendo programar el indexado de carpetas compartidas, carpetas de Exchange, sitios webs, etc. El servicio de Azure requiere que le enviemos los datos a indexar al servicio.

Qué nos ofrece el servicio de búsqueda en Azure

  • Escalado de particiones del índice, incrementando el número de documentos indexados, y réplicas del índice para mejorar el rendimiento en las consultas.
  • API REST con autenticación por clave para administrar los índices y realizar consultas sobre estos. Puedes usar OData para las consultas.
  • Múltiples índices pero de momento sólo se puede consultar uno cada vez
  • Búsqueda en todo el texto o Full-text
  • Modelos de clasificación personalizables para optimizar las búsquedas y acercarlas a las necesidades del negocio.
  • Navegación por atributos del índice con cada consulta.
  • Sugerencias de consultas
  • Destacado del texto que se busca en la consulta.

¿Cómo creamos un servicio de búsqueda en Azure?

Esta es la parte más fácil, como casi todo en Azure. Desde el nuevo Portal de Azure (en Preview) podemos crear un servicio de Search que se encuentra en la sección de «Data, storage, cache, + backup».

 

Como podemos ver en la imagen anterior, tenemos dos modos de servicio, Free o Standard. Si estás haciendo pruebas o desarrollando, las capacidades del Free son más que suficiente para la mayoría de escenarios.

Una vez creado el servicio, podemos acceder a la URL desde la opción «PROPERTIES» y a las claves para la API desde la opción de «KEYS», con estas propiedades podemos empezar a desarrollar.

Creamos un Índice

Lo primero que tenemos que hacer es crear nuestro primer índice con los campos de los documentos que queremos indexar. Para esto enviamos al servicio un objeto JSON con los campos que necesitamos por HTTP PUT a /indexes/[nombre del índice].

//apiKey es la clave de acceso al servicio de búsqueda en Azure

client.DefaultRequestHeaders.Add(«api-key», apiKey);

client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(«application/json»));

//searchUrl es la url del servicio en Azure y searchVersion es la versión actual de la API (?api-version=2014-07-31-Preview)

var url = searchUrl + «/indexes/autores» + searchVersion;

var response = await client.PutAsync(url, new StringContent(jsonObject.ToString(), Encoding.UTF8, «application/json»));

var content = response.Content.ReadAsStringAsync();

 

y el objeto que enviamos con los campos:

{

«name»: «autores»,

«fields»: [

{

«name»: «email»,

«type»: «Edm.String»,

«key»: true,

«searchable»: true

},

{

«name»: «name»,

«type»: «Edm.String»,

«key»: false,

«searchable»: true

},

{

«name»: «bio»,

«type»: «Edm.String»,

«key»: false,

«searchable»: true

},

{

«name»: «url»,

«type»: «Edm.String»,

«key»: false,

«searchable»: false

},

{

«name»: «tags»,

«type»: «Collection(Edm.String)»,

«key»: false,

«searchable»: true

}

]

}

Enviamos documentos al índice

Una vez creado nuestro índice, podemos enviar documentos para que sean indexados y estén disponibles para la búsqueda. Esto lo hacemos por HTTP POST a /indexes/[nombre del índice]/docs/index, como podemos ver en el siguiente ejemplo:

var url = searchUrl + «/indexes/autores/docs/index» + searchVersion;

var response = await client.PostAsync(url, new StringContent(jsonObject.ToString(), Encoding.UTF8, «application/json»));

var content = response.Content.ReadAsStringAsync();

 

al que enviamos el siguiente objeto JSON con los documentos a crear:

{

«value»: [

{

«@search.action»: «upload»,

«email»: «addiacer@gmailcom»,

«name»: «Adrián Díaz»,

«bio»: «Adrián Díaz es Ingeniero de Informática por la Universidad Politécnica de Valencia, MCPD de SharePoint 2010, MAP y MCC 2012. Cofundador del grupo de usuarios de SharePoint de Levante LevaPoint. Lleva desarrollando con tecnologías Microsoft más de 10 años y desde hace 3 años está centrado en el desarrollo sobre SharePoint. Actualmente trabaja en el departamento de desarrollo de ENCAMINA una consultora informática de Valencia que se destaca por realizar soluciones basadas en Tecnología Microsoft, principalmente en SharePoint.»,

«url»: «www.compartimoss.com/autores/adriandiaz»

«tags»: [

«MVP»,

«SharePoint»

]

},

{

«@search.action»: «upload»,

«email»: «santypr@gmailcom»,

«name»: «Santiago Porras»,

«bio»: «UX Developer, experto en desarrollo de experiencias de usuario de soluciones de cualquier ámbito y tecnología, actualmente trabajando en ENCAMINA. Enamorado de SharePoint desde que pude tomar contacto por primera vez, me apasionan las nuevas tecnologías y actualmente mi interés se centra en SharePoint 2010, SharePoint 2013, Windows Azure, ASP.NET MVC 4, Windows 8, Windows Phone y HTML5. Además, compagino mi vida laboral con la difusión de conocimientos y ayuda tecnológica mediante mi participación en TenerifeDev, grupo de usuarios de .NET de Tenerife, como moderador de los foros de SharePoint en MSDN y TechNet y, escribiendo artículos tanto en mi blog personal en Geeks, como algunas veces aquí en la revista digital CompartiMOSS . También podrás encontrarme en Twitter microparticipando con el usuario @saintwukong»,

«url»: «www.compartimoss.com/autores/santiagoporras»

«tags»: [

«MVP»,

«Client Development»

]

}

]

}

Buscar sobre los documentos

Ahora viene la parte más interactiva que nos permite realizar consultas sobre nuestro índice que nos devuelven documentos que cumplan con esas consultas, bien porque está en un campo que es buscable o bien porque especificamos el campo en el que queremos buscar.

Hacer una búsqueda es tan sencillo como hacer un HTTP GET a la url /indexes/[nombre del índice]/docs?QUERY, por ejemplo: /indexes/autores/docs?search=TenerifeDev lo que nos responde con el siguiente JSON con los documentos que ha encontrado y la clasificación de cada documento en función de la búsqueda:

{

    «@odata.context»:»https://adiazcan.search.windows.net/indexes(‘autores’)/$metadata#docs(email,name,bio,tags)»,

    «value»:

    [

        {

        «@search.score»:0.025214419,

        «email»:»santypr@gmailcom»,

        «name»:»Santiago Porras»,

        «bio»:»UX Developer, experto en desarrollo de experiencias de usuario de soluciones de cualquier u00e1mbito y tecnologu00eda, actualmente trabajando en ENCAMINA. Enamorado de SharePoint desde que pude tomar contacto por primera vez, me apasionan las nuevas tecnologu00edas y actualmente mi interu00e9s se centra en SharePoint 2010, SharePoint 2013, Windows Azure, ASP.NET MVC 4, Windows 8, Windows Phone y HTML5. Ademu00e1s, compagino mi vida laboral con la difusiu00f3n de conocimientos y ayuda tecnolu00f3gica mediante mi participaciu00f3n en TenerifeDev, grupo de usuarios de .NET de Tenerife, como moderador de los foros de SharePoint en MSDN y TechNet y, escribiendo artu00edculos tanto en mi blog personal en Geeks, como algunas veces aquu00ed en la revista digital CompartiMOSS . Tambiu00e9n podru00e1s encontrarme en Twitter microparticipando con el usuario @saintwukong»,

        «tags»:[«MVP»,»Client Development»]

        }

    ]

}

Todo esto y mucho más es lo que nos ofrece el servicio de búsqueda de Azure, de momento no tiene todas las capacidades que nos puede dar el servicio de búsqueda de SharePoint pero con el tiempo es posible que se acerque. Además, con el mecanismo de autenticación basado en claves, es mucho más sencillo integrar nuestros desarrollos que frente a SharePoint y para muchas aplicaciones es una necesidad cada vez más común la inclusión de búsqueda de contenidos. Una nueva pieza del puzzle de Azure que hay que seguir y tener en cuenta.

 

Saludos a todos…

SharePoint. Consulta a múltiples listas con búsqueda

En el último artículo de Adrian Diaz sobre cómo realizar consultas en múltiples listas en SharePoint, nos enseñaba una de las diversas formas para conseguir resolver el más que común problema de SharePoint para consultar listas o bibliotecas de documentos que se encuentren distribuidos en diferentes sitios.

Abramos un pequeño debate de cómo y cuál es la mejor forma de realizar consultas en SharePoint sobre múltiples listas, ya que la opción propuesta por Adrián no siempre es la más adecuada o la más eficiente, y me encuentro con ganas de discutir un poco sobre tecnología J.

Como comenta Adrian en su artículo, cuando trabajamos con SharePoint tenemos que tener en cuenta que NO es un SQL Server aunque con las consultas CAML podamos hacer JOIN, UNION o cosas similares. Cuando tratamos con una Gestión Documental, los documentos se distribuyen en diferentes repositorios, cada uno en su departamento o sitio de referencia, en función de la seguridad, los tipos de documentos o por funcionalidad. Además, cada documento se suele clasificar en un Tipo de Contenido, o lo que es lo mismo, un tipo de documento con sus metadatos y procesos.

Pero, ¿Qué pasa cuando necesitamos consultar, por ejemplo, todos los tipos de documentos Ofertas que tenemos en nuestra intranet? Dependiendo de su distribución en sitios, lo habitual sería realizar una consulta en la biblioteca de documentos Comercial, dentro de los sitios de los Departamentos, esto que en seudocódigo traducimos como:

  1. Recorro la lista de sitios de Departamentos
  2. Por cada departamento, hago una consulta en la biblioteca para obtener todos los documentos que sean del tipo Oferta
  3. Cuando recorro todos los sitios, unifico la lista y la devuelvo

Esto es lo que Adrián soluciona de una forma muy eficiente en su artículo usando SPSiteDataQuery, pero ¿Por qué no hacerlo con búsqueda?

El servicio de búsqueda de SharePoint expone un API que nos permite realizar consultas de todo el contenido que tenga indexado y cuando hablo de índice, en SharePoint significa un fichero de texto con la clasificación de la información lista para buscar y devolver resultados de la base de datos de contenido.

SharePoint 2013 nos ofrece esta API tanto en el modelo de objetos de servidor (SSOM) como en el modelo de objetos de cliente (CSOM) o en la interfaz REST, y es aquí donde encontramos la primera ventaja con respecto al SPSiteDataQuery que no es posible su uso en el cliente. Veamos algún ejemplo:

SSOM

KeywordQuery keywordQuery = new KeywordQuery(web);

 

keywordQuery.QueryText = «ContentTypeId:0x0101*»;

keywordQuery.TrimDuplicates = false;

 

SearchExecutor searchExecutor = new SearchExecutor();

ResultTableCollection resultTableCollection = searchExecutor.ExecuteQuery(keywordQuery);

var results = resultTableCollection.Filter(«TableType», KnownTableTypes.RelevantResults);

 

var dt = results.FirstOrDefault().Table;

 

REST

http://host/site/_api/search/query?querytext=’ContentTypeId:0x0101*’&trimduplicates=false

Hay que tener en cuenta que el servicio de búsqueda tiene un lenguaje de consultas específico, distinto a CAML Query, llamado Keyword Query Language (KQL).

Al tratarse de un índice de búsqueda, el rendimiento de la consulta es superior al SPSiteDataQuery y, como todos sabemos, esto en SharePoint siempre importa. Hemos realizado las siguientes pruebas:

Nº de Elementos

Ámbito

Tiempo Search (ms.)

Tiempo SPSiteDataQuery (ms.)

100

Sitio

4712

4261

100

Colección de Sitio

4965

7240

100

Toda la Granja

4965

N/A

* Las pruebas se han realizado en un servidor de desarrollo que no ofrece el mismo rendimiento que un entorno de producción.

Otra de las ventajas de usar búsqueda es que podemos realizar la consulta sobre toda la granja, mientras que el SPSiteDataQuery nos limita al ámbito de Colección de sitios. Con el servicio de búsqueda podemos traernos contenido de cualquier colección de sitios de la granja de SharePoint. Esto aunque parezca trivial, cuando hablamos de portales de miles de usuarios con un uso intensivo de la gestión documental puede ser fundamental y un punto de éxito dentro de la arquitectura de la solución. Por ejemplo, si dividimos los departamentos en múltiples colecciones de sitios podemos almacenar la información en diferentes bases de datos de contenido y garantizar la escalabilidad y el futuro de la intranet.

Por su puesto, el servicio de búsqueda tiene paginado y esto es algo que el SPSiteDataQuery no se puede permitir por cuestiones de arquitectura de SharePoint, pero que es algo muy común en las interfaces de usuario actuales y que debemos buscar siempre la forma más eficiente de realizarla.

Sí, no me queda otra, tengo que hablar de alguna ‘posible’ desventaja y darle algún punto a la solución de Adrian.

Para que las búsquedas funcionen, tenemos que tener todo el contenido indexado y esto implica que el servicio de rastreo de SharePoint ha tenido que pasar por cada elemento que queremos consultar. Hasta SharePoint 2010, lo normal era tener programado un rastreo incremental cada 15 minutos y un rastreo completo diario, lo que nos impide consultar un nuevo documento hasta que no se haya rastreo y lo habitual es que nuestros usuarios crean que el contenido se ha perdido o eliminado por error.

En SharePoint 2013 existe la posibilidad de activar un nuevo tipo de rastreo continuo, o lo que es lo mismo, cada cierto tiempo, se activa un rastreador que se encarga de indexar el contenido existente, con la ventaja de este proceso de rastreo no bloquea la siguiente ejecución y es posible que tengamos 5 o 6 rastreadores que disminuyen la posibilidad de que no aparezca un documento recién creado en nuestra intranet. Vale Adrian J, esto requiere que tengamos más máquina porque los rastreadores son los monstruos de las galletas de los procesadores, pero ¿te has planteado que con una buena arquitectura de SharePoint pensada para búsqueda esto no debería de ser un problema?

Resumiendo…

 

Búsqueda

SPSiteDataQuery

Consultas Cross-Site

Si, toda la granja

Si, sólo en la colección de sitios

API Cliente

Si

No

Velocidad

Más rápido con un ámbito más amplio

Pierde velocidad si se amplía el ámbito de búsqueda

Paginado

Si

No

 

Le paso el guante a Adrian, a ver si es capaz de mejorar estos resultados sin hacer uso de búsqueda.

SharePoint 2013. ¿Solución o Aplicación?

La semana pasada en el Gusenet, Adrian y yo dimos una sesión titulada «Por qué todo lo que veo es SharePoint«.

<

 

Nuestra idea principal era presentar los dos modelos de desarrollo de SharePoint y explicar el por qué desarrollar en SharePoint las aplicaciones que los usuarios demandan.

Como plataforma de implementación de Intranet, Extranet y otras cosas más, SharePoint se encuentra con los clientes para mejorar la colaboración en las empresas. El problema es que no todas las empresas son iguales y necesitan de poder realizar personalizaciones que cumplan con sus reglas de negocio.

SharePoint nos permite hacer este tipo de personalizaciones de tres formas:

  • No-Code Solution, ya que es posible personalizar gran parte de las funcionalidades básicas.
  • SharePoint Solution, extendiendo y añadiendo artefactos de SharePoint para cumplir con las reglas de negocio.
  • SharePoint App, un nuevo modelo de desarrollo que nos ofrece la integración con SharePoint para desplegar aplicaciones dentro de este.

¿Con cuál nos quedamos?

Lo primero es elegir entre No-Code o Code, y en la medida de lo posible os recomiendo ir siempre a Code, pero no siempre es lo mejor. Por ejemplo, para poner una Intranet estándar a un cliente y que empiece a ganar cultura de colaboración en SharePoint, no veo necesario la inversión en una solución de código o para implementar la capa de presentación de Business Intelligence.

Cuando ya tenemos claro que vamos a implementar código por cuestiones de desarrollo de lógica de negocio, personalizaciones que necesitan código o ALM, tenemos que decidir entre una SharePoint Solution o una SharePoint App.

La recomendación de Microsoft es siempre implementar una Aplicación y el principal motivo es la compatibilidad con SharePoint Online. En el camino de Microsoft y sus productos hacia la nube no hay plan para soportar las Soluciones de SharePoint, salvo que sean Soluciones de tipo SandBox.

Yo no estoy del todo de acuerdo. El camino hacia la nube es largo y SharePoint hace muchas cosas bien pero necesita de algunos cambios para implementar las reglas empresariales que los usuarios requieren y, de momento, eso sólo se puede hacer con una Solución. El Modelo de Objetos de Cliente nos limita en ciertas funcionalidades que son necesarias y el modelo de desarrollo de Aplicaciones no nos ofrece todas las herramientas para extender la plataforma ya que su entorno de ejecución es, por defecto, aislado de SharePoint, por esto en ENCAMINA hemos rediseñado nuestro propio modelo de Aplicación.

A la hora de elegir entre Solución o Aplicación, yo tendría las siguientes premisas:

  • Si tenemos un SharePoint Online, prácticamente está claro que tenemos que ir al modelo de Aplicación. Aunque se pueden implementar cosas con SandBox Solutions o inyectando JavaScript en SharePoint Online, con las SandBox estaremos muy limitados y con el segundo no tengo claro que sea un buen modelo de desarrollo e implementación.
  • Para una gestión documental que necesita lógica de negocio, para establecer procesos de ECM o soluciones Records Management, esto tiene que ser una Solución. Entre las bondades de SharePoint podemos incluir la gestión documental, los tipos de contenidos, la gestión de registros, lo que se llama ECM. Si elegimos hacer una aplicación podemos perder estas funcionalidades que SharePoint ya hace o tendremos que reinventar cosas en nuestro código.
  • Si necesitamos datos relacionales o grandes cantidades de filas en las listas, no te lo pienses, esto es si o si una Aplicación. SharePoint no es una base de datos relacional, y, aunque lo he visto gestionar millones de filas en una lista, no es lo recomendable.
  • Cuando hablamos de LOB (Line of Business) o de poner soluciones departamentales en la Intranet, en un 90% deberíamos de elegir una Aplicación. El otro 10% lo podemos dejar para pequeños Web Parts con consultas a datos externos o funcionalidades que podemos soluciones implementando Business Conectivity Services.

Con todo esto, hay que tener en cuenta que un desarrollador de SharePoint, además de conocer SharePoint (IT y Desarrollo) tiene que tener la siguiente foto en su curriculum:

¿Con que modelo te quedas? Yo me quedo con los dos porque nos permite garantizar el éxito de los proyectos y la satisfacción de los clientes implementando el más adecuado para cada caso.

 

Saludos a todos…

SharePoint 2013. Aprovechando las capacidades de búsqueda

Como ya hemos hablado en otros artículos del blog y de CompartiMOSS, el servicio de búsqueda de SharePoint 2013 ha tomado una relevancia fundamental en la construcción de los sitios y de aplicaciones dirigidas por la búsqueda o Search-Driven Application, gracias al API del servicio de búsqueda y a un nuevo Web Part de búsqueda de contenido.

Con el modelo de objetos de cliente y/o al servicio REST de búsqueda se puede implementar aplicaciones en SharePoint o fuera de SharePoint que consulten y muestren el contenido de una forma muy sencilla, como hemos hecho en las aplicaciones móviles de la revista CompartiMOSS.

El Web Part de Búsqueda de Contenido permite crear consultas del contenido de un sitio y aplicarle una plantilla de visualización con HTML y JavaScript, con el consiguiente ahorro en la implementación de Web Part personalizados para mostrar la información de nuestros sitios.

Si analizamos el sitio de CompartiMOSS.com, el 90% de las páginas se generan con este Web Part, consultando el contenido y aplicando la plantilla de visualización adecuada para cada caso, por ejemplo, este mes hemos empezado a mostrar publicidad en la página principal con un pequeño banner, que hemos hecho de la siguiente forma:

  • Creamos una biblioteca de imágenes donde alojaremos los banner con los campos Fecha Inicio y Fecha Fin de la publicidad

 

  • Añadimos estas columnas al esquema de búsqueda del servicio de búsqueda y realizamos un rastreo para que podamos realizar consultas de búsqueda utilizando esas propiedades.
  • En la página de inicio, añadimos el Content Search Web Part (Elemento web de búsqueda de contenido) con la consulta específica para que nos devuelva las imágenes de la biblioteca BannerHome que no estén caducadas (esta consulta es del tipo KQL)

 

  • Nos creamos un Display Template o plantilla de visualización específico para mostrar los banners, en este caso hemos usado nivo slider, y se lo aplicamos en el Web Part.

 

Listo, el resultado se puede ver en la página de CompartiMOSS.

 

Sin apenas escribir líneas de código para desarrollar un Web Part, hemos puesto en funcionamiento un banner, consultando contenido y aplicando una plantilla de visualización con JavaScript y HTML, y todo gracias al servicio de búsqueda SharePoint y a las funcionalidades que ya implementa la plataforma.

 

Saludos a todos…

Evento. Se acerca la European SharePoint Conference 2014

Quedan menos de tres semanas para la conferencia Europea de SharePoint que este año se celebra en Barcelona del 5 al 8 de mayo.

Un evento que no te puedes perder si te dedicas al mundo de SharePoint con sesiones sobre la plataforma, el mundo de aplicaciones y las API o el nuevo Office Graph (Oslo para los amigos).

Este año, nos han ofrecido la oportunidad de dar un sesión y junto con Juan Carlos Gonzalez os hablaremos sobre el interesante y nuevo mundo de las Aplicaciones de SharePoint, en la sesión «SP Apps, New Dev Model, New App Store: The Office Store».

La idea es mostrar las posibilidades que nos ofrece las Aplicaciones de SharePoint, que ventajas y desventajas tienen y porque ver la tienda como una posibilidad empresarial que hasta estos momentos no existía para el mundo de aplicaciones de Office y SharePoint.

 

Nos os perdáis esta oportunidad, son 4 días que incluyen 110 sesiones de los mejores Speaker de SharePoint y un área de exposición donde tendrás a más de 1000 desarrolladores, IT Pro, Consultores, usuarios de SharePoint listos para hacer mucho Networking.

Os esperamos….

Webcast. Segunda Charla con los expertos: Todo lo que quisiste saber sobre SharePoint, pero no te atreviste a preguntar

Desde SUGES y el resto de grupos latinoamericanos de SharePoint os proponemos una nueva edición de Charla con los Expertos de SharePoint de habla hispana el próximo 10 de abril a las 15:00 (horario de Londres). En esta ocasión como novedad tendremos un cambio de plataforma tanto a nivel de registro para el chat como para asistir el mismo:

Para el registro, accede a Eventbrite: http://charlasharepoint.eventbrite.com/?aff=blogadiaz

El Webcast será con Lync Online y para facilitar vuestra asistencia, gracias a nuestra compañera Vielka Rojas disponemos de un pequeño how-to para participar en la reunión utilizando Lync: http://vkrojas.wordpress.com/2014/02/26/como-atender-una-reunion-con-lync-web/

Preparen las preguntas que quedan 10 días para esta sesión.

 

SharePoint. Despliegue de una Single Page Application (SPA)

Una SPA o Single Page Application es una aplicación web que se ejecuta siempre en la misma página, buscando mejorar la experiencia del usuario que no sufre la navegación entre páginas o las tan odiosas recargas de página o Postback. Combinando HTML5, CSS y JavaScript se va renderizando el contenido, posiblemente pre-cargado, que el usuario solicita en cada momento de una forma más dinámica, sin necesidad de navegar o cambiar la URL base de acceso a la aplicación. Por si no os habéis dado cuenta, SharePoint 2013 usa este concepto, lo podemos ver cuando accedemos a un sitio de colaboración, la mayoría de los enlaces están bajo la URL start.aspx y no recargan la página, tan solo se renderiza el contenido que solicitamos.

La idea es ¿Por qué no usar este concepto de aplicación para implementar nuestras soluciones de SharePoint? Los desarrolladores de SharePoint siempre nos hemos quejado porque incluir buenas prácticas o patrones de diseño en nuestras soluciones es altamente complejo, pero no imposible, y os lo voy a demostrar.

Existen diversos Frameworks JavaScript que nos permiten implementar una SPA, como Knockout, Angular o Backbone. Por ejemplo, Backbone nos permite aplicar el patrón MVC (Modelo-Vista-Controlador) y es posible hacerlo en una Aplicación o Solución de SharePoint.

Para los que no conozcan este patrón, básicamente y de una forma rápida, distribuimos nuestro código en tres patas:

  • Modelo que representa los datos de dominio o la lógica de negocio
  • Vista que nos permite visualizar el modelo
  • Controlador que recibe las acciones del usuario y actualiza el modelo

 

Con Backbone es muy sencillo implementar el Modelo, las Vistas y el Controlador, que en Backbone lo representa las Rutas, empaquetar todo en un fichero JavaScript de aplicación y desplegarlo en SharePoint. Adiós a nuestro código espagueti y demos la bienvenida al maravilloso mundo del buen código.

Usando Backbone y el servicio REST de SharePoint seremos capaces de crear aplicaciones SharePoint y que nuestro código cumpla con los estándares actuales del mercado. Veamos un pequeño ejemplo:

Modelo

Item = Backbone.Model.extend({

defaults: function () {

return {

id: -1,

title: null

}

}

});

Vista

AppView = Backbone.View.extend({

 

el: $(«#app»),

 

events: {

«click #addItem»: «addItem»

},

 

addItem: function () {

var item = {

title: this.newItemName.val()

};

 

itemList.create(item);

 

this.newItemName.val(»);

},

 

initialize: function () {

this.newItemName = this.$(«#itemName»);

 

this.listenTo(this.model, ‘change’, this.render);

this.listenTo(this.model, ‘add’, this.render);

},

 

render: function () {

$(«#itemList»).html(«»);

if (this.model.length) {

for (var i = 0; i < this.model.length; i++) {

var view = new ItemView({ model: this.model.at(i) });

$(«#itemList»).append(view.render().el);

}

}

}

});

 

ItemView = Backbone.View.extend({

template: _.template($(‘#item-template’).html()),

 

initialize: function () {

this.listenTo(this.model, ‘change’, this.render);

this.listenTo(this.model, ‘destroy’, this.remove);

},

 

render: function () {

this.$el.html(this.template(this.model.toJSON()));

return this;

}

});

Controlador

var router = Backbone.Router.extend({

routes: {

»: ‘home’,

‘new’: ‘viewNew’

},

home: function () {

itemList = new ItemSet();

 

itemList.fetch({ data: { page: ‘no’ } });

 

var app = new AppView({ model: itemList });

app.render();

},

viewNew: function () {

 

}

});

Os recomiendo echar un vistazo al proyecto Backbone.SharePoint que añade una capa de abstracción entre SharePoint y nuestro modelo.

¿Cómo desplegar una SPA en SharePoint?

Tenemos varios modos de despliegue para este tipo de aplicaciones en SharePoint:

  • Mediante el nuevo modelo de Aplicación de SharePoint, en cualquiera de sus modos de alojamiento. La URL de acceso a la aplicación sería la URL de la Aplicación.
  • Con una página desplegada en el PageLayout de SharePoint. La URL sería http://sitio/_layouts/15/SPA/app.aspx
  • Con una página desplegada con un módulo en una biblioteca o en el root de SharePoint. Con una URL parecida a http://sitio/app.aspx o http://sitio/aplicaciones/app.aspx que desde el punto de vista del usuario, aparenta una mejor integración con lo que conoce como su SharePoint.

La idea es que el usuario acceda a una URL donde empezamos a hacer la magia y ejecutamos nuestra aplicación SPA mediante JavaScript, que utilicemos el servicio REST de SharePoint como back-end con los datos almacenados en listas o bibliotecas y que la experiencia de usuario sea similar a una aplicación de escritorio, tal como SharePoint 2013 implementa en algunos casos.

 

Saludos a todos…

NuGet. Repositorio local de paquetes

Desde hace ya algunas versiones de Visual Studio, tenemos una herramienta disponible, llamada NuGet, que nos permite administrar los paquetes de librearías de .NET, asociados a nuestro proyecto o solución de código.

Desde la consola de NuGet podemos buscar e instalar las librearías necesarias para el desarrollo de nuestra solución. Estas librearías pasan por agregar referencias a ensamblados, añadir ficheros JavaScript, plantillas de proyectos, y un largo y numeroso mundo de posibilidades. Estas librerías se obtienen, por defecto, del repositorio oficial nuget.org que mantiene la fundación Outercurve patrocinada por Microsoft, entre otras compañías que colaboran con las galerías de código abierto que gestionan.

Pero no nos quedemos sólo con este repositorio y aprovechemos el potencial que nos ofrece para publicar en un repositorio local las librearías que usamos en nuestros desarrollos. Si, esas librearías de acceso a datos, de gestión del Blob Storage de Azure o de consulta de SharePoint. ¿Por qué no las empaquetamos y las ponemos a disposición de todos los proyectos? De una forma simple, podríamos gestionar versiones, controlar requisitos, configuraciones, etc.

Este repositorio de paquetes NuGet puede ser una carpeta local o de red o un servidor de NuGet, como si del repositorio oficial se tratara. Por ejemplo, una opción muy válida sería tener una carpeta en TFS donde se publican los paquetes, con lo que cada desarrollador podría tenerla sincronizada y configurar el repositorio como carpeta local.

 

Para crear un paquete podemos utilizar la aplicación de NuGet.exe o un Explorador de Paquetes, con lo que nos podríamos plantear incluir en nuestro servidor de Builds la generación del paquete NuGet correspondiente a la versión actual de nuestra librearía, con un comando tan sencillo como:

nuget pack MyProject.csproj Prop Configuration=Release

Este comando, crea un paquete NuGet con los ensamblados y sus dependencias del proyect MyProject.csproj, pero deberíamos de pensar en más y en un paquete podemos incluir lo siguiente:

Al final, vamos completando nuestro repositorio local con las librearías más empleadas y manteniendo un control de versiones de la misma

 

Aprovechemos todas las ventajas que nos ofrece NuGet para gestionar nuestras librearías y las librearías de terceros. Con esto, cuando corrijamos un bug, tendremos una notificación de actualización, como las obtenemos del repositorio oficial, y mejoraremos nuestros procesos de desarrollo.

 

Saludos a todos…