sharepoint-2013-apps-nuevo-modelo-desarrollo.pdf

SharePoint 2013 Apps:el nuevo modelo de desarrollo

ADVERTENCIA LEGAL

Todos los derechos de esta obra están reservados a SolidQTM Press

El editor prohíbe cualquier tipo de fijación, reproducción, transformación o distribución de esta obra, ya sea mediante venta, alquiler o cualquier otra forma de cesión de uso o comunicación públi-ca de la misma, total o parcialmente, por cualquier sistema o en cualquier soporte, ya sea por foto-copia, medio mecánico o electrónico, incluido el tratamiento informático de la misma, en cualquier lugar del mundo.

La vulneración de cualquiera de estos derechos podrá ser considerada como una actividad pe-nal tipificada en los artículos 270 y siguientes del Código Penal.

La protección de esta obra se extiende al mundo entero, de acuerdo con las leyes y convenios internacionales.

© SolidQTM Press, 2012

ISBN: 978-84-940719-0-4

SharePoint 2013 Apps: el nuevo modelo de desarrollo

Serie SharePoint

Autores: José Quinto Zamora, Cristian Zaragoza, Guillermo Bas, Roberto Berná e Iván Paredes.

Prólogo: Daniel A. Seara.

Revisor técnico: Daniel A. Seara.

Revisión lingüística: Paco Marín.

Diseño y maquetación: Rocío Guerrero.

Imagen de cubierta: Ralph Bijker

Apartado de correos 202 03340 Albatera, Alicante, España http://www.solidq.com

Este e-Book está publicado con fines promocionales, no está permitida su venta.

http://www.flickr.com/photos/17258892@N05/

http://www.solidq.com

Cloud App Model 12Herramientas de desarrollo 14Visio 2013 14SharePoint Designer 2013 16Visual Studio 2012 20Proyecto NAPA 23Mayor uso de los estándares web 24Más tipos de aplicaciones 25Representación del lado del cliente (Client-side render-ing) 26Novedades en las API 27Integración de mapas y geolocalización 27Características Sociales 29Comunidades (Communities) 29Flujos de trabajo (Workflows) 33Servicios de conectividad empresarial (Business Connectivity Services) 33Búsqueda empresarial 38Dispositivos móviles 44

Interfaz gráfica 44Office Web Apps en móviles 45Notificaciones y alertas desde listas de SharePoint 45Contenido de inteligencia de negocio desde iPad 46Geolocalización en aplicaciones móviles 46¿Cómo se desarrollan aplicaciones de Windows Phone para SharePoint 2013? 46ECM (Enterprise Content Management) 47eDiscovery 47WCM (Web Content Management) 50Gestor de diseño (Design Manager) 50Sitios dirigidos por las búsquedas 51Catálogos y publicación entre colecciones de sitios 53Mejoras en SEO (Search Engines Optimization) 54Cambios en multimedia 54Navegación administrada (metadatos administrados) 54Otras novedades 55Nuevas aplicaciones de servicio 55Novedades en inteligencia de negocio para SharePoint 2013 55Conclusiones 56

Introducción. El desarrollo sobre SharePoint a lo largo de los tiempos 57SharePoint 2013 y su nuevo modelo de aplicaciones 59¿Cuándo usar soluciones y cuándo aplicaciones? 61El Office Store 62Tipos de SharePoint App. Visualización y funcionalidad 65

Página completa (Immersive Full Page) 65Parte de página (App Part) 66Acción personalizada (UI Custom Action) 68Tipos de SharePoint App. Opciones de alojamiento 69Apps alojadas en SharePoint (SharePoint-hosted Apps) 69Apps auto-alojadas (Autohosted Apps) 72Apps combinadas (Hybrid Apps) 73Resumiendo 75Conclusiones 76

ÍndiceCapítulo 1. Novedades en SharePoint 2013

Capítulo 2. Introducción a las SharePoint Apps

Mi primera app 77Introducción 77Preparación del entorno de desarrollo 78¡Hola Mundo! 88Maquetación y diseño de apps 105

Introducción 105Cloud-hosted Apps 142Modelo de objetos de cliente y API REST en SharePoint 2013 150API REST en SharePoint 2010 155API REST SharePoint 2013 156Ejemplos de uso de las API 161Conclusiones 176

Instalando aplicaciones desde el Office Store 177Administración de aplicaciones instaladas 185El catálogo de aplicaciones (App Catalog) 187Conclusiones 189

Capítulo 3. Desarrollo de SharePoint Apps

Capítulo 4. Instalación y administración de SharePoint Apps

Plataforma de desarrollo en la Nube – Introducción a Microsoft Napa 190Navegadores soportados 192Instalando y ejecutando NAPA por primera vez 193Conclusiones 201Eventos en SharePoint 2013 201Events Receivers Remotos 203App Event Receivers 207Conclusiones 208

Novedades de flujos de trabajo para SharePoint 2013 209Para el diseñador 209Para el desarrollador 209Para el responsable de IT 210Arquitectura 210Workflow Manager Client 1.0 211Windows Azure Service Bus 211Workflow Service Manager 212Instalación y configuración del entorno 212Interfaces de programación 217Conclusiones

Capítulo 5. Novedades influenciadas por las SharePoint Apps

Autores 218

Prólogo

P6

Prólogo

Estos últimos años, durante este nuevo milenio, muchas cosas han cambiado en la comu-nicación entre los seres humanos. La filosofía de las redes sociales ha terminado abarcando también gran parte de la tarea de sincronización de actividades y conocimiento intrínseco en las empresas.

Desde el punto de vista de la plataforma Microsoft©, el elemento fundamental que ha dado progresivamente soporte a esto es, indudablemente, SharePoint.

Las distintas versiones que conocemos, han evolucionado acompañando este proceso, desde un simple repositorio de documentos, hasta convertirse hoy, en la plataforma de elec-ción para almacenar, procesar y compartir toda la documentación de muchos procesos en las empresas.

No solo esto, se ha expandido para dar una visión pública de las mismas, a través de sus infraestructuras de publicación, ha facilitado la interacción con los datos de negocio hasta el punto de transformarse progresivamente en la “cara visible” de elección de los procesos de Inteligencia de negocio.

Y también, cómo, facilitando la interacción entre los miembros de las empresas, la facili-dad de localizar información pertinente entre todo lo disponible en las mismas, de una forma rápida, eficiente y clara para los usuarios y muchas cosas más.

Estamos en las vísperas de una nueva versión del producto, denominado ya SharePoint 2013.

Por supuesto, se han dedicado muchos esfuerzos en brindar más y mejores prestaciones. Y adaptando la plataforma al devenir de los tiempos, con mayor presencia en la Nube, incre-mentado el acceso a la información desde distintos dispositivos y demás exigencias propias de la evolución de la humanidad.

Esto hace que, evidentemente, los mecanismos de personalizar las implementaciones en SharePoint exijan cada vez más de sí, y requiera mayor integración con la plataforma.

Además, la apuesta va de cara a integrar cada vez más, por ejemplo, las aplicaciones de Office.

Y qué duda cabe que, en la relación costo-beneficio, cada vez son más las empresas que deciden llevar su implementación a entornos externalizados en la Nube, como es el caso de Windows Azure©.

Prólogo

P7

De todo esto se decanta que, obviamente, la forma de generar personalizaciones e inclu-sive implementar aplicaciones sobre la plataforma SharePoint 2013, requiere adaptaciones y mejoras.

Este libro, precisamente, realiza un recorrido completo de todas esas opciones, haciendo hincapié en las diversas integraciones, así como en la comparación con las formas previamente existentes.

Los cambios por venir son realmente importantes, al punto que algunas cosas dadas como novedosas en la versión actual, podrían considerarse casi obsoletas en esta nueva por venir.

Partiendo de colaboraciones directas con el equipo de producto que el grupo que tengo el honor de dirigir y yo mismo hemos mantenido durante todo el proceso de diseño y creación de esta nueva versión, nos hemos decidido, ahora que ya es de conocimiento público, dar un fundamento adecuado a todos aquellos interesados en implementar soluciones para la nueva versión de Office y SharePoint, tanto en instalaciones de los usuarios, como en línea (“en la Nube” que puedo asegurarte que no se cae). Si te lees el libro enterito, vas a entender como es el tema en la nueva versión.

Desde ya aclaro que no vas a tener ejemplos complicados (espero que los pidan, así con-venzo al equipo a expandirse en muchos más detales), aunque sí puedo asegurarte que vas a entender perfectamente “lo que vendrá” con el desarrollo de apps de SharePoint.

Y no quiero cerrar este prólogo sin reforzar un concepto que escribí previamente:

Es para mí un verdadero honor guiar en lo esencial los pasos de esta pandilla de excelen-tes profesionales con los que comparto el día a día de nuestras tareas y proyectos en SolidQ. Definitivamente, no sería posible hacer todas las cosas que hacemos, y conseguir objetivos tan importantes, si su prestancia, profesionalidad, conocimiento, capacidad de progreso, genero-sidad, colaboración y compañerismo.

Un orgullo, Cristian, Guillermo, Iván, José, y Roberto.

“Dani” Seara

Madrid, un nublado día de octubre de 2012.

Prólogo

P8

Organización del libro

El objetivo de este libro es profundizar en el nuevo modelo de desarrollo de SharePoint, que pretende dar cabida a lo que llaman las SharePoint Apps. No obstante, dada la importancia del resto de novedades incluidas en SharePoint 2013, no hemos querido perder la oportunidad de hacer un repaso de ellas, profundizando un poco en aquellas que hemos considerado más importantes.

En el capítulo 1 del libro veremos las novedades referentes a SharePoint 2013 separadas por categorías. Este capítulo pretende que el lector tenga una visión general de todas las novedades sin profundizar mucho en ellas, pero sí explicando claramente y con ejemplos y diagramas aquellas novedades que no son tan fáciles de entender, como por ejemplo, toda la parte de eDiscovery.

En el capítulo 2, veremos una introducción a las SharePoint Apps, cuyo objetivo es sentar las bases y explicar los porqués de un nuevo modelo de desarrollo.

En el capítulo 3, profundizaremos en el desarrollo de las SharePoint Apps. Veremos desde una aplicación “hola mundo”, hasta los componentes más complejos a la hora de maquetar una app de SharePoint o de acceder a SharePoint 2013 desde una app mediante el modelo de objetos cliente y el API REST. Todos sabemos que la teoría en este tipo de desarrollos es muy bonita y se explica detallado en la mayoría de los recursos de MSDN, pero a la hora de la verdad, siempre hay cosas que no van como dice la teoría, sino como marcan los atajos o workarounds que los propios programadores vamos experimentando a base de golpes. Además todos los ejemplos montados se han pensado en términos del programador que parte desde cero.

En el capítulo 4, veremos los detalles de la instalación y administración de apps, es decir, como instalar una app del Office Store, capacidades de administración en base a licencias, permisos, etc. Además, comentaremos qué es el nuevo catálogo de aplicaciones de SharePoint 2013.

En el capítulo 5, entraremos más en detalle en aquellas novedades que, aún ya habiendo sido mencionadas en el capítulo 1, merecen un hincapié especial debido a su drástico cambio, en parte, influido por el nuevo modelo de SharePoint Apps. Estamos hablando de Microsoft NAPA, manejadores de eventos remotos (en inglés Remote Event Receivers) y la nueva arquitec-tura de los flujos de trabajo.

Prólogo

P9

Ejemplos de código

En este libro se han utilizado ejemplos de código fuente, concretamente para los capítu-los 3 y 5. Los lenguajes utilizados han sido HTML, JavaScript, CSS, C# y Visual Basic. Todos los ejemplos de código utilizan la versión Microsoft Visual Studio 2012 y pueden ser descargados desde las siguientes direcciones url:

http://www.solidq.com/sqj/books/Materials/Ejemplos-de-codigo-SharePoint-Apps.zip

Ante cualquier problema para descargar el código contacten con [email protected].

Preguntas y comentarios

Si tienes cualquier comentario o idea acerca de este libro o del material relacionado, o si tiene preguntas que no se responden en este libro, póngase en contacto con [email protected].

http://www.solidq.com/sqj/books/Materials/Ejemplos-de-codigo-SharePoint-Apps.zip

mailto:[email protected]



Capítulo 1. Novedades en SharePoint 2013 Preview

P10

A lo largo de la historia de SharePoint, ha habido cambios importantes, siempre respon-diendo a las necesidades del mercado en cada momento.

Los primeros productos de Microsoft que se acotaron bajo el término “SharePoint” fue-ron SharePoint Team Services (STS) y SharePoint Portal Server 2001 (codename Tahoe). El equipo de SharePoint Team Services se encargaba de ayudar a los equipos de trabajo a com-partir información rápida y fácilmente. Por su parte, SharePoint Portal Server 2001 ofrecía capa-cidades de búsqueda, gestión documental y personalización, pero como a todas las primeras versiones, le faltaba mucho por hacer.

Estos dos sistemas, aunque eran muy útiles resolviendo sus funciones, estaban poco inte-grados. Motivo por el cual, después de importantes quejas de los clientes, en el año 2002 estos dos equipos se unieron para proporcionar una plataforma común. Como resultado, ofrecieron al mercado un conjunto de dos productos: Windows SharePoint Services 2.0 que era la edi-ción gratuita (licencia de Windows Server) y SharePoint Portal Server 2003. Se hizo un redi-seño de la arquitectura con los objetivos principales de poner SQL Server 2000 como sistema de almacenamiento y ASP.NET como plataforma de desarrollo, con lo que todo esto conlleva: Master Pages, Web Parts, etc.

Paralelamente al equipo de SharePoint existía el equipo de Microsoft Content Management Server 2002 que se dedicaba principalmente a gestión de contenidos web. En

11


2004, ante la petición de muchos de sus clientes, decidieron unir también estos dos equipos, surgiendo el producto Microsoft Content Management Server Connector for SharePoint Technologies (codename Spark), que integraba algunas funcionalidades de SPS 2003 y MCMS 2002, como por ejemplo, poder utilizar el motor de búsquedas de SPS en MCMS. Spark fue solamente un parche, ya que no proporcionaba una plataforma común. Fue cuando, en octu-bre de 2006, Microsoft hizo el lanzamiento de Windows SharePoint Services 3.0 y Microsoft Office SharePoint Server 2007. SharePoint 2007 tuvo un tremendo éxito con cerca de 100 millones de licencias vendidas. Con SharePoint 2007 se introducen muchas capacidades y se transforma el concepto de SharePoint de ser un sistema de portales y sitios de equipos de trabajo a ser un portal de colaboración de negocio en el que se integran capacidades de: cola-boración, portal, búsqueda, gestión de contenido, formulario de negocio, flujos de trabajo e integración con Inteligencia de negocio.

Dado el éxito de SharePoint 2007, Microsoft siguió apostando por cada uno de los pilares o capacidades (workloads en inglés) mejorándolos paralelamente. En 2007, adquirió Dundas que son componentes de visualización avanzada, y en 2008, adquirió Powerset y FAST ESP, dos empresas dedicadas a la búsqueda empresarial, la segunda de las más importantes del mercado en el momento.

En mayo de 2010, fue cuando Microsoft hizo el lanzamiento de SharePoint 2010, que mejoraría y rediseñaría las capacidades de la versión anterior. La versión gratuita, en este caso, se llamaría SharePoint Foundation 2010 (SPF 2010) y la versión de pago SharePoint Server 2010 (SPS 2010). En SharePoint 2010, se introduce la experiencia de usuario amigable (Ribbon UI), se mejoran las capacidades de multi-navegador y dispositivo, viendo la evidente tendencia del mercado, además de utilizar AJAX para mejorar la experiencia del usuario. Además, en esta versión se convierte Groove en SharePoint WorkSpace permitiendo usar SharePoint en modo offline. Otra gran mejora es Office Web Apps, que nos permite ver y editar documentos de Office directamente en el navegador. También se invierte mucho en mejorar las características sociales: My Site, manejo de perfiles, conexión entre personas, etc. En cuanto a conexión con sistemas externos, nacen los BCS (servicios de conectividad empresarial), que nos permiten enlazar con fuentes externas en modo lectura y escritura. Sin olvidarnos de todas las ventajas para desarrollador: REST, ATOM, JSON, LINQ, depurar con [F5], etc.

Esto es el estado del arte del producto SharePoint hasta su versión actual, SharePoint 2010. No obstante, el 16 de Julio de 2012 sale la primera beta pública de SharePoint 2013, llamada

12


SharePoint 2013 Preview. Además, el día 24 de Octubre de 2012 salió la versión RTM en el sitio de MSDN, descargable únicamente para aquellos desarrolladores con subscripción con suficientes derechos. Microsoft anunció que la disponibilidad general de SharePoint 2013 sal-dría el Q1 de 2013.

A todo esto, se añade el cambio de logos y branding que está ejecutando Microsoft en todas sus áreas siguiendo el diseño novedoso de Windows 8, la que lleva a un cambio de logo en SharePoint también:

SharePoint 2013 trae muchas novedades también en todas las capacidades o workloads, siendo dos de los ejes centrales, la Nube y el contenido social. Este capítulo pretende dar una visión a alto nivel de estas novedades. Con esto conseguimos que aquellos que disponemos de menos tiempo para leer densas documentaciones podamos fácilmente conocer qué trae esta nueva versión y cómo podemos aprovecharlo para nuestra rutina diaria.

Los desarrolladores web estamos de suerte, dado que con SharePoint 2013 vienen buenas noticias, ya que Microsoft cada vez está centrando más atención en HTML, CSS y JavaScript, tanto para desarrollos sobre el propio SharePoint 2013 como para el resto de productos de Office 2013 a través de las Office Apps (aplicaciones tipo complemento -addin- para Office 2013). Debido a ello, surgen nuevos tipos de componentes o aplicaciones sobre SharePoint llamadas SharePoint Apps. Para aclarar, esta nueva forma de crear aplicaciones no elimina la tradicional forma de crear soluciones SharePoint mediante Soluciones de granja o Sandbox, sino que añade más posibilidades. En esta sección del libro nos centraremos en novedades de desarrollo a más alto nivel y no entraremos muy en detalle en las SharePoint Apps, puesto que el resto de los capítulos del libro se centran exclusivamente en las apps, incluyendo desarrollo, gestión y publicación en MarketPlace (Office Store).

Veamos a continuación una relación de las novedades para el desarrollador en SharePoint 2013.

http://blogs.office.com/b/office-news/archive/2012/10/11/office-reaches-rtm.aspx

13


Cloud App Model

Tal como comentaba, en SharePoint 2013 se introducen las SharePoint Apps y con ellas un nuevo modelo de desarrollo de aplicaciones. Es decir, que en SharePoint 2013, tendre-mos dos opciones a la hora de desarrollar aplicaciones, podremos generar Soluciones (wsp) o Aplicaciones (app).

Figura 1-1. Opciones de desarro-llo en SharePoint 2013

Estas opciones también se verán reflejadas como plantillas de proyectos distintas en Visual Studio 2012:

Figura 1-2. Plantillas de desarrollo para SharePoint 2013 en Visual Studio 2012

14


Las SharePoint Solutions son las soluciones tradicionales de SharePoint que pueden crearse con Visual Studio para extender nuestras aplicaciones web con funcionalidad adicional. El con-cepto de SharePoint App es nuevo, pero la idea es similar, dotar a SharePoint de funcionalidad adicional, aunque en este caso se rediseña el paradigma con los siguientes objetivos:

- Proporcionar un alto nivel de aislamiento en las aplicaciones, puesto que no tienen por qué vivir en SharePoint. Pueden estar alojadas y consumir recursos de otros servidores (IIS, Azure, etc.).

- Facilitar la instalación y actualización de aplicaciones a los usuarios, ya que las SharePoint Apps se adquieren vía MarketPlace a través del SharePoint Store (público) o del App Catalog (privado).

- Solventar una única necesidad de negocio. La finalidad de las apps es de solventar una necesidad específica de los usuarios, no de hacer una mega aplicación que se encarga de todo.

No obstante, se podrán crear cualquiera de los dos tipos de aplicaciones para SharePoint 2013.

En los siguientes capítulos de éste libro, hablaremos más en detalle de este nuevo modelo de desarrollo, ya que es nuestro objetivo principal.

15


Herramientas de desarrollo

Comenzando por el más básico, debido a que está más orientado a usuarios de negocio que a desarrolladores, tenemos a Visio, después a SharePoint Designer, que está orientado a usuarios más técnicos y a Visual Studio, que ya está orientado a desarrolladores puros. No olvi-demos el proyecto NAPA, que es como un Visual Studio (simplificado y limitado a SharePoint Apps) pero embebido en una página web. Comentaremos en este módulo estos 4 productos para el desarrollo de componentes a medida en SharePoint 2013, dejando el proyecto NAPA en un capítulo aparte debido a su novedad y aplicación exclusiva para SharePoint y Office Apps.

Visio 2013

Dentro del ámbito de SharePoint, se considera a Visio como una herramienta de desarrollo debido a que nos permite de forma visual e intuitiva crear flujos de trabajo (en inglés workflows) personalizados y después exportarlos a SharePoint Designer para poder añadir algunas accio-nes más avanzadas.

En Visio 2013 y SharePoint Designer 2013 se incluyen novedades en el desarrollo de flujos de trabajo, entre ellas nuevas Formas (Shapes) que representan Etapas (Stages), Bucles (Loops) y Pasos (Steps). Dichas Formas, en versiones anteriores de Visio, no estaban disponibles. Por el nombre se puede intuir un poco la funcionalidad que desempeñan estos tres nuevos compo-nentes. El objetivo del libro no es avanzar en este tema sino introducirlo; para más información sobre workflows de SharePoint 2013 en Visio 2013, véanse los siguientes enlaces:

Workflow development in SharePoint Designer 2013 and Visio 2013.

Shapes in the SharePoint Server 2013 workflow template in Visio 2013.

http://msdn.microsoft.com/en-us/library/sharepoint/jj163272(office.15)

http://msdn.microsoft.com/en-us/library/sharepoint/jj163272(office.15)

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

16


Figura 1-3.Plantilla de SharePoint 2013 Workflow en Visio 2013

Figura 1-4. Menú de formas (shapes) para flujos de trabajo de SharePoint 2013 dentro de Visio 2013.

17


SharePoint Designer 2013

En SharePoint Designer 2013 (SPD 2013) el primer cambio que observamos al instalarlo y ejecutarlo es el logo:

Figura 1-5. Logo de SharePoint Designer 2013

En esta parte, tenemos noticias para aquellos que nos dedicamos a aplicar diseños en SharePoint. Parece ser que Microsoft no considera apropiado SharePoint Designer para aplicar “branding”, de hecho, siendo así, yo no considero apropiado el nombre del producto “SharePoint Designer”. Y esto no quiere decir que SPD esté en peligro de extinción, ha habido cambios y mejoras en el producto, pero mucho más orientadas del lado de los flujos de trabajo. Veamos una serie de mejoras que se han introducido:

1. Desaparece la vista de Diseño para HTML

Han quitado la vista de Diseño dentro del editor web de SPD 2013, por lo que ahora solamente tenemos la posibilidad de editar páginas maestras, diseños de pági-nas, etc., con vista de código. Más información: SharePoint Designer 2013’s missing design view y SharePoint Designer 2013 Design View is Gone!

2. Crear flujos de trabajo basados en el nuevo .NET 4.x Workflow Infrastructure (SharePoint 2013 Workflows)

También se mantendrá la compatibilidad hacia atrás para poder crear y editar flujos de trabajo de SharePoint 2010.

http://social.technet.microsoft.com/Forums/en-US/sharepointitpropreview/thread/8f8e2cb3-a90f-4653-9d22-050f9f0d8612

http://social.technet.microsoft.com/Forums/en-US/sharepointitpropreview/thread/8f8e2cb3-a90f-4653-9d22-050f9f0d8612

http://blog.sharepointelearning.com/sharepoint-designer-2013-data-view-web-part-list-view-web-part-design-view-is-gone/

18


Figura 1-6. rear flujo de trabajo para SharePoint 2013 desde SharePoint Designer

Nota. Si no ves la opción de SharePoint 2013 Workflow al crear un nuevo flujo de trabajo en SPD 2013 es porque no tienes configurado Windows Azure Workflow en la granja de SharePoint 2013. Recuerda que este com-ponente no se instala con SharePoint 2013; hay que instalarlo aparte. Más información: Instalación y configuración de flujos de trabajo para SharePoint Server 2013.

3. Integración con Etapas (máquinas de estados)

Los flujos de trabajo hasta ahora debían crear actividades en serie. Ahora los flujos de trabajo de SharePoint 2013 podrán implementar máquinas de estados, es decir, podrán saltar de un estado a otro dependiendo de ciertas condiciones, incluso lle-gando a una etapa anterior.

http://technet.microsoft.com/es-es/library/jj658588(v=office.15).aspx

http://technet.microsoft.com/es-es/library/jj658588(v=office.15).aspx

http://es.wikipedia.org/wiki/M%C3%A1quina_de_estados

19


Figura 1-7. Máquina de estados finitos para los flujos de trabajo de SharePoint 2013

4. Visual Designer (Integrado en SPD 2013)

Cuando desarrollamos flujos de trabajo en Visio, tenemos disponible un editor visual mediante el que podemos usar figuras (shapes) directamente arrastrándolas y soltán-dolas. En el caso de SPD 2013, y solamente para desarrollar workflows de SharePoint 2013 (no para los de SharePoint 2010), tenemos integrado el Visual Designer de Visio dentro de SPD. Normalmente desde el Visual Designer se introducen las etapas de la máquina de estados y desde el diseñador, en modo sentencias declarativas “Sentence-Style”, introduciremos las acciones como lo hemos hecho siempre.

5. Invocar HTTP (REST) Web Services

Existe una acción que nos permite invocar a un servicio web REST por HTTP de forma gráfica. Ejemplo de uso (en inglés): How to work with web service using “Call HTTP Web Service” action in SharePoint Designer 2013.

http://blogs.msdn.com/b/sharepointdesigner/archive/2012/09/05/how-to-work-with-web-service-using-call-http-web-service-action.aspx

http://blogs.msdn.com/b/sharepointdesigner/archive/2012/09/05/how-to-work-with-web-service-using-call-http-web-service-action.aspx

20


6. Soporte a copiar y pegar

Una de las características más solicitadas, sobre todo a nivel de diseño de flujos de trabajo, es poder copiar y pegar ciertas acciones ante procesos repetitivos. Ahora ya está soportado. Más información (en inglés): Copy-and-Paste support in SharePoint Designer 2013.

7. Loops

Por fin se pueden hacer bucles en los flujos de trabajo mediante la inclusión de una actividad navita.

8. Iniciar Workflows de SharePoint 2010

Nueva acción que permite invocar a los workflows de 2010 desde uno de 2013. De este modo se aumenta la compatibilidad hacia atrás.

9. Mejorado el editor de correo electrónico (formato enriquecido)

10. Variables de tipo Diccionario

Podremos crear variables para almacenar vectores o arrays de valores, combinando esto con la nueva acción de Loop podremos alcanzar muchos más escenarios.

Para más información sobre SharePoint Designer, recomiendo mirar directamente en el blog del equipo de producto: SharePoint Designer Team Blog.

http://blogs.msdn.com/b/sharepointdesigner/archive/2012/08/10/copy-and-paste-support-in-sharepoint-designer-2013.aspx

http://blogs.msdn.com/b/sharepointdesigner/archive/2012/08/10/copy-and-paste-support-in-sharepoint-designer-2013.aspx

http://blogs.msdn.com/b/sharepointdesigner/

21


Visual Studio 2012

Cada equipo de producto de Microsoft trabaja en paralelo para intentar mejorar día a día, por esto es que el 12 de septiembre de 2012 fue el lanzamiento oficial de Visual Studio 2012 y, claro, en lo que a los desarrolladores SharePoint nos afecta hubieron novedades tanto para SharePoint 2010 como para SharePoint 2013 . Veamos primero aquellas novedades que aplican a ambas versiones de SharePoint y dejemos para el final las herramientas para desarrollo de SharePoint Apps, que solamente afectan a SharePoint 2013.

1. Diseñador de listas y tipos de contenido

Cuando creamos nuevas listas o tipos de contenido desde Visual Studio (a través de “Nuevo Elemento...”) ahora ya no tenemos que pelearnos con unos ficheros XML tediosos y difíciles de entender; han hecho un gran trabajo con el diseñador visual para esto, véase en la imagen:

2.

Figura 1-8. Diseñador de listas y tipos de contenido en SharePoint 2013.

Crear columnas de sitio

Tenemos disponible un nueva plantilla (Item Template) para la creación de colum-nas de sitio.

3. Crear Web Parts de Silverlight

Nueva plantilla que nos facilita la creación de Web Parts para Silverlight.

22


4. Publicar soluciones SharePoint en servidores remotos

Esto es desde Visual Studio tener la capacidad de desplegar en otros servidores. Más información: Cómo: Implementar, publicar y actualizar una solución de SharePoint en un servidor remoto.

5. Utilizar herramientas de generación de perfiles para medir el rendimiento de SharePoint

Estas herramientas nos permiten observar y grabar el comportamiento en cuanto a rendimiento detectando: posibles cuellos de botella, código ineficiente, fallos de liberación de memoria, etc.

Para ver ejemplos y más información sobre esto vea estas páginas:

- Analizar el rendimiento de la aplicación mediante las herramientas de generación de perfiles.

- Generar perfiles de rendimiento de aplicaciones de SharePoint.

6. Crear Sandboxed Visual Web Parts

En SharePoint 2010 no se permitía crear de forma fácil un Visual Web Part con una SandBoxed solution, ahora ya existe plantilla para ello.

7. Intellisense y depuración para JavaScript

Han mejorado mucho la depuración en JavaScript, para ver más información: Depurar soluciones de SharePoint.

http://msdn.microsoft.com/es-es/library/hh370987


http://msdn.microsoft.com/es-es/library/z9z62c29

http://msdn.microsoft.com/es-es/library/z9z62c29


http://msdn.microsoft.com/es-es/library/ee231550.aspx

23


Además de todas estas novedades, para poder desarrollar las nuevas SharePoint Apps (que aplican solamente a SharePoint 2013) vamos a necesitar Visual Studio 2012. Pero no es suficiente con VS 2012 de base, sino que tenemos que instalar las Microsoft Office Developer Tools for Visual Studio 2012 (descarga desde aquí). Estas herramientas nos proporcionan plantillas para facilitarnos la creación de aplicaciones de Office 2013 y SharePoint 2013:

Figura 1-9. Plantillas de Visual Studio 2012 para SharePoint 2013 Apps.

Debemos tener en cuenta que para poder instalar estas plantillas de desarrollo es reque-rida cualquiera de estas versiones de Visual Studio: Ultimate, Premium o Professional.

Además, si nos preguntamos, ¿podemos desarrollar SharePoint Apps con Visual Studio 2010? La respuesta es no. Con VS 2010, podremos desarrollar soluciones de granja y sandbox como lo veníamos haciendo para SharePoint 2010, pero en este caso para 2013.

http://msdn.microsoft.com/es-es/library/ee231550.aspx

24


Proyecto NAPA

No vamos a entrar muy en detalle, puesto que tenemos una sección dedicada a ello en el capítulo 5 de este mismo libro, pero es un IDE de desarrollo web. Ahí lo dejo.

Figura 1-10, Proyecto NAPA. Entorno de desarrollo en la Nube.

25


Mayor uso de los estándares web

Con SharePoint 2013, se abre la posibilidad de crear aplicaciones de SharePoint a un mayor ámbito de desarrolladores no acostumbrados a la tecnología Microsoft. De hecho, para desa-rrollar las nuevas SharePoint Apps se utilizarán las tecnologías HTML, CSS, JavaScript, REST, OData, OAuth, etc.

El hecho de que una SharePoint App se ejecute en un iFrame independiza a ésta del con-texto de SharePoint, por lo que pasa a ser una aplicación remota. Como toda aplicación remota, para poder realizar la comunicación con el propio SharePoint, se realiza o bien a través de REST o de Client Object Model. Con esto, se consigue que en cualquier plataforma y/o tecnología web se pueda desarrollar una aplicación para SharePoint 2013. Por ejemplo, imaginemos una aplicación de gestión de vacaciones realizada con PHP, la cual queremos integrar en SharePoint. Ahora es posible simplemente usando el modelo de objetos cliente para toda la comunicación con SharePoint; el resto de componentes de la aplicación funcionarían tal cual estaban (pre-sentación, navegabilidad entre formularios, etc.). Véase en la imagen las posibles opciones de acceso a datos desde una app hacia SharePoint.

Figura 1-11. Posibilidades de desarrollo de aplicaciones cliente en SharePoint 2013.

Ahora no entraremos más en detalle en las tecnologías mencionadas, pues al tratarse de un libro de desarrollo se va a profundizar sobre cada uno de estos puntos más adelante. Por adelantar un poco, cabe mencionar que hay muchas novedades en la parte de REST y modelo de objetos cliente.

26


Más tipos de aplicaciones

Con SharePoint 2013 podemos desarrollar más tipos de aplicaciones que anteriormente. Hagamos una categorización dependiendo de las herramientas usadas para crearlas, de los modelos de programación utilizados, de los métodos usados para empaquetarlas, desplegar-las y publicarlas, y los dispositivos en los que se ejecutan.

- SharePoint Apps (el tipo de aplicaciones en el que se centra este libro). Son soluciones independientes para realizar tareas pequeñas. Los usuarios pueden descargarlas e instalarlas directamente desde un catálogo público llamado App Store. Pueden incluir componentes básicos de SharePoint como: listas, páginas, Web Parts, flujos de trabajo, tipos de contenido, etc. Se pueden ejecutar en un servidor externo (Azure u otros).

- Sitios de publicación. En SharePoint un sitio de publicación nos sirve para hacer imple-mentaciones de webs públicas. Debido a esto, y a la cantidad de conceptos a asimilar en una web pública (SEO, branding, navegación, URL, usabilidad, etc.) se enmarcan la creación de sitios públicos como una tipo de aplicación propio dentro de SharePoint. Además en SharePoint 2013, hay bastantes novedades en este sentido, las cuales veremos más adelante.

- Soluciones de granja. Las soluciones de granja son los “.wsp” que ya conocemos. Es decir, aquellas soluciones que normalmente son un conjunto de Web Parts, y otras extensiones cuyo despliegue es realizado por una característica (feature) y que resulta en añadir ciertos ensamblados (DLL) a la GAC (Global Assembly Cache) del servidor frontal de SharePoint (o ser-vidores si hay más de uno). Para instalar este tipo de aplicaciones, se requiere hacer el desplie-gue directamente en el servidor. Las soluciones de granja permanecen igual en SharePoint 2013, salvo un detalle, ya que en SharePoint 2010 se podían desplegar con políticas CAS (Custom Access Security) asociadas y estas políticas son ignoradas en SharePoint 2013. Además, con la aparición de las SharePoint Apps aparecen ciertas recomendaciones sobre cuándo usar unas u otras, que las puedes ver en la sección de SharePoint Apps de este libro (capítulo 2).

- Soluciones Sandbox. Son también “.wsp” como las soluciones de granja, pero con un espacio aislado de ejecución y con una API más reducida. Además, se instalan a nivel de sitio sin requerir el acceso en el servidor para ello, simplemente subiendo el “.wsp” a la galería de soluciones del sitio de SharePoint. Debemos de tener en cuenta que según la documentación oficial de Microsoft las soluciones sandbox están marcadas como obsoletas en SharePoint 2013.

- Aplicaciones para móvil. Con SharePoint 2013, se abre el abanico de posibilidades en cuanto al acceso a SharePoint desde las aplicaciones móviles. En el caso de Windows Phone,

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

27


existe una API de cliente disponible para ello, y en el caso del resto de dispositivos móviles, se pueden usar los nuevos servicios REST/OData que incluyen mucha más funcionalidad ahora.

Representación del lado del cliente (Client-side rendering)

Una de las novedades en el núcleo de la plataforma SharePoint, y con el objetivo de dar soporte a una “rica” experiencia de usuario, es la funcionalidad llamada representación del lado del cliente client-side rendering.

Es un mecanismo que nos permite producir nuestra propia salida para ciertos controles que se hospedan en una página de SharePoint. Cuando decimos salida, nos referimos a que podemos utilizar nuestro propio HTML y JavaScript para definir la lógica y presentación de cierto control.

Un ejemplo es la construcción de un tipo de campo (field) personalizado al cual quere-mos asociarle una representación muy personalizada:

Figura 1-12. Característica de Client-side rendering.

28


Podemos ver un ejemplo completo: Cómo personalizar un tipo de campo con la repre-sentación del cliente.

Novedades en las API

Tal como comentábamos en el punto anterior, donde afirmábamos que SharePoint 2013 hace mayor uso de los estándares, también cabe decir que el equipo de SharePoint ha hecho un gran esfuerzo para ofrecer mucha de la funcionalidad que tiene en el modelo servidor, tam-bién por cliente, tanto en la API de cliente como en la API REST. Hay un apartado completo que habla sobre estas novedades en el capítulo 3 de este libro.

Integración de mapas y geolocalización

Por fin ha llegado, en SharePoint 2013 ya tenemos de forma nativa un tipo de columna (field type) para la geolocalización. Esto es algo que llevábamos implementando manualmente desde las primeras versiones de SharePoint.

Figura 1-13. Característica de Mapas en SharePoint 2013. Imagen obtenida de M;SDN.

Concretamente en un campo de tipo Geolocation podemos introducir coordenadas como valores decimales, tanto para la latitud como longitud, aunque también podemos configurarlo



29


de modo que obtenga las coordenadas del usuario actual directamente desde el navegador (siempre que implemente la API W3C de Geolocalización).

En esta integración tenemos dos factores a tener en cuenta:

1. Almacenamiento de coordenadas.

Como hemos comentado anteriormente, la forma en la que SharePoint almacena la infor-mación de las coordenadas es a través de un tipo de columna nuevo y esto a nivel de SQL Server queda representado con los nuevos tipos de datos geometry, geography y hierarchy ID, que requieren tener instalado SQLSysClrTypes.msi en el servidor de SQL Server. Para descar-garlo, podemos usar este paquete: Microsoft® SQL Server® 2008 R2 SP1 Feature Pack.

Nota. Es importante tener en cuenta que este tipo de columna no está habilitado de forma visual al añadir una nueva columna, para poder aña-dirlo a una lista lo deben hacer los desarrolladores vía código.

2. Representación gráfica de mapas:

En cuanto a la representación gráfica de los puntos geográficos, SharePoint 2013 utiliza los mapas de Bing, concretamente “Bing Maps Ajax control V7”. Además, tenemos un nuevo tipo de vista que es de tipo Mapa.

Nota. Para habilitar el mapa de Bing en nuestra granja de SharePoint 2013, debemos establecer la “clave” de Bing Maps o bien mediante modelo de objetos cliente o bien mediante PowerShell: Set-SPBingMapsKey –BingKey “<Enter a valid Bing Maps key>”

Más información aquí.

También debemos saber que se puede personalizar la representación gráfica del mapa usando la característica Client-side rendering que mencionábamos anteriormente.

http://www.microsoft.com/en-us/download/details.aspx?id=26728




30


Características Sociales

En la parte social, SharePoint ha mejorado mucho, y más que lo hará porque el 25 de junio de 2012 Microsoft compró la red social empresarial Yammer. Concretamente para SharePoint 2013 tenemos novedades en las dos áreas sociales Communities y My Sites.

Comunidades (Communities)

En SharePoint 2010 se podrían crear listas de discusión para crear algo parecido a un foro que permita debates entre los usuarios. En SharePoint 2013 sigue estando la lista de discusión, pero tenemos dos plantillas de sitio nuevas llamadas “Community Site” y “Community Portal”.

Community Site es la plantilla de tipo foro, tan deseada. Podremos organizar discusiones por categorías, tener moderadores, aplicar reglas, revisión de comentarios o crear insignias de talento para motivar a los usuarios. De forma automática, se genera una reputación en el contenido de los foros (cuando tiene más votos -típico like o me gusta-, es más respondido, o incluso es marcado como respuesta) y también habrá una reputación por miembro que será mayor cuanto más activo sea dicho miembro.

Community Portal es una plantilla para obtener un resumen de todas las plantillas Community Site, es decir, cuando tenemos muchos foros organizados en distintos sitios o colecciones de sitio, esta plantilla nos reúne información sobre todos los foros para que los usuarios puedan descubrirlos y unirse a ellos. Además, los sitios basados en esta plantilla utili-zan todas las características de búsqueda empresarial ofreciendo así una buena experiencia de usuario y un filtrado de seguridad, no permitiendo ver ciertos foros a aquellos usuarios que no tienen permisos para verlos.

http://www.microsoft.com/en-us/news/press/2012/jun12/06-25msyammerpr.aspx

31


Figura 1-14. Community Site en SharePoint.

32


My Sites

Llamamos My Sites a las características de SharePoint que nos permite tener un espacio privado como empleados, donde guardar nuestra información, añadir nuestras preferencias, añadir a compañeros a nuestra red de “colleagues” o compañeros, etc.

En SharePoint 2013, seguimos teniendo estos sitios pero la interfaz gráfica ha sido redise-ñada completamente, véase en la imagen:

Figura 1-15. My Site en SharePoint 2013.

Además, se han introducido dos nuevas características: “Microblog” y “Newsfeeds”, que convierten los My Sites en un entorno social muy parecido a Facebook y Twitter. Podremos hacer cosas que probablemente ya nos suenen a todos:

- Participar en conversaciones con nuestros amigos poniendo comentarios.

- Compartir imágenes y enlaces.

- Utilizar tags del estilo #palabra mediante las cuales los usuarios podrán buscar luego.

- Mencionar a gente con @nombre.

- Compartir, comentar y me gusta.

- Seguir a gente, documentos, sitios y etiquetas para personalizar nuestro newsfeed.

33


Como consideración a tener en cuenta, de forma predeterminada en SharePoint 2013, toda esta información se almacena en una biblioteca en el perfil de cada usuario (cada usuario almacena sus estados, comentarios, etc.) y además no se va eliminando la información según un umbral de días (como pasaba en SharePoint 2010). Por este motivo, hay que hacer la plani-ficación del espacio en disco que puede albergar todo esto.

Añadido a esto tenemos la nueva característica de “Compartir Contenido” que nos per-mite como usuarios compartir hasta nivel de ítem o documento con otros usuarios sin tener que llamar al administrador de seguridad o sin tener que conocer el modelo de seguridad de SharePoint. En los “My Site” se ha rediseñado la estructura y ahora no tendremos dos biblio-tecas, una privada y otra pública, sino que habrá solamente una y utilizando la característica de compartir contenido, podremos dar permisos a determinados usuarios para ver algunos contenidos. Además, esta biblioteca estará en las opciones de Office 2013 como sitio preferido para guardar información; para ello, Office 2013 tendrá un servicio de eDiscovery que permitirá descubrir si cierto usuario tiene disponible un “My Site”.

En cuanto a desarrollo, cabe mencionar que hay cambios en los espacios de nombres, así como algunos nuevos:

- Microsoft.Office.Server.ActivityFeed

- Microsoft.Office.Server.Audience

- Microsoft.Office.Server.Infrastructure

- Microsoft.Office.Server.Security

- Microsoft.Office.Server.Social

- Microsoft.Office.Server.SocialData

- Microsoft.Office.Server.UserProfiles

- Microsoft.Office.Server.WebControls

- Microsoft.Office.Server.WebControls.FieldTypes


34


También, al igual que en las demás áreas, el equipo de Microsoft ha hecho un gran esfuerzo para permitir que muchas de estas API estén disponibles también desde modelo de objetos cliente y/o REST. Concretamente, las áreas donde más esfuerzo han hecho implementando REST y CSOM son:

- Social Feeds (CreatePost, LikePost, GetAllLikers, GetMentions, GetFeed, etc.)

- Follow people (Follow, GetFollowers, GetFollowed, GetSuggestions, etc)

- Follow content (FollowedDocumentsUri, GetFollowed, etc.)

- User Profiles (SetMyProfilePicture, GetMyProperties, GetUserProfile, etc.)

Puesto que esto no pretende ser un libro de MSDN, para obtener más información sobre los métodos y propiedades disponibles para cada sección, puede visitar estos recursos: Novedades de los sistemas sociales en SharePoint Server 2013 y Características sociales y de colaboración en SharePoint 2013.

Además, en el capítulo 3 se hace un ejemplo donde se accede a la API de JavaScript.

Flujos de trabajo (Workflows)

En SharePoint 2013, se ha rediseñado completamente toda la infraestructura de flujos de trabajo con el doble objetivo de implementar Windows Workflow Foundation 4 y com-patibilizar estos flujos de trabajo con la Nube. Tanto es así, que el nuevo motor de flujos de trabajo que hasta ahora estaba dentro del propio SharePoint, ahora es un motor de ejecución aislado llamado Workflow Manager Client 1.0, lo que implica que la comunicación entre SharePoint y este motor se hará en base a protocolos como OAuth. Todo esto viene muy en línea de la aparición de SharePoint Online, ya que se pretende estandarizar de tal forma todos los componentes que funcionen de igual forma en SharePoint on-premise y online. Además, el nuevo modelo de SharePoint Apps también ha impulsado este cambio de arquitectura de los flujos de trabajo, para entre otras cosas permitir esta funcionalidad en las SharePoint Apps. No obstante, no pretendo avanzar más en este tema, puesto que en el capítulo 5 hay una sección exclusivamente sobre esto.

Servicios de conectividad empresarial (Business Connectivity Services)

Desde que conozco SharePoint, versión 2007 en adelante, he podido conectarlo con sis-temas o repositorios externos como SAP, ERP, CRM, Bases de datos y demás LOB (Line-Of-

http://technet.microsoft.com/es-es/library/jj219766(v=office.15)




35


Business Systems). Cuando digo conectarlo, dejo muy abierto el abanico de operaciones que se puede hacer sobre esa fuente externa de datos.

En SharePoint 2007, recuerdo que teníamos el BCD (Business Data Catalog) que nos permi-tía solamente leer datos desde sistemas externos y ofrecerlos a SharePoint a modo de campo de lista y también a través del indexador de SharePoint.

En SharePoint 2010 se introducen los BCS (Business Connectivity Services) que dan soporte también a la escritura en sistemas externos, además de los tipos de contenido externos, etc.

Ahora en SharePoint 2013, la nueva arquitectura de BCS es la que se muestra en la figura:

Figura 1-16. Arquitectura de BCS (Business Connectivity Services). Imagen obtenida de MSDN de Microsoft.

De esta imagen cabe destacar que existirá por una parte toda una arquitectura BCS en SharePoint 2013 (tal cual ocurría en SharePoint 2010, pero con mejoras) y además una pequeña infraestructura de BCS en Office 2013.

36


En cuanto al BCS de Office 2013, permite conectar a Office directamente con fuentes de datos externas sin tener un SharePoint por el medio. Sí que es verdad que a la hora de crear el modelo o solución de BCS, debemos asegurarnos de que es compatible con Office 2013, es decir, nos aseguramos que se implementa como lo que llaman “client-side solution”. Además, cuando instalamos Office 2013, de forma predeterminada se nos instala el Business Connectivity Services Client Runtime que se encarga de cachear (podemos trabajar offline) y sincronizar datos externos con Office 2013. No es objetivo de este libro entrar más en detalle en la parte de BCS y Office, pero se puede ver más información aquí.

En cuanto a la arquitectura BCS de SharePoint tenemos las siguientes novedades:

- Integración con las SharePoint Apps

Podemos crear un BCS en el ámbito de una SharePoint App. ¿Qué significa esto? Pues que ese BCS será creado y desplegado cuando instalamos la App, y será eliminado si la desinsta-lamos. Este tipo de modelo de BCS se llaman “SharePoint app-scoped external content type”. Una consideración a tener en cuenta es que el acceso a las fuentes externas definidas en este tipo de BCS estará limitado a esta app en particular.

- OData como fuentes de datos

En SharePoint 2010 se podía conectar desde fuentes WCF, .NET y SQL Server. Ahora, ade-más de estas tres, también se permite un origen OData. En cuanto a autenticación en el origen son soportados: Anónimo, Básica, Windows y usándolo conjuntamente con el Secure Store Service de SharePoint también se puede una autenticación personalizada.

Algunos ejemplos de servicios que pueden generar OData son:

SharePoint 2010

SQL Azure

Windows Azure Table Storage

Windows Azure Marketplace

SQL Server Reporting Services

Microsoft Dynamics CRM 2011

Windows Live

http://technet.microsoft.com/en-us/library/ee661740(v=office.15).aspx#section2

37


- Event Receivers remotos

Hasta ahora no se podían asociar Event Receivers a tipos de contenidos externos, pero en SharePoint 2013 sí que se podrá gracias al concepto de Event Receivers remotos. Dada la importancia de esto y dado que también puede servir como sistema de alertas ante cambios en las fuentes de origen, hay una sección en este libro exclusiva explicando en detalle este tipo de Event Receivers (capítulo 5.2). Aclaro que las alertas tampoco están permitidas en listas externas de SharePoint 2010.

- Mejoras en listas externas (External Lists)

Al igual que en la versión anterior, para poder mapear una base de datos con una lista de SharePoint, tendremos que crear el tipo de contenido externo y después crear la lista externa. Este tipo de listas tiene limitaciones en comparación con las listas normales de SharePoint. En la versión de 2013 han introducido una serie de mejoras:

• Mejor rendimiento en el renderizado de listas debido a que se realiza un paginado, filtrado y ordenamiento antes de obtener los datos. De este modo, vienen los datos ya ordenados, filtrados y solamente los de la página que toque. Me parece que esto debería de haber sido así desde el principio.

• Se puede establecer el límite de elementos que se muestran por página.

• Capacidad de filtrado en columnas avanzada. Con esto podemos definir a nivel de base de datos cómo queremos que sea el filtro, siempre que luego lo indiquemos en el BCD Model.

• Ordenamiento en las columnas. Se pueden definir ordenamientos que afectarán a todo el conjunto de datos y no solamente a los datos parciales obtenidos.

• Exportar a Excel. Se puede exportar una lista externa hacia Excel 2010 y 2013.

- BCS en SharePoint Online

En Office 365 para empresas, el módulo de SharePoint Online incluye BCS. En la versión de 2013 se podrá obtener información desde las fuentes de datos: WCF services, SQL Azure Data Services, OData Endpoints y servicios web.

38


- Acceso desde plataforma móvil con los servicios REST

Comparto algunos enlaces en los que se hace uso de esta característica, para aquellos que quieran profundizar en este tema:

• Referencia a BCS REST API para SharePoint 2013.

• Acceder a datos externos desde código JavaScript usando los servicios REST.

- CSOM - Modelo de Objetos Cliente .NET

También podremos utilizar modelo de objetos cliente para BCS.

La referencia completa de programación con BCS para desarrolladores de MSDN la pue-den ver aquí.



http://msdn.microsoft.com/es-es/library/jj163972(v=office.15).aspx#bkmk_Addresources



39


Búsqueda empresarial

Una de las novedades más importantes de SharePoint 2013 es la búsqueda empresarial. Es que, claro, una cosa es búsqueda como la conocemos en entornos de Internet (Bing, Google, etc.) y otra cosa muy distinta es un motor de búsqueda empresarial que tiene que cumplir con necesidades específicas de cierto empleado y normalmente de manera urgente.

Además de esto, por el simple hecho de tener un motor de búsqueda “en el interior de un firewall”, debemos tener en cuenta varios aspectos importantes:

- Seguridad. En una red empresarial, los recursos a los que cada empleado tiene acceso dependen del rol y los permisos de cada uno. Esto es muy importante tenerlo en cuenta en un sistema BE.

- Diferentes tipos de ficheros. PDF, DOC, DOCX, PPT, PPTX, ZIP, HTML, RDL, BD con for-mato propio,…

- Distintos repositorios. Bases de datos, intranets corporativas (SharePoint,…), carpetas de red compartidas, correo electrónico (Exchange, …), ficheros de Excel, sistemas de archivos, servidores web, Lotus Notes, Sistemas ERP, Sistemas CRM,…

- Combinación de información estructurada y no estructurada. Existe información estructurada en bases de datos, listas, libros de Excel, etc… Pero también información en pági-nas web, vídeos, documentos, etc… que está totalmente desestructurada. Además, muchas veces existe relación entre los distintos tipos de información, por lo que otro reto es el de combinar toda esta información de la forma más adecuada.

- Vocabularios y taxonomías propias. Una de las ventajas es que la mayoría de las bús-quedas tendrán un ámbito concreto de la empresa.

- Fechas de los documentos. Fecha de creación, fecha de análisis de un informe, fechas que están dentro de los documentos, …

- Búsqueda de un documento concreto. Si comparamos con la búsqueda en Internet, en la cual la mayoría de las veces el usuario no sabe lo que está buscando, en la búsqueda empresarial, el usuario muchas veces busca cierta documentación que sabe de su existencia, puesto que ya la consultó en el pasado, pero no recuerda exactamente donde estaba almace-nada. Un sistema de búsqueda empresarial debe aprovechar este aspecto.

- Personalización del modelo de relevancia. En la búsqueda en Internet no tiene sentido hablar de personalizar el modelo de relevancia para ciertos casos, ya que suele ser propietario,

40


pero en sistemas de búsqueda empresarial es muy habitual que las empresas puedan adaptar el modelo de relevancia a sus necesidades.

Microsoft ha dado la importancia que requiere a este tema y en SharePoint 2013 ha inte-grado la búsqueda de FAST para SharePoint 2010 dentro del núcleo de búsquedas. Sí, en otras palabras, no habrá que comprar este producto aparte si queremos disfrutar de sus ventajas.

Cabe decir que no es una integración directa, sino que se ha rediseñada toda la arquitec-tura, pero teniendo en cuenta aquellos factores de FAST que proporcionan mejoras indudables. Veamos cuál es la nueva arquitectura de búsqueda:

1.

Figura 1-17. Arquitectura de Búsqueda Empresarial en SharePoint 2013.

Componente Rastreador (Crawler)

Este componente es responsable de rastrear el contenido que proviene desde distintas fuentes de información. Invoca a los conectores y manejadores de protocolos adecuados para cada fuente de datos.

41


Importante: podemos desarrollar nuestros propios conectores personalizados Más información: Marco de conectores de bús-queda en SharePoint 2013.

La base de datos de Crawl (A) se utiliza para almacenar información sobre los elementos rastreados y el historial del rastreo (tiempo del último rastreo, Id del último rastreo,…)

2. Componente de procesamiento de contenido (Content Processing)

Procesa los elementos rastreados y los pasa al componente de indexación. Aquí es donde se usan los iFilters para hacer el parsing de los documentos. En SharePoint 2013 sigue pudién-dose extender los Format Handlers y crear un propio iFilter.

Realiza una serie de procesos como: creación de tokens, detección de lenguaje, extracción de entidades, stopwords, stemming o lematización, etc.

Escribe información en la base de datos de Links (B) para formar un Web Graph y poder usarlo en el modelo de ranking. Es decir, utiliza el mismo concepto que los motores de bús-queda de Internet para mejorar el ranking de resultados.

Además, también genera variaciones fonéticas para la búsqueda de personas.

3. Componente de procesamiento de analíticas (Analytics Procesing)

Analizan los elementos rastreados y cómo los usuarios interaccionan con los resultados de búsqueda (Analytics Reporting Database - C). Por ejemplo, cuando un usuario ve una página, ese evento se recoge en el Event Store y este componente puede usar esto para analizar com-portamientos y mejorar el ranking consecuentemente.

Podemos crear nuestros propios eventos personalizados.

También utiliza la base de datos de Link (B) para combinar esta información con la información de uso y obtener así mejoras para el algoritmo de ranking.

Concretamente se realizan los siguientes análisis:

- Search Analysis

• Link and Anchor Text Analysis

• Click Distance

http://msdn.microsoft.com/es-es/library/ee556429(v=office.15)

http://msdn.microsoft.com/es-es/library/ee556429(v=office.15)

42


• Search Clicks

• Deep Links

• Social Tags

• Social Distance

• Search Reports

- Usage Analysis

• Recommendations

• Usage Counts

• Activity Ranking

4. Componente de indexación (Index Component)

Se encarga de obtener los elementos rastreados y procesados, y escribirlos de forma ade-cuada en los ficheros de índices.

También recibe las consultas de usuario en un formato compatible y comparable con el formato en que se almacenaron lo elementos. De esta forma, es capaz de comparar la consulta del usuario con todos los documentos que tiene almacenados en el índice y devolver el con-junto de documentos (resultados) más adecuado.

5. Componente de procesamiento de consulta (Query Processing Component)

Realiza el procesamiento lingüístico en tiempo de consulta (word breaking, stemming, query spellcheking, expansión de la consulta -thesaurus-).

Utiliza el modelo de similitud para convertir y adaptar la consulta en un formato adecuado y comparable con los documentos que existen en el índice.

Optimiza la precisión y relevancia del motor de búsquedas

Decide cuales de las “Reglas de Consulta” (nuevo término) son aplicables.

Devuelve a la aplicación cliente los resultados de búsqueda

6. Administración de búsqueda (Search Administration)

Responsable del aprovisionamiento y cambios en la topología de servidores de búsqueda.

43


Responsable de la coordinación de los distintos componentes mencionados anteriormente.

La base de datos de Admin Search (D) almacena información sobre:

- Topología

- Crawl Rules

- Query Rules

- Managed Properties Mappings

- Content Sources

- Crawl Schedules

- Configuraciones de Analytics

A nivel informativo, los procesos de búsqueda son:

- Host Controller: Servicio de Windows que supervisa los procesos NodeRunner.

- NodeRunner.exe: Proceso que contiene los componentes de búsqueda (uno por cada componente: Crawl, Content Processing, Query, Index, Analytic). Puede haber más de uno por servidor.

- MSSearch.exe: Windows Service que contiene el componente de Crawl.

Consejo. Cuando estamos en un entorno de desarrollo, y queremos desa-rrollar algún tipo de aplicación referente con el uso de la búsqueda, hay que tener en cuenta que el proceso “noderunner.exe” consume gran cantidad de recursos. Para reducir un poco la cantidad de recursos que consume se puede: 1. Ejecutar PowerShell:

Set-SPEnterpriseSearchService –PerformanceLevel Reduced

2. Ir al archivo de configuración c:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderrunner.exe.config y cambiar el valor de <nodeRunnerSettings memoryLimitMegabytes=”0”> 3. Reiniciar el servicio SharePoint Search Host Controller

44


En lo que a novedades exclusivas de desarrollo se refiere tenemos también una lista de cosas:

Sintaxis de consulta SQL eliminada

Es decir, que ahora para lanzar una consulta al motor de búsquedas desde el modelo de objetos, tendremos que recurrir o bien a KQL (Keyword Query Language) o bien a FQL (FAST Query Language); este último se introduce debido a la integración de FAST que comentaba antes.

Servicio Web de Búsqueda Obsoleto

El típico servicio web http://servidor/sitio/_vti_bin/search.asmx queda como obsoleto en SharePoint 2013 , esto no significa que no funcione, ya que por temas de compatibilidad con aplicaciones ya creadas si que funciona, pero si estás desarrollando una aplicación que requiere de acceso al motor de búsquedas evita usar este servicio web y utiliza en su lugar o bien el modelo de objetos cliente o la API REST (_api).

Programación con aplicaciones cliente

Podemos tener una aplicación dentro del servidor de SharePoint para invocar al modelo de objetos de servidor de SharePoint y hacer aplicaciones personalizadas de búsqueda o que utilizan la búsqueda. Pero esto en la mayoría de los casos no sirve, y necesitamos acceder al motor de búsqueda desde fuera. Para ello, tenemos dos posibilidades en SharePoint 2013 : utilizar el modelo de objetos cliente en caso de que nuestra aplicación sea .NET o Web basada en llamadas de JavaScript; o la API REST en caso de tener una aplicación de móvil, o de código de servidor en tecnologías no .NET, como Java, PHP, Cocoa, Flash, etc. Concretamente, para la búsqueda tenemos muchas novedades en este apartado, pero como están perfectamente descritas en MSDN, os comparto los enlaces:

- Modelo de objetos cliente de Búsqueda en SharePoint 2013.

- API REST de Búsqueda en SharePoint 2013 (en inglés).


http://blogs.msdn.com/b/nadeemis/archive/2012/08/24/sharepoint-2013-search-rest-api.aspx

http://blogs.msdn.com/b/nadeemis/archive/2012/08/24/sharepoint-2013-search-rest-api.aspx

45


Otras novedades

Existen más novedades en este campo como la inclusión de los operadores NEAR, ONEAR y XRANK en el KQL. También la posibilidad de desarrollar un proceso personalizado en el pro-cesamiento de contenido del indexador.

Además de todo el rediseño que se ha hecho a nivel de administración y configuración con los Result Types, Query rules, Result Sources, etc. No es objetivo de este libro comentar estos temas, pero puede obtener más información: Novedades de Búsqueda en SharePoint 2013.

En el capítulo 3 de este libro hay un ejemplo de uso del modelo de objetos cliente .NET de búsqueda en el que se hace una consulta al motor de búsquedas usando la clase KeywordQuery.

Dispositivos móviles

En SharePoint 2013 hay nuevas características referentes a los dispositivos móviles, no solamente en cuanto al desarrollo, sino que también hay mayor soporte nativo para móviles.

Podemos dividir las novedades en secciones:

Interfaz gráfica

A nivel de cómo se muestran los contenidos de SharePoint en un dispositivo móvil se ha implementado una vista nueva llamada Vista contemporánea, que se añade a las dos existen-tes en SharePoint 2010:

Vista clásica. La misma que en SharePoint 2010.

Vista contemporánea (Contemporary View). Vista optimizada para HTML5 soportada para Mobile Internet Explorer 9.0 para WP 7.5 en adelante, Safari 4.0 para iOS 5.0 en adelante y Android 4.0 en adelante.

Vista Pantalla completa. Vista de SharePoint normal usada para escritorio.

http://technet.microsoft.com/es-es/library/ee667266(v=office.15).aspx

46


Figura 1-18. Vistas móviles disponibles en SharePoint 2013. Imagen obtenida de MSDN de Microsoft.

Puede ver más información sobre los navegadores soportados en SharePoint 2013.

Office Web Apps en móviles

En SharePoint 2010 Office Web Apps se instalaba como un componente integrado en SharePoint, el cual ofrece vistas desde el navegador de escritorio y móvil para Word, Excel y PowerPoint. Ahora, en SharePoint 2013, Office Web Apps pasa a ser un producto separado que requiere instalarse en un servidor aparte, no obstante, sigue pudiéndose integrar con SharePoint 2013 ofreciendo los visores llamados “Word Mobile Viewer”, “Excel Mobile Viewer” y “PowerPoint Mobile Viewer” los cuales están optimizados para ver documentos de Office desde el navegador del móvil, sin tener que descargar el propio fichero al dispositivo móvil.

Notificaciones y alertas desde listas de SharePoint

SharePoint 2013 da soporte a las notificaciones para las aplicaciones móviles, es decir, que cuando se añade o modifica algún elemento de una lista de SharePoint en la aplicación del móvil recibiremos una alerta. Además, también se puede configurar una cuenta de móvil

http://technet.microsoft.com/es-es/library/fp161353(v=office.15)

47


en SharePoint 2013 para permitir a los usuarios suscribirse para recibir un SMS ante cualquier cambio en una lista de SharePoint.

No es objetivo de este libro adentrase en esto, sin embargo, comparto contigo algunos recursos interesantes:

- Configurar cuentas de móvil en SharePoint 2013.

- Configurar y usar Push Notifications en SharePoint 2013 apps para Windows Phone.

Contenido de inteligencia de negocio desde iPad

SharePoint 2013 permite a los usuarios de iPad poder ver ciertos tipos de contenidos de PerformancePoint y Excel Services. Para profundizar en esto, tienes este recurso: Visualización de informes y cuadros de mandos en dispositivos Apple iPad.

Geolocalización en aplicaciones móviles

En un apartado anterior, comentaba las novedades de SharePoint 2013 en lo que a geolo-calización y mapas se refiere. Debemos decir que en las aplicaciones móviles para SharePoint 2013 también tendremos disponible el tipo de columna o campo “location”. Más información en: Uso del tipo de campo de ubicación de SharePoint 2013 en aplicaciones móviles y Cómo integrar mapas de SharePoint 2013 con aplicaciones de lista de Windows Phone.

¿Cómo se desarrollan aplicaciones de Windows Phone para SharePoint 2013?

Para empezar, se necesita tener Visual Studio con el SDK de Windows Phone instalado. Es importante saber que esta plataforma requiere Windows Vista SP2 o Windows 7. Esto quiere decir que no se puede instalar todo este SDK de desarrollo para Windows Phone sobre un Windows Server. Así que el entorno ideal de desarrollo sería: dos máquinas, una con SharePoint 2013 sobre Windows Server y la otra con Windows 7 con Visual Studio y el SDK de Windows

http://technet.microsoft.com/es-es/library/ee428323(v=office.15)



http://technet.microsoft.com/es-es/library/hh697482.aspx

http://technet.microsoft.com/es-es/library/hh697482.aspx




48


Phone instalado. Para profundizar en este tema puede ver Cómo configurar un entorno para desarrollar aplicaciones móviles para SharePoint.

ECM (Enterprise Content Management)

SharePoint 2013, al igual que las versiones anteriores, tiene un núcleo muy fuerte en lo que se refiere a la gestión documental empresarial, también llamada “Enterprise Content Management”.

Como principales novedades en este ámbito tenemos:

eDiscovery

Se habla mucho de esta característica en SharePoint 2013, y a primera vista lo asociamos con algo futurista que nos permitirá descubrir ciertos patrones al estilo de cómo se hace con minería de datos. El objetivo real de esta nueva característica (o al menos uno de ellos) es actuar como lo hacía en SharePoint 2010 la característica “Records Management”, es decir, ayudar a proteger a tu negocio, preservando todo el ciclo de vida de los records, que son activos de una organización que deben ser almacenados para cumplir ciertos requerimientos legales.

Poniendo todo esto sobre la tierra, algunas empresas necesitan almacenar cierta docu-mentación para tenerla visible ante algunas inspecciones legales recurrentes. Esta información puede que la tengan distribuida a lo largo de la(s) intranet(s) corporativa(s) y no hay una per-sona que sepa dónde está todo, a no ser que se dedique exclusivamente a ello. Añadido a todo está también que esta documentación se requiere mantenerla durante una cantidad exacta de tiempo, por ejemplo unos meses, un año, dos años,… depende del caso. También está la problemática que a veces se requiere cierta versión de los records, pero también se quiere que pueda ser modificado. Ante esto, lo lógico es pensar “pues hago una copia del documento y sigo trabajando con ella”, pero claro, ¿dónde lo guardo?, ¿cómo aviso a todos los involucra-dos? Vaya marrón ¿no? En SharePoint 2013, eDiscovery viene a cubrir todas estas necesidades. Veamos un resumen de cómo lo hace:

El centro de eDiscovery

Un nuevo tipo de plantilla de colección de sitios que permite gestionar todos los casos de eDiscovery.



49


Proceso de eDiscovery en SharePoint 2013

Figura 1-19. Proceso de eDiscovery en SharePoint 2013. Imagen obtenida de TechNet de Microsoft.

Cuando se recibe una petición de eDiscovery o de Record Management, lo que haces es ir al sitio creado con la plantilla de tipo eDiscovery y crear un “eDiscovery Case”, llamémosle un “caso”.

Al caso definido, se le asocia un conjunto de fuentes de origen, filtros, y holds (docu-mentos que queremos preservar tal cual están). Respecto a los holds, decir que en SharePoint 2010 se permitían marcar los documentos como hold, lo cual ponía ese documento como solo lectura y los usuarios no podían seguir haciendo cambios sobre ellos. Ahora en SharePoint 2013 , se introduce el concepto de “in-place holds” que permiten mantener una copia intacta del documento que se ha marcado como hold, pero a su vez permite que los usuarios puedan seguir modificándolo. Para ello, y con el objetivo de ahorrar todo el espacio en disco que se pueda, lo que SharePoint hace es crear una biblioteca llamada “preservation hold library” (que solamente es visible para site collection admins) y guardar en ella aquellos documentos a los que se les hace algunas modificaciones desde el momento que se marcan como “in-place holds”.

En la parte de del diagrama de arriba, cabe destacar el concepto de Team Folders que pro-porcionan una interfaz común para los documentos encontrados tanto en SharePoint, como en Exchange, incluso le podemos asociar una dirección de correo electrónico a una Team Folder.

Siguiendo el flujo, aparte de hacer el conjunto de definición de nuestro caso de eDiscovery, también definimos la consulta final y cómo será el conjunto de documentos, listas, páginas, y

50


objetos de Exchange exportados para la liberación del caso. Además, la exportación se hace siguiendo el formato de acuerdo a EDRM (Electronic Data Reference Model). Más información: Información general sobre la exhibición de documentos electrónicos y las suspensiones en contexto en SharePoint Server 2013.

Hablando un poco más de los orígenes permitidos para esto cabe destacar que eDiscovery hace uso (es requisito) del motor de búsquedas de SharePoint Search. Así que, permite utilizar los “Result Sources” que son algo parecido a los “Content Source” mezclados con Federación. Es decir, las fuentes de datos como carpetas compartidas, sitios de SharePoint, web públicas, Documentum, etc.

El objetivo de este proceso, como comentábamos antes, es exportar información filtrada y relevante para auditores externos u otro tipo de usuarios que requiera cierta información de nuestra empresa basada en unos patrones.

Por supuesto, las características de Record Management de SharePoint 2010 siguen estando soportadas, vea más información: Novedades en Record Management para SharePoint 2013.



http://technet.microsoft.com/es-es/library/fp161517(v=office.15)#enterprise-wide-ediscovery

51


WCM (Web Content Management)

Como bien sabemos, SharePoint también puede actuar como sistema de contenidos web, para ello se define el tipo de plantilla de publicación, las características de publicación, etc. En SharePoint 2013, tenemos buenas noticias en esta parte, ya que se ha hecho un gran esfuerzo en conseguir que SharePoint cada vez sea un WCM mejor valorado. Veamos las principales mejoras:

Gestor de diseño (Design Manager)

Con SharePoint 2013, se introducen también cambios que afectan al diseñador de SharePoint, es decir, las personas encargadas de crear todo lo referente a branding, HTML, CSS, etc. El gestor de diseño proporciona un paso a paso de todos los artefacto s necesarios para personalizar el diseño de SharePoint. Además, también tendremos la posibilidad de crear el diseño desde herramientas más orientadas al diseño, como Dreamweaver, y poder luego subir los archivos HTML y CSS a SharePoint, de forma que SharePoint 2013 lo transforma en la estructura de master pages, layouts, etc. Véase en la Figura 120 los pasos que se realizarían para construir un diseño de SharePoint con el gestor de diseño:

Figura 1-20. Pasos del gestor de diseño de SharePoint 2013.

No vamos a entrar en detalle en esta parte, ya que no es el objetivo de este libro. Para más información puedes ver: Desarrollando el diseño del sitio en SharePoint 2013. No obstante, en el capítulo 3 se entra muy en detalle respecto a maquetación y diseño dentro de las SharePoint Apps.


52


Sitios dirigidos por las búsquedas

Una de las características de las que prescindía SharePoint 2010 es poder orientar un sitio público hacia el eCommerce o comercio electrónico, sin tener que hacer un trabajo de desarrollo considerable. Ahora, en SharePoint 2013 , se introduce la plantilla de colección de sitios llamada “Product Catalog”, que nos va a permitir de forma fácil que nuestro sitio de productos pueda actuar como una colección de elementos a clasificar por distintas categorías, de los cuales vamos a querer tener vistas de un conjunto de productos filtrados, así como vista de elementos particulares. A este tipo de sitios se les llama sitios dirigidos por las búsquedas, aunque yo los identifico mejor como sitios de comercio electrónico o incluso sitios de catálogo de productos.

Los elementos clave de este tipo de sitios son:

- Página maestra (igual que la de publicación).

- Diseño de página. Destacamos dos:

o Categoría: para ver un conjunto de productos en modo de agrupaciones o filtrados.

o Vista de elemento: para ver la página de detalle de un elemento o producto concreto.

- Páginas: creadas en nuestro sitio usando la página maestra y seleccionando un diseño de página de los de arriba.

- Search-driven Web Part: el nuevo Content Search Web Part que permite obtener elementos de una consulta al motor de búsquedas y aplicarle un estilo de forma fácil.

o Display Templates (o plantillas de visualización): doble objetivo de controlar las propiedades que se mostrarán para los resultados de la búsqueda y también aplicarle un estilo de acuerdo a nuestro branding.

Control Display Templates: para definir el estilo y diseño del conjunto completo de productos, así como la paginación, ordenamientos, etc.

Item Display Templates: donde se definen los estilos y diseño para un ítem concreto en la colección de productos.

53


Figura 1-20. Configuración del Content Search Web Part de SharePoint 2013. Imagen obte-nida de MSDN.

Figura 1-22. Control Template para el Content Search Web Part. Imagen obtenida de MSDN de Microsoft

54


Figura 1-23. Item Template para el Content Search Web Part. Imagen obtenida de MSDN de Microsoft.

Catálogos y publicación entre colecciones de sitios

Como en todas las nuevas versiones, se definen nuevos términos que no son difíciles, pero que si no se conoce su definición formal, o el objetivo por el que fueron creados, no se llegan a entender del todo bien. Esto me pasó con el término “Catálogos” de SharePoint 2013. Y es que los catálogos son listas o bibliotecas compartidas que sirven para poder publicar conte-nido entre colecciones de sitio. En la sección anterior he definido la estructura básica de un sitio dirigido por búsquedas que hace uso de un catálogo para ello. Pero aquí juntamos dos conceptos, por una parte catálogo como representación visual de cara a realizar un sitio de eCommerce en Internet, y por otra parte, catálogo como medio para compartir contenido entre colecciones de sitios, que es a lo que me refiero ahora. Esta característica se denomina Publicación Cruzada o Cross-Site Publishing (XSP) en inglés. Existe una API específica para esto en SharePoint 2013.



55


Mejoras en SEO (Search Engines Optimization)

Éste es uno de los aspectos donde se han hecho más progresos, bajo mi punto de vista. La verdad es que cuando instalé SharePoint 2013 y vi la cantidad de novedades de SEO (Search Engine Optimization) que tenía, me quedé sorprendido. Las capacidades WCM (Web Content Management) de SharePoint 2010 habían mejorado respecto a la versión 2007, pero en lo que a SEO se refiere, se había quedado como materia pendiente. Pero todo llega, ya tenemos SharePoint 2013 que es mucho más WCM.

Para más información acerca de las novedades en SEO, te recomiendo visitar el siguiente post del blog del equipo de SharePoint de SolidQ: Novedades en SEO para SharePoint 2013.

Cambios en multimedia

Cuando estamos creando páginas web que van a ser publicadas en Internet, debemos ser muy cuidadosos con el contenido multimedia, concretamente con el tamaño de las imágenes, publicación de los vídeos, integración con YouTube, etc. SharePoint 2013 tiene mejoras en este aspecto también. Veámoslas:

- Image Renditions. Consiste en que por cada imagen o vídeo que subimos a SharePoint, ésta se almacena teniendo en cuanta una serie de dimensiones que previamente el administra-dor ha establecido. Con esto conseguimos que cuando insertamos una imagen en una página podamos decidir las dimensiones de ésta.

o Los tipos de imágenes soportados son: gif, jpg, jpeg, jpe, jfif, bmp, dib, png, tif, tiff, ico, wdp y hdp. Y los tipos de vídeos soportados son: wmv, wma, avi, mpg, mp3, mp4, asf, ogg, ogv, oga y webm.

- Mejoras en el vídeo. Aparte de lo mencionado en el punto anterior, tenemos también la capacidad de incluir vídeos externos como YouTube y también la generación automática de thumbnails.

Navegación administrada (metadatos administrados)

Uno de los cambios sorprendentes es el tema de la navegación, ya que hasta ahora dependía de los sitios, subsitios, páginas y algún enlace a medida que pudiésemos introducir. En SharePoint 2013, se puede configurar para que la navegación sea administrada, es decir, mediante metadatos administrados. Esto no quiere decir que tenemos que ir creando toda

http://blogs.solidq.com/sharepoint/post.aspx?id=210&title=novedades+seo+para+sitios+p%C3%BAblicos+de+sharepoint+2013

56


la estructura de navegación a mano. El funcionamiento será parecido, ya que cuando creamos un sitio automáticamente se nos crea el metadato administrado para la navegación. Vamos, que no nos va a traer complicaciones, sino ventajas, ya que podremos cambiar la URL a nues-tro antojo (y esto es bueno a la hora de definir buenas URL para SEO). Además, para el caso concreto de eCommerce que comentábamos anteriormente, nos viene bien, ya que podremos hacer URL distintas para las distintas categorizaciones, por ejemplo, en caso de una tienda de electrodomésticos: /frigoríficos, /lavadoras, /hornos, etc.

Otras novedades

Además de todas las mencionadas anteriormente, tenemos más novedades a las que no entraremos en detalle por quedarse fuera del ámbito de este libro. Pero no por ello dejaremos de mencionarlas y dejar un enlace con más información para los curiosos:

Nuevas aplicaciones de servicio

o Machine Translation Services. Encargado de hacer traducción automática.

o PowerPoint Automation Services. Conversión de .ppt y .pptx hacia otros formatos.

o Mejoras en Access Services 2013.

Novedades en inteligencia de negocio para SharePoint 2013

En la parte relacionada con inteligencia de negocio también hay bastantes novedades sobre todo para Excel Services, Visio Services, PerformancePoint Services, etc. No entrare-mos en detalle en ellas en este libro, pero si tenemos curiosidad, tenemos más información: Novedades de Inteligencia de negocio en SharePoint 2013.


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





57


Conclusiones

A lo largo de la evolución de SharePoint, hemos ido observando como el equipo de Microsoft en cada versión nueva del producto ha puesto el foco en ciertos componentes. Por ejemplo, en SharePoint 2007 el foco de novedades estuvo de cara del desarrollador, concreta-mente todo el sistema de características (features) y soluciones. Más adelante, para SharePoint 2010, el principal foco fue la arquitectura de servicios más escalable y tolerante a fallos, por lo que fue más orientado hacía el profesional IT. Finalmente, en esta nueva versión observamos que el foco de novedades se centra en el usuario, puesto que se han rediseñado todo de cara a seguir las guías de estilo Windows 8 Metro y obtener así una mejor experiencia del usuario. Con esto no quiere decirse que en los demás campos no hayan novedades, como habéis ido observando en este capítulo, sí las ha habido. Lo que quiero dejar como conclusión es que Microsoft está escuchando al usuario final en este sentido y esto siempre es buena noticia para todos.

A todo esto añadir que también tenemos disponible una serie de webcasts mostrando la novedades de Office 2013 y concretamente uno en el que se muestran las novedades de SharePoint 2013, puede verlo aquí.

http://technet.microsoft.com/es-es/ee126078

https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ES&EventID=1032529676&CountryCode=ES



Capítulo 2: Introducción a las SharePoint Apps

P58

En este capítulo dedicado a las nuevas apps de SharePoint vamos explorar de forma teórica los fundamentos de este nuevo modelo, desde su concepción hasta el despliegue, pasando por todos los tipos y clases de apps que seremos capaces de desarrollar con las herramientas que nos ofrece SharePoint 2013.

En esta versión, Microsoft ha hecho el mayor esfuerzo nunca visto hasta ahora por unificar todas las plataformas de colaboración bajo un mismo lanzamiento, propiciando una mayor compenetración entre todos sus productos. Empezando por SharePoint y acabando por Office y Lync, esta vez SharePoint estará completamente alineado en el tiempo en ambas plataformas, online y on premise.

Pero antes de esto, comencemos situándonos en contexto con una introducción sobre el desarrollo de aplicaciones para SharePoint en sus últimas versiones.

Introducción. El desarrollo sobre SharePoint a lo largo de los tiempos

Me inicié en esto del desarrollo sobre la plataforma SharePoint en la primavera del año 2007, en aquel momento la versión del producto que estaba en el mercado era Microsoft Office SharePoint Server 2007 o en su versión reducida y gratuita Windows SharePoint Services 3.0, además, tenía algún viso de integración con Office 2007 aunque limitado y con una gran cantidad de hándicaps por la escasa documentación y la gran cantidad de errores que tenía en aquel momento por ser una tecnología joven ( joven porque era tan solo la tercera versión del producto, precedida por la 2001 y la 2003, que fue la que de alguna manera sentó ciertas bases en torno al producto).

En aquel tiempo (tiempos de SharePoint 2007) solo había una manera “oficial” de desa-rrollar aplicaciones para SharePoint; es lo que comúnmente se llamaban soluciones, que en la mayoría de los casos constaban de Web Parts y/o controles de ASP.NET 2.0. Ésta era la

59


manera de extender esa plataforma de gestión de contenidos increíblemente grande y, dado el potencial de la plataforma ASP.NET, las posibilidades eran prácticamente ilimitadas. Eran tiem-pos de programar Web Parts “a ojo”, sin utilizar diseñadores gráficos (que ya existían para la plataforma ASP.NET pero no para las Web Parts), directamente desde el código C# o VB había que inyectar código HTML con las clases todo mezclado. El modelo de despliegue y las restric-ciones de seguridad de la plataforma hacían de cada despliegue prácticamente una maniobra de guerra, en la que no hacer una copia de seguridad del servidor, etiquetar una rama en el repositorio y demás acciones preventivas no eran una opción, sino una necesidad imperiosa para no morir en el intento.

En cualquier caso, eran tiempos divertidos, el problema era que no había límites, que tocando un XML de políticas o insertando una DLL en la GAC del servidor podíamos violar todas las normas de seguridad del servidor de un banco sin darnos apenas cuenta de lo que habíamos hecho. Y estos problemas en la confiabilidad de las aplicaciones, y sobre todo de su ilimitada capacidad de acción sobre un servidor en determinadas circunstancias nos acabó llevando al modelo de desarrollo de SharePoint 2010.

Microsoft SharePoint Server 2010 Standard/Enterprise y Microsoft SharePoint Foundation 2010 en su versión gratuita, éstas son las tres versiones que Microsoft presentó con el lanzamiento de SharePoint 2010. En su versión 2010, SharePoint trajo un modelo de desarrollo nuevo que intentaba paliar los problemas de seguridad que presentaba el modelo absoluto que presentaba SharePoint 2007. Este modelo de SharePoint 2007, que seguía siendo un modelo perfectamente soportado en su versión 2010, se pasó a llamar soluciones de granja o en inglés farm solutions, nombre muy acertado ya que las soluciones desplegadas de esta manera tienen capacidad para acceder a prácticamente a todos los recursos de la granja de servidores con la única restricción de los permisos de usuario, sorteable, por otra parte, por el propio desarrollador de la solución. Esta parte trajo grandes novedades en cuanto al desarrollo en capas; al fin teníamos la parte de presentación separada de la lógica, como cualquier otro desarrollador en ASP.NET y todo gracias a las Visual Web Parts, un híbrido que consistía en una Web Part que cargaba un control de usuario de .NET. Pero esto es solo un ejemplo de las mejoras lineales razonables que se espera de una nueva versión. Hablemos de la extensión del modelo de desarrollo.

También hicieron su aparición las comúnmente llamadas sandbox solutions o en español soluciones de espacio aislado, que como bien indica el nombre fueron un nuevo tipo de solución incluido en la versión 2010 que ejecutaba su código (código de la API de servidor de SharePoint al igual que en el resto de soluciones) en una “caja” aislada del resto de procesos del servidor SharePoint. Estas soluciones, aunque mucho más restrictivas en las posibilidades de ejecución, trajeron consigo una gran flexibilidad en cuanto a instalación y despliegue. Tan solo subiendo un archivo de solución a una biblioteca de soluciones gestionada por un admi-nistrador de colección de sitios, ya tenías disponible dicha solución. Además, este tipo de soluciones son fácilmente gestionables por el administrador de colección de sitios, y permitían

60


poner límites a los recursos del servidor que consumen, de forma que sea prácticamente impo-sible que una solución aislada de este tipo tire abajo todo el servidor.

Una de las principales razones para el uso de este tipo de soluciones aisladas es la posi-bilidad de desarrollar para SharePoint Online incluido en Office365, sí, la tan recurrente nube pública en su versión SharePoint. Pero esto ha sido claramente insuficiente para equiparar las versiones online (en la Nube) y on premise (en servidores cuya administración queda de nuestro lado), y estas diferencias pretenden hacerse cada vez más y más pequeñas con cada versión de SharePoint.

Además, otra de las razones por las que el modelo de soluciones para SharePoint es insu-ficiente para el actual mercado, es la falta de un modelo claro de comercialización. Es decir, el llamado marketplace de aplicaciones que se utiliza con un gran éxito en diversas plataformas móviles con un rotundo éxito. Este modelo, en el cual una persona puede acceder a cualquier aplicación, descargarla e instalarla en su sistema sin miedo a que dañe la plataforma gracias a una serie de certificaciones que ha tenido que pasar previamente a su publicación en la tienda de aplicaciones. Sin un modelo robusto como éste en el que marketing, calidad y distribución queden completamente homogeneizadas para la plataforma, se hacía difícil la unificación de plataformas online y on premise.

Estos dos ingredientes, el modelo de comercialización, así como el modelo de despliegue y ejecución aislados es lo que nos lleva a la versión actual del producto SharePoint 2013 y a su tercer y nuevo modelo de programación para esta versión, el llamado Cloud App Model (literalmente, modelo de aplicaciones en la Nube).

SharePoint 2013 y su nuevo modelo de aplicaciones

SharePoint 2013 nos trae un modelo de aplicaciones en la Nube que nos permite crear apps. Las apps para SharePoint, desde un punto de vista funcional, son piezas aisladas de fun-cionalidad que extienden las características de un portal SharePoint. Han sido concebidas para que sean fáciles de utilizar, consuman pocos recursos del servidor que las utiliza y sobre todo para que resuelvan una necesidad específica de los usuarios.

En este contexto, se crea un ecosistema para los usuarios de la plataforma Office 3651 en el que las distintas aplicaciones de Office son extensibles a través del Office Store (SharePoint y Office Apps). Pero antes de meternos en la materia principal de este libro que son las SharePoint

1 De ahora (2012) en adelante, Microsoft llama Office 365 al conjunto de productos Office que o bien están exclusivamente en la Nube o bien se instalan desde la Nube, por lo tanto, cabe tener en cuenta que este término ahora engloba tanto al Office tradicional como a Lync Online, Exchange Online y SharePoint Online.

61


Apps, voy a explicar brevemente lo que son las Office Apps y por qué las SharePoint Apps pue-den integrarse con las mismas, haciendo nuestro trabajo sobre SharePoint Apps el doble de útil.

Desde un punto de vista de un desarrollador clásico de SharePoint, las SharePoint Apps podríamos decir que se reducen a una Web Part con algunas consideraciones especiales de aislamiento respecto al servidor en el que están instaladas. Dado que no son más que un trocito de web, podemos acceder a alguno de sus componentes desde otros visores de web. Y aquí es donde entran las Office Apps, ¿Qué son las Office Apps?, para el usuario, desde un punto de vista funcional, las Office Apps son aplicaciones que extenderán la funcionalidad de Office, ya sea interactuando con los datos de su documento o con recursos externos, como pueden ser los mapas de Bing o cualquier otra aplicación web. Bien, pero desde un punto de vista más técnico, ¿Qué son en realidad?, pues no son más que navegadores2 incrustados en Office con un determinado factor de forma, que muestra aquello que nosotros hemos desarrollado. Y ésta es la razón por la que es posible integrar nuestras SharePoint Apps dentro de una Office App (componentes web que se integran dentro de navegadores web).

Después de introducirnos brevemente en algunos conceptos, estamos preparados para comenzar a conocer realmente el nuevo modelo de aplicaciones de SharePoint. En la Figura 21 podemos ver un pequeño dibujo extraído de MSDN que es muy ilustrativo, a grandes rasgos, de cómo nosotros como desarrolladores proveemos aplicaciones a través de la Nube, en este caso en forma de Office Store, haciéndoselas llegar a los usuarios de manera transparente para nosotros.

Figura 2-1. Desarrolladores proveen aplicaciones a través de la Nube

Oficialmente, a este modelo de aplicaciones se le ha dado el nombre de Cloud App Model debido a que fundamentalmente se creó para que fuera posible desplegar este tipo de aplica-ciones en la Nube, tanto desde el lado del proveedor (componentes de la aplicación), como del

2 Concretamente utilizan el motor de Internet Explorer 10.

62


lado del usuario que adquiere la aplicación, ya que son compatibles con la plataforma Office 365, paquete que incluye SharePoint Online.

Con este modelo en la Nube, automáticamente obtenemos toda la versatilidad de la plata-forma Azure o de OData, haciendo que nuestras aplicaciones sean mucho más versátiles, por ejemplo, en cuanto a uso de recursos de servidor. Para ser un poco más gráfico, voy ilustrar con un ejemplo este tipo de ventajas. Imaginemos una aplicación que muestra los datos en tiempo real de una carrera de Fórmula 1. Esta aplicación constaría al menos de una página para mostrar los datos, una base de datos que los almacena y servicios web para refrescar y leer la base de datos de forma constante. Si todos estos recursos de nuestra aplicación están en un solo servidor que tenemos en propiedad, es muy fácil que un número de usuarios elevado des-borde los recursos de nuestro servidor rápidamente, y si por el contrario contratamos una gran cantidad de servidores de forma permanente, estaremos desperdiciando una gran cantidad de recursos una vez que acaba la carrera. En este escenario, alojar nuestros recursos haciendo uso de servicios web en Azure y SQL Azure para la base de datos, consumiríamos solo lo que gas-tamos, empezando por lo mínimo (el equivalente a un pequeño servidor) y Azure se encargaría de auto-provisionar servidores de forma dinámica conforme la demanda aumentase.

En el ejemplo anterior he mencionado Azure como posible plataforma en la Nube y SQL Azure como posible base de datos. Cabe destacar que las aplicaciones son compatibles con la gran mayoría de tecnologías web existentes, es decir, en lugar de usar .NET para nuestros servicios en Azure, podríamos utilizar PHP y una base de datos MySQL en lugar de SQL Azure. Esto es posible gracias los nuevos modelos de objetos que incluye SharePoint 2013, como puede ser el modelo de objetos de JavaScript y la nueva _api, como han bautizado al nuevo acceso a través de servicios REST, ahora muchísimo más completo que en la versión anterior, incluyendo entre otros acceso a los servicios de búsqueda, workflow, la parte de redes sociales, taxonomías, perfiles de usuario y BCS3.

¿Cuándo usar soluciones y cuándo aplicaciones?

Hasta este momento, hemos repasado la historia de los desarrollos en SharePoint y hemos echado un vistazo introductorio el nuevo modelo de desarrollo de SharePoint Apps. Con esta información es posible que muchos lleguemos a una pregunta necesaria a la hora de iniciar un nuevo desarrollo sobre SharePoint. ¿Debemos utilizar soluciones o deberíamos optar por el nuevo modelo de aplicaciones?, para arrojar un poco de luz en este sentido, a continuación podemos encontrar los puntos más representativos de cada una y así poder tomar esta deci-sión dependiendo de qué necesidades tenga el proyecto en cuestión.

Aplicación (app)

3 Business Connectivity Services, el servicio que nos permite conectar a distintas fuentes de datos de otras herramientas de negocio (LOB – Line Of Business) desde SharePoint.

63


- Escenarios en los que se necesitan funcionalidades con un contexto muy acotado (como en una aplicación de escritorio).

- Más flexibilidad en tecnologías, capacidades e infraestructura.

- Mayor nivel de aislamiento de datos, procesos y usuarios.

- Solución (wsp)

- Personalizaciones profundas.

- Despliegue de páginas maestras, diseños de página, recursos.

- Escenarios de personalización de administración de SharePoint.

El Office Store

En este apartado vamos a echar un vistazo al Office Store y sus ventajas desde el punto de vista de negocio y ciclo de vida de las apps. En el capítulo 4 “Administración de SharePoint Apps” de este mismo libro trataremos en profundidad cómo publicar y administrar nuestras aplica-ciones en el Office Store, así como en el catálogo privado de nuestra granja de SharePoint.

El modelo de negocio tipo Marketplace4 tiene múltiples ventajas a la hora de publicar nuestras aplicaciones. Por una parte, nos facilita el contacto directo con los usuarios, homoge-neizándolo con todos ellos a través de canales únicos como puede ser el sistema de valoracio-nes de nuestras aplicaciones, mediante el cual podremos obtener información y opiniones de los usuarios de una forma natural para ellos y unificada para nosotros. Aunque en algún caso pueda parecer contraproducente, si hacemos un buen trabajo o bien si escuchamos a los usua-rios, añadiendo aquellas características que son más solicitadas o corrigiendo aquellos bugs que más usuarios reproducen, lo normal es que seamos premiados con buenas opiniones y en consecuencia con un aumento en el número de descargas.

4 A partir de este punto me referiré al significado de Marketplace directamente como Office Store ya que es el nombre del auténtico mercado de aplicaciones que nos ocupa.

64


Figura 2-2 Office Store de Estados Unidos en fase Beta.

Por otra parte, otra de las ventajas importantes de publicar en el Office Store está en el ciclo de vida de las aplicaciones, muy simplificado en la siguiente figura. El ciclo de vida de desarrollo para el Office Store nos proporciona una forma muy sencilla de publicar y actualizar nuestras aplicaciones. Cuando desarrollamos una aplicación, antes de publicarla en el Office Store, la empaquetamos en un solo archivo que contiene todos los recursos, no necesitamos crear un instalador complejo que deba funcionar en cientos de servidores con distintas confi-guraciones, solo el paquete que genera Visual Studio. Una vez que publicamos dicho paquete (nuestra aplicación) a través del Office Store, solo necesitaremos re-publicar dicho paquete para que todos los usuarios de nuestra aplicación puedan actualizarla de forma totalmente integrada con SharePoint 2013. Este proceso remplazará los componentes anteriores por los de la nueva versión, garantizando que nada falle durante dicho proceso de actualización. Cabe destacar que lo realmente importante de este paquete es un archivo XML llamado manifest que contiene la información esencial de nuestra aplicación (título, versión…), el resto de com-ponentes son los recursos (páginas HTML, hojas de estilos CSS…).

65


Figura 2-3. Ciclo de vida de las aplicaciones en Office Store.

Otras de las ventajas que nos proporciona el Office Store son:

- Administración de nuestra aplicación

o Ciclo de publicación (publicación de actualizaciones automatizadas, es decir, cuando publicamos una nueva versión de nuestra aplicación, el Office Store se encarga de avisar a todos los usuarios automáticamente de que existe una nueva versión de la aplicación que tienen instalada)

o Datos de análisis (número de descargas, número de páginas vistas…)

o Licenciamiento de servicios. El Office Store incluye un marco de trabajo o fra-mework para licenciamiento especialmente orientado a licenciar servicios y no apli-caciones como tal. El objetivo es proteger los datos más allá de la propia aplicación, ya que está demostrado que no hay dispositivo cuya seguridad sea infranquea-ble. La propuesta de Microsoft en este sentido pretende acabar con la piratería a través de la protección de los servicios de datos. Si tu usuario no tiene licencia para acceder a los datos de un determinado servicio, da igual que tenga la apli-cación instalada (de forma irregular), ya que ésta resultará inservible sin el debido acceso a los servicios de datos en la Nube. Para verlo más claro, imaginemos que hemos publicado una aplicación que mediante un servicio web provee información general en tiempo real sobre el campeonato nacional de liga de fútbol de nuestro país, nosotros publicamos dicha aplicación a 3,99€, y con ello esperamos amorti-zar entre otras cosas el coste de los servidores que mantienen dicho servicio web. Como estamos cobrando esa cantidad, decidimos que no es necesario ningún tipo de autenticación para acceder a los datos, ya que el mero hecho de consumirse

66


desde nuestra aplicación implica, en teoría, que han pagado los 3,99€ por utilizar la aplicación. ¿Qué ocurriría en el momento en el que rompieran la seguridad del Office Store? En ese momento, mucha gente comenzaría a utilizar la aplicación sin pagar previamente los 3,99€. Aquí es donde entra el framework de licenciamiento que nos permite validar si la petición de la aplicación tiene una licencia válida, asignada por el Office Store, y en caso contrario podemos denegar las peticiones al servicio web. Protegiendo así nuestra aplicación también desde fuera del dispositivo en el que se ejecuta.

o Monetización. El Office Store integra las cuentas Microsoft que todos utilizamos a menudo en otros mercados existentes como el Windows Phone Marketplace, el Windows 8 Store y Xbox Live. Esto significa que nuestros posibles usuarios no ten-drán que crear cuentas complejas ni añadir de nuevo su tarjeta de crédito para poder comprar aplicaciones.

Tipos de SharePoint App. Visualización y funcionalidad

Ahora que comenzamos a tener una idea general de los conceptos más básicos de este nuevo modelo, es el momento de comenzar a adentrarnos en los detalles. Las SharePoint Apps pueden tener diferentes formas de representación en una página (capa de presentación), con-cretamente son tres los tipos de app que podremos desarrollar según la forma en la que vamos a presentarla al usuario y el tipo de funcionalidad que va a cubrir.

Página completa (Immersive Full Page)

Las apps de Página completa, son aquellas que ocupan toda la interfaz de usuario, es decir que tienen una página maestra propia y todo lo que se muestra en pantalla cuando accedemos a una de ellas es parte de la app. Normalmente, escogeremos este tipo de app cuando quera-mos una inmersión contextual completa del usuario, por ejemplo, para una app compleja de gestión de vacaciones de empleados, que utilizaría presumiblemente varios elementos de la interfaz visual (elementos de navegación, paneles con información, formularios, etc…).

67


Figura 2-4. SharePoint 2013 App del tipo página completa

Para acceder a este tipo de apps, normalmente, entraremos en los contenidos del sitio y seleccionaremos la app en cuestión. Cabe destacar que ahora todo son apps en los contenidos del sitio, tanto las plantillas de lista como las de biblioteca quedan también representadas como apps, de forma que las nuestras quedan completamente integradas como un elemento más dentro del contenido del sitio.

Parte de página (App Part)

Las aplicaciones tipo Parte de página o App Part5 que es el término original con el que fueron bautizadas, quedan representadas en una página con Web Part Zones como cualquier otra Web Part de SharePoint. Por dentro, estas App Parts no son más que Web Parts que dibu-jan un iframe para mostrar la página en la que representamos todos los componentes de nuestra App Part.

5 A partir de este punto, me referiré a este tipo de aplicaciones como App Part ya que la traducción es literal y probablemente no tendremos una versión oficial en español de este término en la documentación oficial.

68


Figura 2-5. SharePoint 2013 App del tipo App Part

Normalmente, la utilizaremos para proveer al usuario de una funcionalidad más concreta y reducida que con las aplicaciones de Página completa. Por ejemplo, un mapa que sitúe geográ-ficamente proveedores en función de los parámetros que le pasemos a nuestra App Part. He dicho parámetros, exacto, esta Web Part especial que vendrá dada por la clase ClientWebPart del modelo de objetos, también podrá recibir parámetros, ya sea a través de las propiedades del Tool Part como hacíamos hasta ahora con el resto de Web Parts, o como consecuencia de otras acciones del usuario o del contexto de la página. Para agregar nuestras App Parts a una página, solo tendremos que buscar bajo la pestaña “Insertar” de la cinta de opciones, la sec-ción “Piezas” y en ésta tenemos la opción “Elemento de aplicación” que nos mostrará las App Parts disponibles para insertar en la página. También podemos encontrar e insertar las App Parts disponibles bajo la categoría “Aplicaciones” desde el menú de inserción de elementos web.

Figura 2-6. Menú Insertar en SharePoint 2013.

Cuando utilizamos App Parts, no estamos necesariamente limitados a una sola App Part por proyecto de SharePoint App, realmente podemos complementar una app de Página com-

69


pleta, con uno a varias App Parts que hacen las veces de widget o complemento reducido de nuestra App completa, es decir, se complementan.

Acción personalizada (UI Custom Action)

En esta forma de representación, las apps son accedidas de la forma más integrada posible, esto es, mediante botones contextuales en la cinta de opciones (Ribbon) de cualquier página o bien en forma de extensión en los menús contextuales de elementos de lista o biblioteca.

Figura 2-7. SharePoint 2013 App del tipo UI Custom Action

Esta forma de entrada para acceder a la funcionalidad de nuestras apps es realmente inte-resante en escenarios en los que necesitamos que nuestras apps se ejecuten sobre un objeto contextual muy concreto como puede ser él envío por correo de una determinada informa-ción perteneciente a un elemento concreto de una lista, o la activación de algún proceso que afecta a todo un contexto como hacen el resto de acciones de la cinta de opciones.

Las acciones personalizadas se configuran mediante XML, en este XML se configuran todas las propiedades del botón que ejecutará la acción, así como la acción que debe activar. Las acciones pueden ser desde un simple enlace con parámetros que dirija al usuario a una página concreta, hasta una compleja función JavaScript que lleve a cabo operaciones mucho más cos-tosas. Es decir, desde las acciones personalizadas solo tendremos de nuevo código de cliente disponible.

70


Tipos de SharePoint App. Opciones de alojamiento

Hasta ahora, hemos hablado de que las apps están compuestas por diferentes recursos como CSS, páginas o archivos JavaScript, pero no hemos visto donde pueden alojarse dichos recursos y qué opciones tenemos como desarrolladores a la hora de escoger dicho aloja-miento. Según donde se alojen los recursos que hacen funcionar nuestra app, podemos hablar de tres tipos de app, más una cuarta opción más compleja que serían las apps de alojamiento híbrido. Estas opciones son: alojada en un proveedor (Provider-hosted6), auto-alojada en la Nube pública (Autohosted7), alojada en el propio servidor SharePoint en el que se ins-tala (SharePoint-hosted) y, por último, una aproximación híbrida que combina varias de las anteriores.

Apps alojadas en SharePoint (SharePoint-hosted Apps)

Las apps alojadas en SharePoint se instalan directamente en un sitio de SharePoint 2013, al que llamaremos Host Web (el sitio que aloja). Los recursos de nuestra app quedarán comple-tamente aislados bajo un sub-sitio de este Host Web, a este sub-sitio lo llamaremos App Web (el sitio de la app), ya que el sitio en sí representará a nuestra app y todos sus recursos.

Este tipo de alojamiento nos permite acceder, y por tanto reutilizar, todos los artefactos del Host Web en SharePoint, ya que nuestra aplicación obtendrá el contexto de dicho sitio y con ello obtendrá acceso mediante el modelo de objetos de JavaScript a los distintos artefactos del sitio. Y precisamente JavaScript es el único modelo de objetos disponible para este tipo de aplicaciones, ya que no nos está permitido usar ningún modelo de objetos de servidor desde ellas.

Estas aplicaciones se despliegan e instalan cuando se descargan desde el Office Store o el catálogo corporativo de aplicaciones.

6 Dado que los tipos de alojamiento han sido nombrados con combinaciones peculiares que es difícil que sean traducidas dos veces igual, acompaño mis traducciones de estos términos con el término original, que muy probablemente os encontraréis en otras publicaciones.

7 En algunas ocasiones también se les ha llegado a llamar Windows Azure Autoprovisioned Apps, en algunos de los vídeos de formación oficiales.

71


Figura 2-8. Visualización y alojamiento en una SharePoint-hosted App

Apps alojadas en un proveedor (Provider-hosted Apps)

Las apps alojadas en un proveedor incluyen una serie de componentes que están alojados fuera de la granja de SharePoint donde la app está instalada, normalmente estos componentes son alojados por el desarrollador de la propia app aunque se puede dar el caso, bien por res-tricciones de seguridad o bien por una cuestión de costes, en los que el propio consumidor de la app aloja estos componentes externos en servidores administrados por él mismo.

Este tipo de aplicaciones pueden ser alojadas tanto en plataformas web remotas de Microsoft, como es Windows Azure, como en otras plataformas, incluidas las que no son de Microsoft, por lo tanto, podemos decir que la gran ventaja de esta aproximación es que podemos elegir cual-quier servicio de alojamiento (hosting) que exista en el mercado. La comunicación remota con el servidor de SharePoint se puede realizar a través de alguno de los modelos de objetos de cliente existentes, así como a través de los servicios web basados en REST y OData. La autenticación en este escenario puede ser o bien implementando el estándar OAuth para autenticación o bien a través de la biblioteca de JavaScript para autenticación a través de dominios (JavaScript cross-domain library).

El único punto que tenemos que considerar como posible contrapartida a la flexibilidad que nos proporcionan las aplicaciones alojadas en el proveedor, es en el caso de que nosotros mismos seamos los alojadores de dichos componentes externos. En este caso, tenemos la res-ponsabilidad de asegurar el funcionamiento ininterrumpido, así como de actualizar el entorno que aloja los componentes. En resumen, una gran flexibilidad conlleva una gran responsabilidad.

Existen dos opciones a la hora de montar nuestro servidor, hacerlo dentro del firewall cor-porativo donde se encuentre el servidor remoto de SharePoint, o fuera del firewall corporativo. Dependiendo de la opción, habrá diferencias en cuanto a las opciones que podemos utilizar durante el desarrollo. Veamos estas dos opciones.

72


Figura 2-9. Apps alojadas en un proveedor (Provider-hosted App)

Con componentes remotos fuera del firewall

En este escenario podemos utilizar JavaScript o los servicios web REST/OData y la auten-ticación se realiza a través de la biblioteca de JavaScript para autorización a través de dominios (cross-domain library8).

En este caso, la responsabilidad cae completamente del lado del desarrollador a la hora de mantener el aislamiento entre los datos de los diferentes usuarios de la aplicación. Esto es así debido a que el servidor va a quedar alojado directamente en los servidores del proveedor, los que están completamente controlados por él, por lo que tanto la seguridad del servidor como el aislamiento de los datos en el mismo corren a cargo del propio proveedor.

Imaginemos que tenemos una aplicación que necesita una base de datos SQL Server com-pleta para funcionar. En este caso, posiblemente hablaríamos de una aplicación alojada en el proveedor, lo que nos llevaría a tener que alojar algunos componentes en nuestro servidor (siendo nosotros el proveedor), esta base de datos en caso de que el cliente no tuviera posi-bilidad de ubicarla dentro de sus sistemas tendríamos que tenerla en un servidor en nuestros sistemas y, por tanto, quedaría fuera del firewall (la red corporativa) del cliente.

8 Más información sobre cómo utilizar esta biblioteca de JavaScript aquí http://msdn.microsoft.com/en-us/library/fp179927(v=office.15).aspx (en inglés).

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


73


Con componentes remotos dentro del firewall

En este escenario podemos utilizar el lenguaje de programación que deseemos. Para comunicar con SharePoint podremos utilizar cualquiera de los modelos de objetos de cliente o bien los servicios REST/OData, y en este caso, también podremos utilizar el protocolo para autenticación y autorización de apps OAuth.

En este punto, la responsabilidad del desarrollador queda en proveer al cliente con un paquete de instalación completo para implantar los componentes remotos en su servidor remoto que queda dentro de la red corporativa (dentro del firewall). Es decir, siguiendo con el ejemplo anterior en el que nuestra aplicación necesita una base de datos SQL Server propia, proveeríamos al cliente de una copia de seguridad o un instalador que creara todas las bases de datos necesarias en el servidor que correspondiera dentro de su red corporativa. En este caso, al tratarse de un servidor propio del cliente, la gestión y, por tanto, la responsabilidad sobre la seguridad de los datos, queda del lado del propio cliente ya que nosotros no tenemos posibilidad de controlar su red corporativa.

Apps auto-alojadas (Autohosted Apps)

Las apps auto-alojadas se alojan sobre Windows Azure Web Sites9 (una especie de Windows Azure reducido). Al igual que ocurre en con las aplicaciones alojadas en el proveedor, las auto-alojadas quedan en un servidor remoto utilizando recursos de dicho servidor, pero también pueden acceder a los elementos del servidor SharePoint donde se instala la aplicación.

En este caso, como estamos utilizando un sistema de nube pública que aprovisiona recursos de forma automática según la necesidad, cuando nuestra aplicación se instala en el servidor de cualquier cliente, todos los componentes de Windows Azure y SQL Azure son aprovisionados automáticamente sin necesidad de que hagamos algo cada vez. El problema del aislamiento que teníamos con las aplicaciones alojadas en el proveedor aquí desaparece, ya que Azure pro-vee un nuevo Windows Azure Web Site cada vez que se instala la aplicación, garantizando así el aislamiento entre los diferentes usuarios de nuestra aplicación, y lo más importante, quedando la responsabilidad de dicho aislamiento del lado de la propia Microsoft.

Añadido a todo esto cabe destacar una ventaja fundamental, inherente al uso de este tipo de servicios en la Nube, y es que Azure administrará por nosotros el balanceo de carga así como el resto de tareas de mantenimiento y administración que puedan necesitar los sitios de Azure.

9 Aquellos lectores interesados en ampliar información sobre este servicio, pueden hacerlo aquí http://www.windowsazure.com/es-es/home/scenarios/web-sites/

http://www.windowsazure.com/es-es/home/scenarios/web-sites/

http://www.windowsazure.com/es-es/home/scenarios/web-sites/

74


Figura 2-10. App auto-alojada (Autohosted App)

Apps combinadas (Hybrid Apps)

Las apps combinadas no son realmente un cuarto tipo de app, sino que son la representa-ción de lo que supone combinar apps alojadas en SharePoint con algunos componentes en la Nube. Este escenario aporta las ventajas de ambos tipos de despliegue, pudiendo utilizar el modelo de objetos de JavaScript desde los componentes alojados en SharePoint, y teniendo que autenticar mediante OAuth para aquellos que estén en la Nube.

La contrapartida de este escenario es que hay que analizar de forma muy exhaustiva las comunicaciones entre servidores, así como las restricciones de seguridad que podemos encon-trar con el cross-site scripting10 a la hora de acceder a los distintos componentes mediante el modelo de objetos de JavaScript.

Aunque este tipo de combinaciones pueden ser muy variadas, un posible ejemplo de app combinada podría ser una aplicación de gestión de préstamos con interés variable. Esta apli-cación podría concebirse inicialmente como una aplicación de tipo SharePoint-hosted dado que podría crear todas las estructuras de datos en forma de listas dentro del propio sitio de SharePoint. La diferencia con una aplicación clásica de este tipo vendría cuando necesita-

10 Wikipedia provee una definición muy completa del término cross-site scripting para aquellos intere-sados en ampliar información http://es.wikipedia.org/wiki/Cross-site_scripting

75


mos obtener de forma periódica el nuevo índice bursátil para los intereses de los préstamos en los distintos plazos. Estos índices para un mejor rendimiento los obtendríamos desde un componente externo (por ejemplo un web role en Azure) los almacenaríamos en una base de datos intermedia (que podría estar en uno de nuestros servidores) y finalmente accederíamos a dichos datos a través de un servicio web, también alojado en nuestros servidores.

Este servicio web sería accedido desde nuestra aplicación inicialmente concebida como SharePoint-hosted y que ahora ya sería una aplicación que combina componentes de los dis-tintos tipos de aplicación.

76


Resumiendo

Para acabar, vamos a resumir de una forma gráfica los tres tipos básicos de alojamiento que hemos visto a lo largo de las páginas anteriores, a continuación tenemos la tabla con la información más importante resumida. De ella sacaremos nuestras propias conclusiones a la hora de decidirnos por un tipo u otro de aplicación desde el punto de vista del alojamiento.

TIPO DE APP CARACTERISTICAS ProgramaciónSharePoint-hosted La más sencilla de implementar y alojar. En ella, todos los componentes de la

aplicación se alojan directamente dentro de la granja de SharePoint del usua-rio. Cada instalación de dicho tipo de aplicaciones queda como un sub-sitio del mismo aislado.

Esta opción solo se recomienda cuando no es necesario acceder a ningún servi-cio alojado fuera de la granja de SharePoint.

Se pueden utilizar elementos del sitio de SharePoint (listas, elementos, Web Parts).

HTML y JavaScript

Provider-hosted Esta opción requiere un servidor dedicado o al menos un sistema de alojamiento que garantice el aislamiento de los datos de los distintos clientes (y sus usuarios). El servidor puede estar dentro o fuera del firewall corporativo del cliente. El desa-rrollador es el responsable de proveer el servidor o bien el paquete de instalación completo.

El desarrollador es el responsable del aislamiento.

Aporta mayor flexibilidad pero también una mayor responsabilidad.

Se pueden usar elementos del sitio de SharePoint (listas, elementos, Web Parts).

HTML, JavaScript con restricciones cross-domain y servicios web REST/OAuth

Autohosted Similar al anterior, pero con la diferencia de que los componentes queda automá-ticamente aprovisionados en Windows Azure.

Los componentes Web y SQL se aprovisionan automáticamente al instalar la aplicación.

La administración y mantenimiento de todos los componentes así como el aisla-miento de los datos corre a cargo de Microsoft.

Se pueden usar elementos del sitio de SharePoint (listas, elementos, Web Parts).

HTML, JavaScript con restricciones cross-domain y servicios web REST/OAuth

77


Conclusiones

Hace unos años trabajando en un proyecto de extranet corporativa para una empresa relacionada con la banca española, se dio el problema de que era totalmente imposible desde el punto de vista de la seguridad de dicha empresa acceder a la caché global de ensamblados (GAC) de Windows. Por esta razón, la solución que por aquel entonces desarrollamos fracasó dado que no podía ser concebida sin introducir ciertos ensamblados en la GAC. Esta anécdota que es real, y viene precisamente a cuento de la importancia que tiene el aislamiento del ser-vidor de nuestros desarrollos.

A lo largo de este capítulo hemos recorrido de forma teórica lo que supone el nuevo modelo de desarrollo para la plataforma SharePoint. Quizás lo más significativo de este modelo no esté en la tecnología que utiliza, y probablemente tampoco en cómo se desarrollan las aplicaciones, lo que mayor valor le debe dar este modelo a todos los desarrolladores es la capacidad de generar nuevas oportunidades de negocio de una forma sencilla y muy segura para los clientes finales de nuestras aplicaciones. Si esto se consigue finalmente, todas las novedades presen-tadas y el esfuerzo que los desarrolladores hacemos cada vez que hay un cambio de modelo como éste, habrán valido la pena.

Capítulo 3: Desarrollo de SharePoint Apps

P78

El objetivo de este capítulo es dar una visión más en detalle de cómo se desarrollan las nuevas apps de SharePoint 2013.

En primer lugar se verá un paso a paso de cómo, partiendo desde cero, se puede desa-rrollar una app de SharePoint. Luego veremos más en detalle aquellas buenas prácticas de maquetación y diseño con ejemplos reales. Y finalmente se verán varios ejemplos del modelo de objetos cliente y REST accediendo a SharePoint desde las apps.

Mi primera app

Introducción

Una vez vistos los aspectos teóricos del nuevo modelo de aplicaciones que presenta SharePoint 2013 con las apps, es el momento de untarse las manos haciendo aquello que mejor saben hacer los desarrolladores: desarrollar. Veremos que a la hora de desarrollar apps para SharePoint 2013, Visual Studio 2012 se encarga de prácticamente todo el trabajo tedioso de configuración de proyectos, dejando al desarrollador un precioso lienzo a su disposición.

Así pues, veremos cómo configurar y desarrollar nuestra primera app basándonos en la arquitectura SharePoint-hosted Apps, y partiendo del tipo más simple de app, la App de Página completa (Immersive Full Page App). Como ya sabemos, esta arquitectura permite desplegar apps dentro del propio servidor donde está instalado SharePoint 2013. Por lo tanto, es ideal para una fase inicial de desarrollo y pruebas. Y además, como veremos, es el modelo “más cercano” a lo que conocemos de SharePoint 2010, por lo que es perfecto para asentar conocimientos y fijar las bases del nuevo modelo de programación que suponen las SharePoint apps. Seguidamente, veremos cómo desarrollar los otros dos tipos de apps disponibles, App Parts y de Acción personalizada (UI Custom Actions). De esta manera, cubrimos todo el aba-

79


nico de posibilidades, y podremos conocer las diferencias en cuanto a desarrollo, de un tipo de app con el resto.

Pero antes siquiera de abrir Visual Studio 2012, se requiere de una serie de configuracio-nes en el entorno de desarrollo a fin de evitar problemas posteriores, y poder desplegar apps correctamente. ¿Empezamos?

Preparación del entorno de desarrollo

Lo primero a aclarar es que los pasos que se siguen a continuación se aplican a una máquina con una instancia de SharePoint 2013 instalada localmente. Lo más cómodo y seguro es tener una máquina virtual aislada a fin de evitar posibles problemas en la máquina anfitrión. Concretamente, para la realización de los distintos laboratorios que veremos, parto de una máquina virtual con Windows Server 2008 R2 x64 como sistema operativo, SQL Server 2012, SharePoint 2013 y Visual Studio 2012. En cuanto a las especificaciones hardware, es importante, para un buen rendimiento y no desesperar, dar cuanta mayor RAM sea posible. Microsoft reco-mienda para un entorno de desarrollo un mínimo 6 GB de RAM. Como referencia, mi máquina tiene 10 GB de RAM, y 50 GB de disco duro. ¿Bien hasta ahora? Seguimos.

Sitio del Desarrollador

El primer paso, y más sencillo, es crear una colección de sitios bajo una aplicación web en SharePoint 2013 con un sitio raíz creado a partir de la nueva plantilla de sitio, “Sitio de Desarrollador”. Ésta es una plantilla específica para instalar y probar las apps que vayamos desarrollando. No podremos desplegar apps desde Visual Studio 2010 en una colección de sitios que esté construido con otra plantilla.

80


Figura 3-1. Plantilla de Sitio de desarrollador.

Reservar un Dominio Aislado para las apps

El siguiente paso es crucial en el desarrollo de una SharePoint-hosted App, y muy impor-tante tenerlo claro, ya que es clave para comprender el funcionamiento de las SharePoint apps. Necesitamos reservar el nombre para un dominio, a partir del cual formar las direcciones de los sitios web que contienen las apps. La idea es sencilla: cada app que creamos se almacena ais-ladamente en su propia aplicación web, ya se encuentre éste en el mismo servidor donde está instalado SharePoint (SharePoint-hosted Apps), en Azure (Autohosted Apps), o en cualquier otro servidor que queramos (Provider-hosted Apps), como se ha visto anteriormente. Ésta es precisamente una de las grandes ventajas de las apps, que se ejecutan bajo un proceso aislado de modo que en ningún caso pueden afectar a SharePoint, ni al servidor en sí.

En el caso de una SharePoint-hosted App, ¿quién, dónde y de qué tipo es el sitio que se crea? Pues bien, cuando instalamos una app, el propio SharePoint 2013 se encarga de crearle un sitio (SPWeb), a partir de la nueva plantilla “APP#0 App Template”, bajo el sitio donde instalamos la app. Este sitio que se crea se conoce como App Web. Y el sitio donde se instala la app, es decir, el SharePoint “anfitrión”, se conoce como Host App.

81


Figura 3-2. Relación entre una Host Web y una App web.

¿Qué ocurre cuando instalamos la app en distintos sub-sitios? Bajo cada uno de estos sub-sitios, se creará a su vez un sitio hijo, que es el que contendrá finalmente a la SharePoint-hosted App. Es decir, cada app se define a nivel de sitio (SPWeb), y vive aisladamente con el resto de apps en su propio sitio, como sub-sitio del sitio donde se instaló. ¡Vaya trabalenguas!.

Hay que aclarar que una app web no se crea únicamente para una app del tipo SharePoint-hosted, sino que también se crea en el caso de que nuestra app, sea del tipo que sea, contenga componentes propios de SharePoint como Listas, Workflows, Características (Features), etc. Es decir, una app del tipo Cloud-hosted (Provider-hosted o Autohosted) puede tener tanto componentes en la Nube, como componentes propios de SharePoint. Es en el caso de tener algún componente de SharePoint, cuando se crearía una app web para así poder alojarlos. Estaríamos entonces antes un caso “mixto” de aprovisionamiento de apps.

82


Figura 3-3. Caso mixto de aprovisionamiento de SharePoint Apps

¿Y bajo qué dirección se crea dicho sitio? Aquí es donde entra en juego el dominio aislado del que hablamos al principio. Por ejemplo, supongamos que tenemos una intranet con la siguiente dirección: laintranet.miempresa.com. Un posible dominio aislado que podemos reservar sería el siguiente: apps.miempresa.com. Si lo hacemos así, al instalar una nueva instan-cia de una app se creará un sitio para la misma con una URL similar a http[s]: App-Prefijo-a1b2c3d4.apps.miempresa.com, donde la cadena a1b2c3d4 es un identificador único que se le asigna aleatoriamente a cada instancia de una app. Entendiendo por instancia, cada app que instalamos a nivel de sitio de SharePoint. Es decir, dentro una misma colección de sitios, pode-mos tener distintas instancias de una app, una por cada vez que la instalemos en cada sitio.

Por último, antes de pasar a ver cómo crear dominios aislados para las apps, queda en el aire la cuestión de cómo registrar esos dominios de manera que sean accesibles. Tenemos la posibilidad clásica de usar un servidor de DNS, que es la opción recomendada para un entorno de producción. Pero para un entorno de desarrollo, es perfectamente válido utilizar el fichero Hosts de Windows. Para alegría nuestra, Visual Studio 2012 se encarga de hacer las modifica-ciones oportunas en el fichero Hosts por nosotros, en el momento de compilar y desplegar una nueva app.

Y bien, ¿cómo reservamos un dominio aislado para las apps? Con nuestro querido amigo Windows PowerShell. Para SharePoint 2013 se han creado una serie de nuevos comandos, o cmdlets como se les conoce en Windows PowerShell. Uno de ellos es el que nos permite reser-var el dominio aislado para las aplicaciones, tal que así:

83


Set-SPAppDomain “apps.miempresa.com”

Para lanzar este cmdlet, y los que vienen a continuación, es preciso hacerlo con un usuario que sea administrador de la granja, y también iniciar la instancia de Windows PowerShell como Administrador. También es importante, asegurarse de que los servicios spadminv4 y sptimerv4 están levantados. Para ello podemos lanzar los siguientes comandos:

net start spadminv4 net start sptimerv4

Por último, podemos comprobar que efectivamente, se ha registrado correctamente el dominio aislado, usando el cmdlet Get-SPAppDomain.

Figura 3-4. Resultado del cmdlet Get-SpAppDomain

Servicios y aplicaciones de servicio

Bien, ya hemos reservado un dominio para aislar las apps, pero siento decir, amigo lector, que aún quedan unos cuantos pasos más antes de dar por terminada la configuración del entorno de desarrollo. El siguiente es iniciar, o más bien, asegurarnos de que está iniciado, tanto la instancia del servicio en el servidor, como la aplicación de servicio, que permite ejecu-tar apps localmente. Estamos hablando de la aplicación de servicio App Management Service Application (Aplicación de Servicio de Administración de Apps). Normalmente, a no ser que

84


explícitamente hayamos desmarcado la casilla, tanto servicio como aplicación de servicio se crean al lanzar el Asistente de Configuración de la Granja.

Figura 3-5. Aplicación de servicio App Management Service en el Asistente de Configuración de la Granja.

Después, debemos comprobar que la instancia del servicio en el servidor está iniciada (Started), accediendo desde la Administración central, a Administrar los servicios del servi-dor (Manage Services on server).

Figura 3-6. Comprobación de que el servicio está iniciado.

Y queda otra aplicación de servicio, algo más complicada tanto de crear (es necesario crearla manualmente), como de entender por qué es necesaria. Nos referimos a la aplicación de servicio Microsoft SharePoint Foundation Subscription Settings Service Application (es corto el nombre…) Al igual que con la aplicación de servicio anterior, debemos asegurarnos tanto de que está creada la aplicación de servicio, como también de que está iniciada la instan-cia del servicio en servidor.

Para entender por qué necesitamos esta aplicación de servicio conviene tener en cuenta en todo momento, que el modelo de programación de las Sharepoint apps fue desarrollado inicialmente para Office 365. Es por ello, que para poder trasladar dicho modelo a SharePoint 2013, el entorno para ejecutar las Sharepoint apps debe de configurarse a nivel de “inquilino”

85


o como es más conocido, tenant. Es decir, como una entidad que contrata un servicio en la Nube. Este concepto de tenant tiene todo el sentido dentro del contexto de Office 365, sin embargo, resulta confuso que para un entorno local, sea necesario crear y configurar “inquili-nos” que consuman servicios. Aun así, necesitamos emular el sistema de tenants en un entorno local, y es por ello por lo que necesitamos la anteriormente citada aplicación de servicio. Sin este servicio, no sería posible crear tenants, lo que a su vez no haría posible instalar y ejecutar apps. Cuando se crea una instancia de Subscription Settings Service Application, el servicio automáticamente crea un “inquilino” o tenant por defecto, que se corresponde con todos los sitios y colecciones de sitios de la granja. Es decir, imaginemos a los sitios y colecciones de sitios de la granja, como una “persona” que ha contratado un servicio. Del mismo modo que para Office 365, una persona contrata un servicio, y por ello, tiene su tenant correspondiente que le permite consumirlo.

Figura 3-7. Comprobación de que la aplicación de servicio está iniciada.

Así pues, tanto para iniciar las dos instancias de los servicios en servidor hacemos uso del siguiente comando de Windows PowerShell:

Get-SPServiceInstance | where{$_.GetType().Name –eq “AppManagementServiceInstance” -or $_.GetType().Name -eq “SPSubscriptionSettingsServiceInstance”} | Start-SPServiceInstance

Figura 3-8. Secuencia de comandos para iniciar las instancias de servicio.

86


En caso de que los servicios ya estuvieran iniciados, obtendríamos el siguiente resultado:

Figura 3-9. Sercvicios ya iniciados.

A continuación, comprobamos que ambas aplicaciones de servicio están ejecutándose, verificando que su estado es “Online”:

Get-SPServiceInstance | where{$_.GetType().Name –eq “AppManagementServiceInstance” -or $_.GetType().Name -eq “SPSubscriptionSettingsServiceInstance”}

Figura 3-10. Comprobación de que los servicios están ejecutándose.

Por último, queda configurar ambas aplicaciones de servicio para indicar la cuenta de usuario con la que van a ejecutarse, la agrupación de aplicaciones (Application Pool) y la base de datos en la que se apoyan. Para la cuenta de usuario, necesitamos un SPManagedAccount. Si ya tenemos uno, nos saltamos el siguiente paso, en el que lo creamos:

$account = New-SPManagedAccount

87


Figura 3-11. Creacón de una cuenta de usuario administrada (Managed Account).

El comando anterior pedirá que se introduzca el usuario en formato “dominio\usuario” y la contraseña del mismo. Cuando ya tenemos el SPManagedAccount, lanzamos los siguientes coman-dos secuencialmente:

$account = Get-SPManagedAccount “dominio\usuario” $appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account $appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account $appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName SettingsServiceDB $proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName AppServiceDB $proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

Y finalmente, el último y definitivo paso (bueno, casi) es crear el “inquilino” o tenant del que hablamos anteriormente. En realidad, como se ha dicho, solo necesita-mos crear un nombre con el que identificar a la identidad que va a consumir los servicios de manera local. Para ello tenemos el siguiente comando, el cual nos pedirá confirmación:

Set-SPAppSiteSubscriptionName -Name “app” -Confirm:$false

88


Configurar Internet Explorer

Una vez reservado el dominio aislado, y configurado las aplicaciones de servicio, tenemos el entorno de desarrollo casi a punto. Nuestra primera app ya casi tiene un hogar donde nacer y crecer feliz. Falta un detalle: configurar Internet Explorer para que nos permita navegar hacia el dominio que hemos creado anteriormente. Para ello, seguimos las siguientes instrucciones:

1. Abrimos la configuración de Internet Explorer.

2. En la pestaña “Conexiones”, clic en “Configuraciones LAN”.

3. Desmarcamos “Detectar configuraciones automáticamente”.

4. Seleccionamos “Usar un servidor proxy para la LAN”.

5. Marcamos “No usar servidor proxy para direcciones locales”.

6. Hacemos clic el botón “Avanzado” y añadimos a la lista de excepciones el nombre de nuestro dominio aislado, tal que así: *.apps.miempresa.com.

7. Cerramos todo, haciendo clic en “OK”.

Las configuraciones que hemos hecho, deben haber quedado así:

Figura 3-12. Configuraciones en Internet Explorer

89


Y ahora sí, si hemos llegado hasta aquí sanos y salvos, ya podemos decir que tenemos un entorno local de desarrollo a punto para las SharePoint apps. En cualquier caso, solo recordar que estas configuraciones son únicamente necesarias para el caso de querer desarrollar apps localmente. Si nuestra intención es desarrollar apps para para Office 365, Microsoft ya nos dejó un entorno preparado, e incluso la posibilidad de usar una herramienta de desarrollo online, Microsoft NAPA, de la cual hablaremos más adelante.

¡Hola Mundo!

¿Por qué será que todo programador se inicia en un lenguaje con un “Hola Mundo”? ¿Es acaso un vestigio de una humanidad antigua, que perdura en nuestros días? ¿O tal vez es cierta la leyenda urbana que en caso de no iniciarse de tal modo, caerá sobre nosotros años de penuria “programacional”? Bueno, desvaríos aparte, y fuere como fuere, nosotros no vamos a ser más originales que nadie, por lo que pueda pasar. Así pues, una vez configurado nuestro entorno de desarrollo, vamos a ver cómo crear nuestra primera SharePoint App. Con la arqui-tectura SharePoint-hosted App como partida, crearemos en primera lugar una app de Página completa donde simplemente se muestre el inmortal “Hola Mundo”. A continuación, veremos el resto de tipos de apps, para tener así una visión global del alcance y las posibilidades de este nuevo modelo de programación.

App de Página completa

Veamos a continuación un paso a paso de como crear una app de este tipo.

Abrimos Visual Studio 2012 como Administrador...

…Y creamos un proyecto nuevo. Bajo el lenguaje de programación con el que más cómodo nos sintamos (Visual Basic en mi caso), encontramos la nueva sección Office/SharePoint11. Esta sección contiene plantillas de proyectos tanto para SharePoint, como para Office. Si desplega-mos el (+), encontramos una sub-sección específica para las apps, y es aquí donde podemos seleccionar “App for SharePoint 2013”.

11 Es necesario instalar las Microsoft Office Developer Tools for Visual Studio 2012 (requiere la versión Premium como mínimo). Se puede descargar mediante la aplicación Web Platform Installer 4.0, que puedes encontrar en http://www.microsoft.com/web/downloads/platform.aspx. O también desde el siguiente enlace directo: http://go.microsoft.com/fwlink/?LinkID=261869

90


Figura 3-13. Plantilla de proyecto para las SharePoint Apps.

Seleccionar la arquitectura

Figura 3-14. Configuración de la App en la plantilla de Visual Studio 2012.

91


Llegamos a la pantalla de la imagen, donde debemos seleccionar, en primer lugar, el sitio SharePoint donde probar nuestra app. Este sitio SharePoint, como vimos en la configuración del entorno de desarrollo, debe ser un sitio creado a partir de la plantilla Sitio del Desarrollador. También especificamos la arquitectura de nuestra app. En nuestro caso, SharePoint-hosted.

Repaso de los componentes del proyecto

Una vez creado el proyecto, podemos ver que la plantilla de Visual Studio 2012 que hemos utilizado para crear la SharePoint-hosted App, automáticamente incluye una serie de módulos para desplegar los archivos que la componen. Concretamente tenemos un módulo para las imágenes (Images), donde por defecto se encuentra el logo de la app. También un módulo para las distintas páginas (Pages). Otro para archivos CSS (Content). Y finalmente un módulo para archivos JavaScript (Scripts). Nos debe llamar la atención que se incluye en éste, la librería de jQuery, tanto en su versión reducida, como también la ampliada con comentarios, especial para desarrollos. En el siguiente capítulo dedicado a la maquetación y diseño de apps, estu-diaremos en profundidad las particularidades de los archivos que componen una SharePoint-hosted App.

En definitiva, el proyecto que tenemos se parece mucho al proyecto que podríamos tener en una solución para SharePoint 2010. Y es que en esencia lo que estamos haciendo es preci-samente eso, construir una solución de SharePoint clásica, con sus Características (Features) y demás componentes, para desplegarla en el sitio web, mejor dicho, la app web, que contendrá nuestra app.

Figura 3-15. Plantilla de proyecto de Visual Studio 2010 para una SharePoint-hosted App.

92


Un primer despliegue

El proyecto que tenemos, aún sin haber hecho nada, ya tiene una serie de archivos fun-cionales per se, que dotan de una funcionalidad por defecto a la app para tener un punto de partida a partir del cual seguir trabajando. ¿Y cuál es esa funcionalidad por defecto? Pues casualmente, resulta que es un “Hola Mundo” J. Por tanto, hacemos “deploy” del proyecto, y si toda va bien, Visual Studio 2012 nos premiará con un “Succesfully installed App for SharePoint”.

Una vez desplegada la app, abrimos nuestro Sitio de Desarrollador, y vemos que en la página de inicio hay una sección Apps in Testing, bajo la cual aparece nuestra recién desple-gada app.

Figura 3-16. Apps in Testing en el Sitio de Desarrollador.

Si queremos ver a nuestra app en acción, debemos ir a “Ver el Contenido del Sitio”, donde aparece un listado con todas las apps instaladas.

Figura 3-17. Listado de Apps en el Contenido de Sitio.

Haciendo clic en nuestra app, enlazamos con la página por defecto de la App Web que tiene el comportamiento por defecto de la app, y que hace las veces de la app de Acción per-sonalizada que andábamos buscando.

93


Figura 3-18. Resultado de la app Hola Mundo.

Y ya tenemos nuestra primera app para SharePoint 2013. Fácil, ¿verdad? Obviamente, Visual Studio 2012 lo ha hecho casi todo, por no decir todo. Es ahora donde empieza realmente nues-tro trabajo como desarrolladores. Pero una vez que ya tenemos la app desplegada e instalada, resulta más fácil hacer las modificaciones que tengamos que hacer, añadir los componentes que tengamos que añadir, y hacer de nuestra app el producto que queramos que sea.

94


App Parts

El proyecto que tenemos hasta ahora tiene la estructura más básica que un proyecto de SharePoint apps puede tener. Tenemos únicamente una página ASP.NET (además del resto de archivos CSS, JavaScript, etc.), con la que construimos una app de Acción personalizada. No obstante, dentro del mismo proyecto, podemos agregar más apps de los dos tipos que res-tan, App Parts y de Acción personalizada. Podemos verlos agregando un nuevo elemento al proyecto.

Figura 3-19. Tipos de Apps disponibles en SharePoint 2013.

Junto con elementos que ya conocemos como son Workflows, Módulos, Columnas de sitio, etc., tenemos el elemento Client Web Part (Host Web) que se corresponde con una App Part, y el elemento UI Custom Action (Host Web).

Como ya hemos visto anteriormente, una App Part es básicamente un iFrame que se inserta en una página de SharePoint, del mismo modo que insertaríamos una Web Part. El contenido de ese iFrame es una página web que nosotros especificamos. Es importante no confundir una App Part con una Web Part, ya que aunque en apariencia final puedan ser idénticos, son con-ceptos completamente distintos que se apoyan en tecnologías distintas.

En un proyecto de SharePoint Apps real, por organización y limpieza, puede ser más inte-resante tener por cada tipo de app un proyecto de Visual Studio 2012 distinto. En nuestro

95


caso, vamos a agregar al proyecto que ya tenemos un nuevo elemento del tipo Client Web Part (Host Web), es decir, una App Part, de manera que aunque en apariencia tendremos una única app que instalar, en realidad serán tres (contando el UI Custom Action App que añadiremos después).

Así pues, añadimos una Client Web Part y la llamamos App Part. Una vez añadido, Visual Studio 2012 nos muestra automáticamente el fichero Elements.xml del mismo. En realidad, una App Part, al igual que una app de Acción personalizada (UI Custom Action), está com-puesta únicamente del fichero Elements.xml. Es dentro de este fichero, donde se hacen las configuraciones, y se referencian los archivos necesarios de los que se sirven las apps para su funcionamiento.

El aspecto que muestra el fichero Elements.xml por defecto es el siguiente:

<?xml version=”1.0” encoding=”utf-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <ClientWebPart Name=”Mi App Part” Title=”Mi App Part Title” Description=”Mi App Part Description” DefaultWidth=”300” DefaultHeight=”200”> <Content Type=”html” Src=”” /> </ClientWebPart> </Elements>

Con la etiqueta ClientWebPart se instancia la App Part y se definen las propiedades bási-cas de ésta, como son el nombre, título, descripción y también la anchura y altura del iFrame que lo contiene. Para especificar el contenido de la App Part, o lo que es lo mismo, qué página web se muestra en el iFrame, está la etiqueta Content. En esta etiqueta tenemos el atributo Src para especificar el origen de la página que se mostrará en la App Part, y el atributo Type¸ con el que se dice de qué tipo es la página. Finalmente, para dar propiedades de configuración a la App Part, del mismo modo que podemos dar propiedades de configuración a una Web Part, tenemos las etiquetas Properties/Property.

<Properties> <Property Name=”nombre” Type=”string” RequiresDesignerPermission=”true”

96


DefaultValue=”Mundo” WebCategory=”Mis Propiedades” WebDisplayName=”Nombre”> </Property> </Properties>

El concepto es sencillo, la forma de configurar una App Part, es a través de la QueryString. Y los parámetros de configuración que van en ella, los definimos en el documento Elements.xml con las etiquetas Properties/Property. Podemos añadir tantas propiedades de configuración como queramos. Por cada propiedad, de manera similar a las propiedades de configuración de una Web Part, especificamos un nombre y el tipo, entre cuatro tipos posibles: cadena de texto (string), entero (Int), lógico (bool) y enumerado (Enum). También especificamos si se requieren permisos de diseñador para editar la propiedad, el valor por defecto de la misma, y el grupo en el que ubicar la propiedad dentro del panel de configuración de la App Part. Y, por último, el nombre de la propie-dad dentro del grupo mencionado.

Una vez tenemos las propiedades definidas, debemos volver a la etiqueta Content, para agregar las propiedades que hemos definido, en la QueryString de la dirección de la página que establecimos en el atributo Src. Para ello, debemos seguir el siguiente formato prede-finido: ?prop1=_prop1_&prop2= _prop2_& prop3=_prop3_. Por lo que según todo lo dicho, el fichero Elements.xml para nuestra primera App Part, debe quedar de la siguiente manera (podemos substituir todo el contenido, por el que sigue):

<?xml version=”1.0” encoding=”UTF-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <ClientWebPart Title=”Hola Mundo” Name=”Hola Mundo” Description=”Mi primer AppPart!.” > <Content Src=”~appWebUrl/Pages/AppPart.aspx?nombre=_nombre_” Type=”html”/> <Properties> <Property Name=”nombre” Type=”string” RequiresDesignerPermission=”true” DefaultValue=”Mundo” WebCategory=”Mis Propiedades” WebDisplayName=”Nombre”> </Property> </Properties> </ClientWebPart> </Elements>

97


Si nos fijamos, en el atributo Src de la etiqueta Content, estamos haciendo referencia a la página AppPart.aspx, que aún no hemos creado. Por lo que el siguiente paso es crear dicha página, dentro del módulo Pages. En esta página, lo que haremos es muy sencillo: analizamos la QueryString en busca del parámetro “nombre”. Una vez tenemos el valor del mismo, lo inserta-mos en una etiqueta <span> al principio de la página. El resultado será que la App Part, nos dará un “¡Hola Mundo!” por defecto, o bien configuramos la propiedad “nombre” dentro del panel de configuración, para obtener un saludo personalizado.

<%@ Register Tagprefix=”WebPartPages” Namespace=”Microsoft.SharePoint.WebPartPages” Assembly=”Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <WebPartPages:AllowFraming ID=”allowframing” runat=”server” /> <html> <body>  <h1>¡Hola <span id=”nombre”></span>!</h1>  <script lang=”javascript”> var params = document.URL.split(“?”)[1].split(“&”); var nombre; // Iterativamente extraemos los valores de la Query String, y // almacenos su valor en variables. for (var i = 0; i < params.length; i = i + 1){ var param = params[i].split(“=”); if (param[0] == “nombre”) nombre = decodeURIComponent(param[1]); } // Finalmente, buscando la etiqueta correspondiente a partir de su // ID, y le insertamos el texto correspondiente. document.getElementById(“nombre”).innerText = nombre; </script> </body> </html>

98


Ahora ya lo tenemos todo, por lo que solo nos queda volver a desplegar el proyecto y probar nuestra App Part. Una vez hecho, vamos a cualquier página que tenga elementos de publicación. La página por defecto del Sitio de Desarrollador nos vale. Editamos la página, y bajo la cinta contextual (Ribbon), nos vamos a la pestaña “INSERT”, y vemos que además de poder insertar Web Parts, como hasta ahora en las ediciones anteriores de SharePoint, tene-mos también la opción de insertar App Parts.

Figura 3-20. Botón para insertar App Parts desde la cinta contextual (Ribbon)

En el listado que aparece debemos encontrar nuestra recién creada App Part, con el nom-bre de “Hola Mundo”.

Figura 3-21. Listado de App Parts disponibles en un sitio de SharePoint 2013.

Lo añadimos, y automáticamente lanzamos un cordial saludo al “mundo mundial”.

Figura 3-22. Resultado de nuestra primera App Part

Si somos curiosos (y lo somos), podemos indagar un poco en el funcionamiento interno de la App Part. Mediante las herramientas del desarrollador de Internet Explorer (F12 para los

99


amigos), podemos comprobar cómo efectivamente, una vez insertamos la App Part en la página, lo que realmente estamos insertado es sencillamente un iFrame que muestra el contenido de una página externa.

Figura 3-23. iFrame generado por una App Part!

Además, en la URL de la propiedad Src del iFrame, vemos como automáticamente se forma la QueryString con las propiedades de configuración que especificamos,

http://app-b85358d732ed70.apps.devsite.local/HolaMundoApp/Pages/AppPart.aspx?nombre=Mundo

Lo último que nos queda por ver es el panel de configuración de la App Part, para com-probar que los parámetros de configuración que especificamos en el fichero Elements.xml, efec-tivamente aparecen bajo el grupo y nombre que indicamos. Además, según la lógica que establecimos en la página que referenciamos en la App Part, cambiando la propiedad nombre, cambiaremos el destinatario del saludo. Para ello, editamos la página de nuevo y editamos la App Part, del mismo modo que editaríamos una Web Part.

100


Figura 3-24. Panel de configura-ción de la App Part.

Vemos, como a parte de las propiedades que podemos encontrar en cualquier Web Part, y que son comunes con una App Part, tenemos una sección con el grupo y las propiedades que definimos en el Elements.xml. Si por ejemplo, cambiamos el valor de la propiedad Nombre, deberíamos cambiar el destinatario del saludo, según la lógica que implementamos en la página.

Figura 3-25. Resultado de la App Part una vez modificadaos los parámetros de configuración.

Y hasta aquí llegamos con la configuración y desarrollo de nuestra primera App Part. Como vemos, es un ejemplo muy sencillo, pero sienta las bases de futuros desarrollos más complejos. Como se puede vislumbrar, el potencial de las App Parts es incrustar en páginas SharePoint

101


contenido de cualquier tipo, desarrollado con prácticamente cualquier tecnología, y con la ventaja de aislar a SharePoint de todo el procesamiento.

UI Custom Actions Apps

Para terminar de ver y “tocar” todos los tipos de apps que hay disponibles, nos falta hacer nuestro particular “Hola Mundo” con una UI Custom Action App. Este tipo de app permite crear botones personalizados en la cinta contextual, y también en el menú desplegable de un elemento de lista. Si hemos hecho alguna personalización de este tipo para SharePoint 2010, la forma de proceder es prácticamente la misma. Una vez agregado al proyecto de SharePoint App un elemento del tipo UI Custom Action (Host Web), automáticamente Visual Studio 2012 nos muestra el fichero Elements.xml del mismo, al igual que ocurría con las App Parts. Dentro de dicho fichero crearemos los botones personalizados para la cinta contextual, o los enlaces en el menú desplegable, referenciando siempre éstos a páginas externas donde se realiza la lógica de negocio que queramos. Para implementar dicha lógica, podemos usar parámetros del elemento asociado con el botón personalizado, como su ID y título, la lista o sitio al que pertenece, etc. Bueno, como diría aquel, “no lo explico, lo hago”.

Volvemos a añadir un elemento al proyecto que tenemos; esta vez del tipo UI Custom Action App (Host Web). Le damos como nombre CustomAction. Automáticamente se abre el fichero Elements.xml asociado. El aspecto del mismo es el siguiente:

<?xml version=”1.0” encoding=”utf-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>   <CustomAction Id=”f0dca5d0-ed9d-484c-a4e4-09c4f89efb36.HostWebCustomAction1” RegistrationType=”List” RegistrationId=”100” Location=”EditControlBlock” Sequence=”100” Title=”Invoke ‘HostWebCustomAction1’ action”>  <UrlAction Url=”~remoteAppUrl/Default.aspx?{StandardTokens}” /> </CustomAction> </Elements>

102


Por medio de la etiqueta CustomAction definimos una acción personalizada con sus pará-metros, del mismo modo que haríamos en SharePoint 2010. Por defecto, tenemos una Acción personalizada asociada al menú desplegable (EditControlBloc), para cada elemento de una lista genérica. Y para definir la acción que se lleva a cabo, está la etiqueta UrlAction, al igual que en SharePoint 2010. Como vemos, la forma de trabajar es idéntica con respecto a la versión anterior de SharePoint. La novedad en este punto, es que en el atributo Url podemos formar parámetros en la QueryString, cuyo valor provenga de una palabra reservada, que indica infor-mación sobre el sitio donde está alojada el botón. Esto lo veremos una vez hayamos sustituido el contenido del fichero Elements.xml por el que sigue:

<?xml version=”1.0” encoding=”utf-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <CustomAction Id=”47708c0a-505a-4db1-b424-989328b7abfb.CustomAction” RegistrationType=”List” RegistrationId=”101” Location=”EditControlBlock” Sequence=”114” Title=”¡Hola Mundo!”> <UrlAction Url=”~appWebUrl/Pages/CustomAction.html?HostUrl={HostUrl}& Source={Source}&ListURLDir={ListUrlDir}& ListID={ListId} &ItemURL={ItemUrl}&ItemID={ItemId}”/> </CustomAction> <CustomAction Id=”75dd24d9-0c16-4ef5-be0a-f52ed0e620fa.CustomAction” RegistrationType=”List” RegistrationId=”101” Location=”CommandUI.Ribbon” Sequence=”115” Title=”Invoke custom action”> <CommandUIExtension> <CommandUIDefinitions> <CommandUIDefinition Location = “Ribbon.Documents.Manage.Controls._children”> <Button Id=”Ribbon.Library.Connect.PropertyViewer” Alt=”¡Hola Mundo!” Sequence=”100” Command=”Invoke_CustomAction” LabelText=”¡Hola Mundo!” TemplateAlias=”o1”

103


Image32by32=”/_layouts/15/1033/images/formatmap32x32.png” Image32by32Left=”-137” Image32by32Top=”-137”/> </CommandUIDefinition> </CommandUIDefinitions> <CommandUIHandlers> <CommandUIHandler Command=”Invoke_CustomAction” CommandAction= “~appWebUrl/Pages/CustomAction.html?HostUrl={HostUrl} & Source={Source}&ListURLDir={ListUrlDir}& SelectedListID={SelectedListId}& SelectedItemID={SelectedItemId}”/> </CommandUIHandlers> </CommandUIExtension> </CustomAction> </Elements>

Definimos dos Acciones personalizadas, una para el menú despegable de un elemento de una biblioteca de documentos (nótese el RegistrationID=”101”), y otro para el mismo elemento, pero en este caso en forma de botón en la cinta contextual.

Para ambos casos, la forma de proceder sigue siendo la misma con respecto a SharePoint 2010. Solo cambia el hecho que comentábamos anteriormente, de poder enviar parámetros referentes al elemento que desencadena la acción, en la QueryString de la página que contiene la lógica. Concretamente, si nos fijamos en el valor del atributo Url de la etiqueta UrlAction, vemos que en la QueryString están las siguientes palabras reservadas:

• Hosturl -> URL del sitio donde está instala la app.

• Source -> URL de la página desde donde se inicia la Acción personalizada.

• ListUrlDir -> URL relativa con respecto al sitio de la lista.

• SelectedListID -> ID de la lista que contiene el elemento que inicia la Acción.

• SelectedItemID -> ID del elemento que desencadena la Acción personalizada.

Finalmente, solo queda crear la página que contiene la lógica, la cual se está referenciando desde el fichero Elements.xml, en la citada etiqueta UrlAction. Para ello, una vez más, dentro del módulo Pages añadimos una página, pera esta vez, de HTML básico, en vez de ASP.NET. Llamamos a la página CustionAction.html, y le damos el siguiente contenido:

104


<!DOCTYPE html> <html xmlns=”http://www.w3.org/1999/xhtml”> <head> <title>Mi Acción Personalizada (Custom Action)</title> </head> <body> <h2>Parámetros de la Query String pasados por la Acción personalizada (Custom Action):</h2>  <ul id=”qsparams”/> <script lang=”javascript”> var params = document.URL.split(“?”)[1].split(“&”); var paramsHTML = “”; // Extracts the parameters from the query string. // Parameters are URLencoded, decode for rendering // in page. for (var i = 0; i < params.length; i = i + 1) { params[i] = decodeURIComponent(params[i]); paramsHTML += “<li>” + params[i] + “</li>”; } // Render parameters in the placeholder. document.getElementById(“qsparams”).innerHTML = paramsHTML; </script> </body> </html>

Como se ve, estamos usando HTML 5 básico, con todo lo que ello supone en cuanto a poder utilizar todas sus nuevas etiquetas de video, audio, etc. Extraemos los parámetros de la QueryString, y mediante JavaScript los insertamos en la página con su nombre y valor.

Así pues, volvemos a desplegar el proyecto desde Visual Studio 2012, para actualizar nues-tra app. Una vez hecho, nos dirigimos a alguna biblioteca de documentos, y será necesario que añadamos algún documento a la misma. Una vez lo hagamos, podremos ver los siguientes elementos dese la interfaz de usuario.

105


Figura 3-26. Nuestra App en la cinta contextual.

El resultado final es que ambos botones enlazan con la siguiente página, donde se están mostrando parámetros de la lista en cuestión:

Figura 3-28. Resultado de nuestra app de Acción personalizada.

106


Maquetación y diseño de apps

Introducción

En el proceso de desarrollo de una app para SharePoint 2013, así como prácticamente para cualquier otra plataforma, sucede que muchas veces son tan importantes los engranajes del interior, como el envoltorio exterior con el que se presenta. E incluso dicho envoltorio puede resultar tanto o más costoso de llevar a cabo. Pero no debemos olvidar, que si bien SharePoint 2013 puede ser muchas cosas, la base es la de una plataforma de colaboración basada en la Web. Por ello, el desarrollador SharePoint 2013 debe saber hacer tanto que los engranajes de su Web Part no paren de girar, como que la presentación luzca bien. Es la conocida dualidad desarrollador/diseñador (e incluso administrador) con la que el programador SharePoint debe saber convivir.

En el marco en el que nos encontramos, a saber, el desarrollo de SharePoint apps, éstas, aunque si bien pueden ser orientadas a un catálogo interno empresarial donde tal vez se le preste menos importancia a la presentación en lugar de la funcionalidad, lo más común es que cuando se desarrolla una app, se haga pensado en llegar al mayor número de usuarios posibles. Usuarios, que pueden tener su portal SharePoint “de cualquier manera”. Y por ello, se debe proveer a nuestra app de mecanismos para permitir que “encajen” y se adapten al mayor número de entornos posibles. Pudiera ser la app que por sí misma resolviera los misterios del Universo, que si toda mañana al acceder a nuestro SharePoint tuviéramos la sensación de haber instalado un “parche”, estaríamos fallando en algo tan importante, como es que sea “apetecible” (se me ocurre patentar “appetecible”) para el usuario.

Además, para conseguir adaptar y conseguir que nuestra app encaje con los estilos del entorno que la rodea debemos tener muy en cuenta, ya que determinará nuestra forma de proceder, si nuestra app va a estar alojada en el propio SharePoint (SharePoint-hosted), o por el contrario, va a estar alojada en la Nube (Cloud-hosted). La distinción se debe a que según donde se aloje la app, podremos utilizar para su desarrollo unas tecnologías web u otras. Por ejemplo, para las SharePoint-hosted, como ya hemos visto en capítulos anteriores, SharePoint 2013 crea un sitio (un SPWeb) para alojar la app. Este sitio se crea a partir de una nueva plan-tilla de sitio específica para apps, la cual aplica por defecto en el sitio raíz, una nueva página maestra de la que hablaremos más tarde. Es decir, tecnología ASP.NET que ya conocemos de versiones anteriores de SharePoint, por lo que las consideraciones a tener en cuenta en cuanto a cómo aplicar estilos, diseños, maquetado etc., en su mayoría ya las conocemos. Por el con-trario, cuando tratamos con apps del tipo Cloud-hosted, no tenemos limitación en cuanto qué tecnología usar para maquetar y diseñar la app. Podemos usar tanto PHP, HTML básico, ASP.NET como cualquier otra tecnología con la que nos sintamos cómodos (lo cual amplia enorme-mente el rango de desarrolladores capaces para desarrollar apps para SharePoint 2013).

107


Por tanto, las opciones para maquetar y diseñas apps, son prácticamente ilimitadas. En ambos casos, SharePoint 2013 proporciona herramientas al desarrollador para conseguir cum-plir con el objetivo de que nuestra app, a parte de funcional sea bonita. Y además, que sea bonita, respetando lo bonito que ya es el sitio que la contiene.

Vuelven los iFrames

En realidad nunca se fueron. Pero sí han recobrado fuerza. E incluso pudiera pensar alguno que es un nuevo invento de la empresa de la manzana. Pero no es así. Los iFrames llevan en el mundo del desarrollo web prácticamente desde los inicios. Pero si bien hace una década, se consideraba una mala práctica su uso, hoy en día es pieza clave en la arquitectura de apps de SharePoint 2013, así como de otras arquitecturas de apps, como la de Facebook. Y si lo analiza-mos, tiene todo el sentido del mundo que sea así. En el caso de SharePoint 2013, ya sabemos que las aplicaciones “viven” completamente aisladas del sitio SharePoint donde se instalan. Incluso las apps del tipo SharePoint-hosted, tienen su propio entorno con un dominio aislado. ¿De qué otra forma íbamos a poder “incrustar” el contenido de un sitio web aislado dentro de otro? Es cierto, tal vez existan otros mecanismos, mejores o peores, como pudiera ser el uso de JavaScript. Pero la curva de aprendizaje con iFrames es prácticamente nula, ya que es un elemento que en mayor o menor medida todo desarrollador conoce.

No obstante, los iFrames siguen presentando limitaciones, tanto a nivel de seguridad, como de integración con el entorno raíz a tener cuenta. Por ejemplo, tenemos la problemática de redimensionar el tamaño del iFrame según la resolución de pantalla del usuario. Así como también, la comunicación entre el entorno raíz, y el iFrame, y los conocidos problemas de cross-domain. Esta clase de limitaciones se han tenido en cuenta en SharePoint 2013, y se le proporcionan al desarrollador mecanismos de manera que la percepción para el desarrollador se asemeje (al menos en cuanto a diseño y experiencia de usuario se refiere), a la que podría ser el desarrollo de un Web Part para SharePoint.

¿Cómo y cuándo hace uso SharePoint 2013 de los iFrames? Bien, como ya sabemos, existen básicamente dos formas de mostrar el contenido de una app. La primera de ellas es mediante el conocido modo Página completa. En este caso, se accede a la app desde un enlace, o una Acción personalizada, que redirige hacia la app web desde donde se muestra el contenido de la app, ocupando toda el área visible del navegador. No debemos olvidar que lo que estamos haciendo es navegar hacia otra aplicación web completamente distinta, con respecto a la aplicación web desde donde se lanzó la app. Por lo tanto, en este caso no tenemos iFrames. Pero es labor del diseñador conseguir, que de cara al usuario, parezca que nos mantenemos en el mismo sitio, respetando los estilos y maquetación del sitio origen. La otra opción para mostrar apps, son las App Parts. Las App Parts, como ya hemos visto, son en última instancia una página dentro de otra. Lo cual es, básicamente, la definición de un iFrame. Aunque también es posible, como veremos, hacer uso de las ventanas modales (Modal Dialogs) que ya conocemos de SharePoint

108


2010, para mostrar el contenido de una app, usando igualmente iFrames, pero “alterados” por SharePoint 2013.

Así pues, e insistiendo en lo que considero que es el punto clave en la maquetación y diseño de apps para SharePoint 2013, el desarrollador de una app para SharePoint 2013 debe tener presente en todo momento que el SharePoint donde vaya a instalarse finalmente su app, puede variar enormemente, con respecto al de otros usuarios. Es su labor conseguir, que su app se adapte perfectamente, y encaje dentro de los estilos y maquetación, sea cual fueren estos, en cualquier escenario. ¿Cómo podemos conseguir esto sin morir en el intento? Bien, la cuestión es adaptar la solución, según al tipo de problema, o mejor dicho, al tipo de app.

No perder el enfoque

A modo de conclusión final, antes de meternos de lleno en el diseño apps, me gustaría recalcar algo de lo que ya hemos hablado brevemente antes. Es importante no confundir cuál es el objetivo cuando hablamos de maquetación y diseño de apps. Habrá observado el lector, que en ningún momento ha aparecido la palara branding, para referirnos al diseño y maque-tación de apps. Y no es casual. Hablamos de branding cuando aplicamos estilos corporativos (colores, fuentes, logos, etc.) de una marca para una intranet, web pública, blog, etc. Es en este caso, cuando usamos todos los recursos que están a nuestra disposición, (los recursos que ofrece SharePoint en este caso) y todos los “trucos” que podamos. Pero ahora, no estamos hablando de branding. Estamos hablando de cómo puedo hacer que “mi” app encaje con los estilos que ya existen, o mejor dicho, con el branding que ya existe, en la aplicación web donde vaya a parar mi app. Ése debe ser nuestro enfoque, y a eso va dedicado este capítulo. Es por ello, que no tiene sentido que tratemos de reinventar la rueda, haciendo trabajos innecesarios. SharePoint 2013 ya ofrece mecanismos para el diseño de apps, precisamente con ese objetivo: tener una app plenamente funcional, con un acabo visual acorde con el resto de elementos de la página, sin tener que dedicarle más tiempo a lo segundo que a lo primero. Así pues, vamos a ver cuáles son esos mecanismos.

SharePoint-hosted Apps

Tal vez, la forma más rápida de comprender y familiarizarse con las apps para SharePoint 2013, sea mediante las SharePoint-hosted Apps, en el sentido de que se apoyan en elementos de SharePoint que podemos conocer de versiones anteriores. En capítulos anteriores, hemos hablado ampliamente sobre cómo funcionan las SharePoint-hosted Apps “por debajo”, qué las distingue de las Cloud-hosted Apps, así como sus ventajas e inconvenientes. En este caso, vamos a desmenuzar este tipo de apps, pero para ver cómo podemos sacarles todo el jugo en cuanto a maquetación y diseño se refiere.

109


Es fácil perderse con tanta nomenclatura nueva en SharePoint 2013, sobre todo en cuanto al nuevo modelo de desarrollo de apps se refiere. Pero en realidad hay que tener el esquema en la cabeza, y no perder de vista que existen tres tipos de apps que podemos alojar de tres formas distintas. Centrándonos en maquetación y diseño de apps se refiere, nos va a importar si la app se aloja en SharePoint (SharePoint-hosted) o lo hace en la Nube (Provider-hosted y Autohosted). Si es el primer caso, partimos con mucho trabajo hecho, y además contamos con una base importante de conocimientos, si ya hemos trabajado con versiones anteriores de SharePoint. Y es que, simplificando al máximo las SharePoint-hosted Apps, éstas no son más que páginas (usualmente ASP.NET, pero también puede ser HTML básico) dentro de SharePoint. La peculiaridad la tiene dicho sitio en sí (que programáticamente no deja de ser un objeto SPWeb), ya que no es accesible del mismo que el resto de sitios de SharePoint, y presenta una serie de restricciones.

Es probable que el lector ya se esté planteando cuestiones del tipo ¿si es un sitio de SharePoint normal y corriente el que contiene a la app, qué pagina maestra se usa? ¿Es posi-ble modificar dicha página maestra? ¿Puedo usar una página maestra propia? ¿Puedo crear diseños de página (layouts)? ¿Qué estilos CSS y archivos JavaScript se aplican? En adelante, trataremos de dar respuesta a estas y otras preguntas con el objetivo de tener presente cuáles son las herramientas con las que contamos a la hora de maquetar SharePoint-hosted Apps, en cualquiera de sus tres variantes y cuál es la forma más eficiente de hacerlo. Y el primer paso para ello es diseccionar un proyecto de Visual Studio 2012 de una SharePoint-hosted App, y ver qué elementos lo compone.

Estructura de un proyecto SharePoint-hosted

Así pues, recién creado un proyecto de SharePoint-hosted App en Visual Studio 2012, tene-mos la siguiente estructura en el mismo:

110


Figura 3-27. Nuestra App en el menú desplegable

Vemos que se trata de un proyecto muy parecido, por no decir idéntico, al proyecto típico de una solución para SharePoint 2010. Nos tiene que llamar la atención que el proyecto cuenta con cuatro módulos para proveer de archivos al sitio SharePoint. Así pues, tenemos el módulo Content, para desplegar la hoja de estilos App.css. El módulo Images, donde por defecto se ubica a la imagen del icono de la app, pero que pudiéramos usar para añadir más imágenes. Un módulo Pages para desplegar páginas, que son en última instancia la app, sí. Y por último, un módulo Scripts para desplegar archivos JavaScript (entre ellos, vemos como hay una ver-sión de jQuery). Por lo tanto, el pensamiento que debemos tener al ver este tipo de proyecto, es que es un proyecto clásico para desplegar archivos. Archivos que utilizaremos, finalmente, para maquetar y diseñar nuestra app.

Por ejemplo, si abrimos el archivo de hoja de estilos App.css, solo encontraremos en él una línea a modo de comentario, invitándonos a introducir nuestros estilos personalizados en dicho archivo. También podemos, obviamente, crear uno o varios archivos de hojas de estilos como, y referenciarlos desde la página en cuestión. De igual modo, para el código JavaScript que queramos añadir a nuestra app, tenemos el fichero App.js. Este fichero no está vacío, cuenta con algunas funciones en su interior, pero perfectamente podemos borrarlas ya que únicamente se usan para el “Hola Mundo”, a modo de ejemplo de la app. No obstante, antes de borrar a lo loco, vamos a fijarnos (y además viene muy bien comentado), en que existe una función que está siendo llamada desde un jQuery(document).ready() que se encuentra en la página default.aspx. La función sharePointReady().

111


// Esta función se ejecuta cuando el DOM está listo y los scripts de // SharePoint se han cargado Añadir en este función el código que se quiera // ejecutar cuando Default.aspx esté lsto Se crea un objecto de contexto que // es necesario para utilizar el modelo de objectos de SharePoint function sharePointReady() { context = new SP.ClientContext.get_current(); web = context.get_web(); getUserName(); }

Es decir, cuando llegamos a esta función, el DOM de la página -además del resto de scripts de SharePoint- están cargados, por lo que podemos usarla para realizar el resto de llamadas a las funciones e iniciar nuestra lógica de JavaScript. Para ello debemos asegurarnos de tener antes el siguiente script:

  <script type=”text/javascript”> $(document).ready(function () { SP.SOD.executeFunc(‘sp.js’, ‘SP.ClientContext’, function () { sharePointReady(); }); }); </script>

Finalmente, en el módulo Pages podemos añadir nuevas páginas, y usar éstas para la app de Página completa (que como sabemos, es la app “por defecto” del proyecto), modificando el fichero AppManifest.xml, o para otras apps que incluyamos en el proyecto, ya sean de Acción personalizada o App Part. Más adelante, hablaremos más en detalle sobre las páginas que componen una SharePoint-hosted App.

Aunque no lo he mencionado explícitamente, por que en realidad es el mismo compor-tamiento que en SharePoint 2010, debemos fijarnos en que, en cuanto añadimos un nuevo

112


archivo a un módulo, automáticamente en el fichero Elements.xml asociado se incluye las refe-rencias al nuevo archivo, indicando hacia dónde debe ser desplegado en SharePoint.

App.master

App.master es una nueva página maestra que trae SharePoint 2013, que se aplica al sitio SharePoint que se crea para alojar la app. Es decir, si en una SharePoint-hosted App estamos tratando en todo momento con elementos naturales de SharePoint (porque insisto, programá-ticamente no deja de ser un objeto SPWeb donde se aloja la app), también es lo “natural”, que se aplique una página maestra como las habituales. Lo cual plantea a su vez otras preguntas, ¿qué tiene de particular dicha página maestra? En realidad no tiene nada de particular, solo que hay ciertos componentes que desaparecen en comparación con, por ejemplo, la nueva V15.master. Por ejemplo, la mayoría de elementos de la cinta contextual (Ribbon) no están, (como es lógico). Es decir, es una app, no un portal. Sobre todo, no perdamos ese foco de la cabeza, en cuanto a maquetación y diseño se refiere, tratando de hacer cosas innecesarias.

¿Podemos modificar dicha página maestra? Como poder, en cuanto a tener la capacidad física para acceder a la ruta \15\TEMPLATE\GLOBAL\ y editar el archivo app.master, sí, podemos. Ahora bien, automáticamente hagamos alguna modificación en dicho fichero, debemos ser conscientes de tres cosas. La primera, la típica, en cuanto haya una actualización de SharePoint, puede ser que perdamos los cambios que hayamos hecho; la segunda, aun no habiendo encon-trado confirmación oficial por la documentación de Microsoft, es de suponer, dado lo poco que les gusta a los de Redmond que les busquen las cosquillas, que supondría perder el soporte; y la tercera, pero no menos importante, es que cualquier cambio que hagamos, se aplicará a todas las apps que tengamos, ya que en todas se usa la app.master. Lo cual plantea la siguiente pregunta: ¿podemos usar páginas maestras propias? Voy a intentar responder a esta pregunta desde dos enfoques distintos. El primero, el del programador SharePoint que soy. Como tal, sé que aunque desde la interfaz de usuario de una app no tenga modo de cambiar la página maestra (porque no lo tengo), también sé, que mediante PowerShell, y dos cmd-lets, todo es posible. Ahora bien, ese no es para nada el objetivo. Y aquí viene el otro enfoque, el enfoque práctico. Como decía anteriormente, estamos hablando de desarrollar apps. Y una app no es un portal web, ni una web pública, ni nada parecido. Es un “añadido” de funcionalidad que insertamos en un sitio SharePoint, que sí puede ser una web pública, o intranet. Por tanto, no debemos rompernos la cabeza en ver cómo podemos modificar la página maestra o cosas por el estilo. En su lugar, debemos pensar -y ese es el objetivo primordial- en cómo puedo hacer que mi app “se camufle”, es decir, se adapte a los estilos de la página que la contiene. Y para conseguir eso mismo, como veremos, SharePoint 2013 ofrece una serie de mecanismos para que maquetar y diseñar apps sea una tarea sencilla y no un desafío.

113


Diseños de Páginas (page layouts)

Dado que acabamos de hablar de páginas maestras, y que somos unos desarrollado-res/diseñadores de SharePoint realmente muy curiosos… ¿Qué hay de diseños de páginas (page layouts) en una SharePoint-hosted App? Bien, como sabemos, las páginas maestras en SharePoint trabajan en combinación con los diseños de páginas. A grandes rasgos, se definen “huecos” en las páginas maestras, mediante los controles ContentPlaceHolders, y dichos hue-cos se “rellenan” después desde los diseños de páginas12. Por lo tanto, si ya sabemos que tene-mos una página maestra para las apps, por algún lado tienen que estar los diseños de página. Y en realidad, ese diseño de página (page layout) ha estado con nosotros desde que creamos el proyecto en Visual Studio 2012. Solo tenemos que examinar el código de la página default.aspx que veíamos anteriormente, para comprobar que efectivamente es así.

... ... ... <%-- The markup and script in the following Content element will be placed in the <head> of the page --%> <asp:Content ContentPlaceHolderId=”PlaceHolderAdditionalPageHead” runat=”server”> <script type=”text/javascript” src=”../Scripts/jquery-1.6.2.min.js”> </script>  <link rel=”Stylesheet” type=”text/css” href=”../Content/App.css” />  <script type=”text/javascript” src=”../Scripts/App.js”></script> ... ... ... </asp:Content> <%-- The markup and script in the following Content element will be placed in the <body> of the page --%> <asp:Content ContentPlaceHolderId=”PlaceHolderMain” runat=”server”> <div> ... ...

12 Para más información sobre el funcionamiento de las páginas maestras, y diseños de página, consulte esta document-ación; http://msdn.microsoft.com/en-us/library/wtxbf3hh(v=vs.100).aspx#HowMasterPagesWork

http://msdn.microsoft.com/en-us/library/wtxbf3hh(v=vs.100).aspx#HowMasterPagesWork

114


... </div> </asp:Content>

Vemos qué se usan dos ContenPlaceHolder: PlaceHolderAdditionalPageHead y PlaceHolderMain. Como se dice en los comentarios que acompañan al código, PlaceHolderAdditionalPageHead para añadir referencias en la cabecera de la página (etiqueta head), y PlaceHolderMain para definir el cuerpo de la página (etiqueta body). Es decir, la página default.aspx, gracias a las referencias que incluye, puede ser considerada a efectos de desa-rrollo, un diseño de página (page layout) de SharePoint normal y corriente. De hecho, podría-mos examinar la app.master en busca del resto de ContentPlaceHolder que se están usando para la maquetación, para así poder “rellenarlos” desde nuestra página.

Figura 3-30. ContentPlaceHolders visibles en la app.master

En realidad los dos ContentPlaceHolder que hemos mencionado, son los únicos que real-mente necesitamos para maquetar y dar estilos a una SharePoint-hosted App. Es por ello, que cuando añadimos un nuevo elemento al proyecto, bajo la sección de Office/SharePoint, encon-tramos el elemento Page (página).

115


Figura 3-31. Diseños de página en las SharePoint-hosted Apps

Por tanto, las páginas que añadimos usando la plantilla de página disponible para las apps de SharePoint son páginas ASP.NET ya preparadas (incluyen las referencias) para usarse en el contexto de una SharePoint-hosted App. Aunque también podemos decirle a nuestra app que no haga uso de la app.master, y use una página en HTML básico, donde nosotros debemos de realizar absolutamente todo el desarrollo desde cero.

Ahora que hemos visto cómo se maqueta una app que se aloja en SharePoint, podemos entender por qué una SharePoint-hosted App “limpia”, es decir, tal cual viene con la plantilla de Visual Studio 2012, no se muestra como una página sin estilos cuando la desplegamos, si no que visualmente se comporta como cualquier página dentro de SharePoint. Esto mismo no sucede, con las Cloud-hosted Apps, ya que una Cloud-hosted App no se apoya en páginas maestras ni diseños de página. En una Cloud-hosted App tenemos que maquetar y dar estilos partiendo desde cero.

116


Figura 3-32. Comparación entre una app “limpia” Cloud-hosted (1) y SharePoint-hosted (2)

Esa es, precisamente, una de las ventajas de las SharePoint-hosted Apps. El objetivo de que nuestra app se adapte y encaje con los estilos de SharePoint, y no parezca un “postizo”, se consigue más fácilmente con este tipo de apps. No obstante, como decíamos anteriormente, también podemos hacer que nuestra app use una página en HTML sin ninguna referencia a la app.master. De esta forma, partiríamos en las mismas condiciones que con una Cloud-hosted App. ¿Cómo podría hacer entonces, que mi app se adaptara a los estilos de SharePoint 2013? ¿Acaso no se puede conseguir que una Cloud-hosted App “herede” los estilos de SharePoint? Sí, claro que se puede. Para ello SharePoint 2013 proporciona el Client Chrome Control, del cual hablaremos en profundidad cuando hablemos de maquetación y diseño para Cloud-hosted Apps.

117


Apps Parts

A continuación, vamos a hablar sobre esos mecanismos que mencionábamos anterior-mente que nos van a permitir adaptar nuestra app a los estilos del entorno donde se muestra. Concretamente, en esta ocasión vamos a centrarnos en las App Parts que se alojan en SharePoint (SharePoint-hosted). Aunque lo que vamos a ver a continuación, es igualmente válido para las Apps Parts que residen en la Nube (Cloud-hosted). El hecho de hablar ahora sobre la maque-tación y diseño de App Parts, bajo el contexto de las SharePoint-hosted Apps, se debe a que, como ya hemos visto, las apps de Página completa en una SharePoint-hosted App, al emplear la página maestra app.master, prácticamente ya están en sintonía con los estilos de SharePoint. Por lo que hay poco que añadir en ese sentido en este momento. Hablaremos en profundidad de los mecanismos que proporciona SharePoint para dar estilos a las apps de Página completa en la sección siguiente, dedicada al diseño y maquetación de Cloud-hosted Apps. En ese caso, sí que estaremos obligados a “poner de nuestra parte”, ya que partiremos de un “lienzo” com-pletamente en blanco.

En el caso de las App Parts, también conocidas como Client Web Parts, ya hemos visto que su uso y visualización es muy similar al de los Elementos Web (Web Parts) tradicionales. Pero para el caso que nos ocupa, es decir, ver la forma en la que se puede adaptar el diseño y apariencia de una App Part con el entorno que la rodea, debemos tener presente, como vimos anteriormente, que una App Part se visualiza mediante iFrames. Se podría equiparar la funcio-nalidad de una App Part, con la del Elemento Web Visor de páginas (Page Viewer WebPart) presente en SharePoint desde versiones anteriores. Ambos realizan la tarea de mostrar el con-tenido de una página mediante un iFrame. La ventaja de las App Parts es que permiten enviar parámetros de configuración a la página a visualizar, así como establecer un contexto con el sitio SharePoint anfitrión.

En adelante, veremos cómo podemos “moldear” una App Part para conseguir esa integra-ción con SharePoint que venimos buscando. Concretamente, analizaremos y veremos cómo resolver los siguientes escenarios:

- Usar los estilos de SharePoint en App Parts.

- Acciones personalizadas, usando las ventanas modales de SharePoint.

118


Usar los estilos de SharePoint en App Parts

Partiendo de la base de que una App Part es un “trozo de página” que insertamos en SharePoint, no tendría sentido que esa página que insertamos tenga a su vez elementos de SharePoint, como la cinta contextual, menú de navegación, etc. Se podría producir una especie de “efecto Droste13”.

Figura 3-33. Efecto Droste

Por lo que la página que usamos para mostrar en las App Parts, serán generalmente pági-nas HTML básicas, sin ninguna referencia a SharePoint. Es decir, nos olvidamos de la app.master y de los ContentPlaceHolder. Por lo tanto, de igual forma que sucede con las apps de Página completa que se alojan en la Nube, no vamos a ver una concordancia entre los estilos de mi app y los de SharePoint del sitio actual, a no ser que usemos algún mecanismo para tal fin. En el caso de las apps en Página completa, veremos que tenemos el Client Chrome Control. En el caso de las App Parts tenemos que asegurarnos de referenciar una hoja de estilos a modo de “comodín”, que a su vez referencia los estilos que se están utilizando actualmente. Vamos a ver cómo, paso a paso.

13 http://es.wikipedia.org/wiki/Efecto_Droste

http://es.wikipedia.org/wiki/Efecto_Droste

119


Paso a paso para referenciar los estilos de SharePoint en una App Part

Paso 1. Creamos un nuevo proyecto de SharePoint-hosted Apps, y le añadimos, según la nomenclatura que usa Visual Studio 2012, un Client Web Part (Host Web), que se corresponde con una App Part.

Figura 3-34. Agregamos un App Part al proyecto

Paso 2. El siguiente paso es crear una nueva página, que constituirá el contenido de nues-tro App Part. Es en esta página donde deberemos hacer referencia a las clases CSS de SharePoint que queramos utilizar, y en donde también, mediante JavaScript, haremos referencia a la hoja de estilos “comodín” que nos va a permitir usar los estilos del sitio anfitrión.

Paso 3. A continuación, tenemos que indicar a nuestro App Part, de dónde debe coger el contenido. Es decir, hemos de modificar su archivo Elements.xml correspondiente:

<?xml version=”1.0” encoding=”utf-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <ClientWebPart Name=”MiAppPart” Title=”MiAppPart”

120


Description=”MiAppPart” DefaultWidth=”1024” DefaultHeight=”500”> <Content Src=”~appWebUrl/Pages/AppPartPage.aspx?{StandardTokens}” Type=”html”/> </ClientWebPart> </Elements>

Como vemos, no estamos enviado parámetros adicionales al App Part, si no que estamos usando el marcador14 StandarTokens, que engloba una serie de parámetros en la QueryString, sobre el sitio actual.

Paso 4. En este paso, vamos a darle contenido a la página que creamos en el paso 2. La idea es ver, que efectivamente, hay un “antes y un después” referenciando la hoja de estilos “comodín” y no haciéndolo. Por eso en la página, de momento, no vamos a añadir nada de JavaScript. Lo que sí vamos a hacer es usar las clases CSS que utiliza SharePoint 2013 para dar estilos a los distintos tipos de textos que podemos tener en una página dentro de SharePoint, como son títulos, subtítulos, secciones, subsecciones, etc. Por ejem-plo, SharePoint 2013 utiliza la clase .ms-core-pageTitle15, para dar formato al título prin-cipal de la página. Por ejemplo, podemos darle el siguiente contenido a la página:

<%@ Register Tagprefix=”WebPartPages” Namespace=”Microsoft.SharePoint.WebPartPages” Assembly=”Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <WebPartPages:AllowFraming ID=”allowframing” runat=”server” /> <!DOCTYPE html> <html xmlns=”http://www.w3.org/1999/xhtml”> <head> <title>Mi App Part usando estilos SharePoint</title> </head> <body>  <h1 class=”ms-core-pageTitle”>¡Hola Mundo!</h1>  <h1 class=”ms-accentText”>Usando los estilos de SharePoint...</h1>  <h2 class=”ms-accentText”>...para que queden las Apps bien bonitas

14 Para más información y ver un listado completo de los marcadores que se pueden utilizar, consulte la siguiente página: http://msdn.microsoft.com/en-us/library/ms431831(v=office.15).aspx15 En la siguiente documentación tenemos un listado completo de las clases CSS existentes que se usan en SharePoint, y en qué casos se deben utilizar: http://msdn.microsoft.com/en-us/library/jj220046%28v=office.15%29.aspx#UXGuide_CSS

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

http://msdn.microsoft.com/en-us/library/jj220046%28v=office.15%29.aspx#UXGuide_CSS

121


:)</h2><br /> <div>  <h2 class=”ms-webpart-titleText”>Usamos esta clase para el título de un WebPart</h2>  <a class=”ms-commandLink” href=”#”>este formato queda bien para los enlaces</a> <br />  Y para intrdocir un texto normal, si somos capaces de definir la normalidad, no espeficamos ninguna clase CSS. </div> </body> </html>

Seguidamente, depuramos desde Visual Studio para ver cómo queda nuestra App Part.

Figura 3-35. App Part sin aplicar estilos SharePoint

Como vemos, esto luce muy poco a lo SharePoint-style. Vamos a ver cómo podemos cam-biar eso.

122


Paso 5. Para terminar, y hacer que nuestra App Part utilice los mismos estilos que se están utilizando en la página actual, incluimos el siguiente código JavaScript en la cabecera de la página.

<script type=”text/javascript”> var hostweburl; (function () { //Get the URI decoded app web URL. hostweburl=decodeURIComponent( getQueryStringParameter(“SPHostUrl”)); //La hoja css “comodin” que necesitamos, se encuentra bajo //web_url/layouts/15/defaultcss.ashx var scriptbase = hostweburl + “/_layouts/15/”; var dclink =document.createElement(“link”); dclink.setAttribute(“rel”, “stylesheet”); dclink.setAttribute(“href”, scriptbase + “defaultcss.ashx”); var head = document.getElementsByTagName(“head”); //Añadimos la etiqueta link que acabamos de formar a la cabecera //de página. head[0].appendChild(dclink); })(); // Función para obtener el valor de un parámetro de la Query String. function getQueryStringParameter(paramToRetrieve) { var params = document.URL.split(“?”)[1].split(“&”); var strParams = “”; for (var i = 0; i < params.length; i = i + 1) { var singleParam = params[i].split(“=”); if (singleParam[0] == paramToRetrieve) return singleParam[1]; } } </script>

123


Y el resultado es el siguiente:

Figura 3-36. Nuestra App Part una vez incluida la referencia la os estilos

Como vemos, con apenas dos funciones JavaScript, se consigue cambiar y adaptar la apariencia de nuestra App Part completamente a los estilos del sitio actual.

Acciones Personalizadas usando las ventanas modales

Hemos hablado de las apps de Página completa y de las Apps Parts, por lo que solo nos queda ver cómo personalizar el aspecto visual de las apps de Acción personalizada. Pudiera pensar el lector por lo leído hasta el momento en este libro, que una app del tipo Acción per-sonalizada ofrece poco “juego” en cuanto a diseño y maquetación, ya que como sabemos, a este tipo de apps se accede desde la cinta contextual de SharePoint 2013, o en los menús de edición de elementos de listas o bibliotecas. Lo cierto es que estas apps son en funcionalidad muy similares a las apps de Página completa, en el sentido de que son enlaces que envían al usuario a una página que se encuentra en otra aplicación web. Por lo que la personalización de la app, debiera hacerse del mismo modo que para las apps en modo Página completa. La salvedad, es que las apps de Acción personalizada, permiten una variante no vista hasta ahora, y es la de visualizar apps dentro de los diálogos modales (modal dialogs) de SharePoint.

Si recordamos de SharePoint 2010, un diálogo modal es un mecanismo que se utiliza para ofrecer una mayor interacción con el usuario, permitiendo mostrar páginas en el mismo con-texto de la página actual donde se encuentra el usuario.

124


Figura 3-37. Ejemplo de diálogo modal en SharePoint 2010.

Del mismo modo, podemos invocar diálogos modales, desde la app de Acción personali-zada, con el objetivo de mantener al usuario en la misma página que se encuentra actualmente, en vez de redirigirle a otro contexto. Resulta especialmente útil esta opción, para, por ejemplo, el caso en el que queramos modificar propiedades de elementos de listas, o por ejemplo, crear un “editor” personalizado con algunas opciones limitadas, etc. Las posibilidades son muy amplias. Pasamos a ver cómo llevar esto a cabo.

Si recuperamos el proyecto que creamos en el capítulo anterior, donde hicimos un “Hola Mundo” introductorio con todos los tipos de apps, podemos volver a exami-nar el fichero Elements.xml que acompaña a la app de Acción personalizada, que en aquel momento llamamos, en un acto tremendo de originalidad “Acción personalizada”.

<?xml version=”1.0” encoding=”utf-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <CustomAction Id=”47708c0a-505a-4db1-b424-989328b7abfb.CustomAction” RegistrationType=”List” RegistrationId=”101” Location=”EditControlBlock” Sequence=”114” Title=”¡Hola Mundo!”> <UrlAction Url=”~appWebUrl/Pages/CustomAction.html?HostUrl={HostUrl}& Source={Source}&ListURLDir={ListUrlDir}&

125


ListID={ListId}&ItemURL={ItemUrl}&ItemID={ItemId}”/> </CustomAction> <CustomAction Id=”75dd24d9-0c16-4ef5-be0a-f52ed0e620fa.CustomAction” RegistrationType=”List” RegistrationId=”101” Location=”CommandUI.Ribbon” Sequence=”115” Title=”Invoke custom action”> <CommandUIExtension> <CommandUIDefinitions> <CommandUIDefinition Location=”Ribbon.Documents.Manage.Controls. _children”> <Button Id=”Ribbon.Library.Connect.PropertyViewer” Alt=”¡Hola Mundo!” Sequence=”100” Command=”Invoke_CustomAction” LabelText=”¡Hola Mundo!” TemplateAlias=”o1” Image32by32=”/_layouts/15/1033/images/formatmap32x32.png” Image32by32Left=”-137” Image32by32Top=”-137”/> </CommandUIDefinition> </CommandUIDefinitions> <CommandUIHandlers> <CommandUIHandler Command=”Invoke_CustomAction” CommandAction=”~appWebUrl/Pages/CustomAction.html?HostUrl= {HostUrl}& Source={Source}& ListURLDir={ListUrlDir}&SelectedListID={SelectedListId} &SelectedItemID={SelectedItemId}”/> </CommandUIHandlers> </CommandUIExtension> </CustomAction> </Elements>

Vemos, que el fichero está compuesto por etiquetas CustomAction, y en las mismas defi-nimos la acción que realizan, con la dirección de la página con la que enlazan, y los pará-metros que se le envían a ésta. Pues bien, para conseguir que la página que constituye la app se abra en el mismo contexto de la página actual, solo hemos de añadir una propiedad más a la etiqueta CustomAction: la propiedad HostWebDialog. Esta propiedad indica que la acción a realizar la debemos situar dentro de un diálogo modal. Así de sencillo. Además, pode-mos especificar el ancho y alto del diálogo modal, con las propiedades HostWebDialogWidth y

126


HostWebDialogHeight. Por lo tanto, la primera acción personalizada del fichero Elements.xml anterior, quedaría tal que así:

<CustomAction Id=”47708c0a-505a-4db1-b424-989328b7abfb.CustomAction” RegistrationType=”List” RegistrationId=”101” Location=”EditControlBlock” Sequence=”114” Title=”¡Hola Mundo!” HostWebDialog=”TRUE” HostWebDialogWidth=”500” HostWebDialogHeight=”500”> <UrlAction Url=”~appWebUrl/Pages/CustomAction.html? HostUrl={HostUrl}& Source={Source}&ListURLDir={ListUrlDir} &ListID={ListId}& ItemURL={ItemUrl}&ItemID={ItemId}”/> </CustomAction>

Vista la teoría, vamos a ir paso a paso construyendo una nueva Acción personalizada, para ver a la misma en acción, y discutir finalmente, qué aspectos en cuanto a diseño y maquetación de la app debemos utilizar, según los mecanismos vistas hasta el momento.

127


Paso a paso para usar ventanas modales en apps

Paso 1. Añadimos un nuevo elemento al proyecto que tenemos abierto en Visual Studio 2012, en este caso del tipo UI Custom Action (Host Web).

Figura 3-38. Añadimos una app de Acción Personalizada al proyecto.

Paso 2. Abrimos el fichero Elements.xml que compone la app de Acción personalizada que acabamos de crear. Por defecto, vemos que el fichero contiene las líneas de código necesarias para crear una acción personalizada asociada al menú de edición de un elemento de lista. Vamos a substituir todo el contenido del fichero, por el siguiente:

<?xml version=”1.0” encoding=”utf-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <CustomAction Id=”47708c0a-505a-4db1-b424-989328b7abfb.CustomAction” RegistrationType=”List” RegistrationId=”101” Location=”EditControlBlock” Sequence=”114”

128


Title=”¡Click aquí!” HostWebDialog=”TRUE” HostWebDialogWidth=”500” HostWebDialogHeight=”500”> <UrlAction Url=”~appWebUrl/Pages/AppPartPage.aspx?{StandardTokens}”/> </CustomAction> </Elements>

Donde lo que estamos haciendo es crear nuevamente una Acción personalizada asociada al menú desplegable de los elementos de una biblioteca de documentos. Dicha Acción perso-nalizada, vemos que tiene asociada como la “URL de acción” (UrlAction) la misma página que usamos para formar la App Part anterior. Y finalmente, usamos las propiedades que mencioná-bamos anteriormente, para permitir que la página se muestre dentro de una ventana o diálogo modal.

El hecho de utilizar la misma página que utilizábamos para la App Part anterior no es una casualidad, si no todo lo contrario. La ventana o diálogo modal con la que se muestra la app de Acción personalizada es nuevamente un iFrame, solo que un iFrame con unos estilos pro-pios que da automáticamente el propio SharePoint mediante JavaScript y CSS que permiten realzarlo. Por lo que siendo un iFrame como es, podemos usar los mismos mecanismos que usamos para las App Parts, es decir, referenciar la hoja de estilos “comodín” default.ashx, y así conseguir que la app de Acción personalizada, que se muestra dentro de un diálogo modal, herede los estilos del sitio actual.

Paso 3. Solo queda depurar nuevamente el proyecto mediante Visual Studio, para com-probar cómo se comporta la app de Acción personalizada, y ver si efectivamente, como es de esperar, obtiene los estilos del sitio actual, al estar utilizando la misma técnica que usamos en la App Part anterior para referenciar la hoja de estilos “comodín”. Para ello, una vez en modo depuración, accedemos a una biblioteca de documentos de SharePoint, donde tengamos al menos un documento, y expandimos el menú de edición de un elemento.

129


Figura 3-39. Nueva opción dentro del menú de edición

Vemos que efectivamente, contamos con la nueva opción dentro del menú de edición del elemento de la biblioteca de documentos. Vamos a ver a continuación, cuál es la acción que realiza:

Figura 3-40. Resultado de la acción personalizada

Y aquí lo tenemos. Vemos que como era de esperar, mostramos el mismo contenido (la misma página) que la App Part que desarrollamos anteriormente. En esta ocasión, estamos usando una app de Acción personalizada, apoyándose en las posibilidades que ofrecen éstas en SharePoint 2013 de mostrar el contenido de las CustomAction, en ventanas modales.

130


Ejemplo práctico

A modo de resumen de todo lo visto hasta ahora, vamos a construir desde cero una SharePoint-hosted App, donde veamos cuál podría ser el proceso “real” de desarrollar una app para SharePoint 2013. La idea es desarrollar una App Part que sirva para construir formularios a medida. Es decir, únicamente configurando esta App Part, podemos añadir tantos campos al formulario como queramos, del tipo que queramos, y en el orden que queramos. Suena bien ¿verdad? Para este ejemplo, y dado que estamos hablando de maquetación y diseño, nos vamos a centrar precisamente en eso, en maquetar y diseñar la app. Queda a cargo del lector, una vez leído el capítulo siguiente donde hablaremos del Modelo de Objetos de Cliente y el API Rest de SharePoint 2013, implementar la lógica de la app. Dicha lógica sería sencilla de implementar; ya lo único que tendría que hacer sería leer los valores del formulario y crear un elemento con ellos en una lista de SharePoint. Así pues, vamos paso a paso.

Paso a paso para hacer una app completa

Paso 1. El primer paso, y más sencillo, es crear el proyecto para una SharePoint-hosted App en Visual Studio 2012. Antes, deberíamos haber creado una aplicación web de SharePoint desde la administración central, usando la plantilla de Sitio del Desarrollador, tal y como vimos en el capítulo anterior.

Paso 2. En este momento ya tenemos una app de Página completa plenamente funcional. El proyecto en “limpio” que crea Visual Studio 2012 para las SharePoint-hosted Apps, contiene el código y los archivos necesarios para crear una app a Página completa con el clásico “Hola Mundo”. En nuestro caso vamos a construir una App Part, por lo que añadimos un nuevo ele-mento al proyecto del tipo Client Web Part.

Paso 3. Una vez añadido la App Part al proyecto, vamos a añadir en el módulo Pages una nueva página.

131


Figura 3-41. Añadir un elemento de tipo Página (Page) al Proyecto de Visual Studio 2012

Paso 4. En la página que acabamos de añadir al proyecto, vamos a escribir el cuerpo de la app. Es decir, aquí es donde se maqueta la app. En este caso, podemos sustituir todo el con-tenido de la página, por el que sigue:

<%@ Register Tagprefix=”WebPartPages” Namespace=”Microsoft.SharePoint.WebPartPages” Assembly=”Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %> <WebPartPages:AllowFraming ID=”allowframing” runat=”server” /> <!DOCTYPE html> <html> <head> <title>My Custom Form</title>  <script type=”text/javascript” src=”../scripts/jquery-1.6.2.min.js”> </script> <script type=”text/javascript” src=”../scripts/App.js”></script>  <link type=”text/css” rel=”stylesheet” href=”../Content/App.css” /> </head> <body> <form>

132


<div id=”container”> <div class=”title ms-core-pageTitle”></div> <div class=”buttons”></div> </div> </form> </body> </html>

Como vemos, usamos HTML5 básico para maquetar la app. Nada extraño hasta aquí. Lo único que pudiera resultar “raro” es la línea código que aparece resaltada. Necesitamos incluir el control AllowFraming (así como la referencia a la DLL que lo contiene), para poder permitir que la página se visualice dentro un iFrame. De lo contrario obtendríamos un error indicando, literalmente: “Este contenido no se puede mostrar en un iFrame” (“This contento cannot be displayed in a frame”).

Por otro lado, vemos que el cuerpo de la página es realmente muy sencillo. Esto es porque realmente el contenido de la app lo vamos a generar dinámicamente mediante JavaScript.

Paso 5. En la página anterior tenemos la referencia al archivo App.css. En este paso vamos a editar dicho archivo para definir los estilos que necesitamos. Por tanto, abrimos el archivo App.css que se genera automáticamente con el proyecto y se encuentra vacío, y añadimos el siguiente contenido:

#container { width:auto; float:left; background-color:rgb(89, 192, 61);} #container .register { margin:0 0 10px 0; padding:10px 40px 20px 40px;} #container .register span.ms-commandLink { width:50px; margin-right:15px; display:block; color:#FFF; } #container .register input[type=text]{ width:300px; height:25px; color:rgb(89, 192, 61);} #container .register select{ width:300px;} #container .buttons {

133


margin-left:30px; margin-bottom:30px; margin-top:40px;} #container .buttons button{ width:150px; font-size:15px; color:rgb(89, 192, 61);} #container .title { color:#FFF; margin-left:40px; margin-bottom:15px; font-size:40pt;}

Paso 6. Ahora le toca el turno al JavaScript. Editamos el archivo App.js, y sustituimos todo su contenido, por las siguientes funciones. Iremos comentando sobre la marcha para qué se usa cada una.

var hostweburl; (function () { //Get the URI decoded app web URL. hostweburl = decodeURIComponent(getQueryStringParameter(“SPHostUrl”)); var scriptbase = hostweburl + “/_layouts/15/”; var dclink = document.createElement(“link”); dclink.setAttribute(“rel”, “stylesheet”); dclink.setAttribute(“href”, scriptbase + “defaultcss.ashx”); var head = document.getElementsByTagName(“head”); head[0].appendChild(dclink); })(); function sharePointReady() { buildCustomForm(); formFocus(); }

En primer lugar, usamos el mecanismo que acabamos de ver para referenciar los estilos de SharePoint en App Parts. A continuación, en la función SharePointReady, que como ya vimos, espera a que esté cargado todo el DOM de la página, y también resto de archivos JavaScript de SharePoint, hacemos el resto de llamadas a las funciones JavaScript.

134


function buildCustomForm() { var order = (existsQueryStringParameter(‘order’)) ? getQueryStringParameter(‘order’).split(“;”) : “”; var plain = (existsQueryStringParameter(‘plain’)) ? getQueryStringParameter(‘plain’).split(“;”) : “”; var area = (existsQueryStringParameter(‘area’)) ? getQueryStringParameter(‘area’).split(“;”) : “”; var radio = (existsQueryStringParameter(‘radio’)) ? getQueryStringParameter(‘radio’).split(“;”) : “”; var check = (existsQueryStringParameter(‘check’)) ? getQueryStringParameter(‘check’).split(“;”) : “”; var dropdown = (existsQueryStringParameter(‘dropdown’)) ? getQueryStringParameter(‘dropdown’).split(“;”) : “”; var button = (existsQueryStringParameter(‘button’)) ? getQueryStringParameter(‘button’).split(“;”) : “”; for (var i = 0; i < order.length; i++) { //Cajas de texto plano for (var j = 0; j < plain.length; j++) { var label = plain[j]; if (label.toLowerCase() == order[i].toLowerCase()) { jQuery(“#container”).append(“<div class=’register’> <span class=’ms-commandLink’>” + plain[j] + “</span><input type=’text’/></div>”); break; } } //Cajas de area de texto for (var k = 0; k < area.length; k++) { var label = area[k].substring(0, area[k].indexOf(‘[‘)); if (label.toLowerCase() == order[i].toLowerCase()) { var textArea = area[k].substring(area[k].indexOf(‘[‘) + 1, area[k].indexOf(‘]’)); var rows = textArea.split(“-”)[0]; var cols = textArea.split(“-”)[1]; jQuery(“#container”).append(“<div class=’register’> <span class=’ms-commandLink’>” + label + “</span><textarea rows=’” + rows + “’ cols=’” + cols + “’/></div>”); break; } } //Radio buttons for (var m = 0; m < radio.length; m++) {

135


var name = radio[m].substring(0, radio[m].indexOf(‘[‘)); if (name.toLowerCase() == order[i].toLowerCase()) { var choices = radio[m].substring(radio[m].indexOf(‘[‘) + 1, radio[m].indexOf(‘]’)).split(“-”); var result = “”; for (var n = 0; n < choices.length; n++) { if (choices[n].charAt(0) == “#”) { result += “<input type=’radio’ name=’” + name.toLowerCase() + “’ value=’” + choices[n].replace(‘#’, ‘’).toLowerCase() + “’ CHECKED>” + toTitleCase(choices[n].replace(‘#’, ‘’)); } else { result += “<input type=’radio’ name=’” + name.toLowerCase() + “’ value=’” + choices[n].toLowerCase() + “’>” + toTitleCase(choices[n]); } } jQuery(“#container”).append(“<div class=’register’> <span class=’ms-commandLink’>” + toTitleCase(name) + “</span>” + result + “</div>”); break; } } //check buttons for (var l = 0; l < check.length; l++) { var name = check[l].substring(0, check[l].indexOf(‘[‘)); if (name.toLowerCase() == order[i].toLowerCase()) { var choices = check[l].substring(check[l].indexOf(‘[‘) + 1, check[l].indexOf(‘]’)).split(“-”); var result = “”; for (var o = 0; o < choices.length; o++) { if (choices[o].charAt(0) == “#”) { result += “<input type=’checkbox’ name=’” + name.toLowerCase() + “’ value=’” + choices[o].replace(‘#’, ‘’).toLowerCase() + “’ CHECKED>” + toTitleCase(choices[o].replace(‘#’, ‘’)); } else { result += “<input type=’checkbox’ name=’” + name.toLowerCase() + “’ value=’” + choices[o].toLowerCase() + “’>” + toTitleCase(choices[o]);

136


} } jQuery(“#container”).append(“<div class=’register’> <span class=’ms-commandLink’>” + toTitleCase(name) + “</span>” + result + “</div>”); break; } } //drop down list for (var p = 0; p < dropdown.length; p++) { var name = dropdown[p].substring(0, dropdown[p].indexOf(‘[‘)); if (name.toLowerCase() == order[i].toLowerCase()) { var choices = dropdown[p].substring(dropdown[p].indexOf(‘[‘) + 1, dropdown[p].indexOf(‘]’)).split(“-”); var result = “<select>”; for (var q = 0; q < choices.length; q++) { if (choices[q].charAt(0) == “#”) { result += “<option value=’” + choices[q].replace(‘#’, ‘’).toLowerCase() + “’ SELECTED>” + toTitleCase(choices[q].replace(‘#’, ‘’)) + “</option>”; } else { result += “<option value=’” + choices[q].toLowerCase() + “’>” + toTitleCase(choices[q]) + “</option>”; } } result += “</select>”; jQuery(“#container”).append(“<div class=’register’> <span class=’ms-commandLink’>” + toTitleCase(name) + “</span>” + result + “</div>”); break; } } //buttons for (var r = 0; r < button.length; r++) { var name = button[r].substring(0, button[r].indexOf(‘[‘)); if (name.toLowerCase() == order[i].toLowerCase()) { var type = button[r].substring(button[r].indexOf(‘[‘) + 1, button[r].indexOf(‘]’)).toLowerCase(); jQuery(“#container > .buttons”).append(“<button type=’” + type + “’>” + toTitleCase(name) + “</button>”); break; }

137


} } //Añadimos el titulo jQuery(“#container > div.title.html(title.replace(“%20”, “ “)); //Movemos los botones al final del formulario jQuery(“#container”).append(jQuery(“#container > .buttons”)); }

En esta función recae todo el peso de la lógica de la App Part. Lo que se hace en ella es úni-camente consultar la QueryString en busca de una sería de parámetros concretos, y después formar los campos del formulario a partir de la información de estos parámetros. Cada uno de estos parámetros se corresponde con campos a insertar dinámicamente en el formulario. La clave está en que estos parámetros tienen un valor con un formato específico, de manera que su interpretación da información acerca de cómo crear el campo en cuestión. Estos son los nombres de los parámetros, con el tipo de campo de formulario que crean y el formato que usan:

Cajas de texto plano: plain=Campo1;Campo2;Campo3

Donde los valores campo1 y campo2 indican el nombre de la etiqueta que da nombre a las cajas de texto.

Cajas de áreas de texto: area=Campo1[f-c];Campo2[f-c];Campo3[f-c]

Donde el valor campo1 y campo1, indican el nombre de la etiqueta que acompaña a la caja de área de texto, y los valores f y c se corresponden con el numero de filas y columnas con los que crear la caja de texto.

Botones tipo radio: radio=Campo1[Valor1-Valor2];Campo2[Valor1-#Valor2]

Donde los valores campo1 y campo2, indican el nombre de la etiqueta que acompaña a la botones de tipo radio, y los valores Valor1 y Valor2, son los posibles valores. Por ejemplo, un uso podría ser: radio=Sexo[Hombre-Mujer]

Podemos poner el carácter almohadilla (#) delante de un valor, para especificar que sea el valor por defecto. Por ejemplo: radio=Color[Amarillo-Rojo-#Azul]

Botones de cajas de validación (checkboxes): check=Campo1[Valor1-Valor2];

138


Es el mismo funcionamiento que en el caso anterior, solo que el resultado se muestra como botones de cajas de validación.

Listas desplegables(dropodown list): dropdown=Campo1[Valor1-Valor2-Valor3];

Es el mismo funcionamiento que en el caso anterior, solo que el resultado se muestra como una lista desplegable.

Botones: button=Boton1[Submit];Boton2[Reset]

Donde los valores Boton1 y Boton2, indican el texto dentro del botón, y el contenido dentro de los corchetes es la función que realizan.

Orden de los campos: order=Campo1;Campo2;Campo3;Campo4

Por último tenemos el parámetro order para indicar en qué orden queremos que apa-rezcan los campos en el formulario. Para ello, simplemente se escriben secuencialmente los nombres de los campos que hemos ido poniendo, en el orden que aparezcan. Si el nombre del algún campo no aparece, este no se mostrará.

function getQueryStringParameter(paramToRetrieve) { var params = document.URL.split(“?”)[1].split(“&”); var strParams = “”; for (var i = 0; i < params.length; i = i + 1) { var singleParam = params[i].split(“=”); if (singleParam[0] == paramToRetrieve) return singleParam[1]; } } function existsQueryStringParameter(field) { var url = window.location.href; if (url.indexOf(‘?’ + field + ‘=’) != -1) return true; else if (url.indexOf(‘&’ + field + ‘=’) != -1) return true; return false; } function toTitleCase(str) { return str.replace(/\w\S*/g, function (txt) { return txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase(); }); } function formFocus() { var inputs = jQuery(“#container > div.register > input[type=text]”); var prevColor = jQuery(“#container”).css(“background-color”); inputs.focus(function () {

139


jQuery(this).parent(“div.register”).css(“background-color”, “rgb(79,172,55)”); jQuery(this).css(“background-color”, “#FFF”); }).blur(function () { jQuery(this).parent(“div.register”).css(“background-color”, prevColor); jQuery(this).css(“background-color”, “rgba(255, 255, 255, 0.85)”); }); }

El resto de funciones se utilizan como “herramientas” para consultar la QueryString, com-probar si tiene valor algún parámetro de la QueryString, y dejar en minúsculas una cadena de texto, excepto el primer carácter. La función formFocus se utiliza para resaltar el campo del formulario que está editando el usuario.

Paso 7. Ya tenemos casi todos los componentes listos. Tan solo nos falta configurar la App Part mediante su fichero Elements.xml asociada, para indicarle qué página debe usar, cuál es el tamaño del iFrame donde se muestra, y cuáles van a ser sus parámetros de configuración. Para ello editamos el archivo Elements.xml, y sustituimos su contenido por el siguiente:

<?xml version=”1.0” encoding=”UTF-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <ClientWebPart Title=”Custom Form” Name=”Custom Form” Description=”My Custom Form!.” DefaultHeight=”600” DefaultWidth=”392”>  <Content Src=”~appWebUrl/Pages/CustomFormAppPartPage.aspx?titulo=_titulo_ &plain=_plain_&area=_area_&radio=_radio_& check=_check_& dropdown=_dropdown_& button=_button_ &order=_order_&{StandardTokens}” Type=”html”/> <Properties> <Property Name=”titulo” Type=”titulo” RequiresDesignerPermission=”true” DefaultValue=”Contact Us” WebCategory=”Configuración”

140


WebDisplayName=”Cajas de texto:”> </Property> <Property Name=”plain” Type=”string” RequiresDesignerPermission=”true” DefaultValue=”Nombre;Apellidos;Email;Website” WebCategory=”Campos” WebDisplayName=”Cajas de texto:”> </Property> <Property Name=”area” Type=”string” RequiresDesignerPermission=”true” DefaultValue=”Mensaje[10-41]” WebCategory=”Campos” WebDisplayName=”Cajas de area de texto:”> </Property> <Property Name=”radio” Type=”string” RequiresDesignerPermission=”true” DefaultValue=”Sexo[Hombre-Mujer]” WebCategory=”Campos” WebDisplayName=”Botones de tipo radio:”> </Property> <Property Name=”check” Type=”string” RequiresDesignerPermission=”true” DefaultValue=”Aficiones[Deporte-Viajar-Cine-Lectura-Fiesta]” WebCategory=”Campos” WebDisplayName=”Botones de cajas de validación:”> </Property> <Property Name=”dropdown” Type=”string” RequiresDesignerPermission=”true” DefaultValue=”Pais[Argentina-Italia-Francia-USA-Otros]” WebCategory=”Campos” WebDisplayName=”Listas desplegables:”> </Property> <Property Name=”button” Type=”string” RequiresDesignerPermission=”true”

141


DefaultValue=”Enviar[submit];Limpiar[reset]” WebCategory=”Campos” WebDisplayName=”Botones:”> </Property> <Property Name=”order” Type=”string” RequiresDesignerPermission=”true” DefaultValue=”Nombre;Apellidos;Email;Website;Limpiar;Enviar” WebCategory=”Campos” WebDisplayName=”Orden de los campos:”> </Property> </Properties> </ClientWebPart> </Elements>

El contenido de este Elements.xml ya no nos debe pillar por sorpresa. En primer lugar definimos el contenido del mismo, y en segundo lugar, las propiedades de configuración, que le serán enviadas a la App Part mediante QueryString. Es por eso que cuando especificamos la URL de la página que contiene el cuerpo de la app, anidamos en ella todos los parámetros de la QueryString que hemos definido, siguiendo un formato especificado por SharePoint. Son estos parámetros en la QueryString, los que consultaremos y trataremos desde las funciones JavaScript que hemos definido anteriormente.

Además, nos debemos fijar que a los parámetros de configuración que definimos, pode-mos ponerle unos valores por defecto. En este caso, estos valores por defecto están estable-cidos para crear un formulario básico de contacto. Aunque todos los parámetros tienen valor, fijémonos en la propiedad order, donde solo incluimos algunos de ellos. El resto se quedan a modo de ejemplo para futuros usos.

Paso 8. Ya solo queda depurar la aplicación desde Visual Studio 2012, y comprobar cuál es el resultado de nuestra App Part. Para ello, como siempre, pulsamos [F5] y esperamos a que se inicie una instancia del navegador que tengamos definido por defecto. A continuación, se nos pedirá que introduzcamos las credenciales. Finalmente, accederemos al listado de apps que hay instaladas en el Sitio del Desarrollador que hayamos especificado. Comprobamos que efectivamente, aparece nuestra app entre ellas.

Como hemos creado una App Part, para verla en acción, accedemos a alguna página cual-quiera, la editamos, y añadimos un Web Part en la zona que queramos. Bajo la sección de Apps, debemos encontrar a nuestra app. Una vez la incluyamos en la página, ésta deberá de ser el aspecto final.

142


Figura 3-42. Resultado final de la App Part

Como vemos, hemos conseguido una app plenamente funcional, sin renunciar a un buen diseño. En este caso, estamos añadiendo simplemente cuatro campos de caja de texto simples, y dos botones, pero gracias a los parámetros de configuración que se le envían mediante QueryString, podríamos adaptar la App Part según los requisitos del momento, tanto como quisiéramos. Solo sería cuestión de editar la App Part mediante su panel de configuración (igual que haríamos para un elemento web –Web Part- clásico), y añadir nuevos campos siguiendo los formatos que vimos anteriormente.

Y con este ejemplo, damos por terminada la sección dedicada a hablar de cómo maquetar y diseñar SharePoint-hosted Apps. Hemos visto que desarrollar apps desde cero, dista muy poco de diseñar cualquier página de una aplicación web, siendo éste su principal “reclamo”. Pasamos ahora a ver qué tenemos que tener en cuenta si nos decidimos por las Cloud-hosted Apps.

143


Cloud-hosted Apps

Introducción

Una vez explicadas las apps que “viven” en el propio SharePoint, desde el punto de vista más estrictamente relacionado con diseño y la maquetación, toca hacer lo propio con las apps que se encuentran al otro lado de la arquitectura, es decir, aquellas que tienen su “casa” en la Nube.

Dentro de esta subcategorización de apps (la de las Cloud-hosted Apps), tenemos a su vez dos opciones: Autohosted Apps, y Provider-hosted Apps. A estas alturas de este libro, ya sabe-mos que las Autohosted se caracterizan por usar Azure como servidor en la Nube predefinido (y por tanto, la opción recomendada por Microsoft), mientras que con las Provider-hosted no tenemos ninguna limitación, en cuanto a qué tipo de hospedaje en la Nube utilizar (aunque todo el mantenimiento, obviamente, corre por nuestra cuenta). En cualquier caso, elijamos un mecanismo u otro para ubicar nuestras apps en la Nube, en ambos casos hay un punto muy importante a tener en cuenta: podemos utilizar cualquier tecnología web para desarrollar, y por tanto, maquetar y diseñar nuestra SharePoint app. Éste es un punto del que ya hemos hablado anteriormente, pero que considero que merece la pena reincidir, porque es una de las premisas en las que Microsoft más confía para garantizar el éxito de su plataforma de apps para SharePoint. Dado que SharePoint 2013 se basa en tecnologías web que son están-dares como HTML, CSS, JavaScript, OData, Rest, etc., desarrollar para SharePoint deja de ser exclusivo para los desarrolladores afines a Microsoft. De hecho, hay una frase en la documen-tación de MSDN de Microsoft que define perfectamente, de forma muy concisa, el mensaje que se quiere transmitir:

“Las apps son básicamente aplicaciones web. Si sabes hacer una aplicación web, sabes hacer una app para SharePoint.”

Por tanto, las Cloud-hosted Apps son una gran oportunidad de negocio, que debemos tener muy presente, cuando vayamos a decidirnos sobre qué tipo de app basar nuestro desarrollo.

Centrándonos en el asunto que nos preocupa en este capítulo, la maquetación y diseño de apps, es obvio que maquetar y diseñar Cloud-hosted Apps es mucho más “libre” que en el caso de las SharePoint-hosted Apps. Aquí no tenemos reglas que seguir, en cuanto a una página maestra que se aplica por defecto, una maquetación basada en ContentPlaceHolders, etc. Aquí, lo que tenemos es un lienzo completamente en blanco. Partimos de cero. Lo cual también tiene sus ventajas. Por ejemplo, si ya tenemos una app de Facebook en PHP, adaptarla para que se convierta en una app de SharePoint, solo sería cuestión de modificar el acceso a datos, ya que la presentación nos podría valer la misma. Anteriormente, hemos hablado de centrar nuestro foco en la maquetación y diseño de apps, en conseguir que se adapten al entorno que

144


las contiene y parezcan un elemento más de él, en vez de un parche. ¿Cómo conseguimos esto con una Cloud-hosted App, donde no tenemos ninguna conexión directa con SharePoint? Bueno, a ésta y otras preguntas, vamos a tratar de darle respuesta en esta sección.

Estructura de un proyecto Cloud-hosted

Dado que vimos en la sección anterior cuál es la estructura de un proyecto SharePoint-hosted, vamos a hacer lo propio con un proyecto Cloud-hosted.

Figura 3-43. Estructura de un proyecto Cloud-hosted

La estructura de una Cloud-hosted App que se crea en Visual Studio 2012 con las corres-pondientes plantillas es la misma para Autohosted y Provider-hosted. En ambos casos, tene-mos una solución que contiene un proyecto para la definición de la app, mediante el archivo AppManifest.xml. Y otro proyecto con una aplicación web ASP.NET clásica, con la que dar forma a la app. Hay que tener claro, que éste es el proyecto base que ofrece Visual Studio 2010. Si no queremos una aplicación web basada en ASP.NET, incluso como si no queremos usar Visual Studio, como ya hemos visto, no tenemos ninguna obligación. Pero resulta lógico, que usando Visual Studio como plataforma de desarrollo, se proporcione ASP.NET como tecnología base.

Así pues, analizando los componentes de la Cloud-hosted App, vemos que ésta se encuen-tra completamente vacía, a diferencia del proyecto base de Visual Studio para la SharePoint-hosted App. Como vimos para las SharePoint-hosted Apps, el proyecto que crea Visual Studio 2012 ya contiene una serie de archivos por defecto, a partir de los cuales iniciar el desarrollo. Pero en este caso, si queremos añadir archivos CSS, JavaScript o páginas HTML, tenemos que ir a la aplicación web y añadirlos manualmente, y seguidamente incluir las referencias que toquen. Tenemos libertad total para desarrollar y maquetar, pero esa libertad también conlleva un poco de trabajo extra por nuestra parte. La “magia” de Visual Studio 2012 hace que cuando

145


depuramos la app, se lance un IIS Express para ejecutar la aplicación web, y a donde se dirigen las solicitudes desde el sitio SharePoint “anfitrión”.

Antes de continuar, resulta interesante comentar que en las Cloud-hosted Apps, podemos seguir usando componentes de SharePoint como listas, módulos, columnas de sitios, etc. Es decir, en el proyecto que contiene la definición de la app, podríamos añadir un nuevo elemento de SharePoint. La pregunta entonces sería, ¿si en este caso mi app no se aloja en SharePoint, donde se crean esos componentes? Pues la respuesta es que SharePoint crea un nuevo sitio, como el que se crea para una SharePoint-hosted App, para alojar dichos componentes. De esta forma, estaríamos ante un alojamiento mixto de apps.

Apps de Página completa

En la sección anterior vimos qué mecanismos ofrece SharePoint 2013 para trabajar con las App Parts, y emplazábamos a ver los mecanismos que existen para trabajar con las apps de Página completa en la presente sección de Cloud-hosted Apps. Es ahora, que sabemos que la aplicación web (en la tecnología que sea) que constituye una Cloud-hosted App no presenta ninguna conexión con SharePoint, cuando tiene sentido preguntarse, ¿cómo puedo conseguir que una app de Página completa, no parezca una página aislada, si no que realmente sea un elemento más de SharePoint? La respuesta a esa pregunta tiene un nombre que ya conocemos: Client Chrome Control.

Client Chrome Control

El Client Chrome Control es un mecanismo que ofrece SharePoint 2013 para poder heredar el aspecto o la apariencia (el look and feel que dirían los angloparlantes) del sitio SharePoint donde instalamos la app. Se trata de control JavaScript que añade elementos propios de SharePoint a la cabecera de la página que forma la app como el título, la miga de pan (breadcrumb), el logo, etc. Y además “inyecta” los estilos del sitio SharePoint anfitrión para dar el mismo aspecto en cuanto a fuentes, tamaños, etc., al resto de elementos de la app. Pero como la mayoría de las cosas en la vida, la mejor manera de entender un concepto es aplicándolo uno mismo. Así que vamos a ello con el siguiente paso a paso.

Paso 1. Lo primero es crear un nuevo proyecto en Visual Studio 2012, partiendo de la plantilla “App for SharePoint 2013”. En mi caso, he llamado al nuevo proyecto, Demo1. Cuando llegamos a la pantalla donde debemos especificar el sitio SharePoint objetivo (recordemos que debe ser un sitio creado con la plantilla “Sitio del Desarrollador”), nos aseguramos de seleccionar la opción “Autohosted”, como mecanismo para alojar nuestra app. A estas alturas del partido, ya sabemos que con este mecanismo de aprovisionamiento de apps, las apps se alojan en la Nube, concretamos en Azure.

146


Figura 3-44. Proyecto de Visual Studio para una app en modo Autohosted

Paso 2. Si nos fijamos en la aplicación web ASP.NET que se incluye en la solución (el segundo proyecto), contiene una página por defecto, default.aspx. Esta página será el cuerpo de nuestra app de Página completa. Actualmente, como es de esperar, se encuentra completamente vacía, por lo que en este paso es donde debemos dar contenido a dicha página. Por ejemplo, pode-mos añadir un clásico “¡Hola Mundo!”, para simplemente depurar la app y comprobar que vamos bien hasta ahora.

<%@ Page Language=”vb” AutoEventWireup=”false” CodeBehind=”Default.aspx.vb” Inherits=”Demo1Web._Default” %> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> <html xmlns=”http://www.w3.org/1999/xhtml”> <head runat=”server”> <title>Mi App en Página Completa</title> </head> <body> <form id=”form1” runat=”server”>  <h1 class=”ms-accentText”>Hola Mundo!</h1>

147


</form> </body> </html>

Así pues, si en este momento depuramos la aplicación desde Visual Studio ([F5]), vemos cómo, en primer lugar, se abre una instancia de Internet Explorer y a continuación se nos pide que introduzcamos las credenciales para autenticarnos en el sitio web. Acto seguido, se nos pregunta si la app que vamos a desplegar en el sitio es de confianza. Dado que la app la hemos hecho nosotros, y somos gente de fiar, decimos que sí :).

Figura 3-45. SharePoint pregunta si la app que vamos a instalar es de confianza

Y éste es lo que obtenemos:

Figura 3-46. Contenido de nuestra Autohosted App, antes de aplicar el Chrome Control

148


Paso 3. Una vez definido el contenido de la página, es el momento de hacer uso del Client Chrome Control. Para ello, el primer paso y el más sencillo, es añadir a nuestra página una etiqueta <div> a modo de “marcador de posición”. Este <div> debe ser el primer elemento en la página, con un atributo ID reconocible. Esta etiqueta sirve al Client Chrome Control, para, mediante JavaScript, insertar en la página el resultado del procesamiento del control. Por lo que el maquetado de nuestra página queda así:

<%@ Page Language=”vb” AutoEventWireup=”false” CodeBehind=”Default.aspx.vb” Inherits=”Demo1Web._Default” %> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”> <html xmlns=”http://www.w3.org/1999/xhtml”> <head runat=”server”> <title>Mi App en Página Completa</title> </head> <body> <form id=”form1” runat=”server”>  <div id=”chrome_control_marcador”></div>  <h1 class=”ms-accentText”>Hola Mundo!</h1> </form> </body> </html>

Paso 4. A continuación, definimos el código JavaScript necesario para hacer funcionar el Client Chrome Control. Dicho código bien pudiera ir en la propia página, pero para seguir las buenas prácticas de desarrollo, creamos un fichero default.js aparte. En dicho fichero, inserta-mos el siguiente código:

var hostweburl; // Obtenemos los recursos de SharePoint necesarios. jQuery(document).ready(function () { // Obtenemos la URL decodificada del sitio SP anfitrion (Host Web), a // partir de los parametros en la Query String. hostweburl = decodeURIComponent(getQueryStringParameter(“SPHostUrl”)); // Los archivos js se encuentran todos a partir de “/_layouts/15/”

149


var scriptbase = hostweburl + “/_layouts/15/”; // Cargamos el fichero SP.UI.Controls.js necesario, y continuamos con la // ejecuacion con el manejador de exito correspondiente. jQuery.getScript(scriptbase + “SP.UI.Controls.js”, prepararChrome) }); //En esta función se configuran las opciones y se ejecuta el control. function prepararChrome() { //Las URLs que definimos para las páginas de Ayuda, Cuenta, Contacto, etc //las formamos agregando la misma Query String que la URL del sitio anfitrion. var options = { “appIconUrl”: “../images/sp.jpg”, “appTitle”: “Título de mi App”, “appHelpPageUrl”: “Ayuda.html?” + document.URL.split(“?”)[1], “settingsLinks”: [ { “linkUrl”: “cuenta.html?” + document.URL.split(“?”)[1], “displayName”: “Mi Cuenta” }, { “linkUrl”: “contactanos.html?” + document.URL.split(“?”)[1], “displayName”: “Contáctanos” }, { “linkUrl”: “configuraciones.html?” + document.URL.split(“?”)[1], “displayName”: “Configuraciones”} ] }; var nav = new SP.UI.Controls.Navigation(“chrome_control_marcador”, options); nav.setVisible(true); } // Función para obtener un valor de la Query String function getQueryStringParameter(paramToRetrieve) { var params = document.URL.split(“?”)[1].split(“&”); var strParams = “”; for (var i = 0; i < params.length; i = i + 1) { var singleParam = params[i].split(“=”); if (singleParam[0] == paramToRetrieve) return singleParam[1]; } }

150


Analizando el código JavaScript, vemos que el funcionamiento del Client Chrome Control es muy sencillo. En primer lugar, mediante jQuery, capturamos cuando el DOM de la página está com-pletamente cargado, y acto seguido cargamos en la página el fichero JavaScript SP.UI.Controls.js. Si el citado fichero, se carga con éxito en la página, pasamos a ejecutar la función prepararChrome, que hace las veces de callBack. Es en esta función donde llevamos a cabo la configuración del Client Chrome Control y, finalmente, procedemos a su ejecución.

De las opciones posibles de configuración nos debe llamar la atención las siguientes:

• appIconUrl. Especificamos la URL del icono de la app.

• appTitle. Título de la app, para mostrar en la “miga de pan” y en el cuerpo de la app.

• appHelpPageUrl. Dirección para la página de ayuda.

• settingsLinks. Dirección(es) de la(s) página(s) bajo la sección de configuración.

o linkUrl. URL de la página en cuestión.

o displayName. Nombre a mostrar para identificar la página.

Una vez tenemos lista las configuraciones, ejecutamos el control, ligando su resultado con la etiqueta <div> que definimos al principio.

Paso 5. Finalmente, incluimos las referencias en la página al fichero JavaScript que acaba-mos de crear, así como a jQuery y a la librería de Ajax de Microsoft.

<script src=”http://ajax.aspnetcdn.com/ajax/4.0/1/MicrosoftAjax.js” type=”text/javascript”></script> <script type=”text/javascript” src=”https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js”> </script> <script type=”text/javascript” src=”../js/default.js”></script>

Solo queda ver el resultado del Client Chrome Control, para lo que pasamos a depurar ([F5]) nuevamente la app.

151


Figura 3-47. Contenido de nuestra Autohosted App, después de aplicar el Chrome Control

Como vemos, la apariencia de la app ha cambiando por completo, adaptándose al diseño de SharePoint. Por lo que construir aplicaciones en modo Página completa, no suponen ningún problema en cuanto a respetar los estilos del sitio anfitrión o Host Web se refiere, aun tratando con apps del tipo Cloud-hosted.

Modelo de objetos de cliente y API REST en SharePoint 2013

Empezaremos este nuevo capítulo hablando de las novedades que aporta SharePoint 2013 en cuanto al modelo de objetos de cliente. Seguiremos con una breve exposición de las distin-tas API disponibles de desarrollo y por último nos centraremos principalmente en las noveda-des en cuanto a la API REST de la plataforma.

Comentar que fue en la versión 2010, cuando se introdujo dicho modelo de objetos de cliente el cual permitía interactuar de forma remota con sitios de SharePoint sin tener que recurrir a ningún tipo de servicio web.

152


Pues bien, en la nueva versión de SharePoint mantenemos el modelo de objetos de cliente y además lo ampliamos permitiéndonos así trabajar también con metadatos administrados, la búsqueda, etc…

Respecto a la arquitectura, se sigue manteniendo la misma, incluyendo una nueva API bautizada como _api como bien se dijo en el capítulo 2. Dentro del modelo de objetos de cliente, disponemos de varias vías para comunicarnos con SharePoint, mediante código .NET Framework, Silverlight, JavaScript y REST. A continuación, un gráfico explicativo de cómo fun-ciona la arquitectura del modelo de objetos en cliente.

Figura 3-48. Arquitectura del modelo de objetos de cliente

Interfaces de desarrollo (API) disponibles

Tendremos varios conjuntos de API que podremos utilizar, lo importante será saber cuál es la más apropiada en cada caso. Éste es un paso muy importante, ya que elegir una API equivo-cada nos haría perder mucho tiempo. Para elegir una API u otra, básicamente tendremos que tener en cuenta 3 factores:

153


• Tipo de la aplicación. Donde podemos encontrarnos con aplicaciones para SharePoint, elementos web de páginas de SharePoint, aplicaciones ASP.NET que se han expuesto en SharePoint con un IFrame, JavaScript que se ejecuten en páginas de sitios de SharePoint, aplicaciones de consola para administración de SharePoint, Timer Jobs personalizados, etc…

• Habilidades del desarrollador. Unas habilidades u otras nos harán decantarnos por el tipo de API. Entre estas habilidades encontramos JavaScript, ASP.NET, REST/OData, .NET Framework, Silverlight, Windows Phone y Windows PowerShell.

• El dispositivo en el que se ejecuta el código. Servidores de SharePoint, servidores externos, equipos cliente, dispositivos móviles, etc…

Una vez comentados estos factores, vamos a definir brevemente las API que hay disponi-bles para SharePoint comenzando con un gráfico que nos va a ayudar a agruparlas en conjuntos.

Figura 3-49. Conjuntos de API de SharePoint (este diagrama ha sido seleccionado de MSDN)

Modelo de Objetos de Servidor

Es el conjunto de mayor tamaño, en cuanto a funcionalidad disponible se refiere. Se encuen-tra en el modelo de objetos de servidor. La mayor parte de estas clases se encuentran en el

154


espacio de nombre Microsoft.SharePoint. Además, la mayoría de los componentes SharePoint son extensibles al modelo de objetos de servidor.

Limitación para las SharePoint Apps: No se puede usar el modelo de objetos de servidor en una app para SharePoint, puesto que la idea es que se ejecute en un contexto aislado y, además, la mayoría de las veces quedarán alojadas en servidores externos.

Modelo de Objetos de cliente (CSOM “Client-side object model”)

En SharePoint 2013 disponemos de varios modelos de objetos de cliente para nuestro código: .NET, JavaScript, Silverlight y Silverlight para móviles.

Modelo de objetos de cliente .NET

Este modelo se utiliza en aplicaciones de .NET Framework que se ejecutan en clientes de Windows (que no son teléfonos) como puede ser un equipo de un usuario, un servidor externo a la granja de SharePoint, etc… Un ejemplo de esto es una aplicación de escritorio de Windows que nos permita acceder a las listas de SharePoint para ver la información.

Modelo de objetos de cliente de Silverlight

Se usa en las aplicaciones de Silverlight. Es idéntico al modelo de objetos de cliente de .NET Framework. La principal diferencia está en que en la versión de Silverlight, todos los lotes de comandos se envían al servidor de forma asíncrona, por lo que la IU de la aplicación per-manece activa.

Los ensamblados del modelo de objetos de cliente de Silverlight suelen guardarse en ProgramFiles\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin. Recuerda que en las apps de SharePoint no se puede utilizar el modelo de objetos de servidor.

Modelo de objetos de móviles de Silverlight

Para este apartado existe una versión especial del modelo de objetos de cliente de Silverlight disponible para los teléfonos con Windows Phone 7. Incluye algunas API adicionales que solo son relevantes para los teléfonos, como puede ser una API que permite a una aplicación de móviles registrar las notificaciones sirviéndose del servicio Microsoft Push Notification.

155


Los ensamblados se pueden guardar en ProgramFiles\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\ClientBin y deben ir empaquetados en el archivo .xap de la aplicación.

Modelo de objetos JavaScript (JSOM)

SharePoint 2013 ofrece un modelo de objetos de JavaScript que se puede usar en archi-vos con extensión .js independientes, e incluye la misma funcionalidad que los modelos de objetos de cliente de .NET Framework y Silverlight. Este modelo de objetos se puede usar para interactuar con contenido de SharePoint desde las SharePoint apps (ya que no se permite usar código de servidor). La infraestructura del modelo de JavaScript interactúa con los servidores de forma asíncrona. Se soluciona el problema de cross-domain. Este problema surge al intentar la comunicación entre varios dominios. El servidor devuelve los datos en formato JSON.

API REST/OData

Esta API surge de la necesidad de obtener acceso a las entidades de SharePoint desde tecnologías de cliente que no usan JavaScript y no se encuentran integradas en las plataformas .NET Framework o Siliverlight. Esto quiere decir, que podríamos acceder a SharePoint desde cualquier lenguaje de programación como PHP, JSP, Action Script, Flash, Cocoa, etc… Por lo tanto, ya podéis imaginar la gran potencia de esta API REST, la cual nos permite unificar el acceso a SharePoint desde cualquier dispositivo y plataforma. Para tal fin, SharePoint 2013 ofrece la implementación de un servicio web (REST Representational State Transfer) que usa el protocolo OData para realizar las operaciones sobre listas SharePoint.

OData viene de las siglas “Open Data Protocol”. Principalmente se utiliza para exponer datos de una forma genérica, por ejemplo, en nuestro caso, podría ser una lista. Para consultar estos datos desde la aplicación cliente es necesario crear una URI siguiendo el estándar OData. Aquí es donde entra REST como protocolo de comunicación entre los datos y la aplicación cliente enviando una petición HTTP RESTful con el endpoint correspondiente. La respuesta emitida que recibe la aplicación cliente se encontrará en formato JSON o Atom.

Otra cosa a mencionar es que prácticamente todas las API de los modelos de objetos de cliente cuentan con su correspondiente extremo de REST. Esto nos permite interactuar con SharePoint a través de cualquier tecnología compatible con las capacidades estándar de REST. Para usar las capacidades de REST que se encuentran integradas en SharePoint 2013, el código construye una solicitud HTTP RESTful para un extremo correspondiente a la API del modelo de objetos de cliente que el usuario especifica. El servicio web client.svc controla la solicitud HTTP y emite una respuesta en formato Atom o JSON.

156


A continuación, un gráfico explicativo, el cual muestra la relación existente entre las API de cliente y SharePoint.

Figura 3-50. Aplicaciones en el lado del cliente y API de SharePoint

API REST en SharePoint 2010

Antes de entrar en materia sobre la API REST en SharePoint 2013, deberíamos hablar del estado de esta API en la versión anterior del producto. En SharePoint 2010, ya disponíamos de esta API, aunque su funcionalidad estaba muy limitada. Al igual que en SharePoint 2013, se servía del protocolo OData.

En SharePoint 2010 se introdujo el soporte para WCF Data Services que nos permitía con-sultar de forma sencilla listas y bibliotecas, además de poder realizar operaciones CRUD sobre las mismas dentro de cualquier plataforma que soportara REST, la cual podía ser .NET o no. Para tal fin, se utilizaba el servicio ListData.svc. A la hora de acceder a dicho servicio, la URL quedaría http://mistio/_vti_bin/ListData.svc.

157


Figura 3-51. API REST en SharePoint 2010

API REST SharePoint 2013

Una vez visto el funcionamiento de esta API bajo SharePoint 2010, ahora es el turno de verlo bajo SharePoint 2013.

Ahora no solo vamos a poder interactuar con listas y bibliotecas de sitios, sino que también podremos interactuar con sitios y servicios. SharePoint 2013 cuenta con una API REST que se bautiza como _api. Ahora las URL serán del tipo http://misitio/_api/..., por ejemplo, para consultar el nombre de un sitio mediante código manejado la URL será http://misitio/_api/Web/?$select=Title. El símbolo “$” es un mecanismo estándar de OData para filtrar resultados sobre una petición. También podríamos usar el navegador para consultar directamente el nom-bre del sitio introduciendo http://mistio/_api/Web/title Mencionar que _api es un nombre abs-tracto o se podría decir una abreviatura de _vti_bin/client.svc ya que las URL tienen la limitación de 256 caracteres.

Como hemos comentado anteriormente, la API REST nos permite interactuar con SharePoint usando cualquier tecnología que soporte REST. Para usar REST, se construye una petición HTTP usando el protocolo OData. El servicio client.svc maneja la petición HTTP y emite la respuesta en formato Atom o JSON. La aplicación cliente debe entonces parsear la respuesta. En el siguiente gráfico se puede apreciar la arquitectura del servicio REST.

http://misitio/_api/Web/?$select=Title

http://misitio/_api/Web/?$select=Title

158


Figura 3-52. Arquitectura servicio REST de SharePoint 2013

URI del servicio REST

La mayoría de las API de modelo de objetos de cliente tienen o está planificado que tengan su correspondiente endpoint. Puedes usar REST endpoints para ejecutar peticiones HTTP usando un servicio basado en URI, para recuperar o actualizar entidades de SharePoint. Podríamos decir que cada entidad de SharePoint está expuesta mediante un endpoint repre-sentado en formato XML o JSON. Por lo tanto, para acceder a dichas entidades se necesita saber la URL del endpoint correspondiente. Esto nos permite, conociendo los endpoints, realizar peticiones HTTP en cualquier lenguaje.

Resumiendo, el endpoint proporciona a las aplicaciones cliente acceso a la funcionalidad del servicio. A continuación, vamos a ver cómo construir estas URI empezando desde lo más básico.

Para empezar, debemos tener claros los principales puntos de entrada del servicio REST que corresponden con la colección de sitios y el sitio actual.

CONTEXTO REST SERVIDOR CLIENTEColección de sitios

http://myapplication/site/_api/site

SPContext.Current.Site ClientContext.Site

Sitio actual http://myapplication/site/_api/web

SPContet.Current.Web ClientContext.Web

A partir de esto, que es lo básico, podremos construir el resto de las URI necesarias para acceder al modelo de objetos desde REST. Mencionar también que da igual poner mayúsculas



http://myapplication/site/_api/web

http://myapplication/site/_api/web

159


y minúsculas, por ejemplo, esta URI: http://myapplication/site/_api/web/lists/getbytitle(“Title”) que obtiene una determinada lista, se corresponde con la función GetByTitle del modelo de objetos de cliente y funcionaría a la perfección.

Además de acceder a la colección de sitios y al sitio actual, tenemos otros puntos de acceso:

ÁREA PUNTO DE ACCESOColección de sitios http://myapplication/site/_api/siteSitio actual http://myapplication/site/_api/webPerfil de usuario http://myapplication/site/_api/SP.UserProfiles.PeopleManagerBúsqueda http://myapplication/site/_api/searchPublicación http://myapplication/site/_api/publishing

Utilizar parámetros con “alias”

A la hora de pasar parámetros por REST, les podemos poner los identificadores que queramos, es decir, les podemos poner un “alias”. En el siguiente ejemplo vemos que asigna el alias @tem-plate al título y posteriormente le da valor.

http://myapplication/site/api/web/appyWebTemplate(title=@template)?@template=”STS#0

Parámetros en la query string

También podemos pasar parámetros en la query string en la llamada REST.

http://myapplication/site/_api/web/applyWebTemplate?template=”STS#0”

Métodos específicos y propiedades

También es posible construir URI mediante métodos estáticos o propiedades. Estas URI tienen su equivalencia en métodos o propiedades estáticas en las cuales se utiliza la sentencia equiva-lente del modelo de objetos ECMAScript. La pega que tienen estas propiedades es que tienen que ser accesibles directamente.

http://myapplication/site/_api/SP.Utilities.Utility.getImageUrl(‘imageName’)

http://myapplication/site/_api/web/lists/getbytitle(�Title�)

http://myapplication/site/api/web/appyWebTemplate(title=@template)?@template=�STS#0

http://myapplication/site/_api/SP.Utilities.Utility.getImageUrl(�imageName�)

160


Consultar elementos

Para consultar elementos mediante llamadas REST, tenemos el parámetro $select. Este parámetro especifica qué campos serán devueltos. El comodín “*” indica que se devuelve todo el conjunto de campos; por defecto es la opción que se ejecuta.

http://myapplication/site/_api/web/lists/getbytitle(‘nombreLista’)?$select=Title

Filtrar elementos

Para obtener un conjunto de elementos filtrados utilizaremos la cláusula $filter.

http://myapplication/site/_api/web/lists/getbytitle(‘Customers’)/items?$filter= Country eq ‘UK’

Operadores que podemos utilizar

COMPARACIONES NUMÉRICAS COMPARACIONES DE CADENAS FUNCIONES DE FECHASLt, Le, Gt, Ge, Eq, Ne startsWidth, substringof, Eq, Ne day(), month(), year(), Hour(),

minute(), second()

Ordenar elementos

Para ordenar elementos que nos ha devuelto la query utilizamos la cláusula $orderby. Para ordenar por varios campos estos irán separados por “,”. También se puede especificar si que-remos dicho orden en ascendente o descendente con “asc” y “desc”.

http://myapplication/site/_api/web/lists/getbytitle(‘Customers’)/items?$orderby=Name

Cláusula top

Esta opción permite traernos los n primeros elementos.

http://myapplication/site/_api/web/lists/getbytitle(‘Customers’)/items?$top=10

http://myapplication/site/_api/web/lists/getbytitle(�Customers�)/items?$filter= Country eq 'UK'

http://myapplication/site/_api/web/lists/getbytitle(�Customers�)/items?$filter= Country eq 'UK'

161


Errores y excepciones

En caso de errores o excepciones, el endpoint del servicio REST devuelve el error HTTP correspondiente, los cuales citamos a continuación:

• 400 - Peticiones mal hechas

• 404 - Endpoints que no existen

• 500 - Errores internos del servidor

Cross-domain library

En las apps para SharePoint es común acceder a datos de varios orígenes. Como bien sabemos, este acceso es bloqueado, ya que existen mecanismos para prevenir la comunicación con más de un dominio. Este problema nos lo soluciona la cross-domain library. Al utilizarla las apps serán capaces de acceder a datos bajo un dominio remoto y también al dominio dónde se encuentre nuestro SharePoint.

Entrando un poco más en detalle, la cross-domain library es una librería del lado del cliente. Para poder utilizarla necesitaremos cargar el script SP.RequestExecutor.js que se encuentra almacenado en SharePoint bajo la ruta /_layouts/15/…

Es una muy buena opción si quieres o necesitas que tu código se ejecute en el lado del cliente. También nos permite esquivar barreras e incluso temas como el firewall entre SharePoint y un servidor remoto.

En el siguiente enlace podréis encontrar documentación más detallada sobre la cross-domain library:



162


Ejemplos de uso de las API

Ejemplo 1 – Modelo de objetos cliente JavaScript

En este ejemplo, vamos a interactuar con social feeds desde una app mediante el modelo de objetos de cliente JavaScript. En concreto, publicaremos comentarios y respuestas.

1. Lo primero de todo es tener configurado My Site bajo el sitio que vamos a que vamos a desplegar la app.

2. Creamos un proyecto del tipo “App for SharePoint 2013” y elegimos la opción SharePoint-Hosted para alojarla en nuestro SharePoint.

3. De la página que se crea por defecto Default.aspx borraremos el bloque de código JavaScript encargado de llamar a la función sharePointReady(), puesto que para este ejemplo no haremos uso de ella. Dentro del ContentPlaceHolder “PlaceHolderMain”, borraremos el contenido e incluiremos las siguientes líneas. Estas cuatro líneas a incluir, la primera representa el mensaje que muestra el resultado de la inserción del comentario. Las dos siguientes referen-cian a los archivos necesarios para utilizar el modelo de objetos de cliente de JavaScript para el tema de social feeds. La última línea es la encargada de generar un mensaje sobre la seguridad cuando sea requerido; suele ser usado en operaciones que actualizan contenido. Por lo tanto, el “PlaceHolderMain” quedaría así.

<asp:Content ContentPlaceHolderId=”PlaceHolderMain” runat=”server”> <span id=”spanMessage” style=”color: #FF0000;”></span> <SharePoint:ScriptLink ID=”ScriptLink1” name=”SP.js” runat=”server” ondemand=”false” localizable=”false” loadafterui=”true” /> <SharePoint:ScriptLink ID=”ScriptLink2” name=”SP.UserProfiles.js” runat=”server” ondemand=”false” localizable=”false” loadafterui=”true” /> <SharePoint:FormDigest id=”FormDigest” runat=”server”/> </asp:Content>

4. El siguiente archivo a modificar será el App.js, el archivo que se crea por defecto al elegir este tipo de proyecto, en el cual iría el código JavaScript nuestro personalizado. Por lo tanto, borramos todo el contenido que tiene actualmente para introducir nuestro código.

163


5. Lo primero que haremos en el archivo App.js, será llamar a la función excuteOrDe-layUntilScriptLoaded, la cual llamará a la función PublishPost después de haber cargado el archivo SP.UserProfiles.js.

SP.SOD.executeOrDelayUntilScriptLoaded(PublishPost, ‘SP.UserProfiles.js’);

6. La función principal de nuestra demostración es PublishPost, en esta función ten-dremos diferenciados 4 bloques.

• Crearemos una instancia de la clase SocialFeedManager pasándole el contexto actual. Esta clase es la que nos permite acceder a los social feeds. Nos proporcionará métodos para crear, actualizar, borrar y leer comentarios.

clientContext = SP.ClientContext.get_current(); feedManager = new SP.Social.SocialFeedManager(clientContext);

• En el comentario que queremos introducir, vamos a añadirle un link. Para ello nece-sitamos hacer uso de la clase SP.Social.SocialDataItem y sus propiedades.

var linkDataItem = new SP.Social.SocialDataItem(); linkDataItem.set_itemType(SP.Social.SocialDataItemType.link); linkDataItem.set_text(‘link’); linkDataItem.set_uri(‘http://www.solidq.com’); var socialDataItems = [linkDataItem];

• El siguiente paso es crear el comentario, meterle texto y añadirle el link creado previamente. Para ello, hacemos uso de la clase SP.Social.SocialPostCreationData y sus propiedades.

164


var postCreationData = new SP.Social.SocialPostCreationData(); postCreationData.set_contentText(‘Este es el texto del comentario, el cual contiene un {0}.’); postCreationData.set_contentItems(socialDataItems);

• Publicamos el post, si todo va bien irá a la función PublishReply y si va mal irá PostFailed

resultThread = feedManager.createPost(null, postCreationData); clientContext.executeQueryAsync(PublishReply, PostFailed);

7. La siguiente función a comentar es la de PublishReply. Si el comentario se introdujo correctamente, se introducirá una respuesta en consecuencia. Para insertar la respuesta al comentario introducido, esta vez cogemos el id de dicho comentario introducido y le inser-tamos el comentario respuesta.

var postCreationData = new SP.Social.SocialPostCreationData(); postCreationData.set_contentText(‘Este texto es la respuesta.’); resultThread = feedManager.createPost(resultThread.get_id(), postCreationData); clientContext.executeQueryAsync(PostSucceeded, PostFailed);

8. Las últimas dos funciones que nos informan de si fue bien la operación o no. Estas funciones básicamente rellenan un span indicando el resultado de la operación.

165


function PostSucceeded(sender, args) { $get(“spanMessage”).innerText = ‘El comentario y la respuesta fueron publicados.’; } function PostFailed(sender, args) { $get(“spanMessage”).innerText = ‘La petición falló: ‘ + args.get_message(); }

9. El último paso del desarrollo es dotar a nuestra app de los permisos necesarios a la hora de interactuar con los social feeds. Para leer y escribir en los social feeds nos harán falta dos tipos de permisos a nivel de app. Para ello accedemos al AppManifest.xml y ponemos los permisos de la siguiente imagen.

Figura 3-53. Permisos para social feeds a nivel de app

166


10. Tan solo nos queda visualizar el resultado. En la siguiente imagen puedes ver el comentario con el link y la respuesta al comentario.

Figura 3-54. Resultado demostración 1: Comentario y Respuesta

Ejemplo 2 – Modelo de objetos cliente .NET

En este ejemplo, usaremos el servicio de búsqueda de SharePoint mediante el modelo de objetos de cliente .NET.

Con las novedades que ha traído consigo el modelo de objetos de cliente, ahora desde el lado del cliente, vamos a poder hacer uso también del servicio de búsquedas. Para ello, vamos a realizar una pequeña aplicación de consola que se encargue de buscar la palabra clave “SolidQ” utilizando el motor de búsquedas de SharePoint 2013. Previamente habremos subido un documento llamado “SolidQDocument” y realizado un full Crawl.

1. Creamos un proyecto tipo “Aplicación de consola”.

2. Añadimos las librerías necesarias al proyecto

Microsoft.SharePoint.Client.dll

Microsoft.SharePoint.Client.Runtime.dll

Microsoft.SharePoint.Client.Search.dll

3. Añadimos las referencias al proyecto:

using Microsoft.SharePoint.Client; using Microsoft.SharePoint.Client.Search; using Microsoft.SharePoint.Client.Search.Query;

167


4. En este paso ya nos metemos a programar. Desde la aplicación cliente necesitare-mos recuperar el contexto, para ello le pasamos la URL de nuestro sitio.

using (ClientContext clientContext = new ClientContext(“http://mydeveloper-site”))

5. Tendremos que declararnos un objeto KeywordQuery pasándole el contexto. Este objeto será el encargado de representar la consulta a realizar a SharePoint. Su parámetro QueryText será el texto a buscar.

Nota. El lenguaje de consultas SQL para búsquedas lo han quitado en esta versión, quedando solamente el KQL (Keyword Query Language) y FQL (FAST Query Language). Concretamente en este ejemplo utilizamos el KQL.

KeywordQuery keywordQuery = new KeywordQuery(clientContext); keywordQuery.QueryText = “SolidQ”;

6. A diferencia del modelo de objetos de servidor, nos hará falta declararnos otro objeto llamado SearchExecutor, encargado de mandar las consultas al motor de búsquedas. A este objeto será necesario que pasemos también el contexto.

SearchExecutor searchExecutor = new SearchExecutor(clientContext);

7. Para obtener los resultados de la búsqueda llamaremos a una función del SearchExecutor llamada ExecuteQuery pasándole el objeto KeywordQuery que habíamos

168


declarado previamente. Este método devuelve los resultados del tipo ClientResult<ResultTableCollection>.

ClientResult<ResultTableCollection> resultado = searchExecutor.ExecuteQuery(keywordQuery);

8. Este paso es muy importante, ya que podemos creer que se ha ejecutado la consulta y ya tenemos el trabajo hecho. Pues bien, hasta que no hagamos el ExecuteQuery del contexto no tendrá efecto la consulta.

clientContext.ExecuteQuery();

9. Tan solo quedaría mostrar el resultado por pantalla que tendríamos almacenado en resultado. Aquí, podemos apreciar que hemos consultado el archivo que previamente subimos desde SharePoint.

10. El código al completo

namespace SharePoint2013_3_3_2 { class Program { static void Main(string[] args) { using (ClientContext clientContext = new ClientContext(“http://mydevelopersite”)) { KeywordQuery keywordQuery = new KeywordQuery(clientContext); keywordQuery.QueryText = “SolidQ”; SearchExecutor searchExecutor = new SearchExecutor(clientContext);

169


ClientResult<ResultTableCollection> resultado = searchExecutor.ExecuteQuery(keywordQuery); clientContext.ExecuteQuery(); foreach (var resultRow in resultado.Value[0].ResultRows) { Console.WriteLine(resultRow[“Title”] + “-” + resultRow[“Path”] + “-”); } Console.ReadLine(); } } } }

Ejemplo 3 – Modelo de objetos cliente JavaScript + REST

En este ejemplo accederemos a una lista para consultar los datos mediante REST + JavaScript.

Una vez vistos todos los apartados necesarios para comprender cómo funciona la API REST, vamos a proceder a realizar una demostración. El escenario que presento trata de crear un SharePoint-hosted App, la cual crea y despliega una lista cuyos datos son consultados vía REST. Cuando digo que despliega una lista me refiero a que crea una lista, pero en lugar de ser una lista dentro de un sitio de SharePoint, crea la lista dentro del subsitio que se crea para la propia app (véase el capítulo 2 para comprender funcionamiento interno de las apps según donde están alojadas). Mencionar también, que en este ejemplo podríamos hacerlo sin pro-blemas ya que la app estará alojada en SharePoint, es decir, en el mismo servidor que nuestros datos. Si hubiéramos elegido Provider-hosted o Autohosted tendríamos que haber utilizado la cross-domain library, la cual ha sido explicada anteriormente.

Antes de empezar con el ejemplo, sería importante tener claros ciertos conceptos sobre el despliegue de la lista desde un proyecto SharePoint-hosted.

Para empezar, por el hecho de tener esta lista en la app web (subsitio creado para albergar la app), ésta no será accesible desde la interfaz, a menos que pongamos nosotros la URL ade-cuada en el navegador o desarrollemos código personalizado que nos permita modificar la lista. Otra forma de consultarla es mediante PowerShell. Hay que tener en cuenta que al desplegar la lista como parte de nuestro proyecto SharePoint-Hosted dicha lista dependerá de la app, es decir, cuando se borre la app esta lista desaparecerá. A raíz de esto surge la pregunta, de si es mejor tener la lista dentro de la app o creada en nuestro SharePoint. Pues depende mucho de nuestros intereses, si es una lista global en la cual varios recursos o aplicaciones van a tirar de ella, entonces debería estar en SharePoint. En cambio, si es una lista de ámbito local, utilizada

170


solamente por la app que me estoy instalando, como la del ejemplo, es decir, que únicamente se usa para dar servicio a la app, lógicamente debería estar embebida en dicha app.

A continuación, vemos un ejemplo del escenario previamente comentado. En el primer bloque vemos una lista que se encuentra en SharePoint y en el segundo vemos una lista que se despliega mediante una SharePoint-hosted App en la cual, al borrar el sitio que crea consigo la app, se elimina también la lista.

Figura 3-55. Alojamiento de una lista en una SharePoint App

Dicho esto comencemos con el ejemplo.

1. Empezaremos creando un proyecto SharePoint-hosted App.

2. Añadiremos la lista al proyecto la cual llamaremos “Customers” utilizando una de las tantas plantillas que tenemos, en concreto la de “Contacts”

171


Figura 3-56. Añadir lista Customers a una SharePoint app

3. El siguiente paso es meterle contenido a esta lista. Para ello nos vamos al Elements.xml y añadimos los datos necesarios dentro de a etiqueta<ListInstance>. El archivo en cuestión quedaría de la siguiente forma:

<?xml version=”1.0” encoding=”utf-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <ListInstance Title=”Customers” OnQuickLaunch=”TRUE” TemplateType=”105” FeatureId=”00bfea71-7e6d-4186-9ba8-c047ac750105” Url=”Lists/Customers” Description=”My List Instance”> <Data> <Rows> <Row> <Field Name=”FirstName”>Jose</Field> <Field Name=”Title”>Quinto</Field> <Field Name=”WorkPhone”>11111</Field> </Row> <Row> <Field Name=”FirstName”>Guillermo</Field>

172


<Field Name=”Title”>Bas</Field> <Field Name=”WorkPhone”>22222</Field> </Row> <Row> <Field Name=”FirstName”>Cristian</Field> <Field Name=”Title”>Zaragoza</Field> <Field Name=”WorkPhone”>33333</Field> </Row> <Row> <Field Name=”FirstName”>Roberto</Field> <Field Name=”Title”>Ramon</Field> <Field Name=”WorkPhone”>44444</Field> </Row> </Rows> </Data> </ListInstance> </Elements>

4. Una vez construida la lista a consultar, necesitamos añadir el código necesario para consultarla mediante REST y obtener todos sus datos. Para ello, utilizaremos el archivo App.js, que es el archivo que viene por defecto bajo la carpeta Scripts/App.js y se utiliza para meter código JavaScript personalizado. En este archivo vienen introducidas unas funciones las cuales se ejecutan por defecto y de las que podemos borrar todas menos una, sha-rePointReady(); si borramos ésta nos dará un error JavaScript. Esta función actúa como .ready() de jQuery, es decir, cada vez que se recarga la página esta función se lanza.

A continuación, vamos a realizar un estudio sobre este archivo que es el más importante, empezando -como no- por la función sharePointReady(). En concreto, consultaremos la lista desplegada, seleccionaremos los campos FirstName,Title,WorkPhone y terminaremos orde-nando con FirstName,Title. La variable _spPageContextInfo.webAbsoluteUrl nos proporciona el contexto en el cual se encuentra nuestra app, necesario para hacer la llamada REST. Una vez formada la cadena, llamamos a la función getJSON pasándole la dirección y la función a la que accede. Si todo ha ido bien, entra en la función onSuccess mandándole por parámetro los datos devueltos en formato JSON; si no ha ido bien, pasa de línea y entra en la función onFail.

function sharePointReady() { var requestUri = _spPageContextInfo.webAbsoluteUrl + “/_api/Web/Lists/getByTitle(‘Customers’)/items/” + “?$select=FirstName,Title,WorkPhone” + “&$orderby=FirstName,Title”;

173


jqhxr = $.getJSON(requestUri, null, onSuccess); jqhxr.error(onFail); }

5. La siguiente función a comentar es onSuccess. Ésta recibe por parámetro los datos devueltos por la llamada REST. Mediante jQuery creamos una plantilla, a los datos le asigna-remos esa plantilla y, por último, lo meteremos todo bajo un <ul> de HTML con id=results que tendríamos ya previamente definido.

function onSuccess(data) { var odataResults = data.d.results; var markup = “<li><b>${FirstName}</b> <b>${Title}</b> <b>${WorkPhone}</b></li>”; $.template(“dataCustomers”, markup); $.tmpl(“dataCustomers”, odataResults).appendTo(“#results”); }

6. La última función del archivo a comentar será onFail(). A ésta llegaremos si la peti-ción vía REST ha fallado. Lo único que hará esta función será mostrar el error producido.

function onFail(errorObject, errorMessage) { $(“#results”).text(“Error: “ + errorMessage); }

7. Utilizaremos la página que viene por defecto en SharePoint, default.aspx. En esta página necesitaremos incluir la cabecera necesaria para aplicar plantillas de jQuery.

<script src=”http://ajax.microsoft.com/ajax/jquery.templates/beta1/ jquery.tmpl.min.js”></script>

174


8. El siguiente cambio a realizar en el archivo default.aspx será en el “PlaceHolderMain” en el que habrá que incluir el <ul> con id=results en el cual metíamos los datos, quedando así:

<asp:Content ContentPlaceHolderId=”PlaceHolderMain” runat=”server”> <ul id=”results”></ul> </asp:Content>

9. El aspecto final del proyecto quedaría así:

Figura 3-57. Estructura del pro-yecto de una SharePoint app

175


10. El resultado del ejercicio sería el siguiente:

Figura 3-58. Resultado API REST + JavaScript

176


¿Qué modelo de objetos usar en cada caso?

En este último apartado, vamos a representar en una tabla, algunos de los escenarios más interesantes que podemos encontrar respecto a SharePoint 2013 y vamos ha indicar el modelo de objetos más apropiado para cada caso.

Nº ESCENARIO MODELO DE OBJETOS1 Desarrollo de WebPart personalizado Modelo de objetos de servidor2 Desarrollo de aplicación de páginas personalizada Modelo de objetos de servidor3 Desarrollo de un control de usuario Modelo de objetos de servidor4 Desarrollo de un Workflow personalizado Modelo de objetos de servidor5 Desarrollo de un Timer Job personalizado Modelo de objetos de servidor6 Desarrollo de manejadores de eventos

personalizados(Events Receivers)Modelo de objetos de servidor

7 Desarrollo de una Windows Phone app para implemen-tar operaciones CRUD en SharePoint

Modelo de objetos de cliente en móvil

8 Desarrollo de una Windows Phone app para imple-mentar notificaciones en el móvil producidas por eventos de SharePoint

Modelo de objetos de cliente en móvil

9 Desarrollo de una aplicación LAMP(Linux-Apache-MySql-PHP) que realice operaciones CRUD en SharePoint

REST/OData endpoints

10 Desarrollo de una aplicación iOS o Android que per-mita realizar operaciones CRUD sobre SharePoint

REST/OData endpoints

11 Desarrollo de una aplicación ASP.NET que permita realizar operaciones CRUD sobre SharePoint fuera del firewall

Modelo de objetos de cliente Ja-vaScript

12 Desarrollo de una aplicación HTML/JavaScript que per-mita realizar operaciones CRUD sobre SharePoint

Modelo de objetos de cliente Ja-vaScript

13 Desarrollo de una aplicación ASP.NET que permita realizar operaciones CRUD dentro del firewall

Cliente .NET Framework, cliente Silverlight, REST/OData endpoints

14 Desarrollo de una aplicación .NET en cliente que permita realizar operaciones sobre SharePoint

Cliente .NET Framework


P177

Conclusiones

Hemos empezado este capítulo profundizando sobre el desarrollo de las SharePoint apps. Hemos visto que uno de los puntos más importantes en cuanto a lo que se pretende conseguir con las apps es que “vivan” de manera aislada al entorno donde está instalado SharePoint. De esta manera, se consigue que las apps no “roben” recursos a SharePoint, y por tanto, evitar problemas de rendimiento. Al mismo tiempo, con esto mismo se consigue dar libertad a los desarrolladores en cuanto a qué lenguaje utilizar para desarrollar apps. No estamos sujetos a usar tecnologías de Microsoft, si no que es posible utilizar desde PHP a HTML básico.

Por otro lado, se ha visto que con las apps uno de los peligros que corremos es dar la sensación al usuario de que le estamos sacando fuera del contexto de SharePoint, y esto es precisamente lo que debemos evitar a toda costa. Para ello SharePoint 2013 cuenta con una serie de mecanismos que permiten maquetar y diseñar apps con el fin de que éstas se adapten al entorno donde se muestran, heredando los estilos de la página o sitio en cuestión.

Hemos hecho un intensivo recorrido sobre el conjunto de las API disponibles que tiene para utilizar el desarrollador. Una vez vistas las distintas API, hemos centrado nuestra atención principalmente en aquellas que están en el lado del cliente, básicamente porque en este libro estamos tratando todo lo relacionado con las apps y desde éstas, recuerda que no está permi-tido utilizar código de servidor.

También hemos hecho mucho hincapié en las novedades que trae consigo la API REST, a la que se le amplía mucho su funcionalidad en la nueva versión del producto. Con esta API REST y su extendida funcionalidad, seremos capaces que acceder a SharePoint desde cualquier dispositivo que soporte REST. Por lo tanto, acabamos con esta limitación que tantos dolores de cabeza había producido. Para trabajar con REST y no tener problemas del cross domain (que tengamos nuestra aplicación y nuestro SharePoint en servidores distintos), en este capítulo se explica el uso de la cross-domain library la cual nos permitirá resolver esta problemática. Por lo tanto, es fundamental conocerla y aplicarla, ya que casi siempre necesitaremos hacer uso de ella. Desde esta API también es posible hacer uso de los servicios disponibles en SharePoint, como puede ser por ejemplo el servicio de búsqueda. Por lo tanto, podemos concluir que la API REST es una candidata muy firme para ser utilizada siempre que se pueda en nuestros desarrollos, ya que una vez aprendamos a manejarnos con ella, seremos capaces de desarrollar en distintos dispositivos con la misma base de lo que ya sabemos.

Por último, una vez visto todo esto, es importante saber qué modelo de objetos utilizar en cada escenario. Para ello, incluimos una tabla en la que el desarrollador puede orientarse sobre qué API elegir, ya que la elección de la misma es el paso más importante.

Capítulo 4: Instalación y administración de SharePoint Apps

P178

Hasta este punto de este libro nos hemos sumergido en el universo de las SharePoint apps desde su concepción hasta su desarrollo pasando por un amplio abanico de posibilidades en lo que se refiere a la implementación de las mismas. Sin embargo, nos queda uno de los apar-tados más importantes, la gestión de las apps en nuestra granja, desde su instalación hasta la gestión de permisos y autorización de las mismas en nuestros servidores. Esto es lo que vamos estudiar en este capítulo; empezaremos por el acceso al Office Store y la instalación de aplica-ciones expuestas públicamente.

Instalando aplicaciones desde el Office Store

Para revisar el proceso de instalación de aplicaciones para SharePoint desde el Office Store, vamos a utilizar una cuenta de Office 365 Preview en su versión Enterprise. En este punto, cabe recordar que la plataforma de SharePoint apps está diseñada para que estas funcionen exacta-mente igual tanto en SharePoint Online como en la versión de servidor local. Para este proceso estoy utilizando un usuario que tiene el rol de administrador global de la cuenta de Office 365, cuyos permisos equivalentes en una granja local serían los de administrador de la granja.

Desde nuestro sitio principal de SharePoint Online podemos hacer clic sobre los tres puntos de la barra de opciones superior y acceder desde ahí al Office Store público ver Figura 4-1. Barra superior de opciones.

179


Figura 4-1. Barra superior de opciones

Es posible que encontremos un mensaje similar a este “Lo sentimos, pero no hay ninguna aplicación de Office o SharePoint disponible para su país o región en este momento. Visite el sitio de EE.UU. para ver las últimas aplicaciones.”. Dado que estamos aún en una fase temprana de publicación de SharePoint apps, aceptaremos la invitación de visitar el Office Store de los Estados Unidos para nuestro ejemplo.

Una vez situados sobre el Office Store de Estados Unidos podemos acceder a las aplica-ciones de SharePoint filtrando desde el menú principal donde pone “Apps for SharePoint” (ver Figura 4-2. Filtros en el Office Store).

Figura 4-2. Filtros en el Office Store

Allí seleccionamos la aplicación que deseamos instalar para ver su página de descripción completa. En este caso, vamos a hacerlo sobre la aplicación de integración con Facebook de Microsoft (Facebook Integration).

180


Una vez lleguemos a la página de descripción de la aplicación veremos algo parecido a la Figura 4-3. Página de detalle de la aplicación Facebook Integration.

Figura 4-3. Página de detalle de la aplica-ción Facebook Integration

En la Figura 4-3 podemos observar cómo se nos presenta la descripción de la aplicación, una imagen descriptiva de su funcionamiento y lo más importante el botón verde “Add” (Añadir), que nos permitirá ver lo que tenemos que hacer para añadir dicha aplicación a nuestro sitio. Así pues hacemos clic en dicho botón y llegamos a una página de instrucciones en la que se nos invita a copiar un código a través del cual podremos encontrar y añadir la aplicación direc-tamente en el sitio que deseemos (ver Figura 4-4. Instrucciones para obtener la aplicación).

181


Figura 4-4. Instrucciones para obtener la aplicación

182


Siguiendo las instrucciones, copiamos dicho código y volvemos a nuestro sitio (aquel en el que deseemos instalar la aplicación), y accedemos al menú de agregar aplicaciones a través del menú de configuración que hay arriba a la derecha en la barra superior de opciones de nuestro sitio (ver Figura 4-5. Acceso al menú de agregar aplicaciones).

Figura 4-5. Acceso al menú de agregar aplicaciones

Una vez estamos en el sitio donde aparecen todas nuestra aplicaciones disponibles pode-mos buscar la aplicación de Facebook Integration a través del código proporcionado anterior-mente por el Office Store, poniendo este código en el buscador no encontrará resultados locales para aplicaciones instaladas pero sí nos avisará de que hay un resultado coincidente en el Office Store (ver Figura 4-6. Búsqueda de aplicaciones por código.

Figura 4-6. Búsqueda de aplicaciones por código

183


Así pues, hacemos clic en el link “Almacén de SharePoint” que nos llevará de nuevo al Office Store, pero esta vez con un formato diferente asociado de alguna forma a nuestro sitio. Aquí de nuevo tendremos que seleccionar la región como Estados Unidos para poder acceder a la aplicación. Finalmente, haremos clic sobre el icono de la aplicación (ver Figura 4-7. Almacén de SharePoint) para acceder de nuevo a su página de detalles.

Figura 4-7. Almacén de SharePoint

Esta vez, antes de hacer clic sobre el botón “Agregar” observamos que debajo del mismo tenemos detallados los permisos que necesita la aplicación (y que debemos aceptar para ins-talarla) (ver Figura 4-8. Permisos de aplicación).

Figura 4-8. Permisos de aplicación

184


Una vez revisados los permisos, cerramos la ventana emergente y pulsamos sobre el botón “Agregar”. En este punto es posible que nos solicite volver a autenticarnos con una cuenta Microsoft y no con la cuenta de la organización16.

Una vez hecho esto, nos mostrará un mensaje en el que nos confirma que hemos obte-nido esta aplicación para todas las personas de nuestra organización y además nos muestra la posibilidad, mediante una casilla de verificación, de agregarla directamente al sitio en el que estábamos; en este caso, como era un sitio público vacío nos muestra el título “Título de página web” que es el texto por defecto que lleva este tipo de plantilla en el nombre del sitio (ver Figura 4-9. Pantalla de obtención de aplicación).

Figura 4-9. Pantalla de obtención de aplicación

16 EstosignificaquetenemosqueautenticarnosconlacuentadecorreoatravésdelacualcreamosestasubscripcióndeOffice365yquenecesariamenteestáasociadaaMicrosoft(loqueanteseraconocidocomoLiveID).

185


Una vez pulsamos el botón volver al sitio, nos pide confirmación de los permisos otorga-dos a la aplicación y nos permite leer los términos y condiciones (ver Figura 4-10. Confirmación de confianza en la aplicación). Pulsamos en “Confiar” y continuamos hasta nuestro sitio.

Figura 4-10. Confirmación de confianza en la aplicación

Una vez hayamos vuelto a nuestro sitio ya veremos la aplicación agregada en el mismo, junto con el resto de aplicaciones existentes (ver Figura 4-11. Aplicaciones disponibles en un sitio).

Figura 4-11. Aplicaciones disponibles en un sitio

186


Ahora ya podemos hacer uso de la aplicación haciendo clic en ella. En este punto, no vamos a seguir profundizando en el funcionamiento de la aplicación Facebook Integration ya que a partir del momento en que hacemos clic en la aplicación ya agregada a nuestro sitio, la expe-riencia dependerá del desarrollador de la misma, qué opciones haya agregado, qué interfaz de usuario, etc… Pero no por eso hemos terminado con la administración de nuestra aplicación.

Administración de aplicaciones instaladas

Vamos a continuar administrando nuestras aplicaciones instaladas y viendo qué opciones tenemos disponibles para su gestión una vez las hemos adquirido y agregado a nuestros sitios.

Continuando con el ejemplo anterior, en el que instalamos la aplicación Facebook Integration en un sitio público, vamos a ver qué información y opciones de administración nos ofrece el sistema respecto a esta aplicación. Al situarnos encima de la aplicación, arriba a la derecha, observamos que aparecen tres puntos que nos indican que hay opciones ocultas, al hacer clic en los mismos se muestra un pequeño globo con información y opciones sobre la aplicación y de nuevo otros tres puntos a la derecha a través de los cuales podemos acceder a otras tres opciones adicionales (ver Figura 4-12. Menú contextual de aplicación).

Figura 4-12. Menú contextual de aplicación

Aquí las opciones más interesantes son precisamente las últimas tres:

- Detalles. Esta opción nos lleva a una página de detalles sobre la aplicación, con infor-mación muy relevante sobre su utilización: estadística de errores, quién instaló la aplicación, estadística de uso y otras opciones muy interesantes de monitorización.

187


- Permisos. Aquí podemos volver a “confiar” en la aplicación reconociendo de nuevo los permisos que necesita la misma, bien sea porque se los hemos denegado en algún momento o por cualquier otra razón.

- Quitar. Como bien indica el nombre de esta opción, nos servirá para quitar la aplicación de este sitio, con lo que dejará de estar disponible. Si queremos volver a utilizarla en el futuro, tendremos que volver a agregarla desde el menú “Agregar una aplicación”.

Por último, podemos administrar los permisos de cada aplicación instalada tanto a nivel de sitio como de colección de sitios. Para administrar los permisos de aplicación a este nivel tenemos que acceder a la configuración del sitio desde el menú de configuración de la barra superior de opciones (ver Figura 4-13. Acceso a configuración del sitio).Desde la configura-ción del sitio podemos restringir el uso de cualquier aplicación instalada tanto a nivel de sitio “Permisos de aplicaciones del sitio” como a nivel de colección de sitios “Permisos de aplicación de colección de sitios” (ver Figura 4-14. Opciones de configuración de permisos).

Figura 4-13. Acceso a configu-ración del sitio

Figura 4-14. Opciones de configuración de permisos

188


La interfaz para eliminar los permisos de una aplicación es muy sencilla e idéntica en ambos casos, tan solo aparecerá un listado de aplicaciones instaladas y una cruz a la izquierda para eliminar los permisos de dicha aplicación (ver Figura 4-15. Gestión de permisos de la aplicación).

Figura 4-15. Gestión de permisos de la aplicación

El catálogo de aplicaciones (App Catalog)

En este capítulo solo hemos revisado en profundidad el proceso de instalación para SharePoint Online en la plataforma Office 365 Preview. Para entornos de servidor local en nues-tra propia red corporativa, además de utilizar este sistema para instalar aplicaciones externas, existe un catálogo local de aplicaciones, lo que vendría a ser un Office Store local controlado por nosotros. Las opciones de configuración del mismo las podemos encontrar en la adminis-tración central17 de SharePoint 2013. En la Figura 4-16 podemos observar como dentro de la Administración Central existe un área nueva dedicada a las SharePoint apps. Justamente desde esta área podremos crear la colección de sitios de tipo Catalog App Host que nos permitirá utilizar nuestro SharePoint como catálogo de apps (ver Figura 4-17. Creación y configuración del Catálogo de apps dentro de SharePoint 2013.).

Figura 4-16. Sección dedi-cada a las SharePoint apps dentro de la Administración Central de SharePoint 2013.

17 Más información sobre la configuración del App Catalog aquí http://msdn.microsoft.com/en-us/library/fp123530(v=office.15).aspx (En inglés)



189


Figura 4-17. Creación y configuración del Catálogo de apps dentro de SharePoint 2013.

Este catálogo de aplicaciones nos permite instalar aplicaciones creadas por terceros sin pasar por el Office Store, de forma que siguiendo las mismas reglas de seguridad y aislamiento podamos proveer o contratar dependiendo de la situación aplicaciones personalizadas, reali-zadas por terceros.

190


Conclusiones

Hemos seguido el ciclo de instalación y administración completo de una aplicación obte-nida desde el Office Store para un entorno de SharePoint Online sobre Office 365 Enterprise Preview.

El proceso de instalación queda todavía relativamente complejo dada la necesidad de navegar el Office Store para obtener el código único de la aplicación que deseamos instalar antes de poder encontrarla con facilidad desde nuestro entorno. Suponemos que en próxi-mas actualizaciones, quizás la RTM del producto, este proceso será más intuitivo y sencillo. En cambio, no podemos decir lo mismo del proceso de gestión de permisos y desinstalación de aplicaciones, ya que se ha demostrado que es un proceso realmente sencillo y que nos pro-porciona la información necesaria para saber qué uso se está haciendo de cada aplicación en nuestros sitios con las métricas de uso del detalle de las aplicaciones.

Con todo esto, podemos concluir que la administración del nuevo modelo aplicaciones se muestra sólido para ser su primera versión y más que suficiente para las necesidades de moni-torización que acostumbran a utilizarse en la mayoría de entornos de TI empresariales.

Capítulo 5: Novedades influenciadas por las SharePoint Apps

P191

El nuevo modelo de desarrollo que concierne a las SharePoint Apps, ha propiciado una serie de novedades necesarias que vienen a complementar dicho modelo. En este capítulo tra-taremos temas muy interesantes como “Napa” (el entorno de desarrollo de SharePoint y Office Apps en la Nube), los nuevos eventos remotos que pueden complementar la funcionalidad de las apps y un último apartado referido a los flujos de trabajo donde veremos que toda la infraestructura ya no es guardada bajo SharePoint.

Plataforma de desarrollo en la Nube – Introducción a Mi-crosoft Napa

Una de las grandes bazas de la nueva versión de SharePoint, y en especial su nuevo modelo de desarrollo de aplicaciones, es que no haya diferencias entre lo que se puede hacer en la Nube y en nuestros propios servidores locales. En este contexto de empeño por parte de Microsoft de equiparar los servicios en la Nube a los servicios locales, nace una plataforma de desarrollo de SharePoint y Office apps cuyo nombre en clave es Napa. Este nombre, para aquellos que no somos naturales de Estados Unidos, nos suena más bien pintoresco (a los autores de este libro personalmente nos recuerda a un personaje del mismo nombre en la serie de dibujos Dragon Ball), pero en realidad no tiene mucho misterio, es el nombre de una región llamada Valle de Napa (Napa Valley) situada en el estado de California, en los Estados Unidos, que es famoso por sus viñedos y la producción de vino (ver Figura 5-1. Foto tomada por Brocken Inaglory (extraída de Wikipedia.org)).

192


Figura 5-1. Foto tomada por Brocken Inaglory (extraída de Wikipedia.org)

Pero más allá de nombres curiosos y paisajes idílicos, Napa es una plataforma de desarro-llo que hace posible el desarrollo de aplicaciones para SharePoint y Office desde la Nube, sí, lo mismo que Visual Studio, pero directamente desde nuestro navegador sin necesidad de insta-lar absolutamente nada en nuestra máquina local.

Por supuesto, Napa, en su versión actual, marcada en el Office Store como beta, no nos ofrece todas las posibilidades que podemos encontrar en herramientas de escritorio como Visual Studio. Por eso, a continuación vamos a detallar qué tipos de aplicación nos permitirá desarrollar Napa y en qué condiciones.

- Aplicaciones para SharePoint. Solo podremos desarrollar aplicaciones para SharePoint del tipo SharePoint-hosted, ni las Provider-hosted ni las Autohosted estarán soportadas.

- Aplicaciones para Word. Solo podremos crear aplicaciones de tipo Panel de tareas lateral (Task Pane). En este caso se requiere Office 2013 para desplegar la aplicación.

- Aplicaciones para Excel. Podremos crear dos tipos de aplicaciones para Excel, por una parte los mismos Paneles de tareas laterales (Task Pane) de Word nos servirán para Excel, y por otra parte también podremos desarrollar aplicaciones de contenido para Excel (Content Apps) que son aquellas que se despliegan directamente sobre el contenido de una hoja de cálculo de

193


Excel. En este segundo caso, sí funcionarían sobre la Excel Web App directamente sin necesi-dad de tener Excel 2013 instalado en el escritorio.

- Aplicaciones para Outlook. Podremos crear las también llamadas Mail Apps sin problemas.

Dado el contexto del libro en este capítulo solo desarrollaremos una pequeña aplicación para SharePoint haciendo uso de Napa.

Navegadores soportados

El lema principal de Napa es que puedas desarrollar tus aplicaciones desde cualquier parte y en cualquier momento, con este objetivo Napa está soportado para los tres navegadores más utilizados en sus versiones más recientes, Internet Explorer 9 o superior, Firefox 15 o superior y Google Chrome 21 o superior. Además, como no se utiliza ningún tipo de plugin externo al propio navegador, también es compatible con la versión táctil de Internet Explorer 10 (accesi-ble desde la parte Metro de Windows 8) (ver Figura 5-2. Napa funcionando sobre IE10 versión metro)

Figura 5-2. Napa funcionando sobre IE10 versión metro

Con esto podemos dar por sentado que funcionará también en tabletas con Windows 8 RT, lo que resulta bastante impresionante.

Lamentablemente, no todo son buenas noticias en este sentido ya que en esta fase de desa-rrollo, Napa no es compatible con ninguna versión de Safari, ni Windows ni Mac ni iOS, es decir,

194


no es posible ejecutarlo desde dispositivos iPad, por ejemplo. Si lo intentamos, obtendremos un mensaje diciendo que el navegador que estamos utilizando no está soportado.

Instalando y ejecutando NAPA por primera vez

Para utilizar Napa necesitamos obtenerlo e instalarlo en forma de aplicación para SharePoint desde el Office Store. Para la instalación de la aplicación seguiremos los siguientes pasos.

En primer lugar, para poder instalar Napa vamos a necesitar una colección de sitios creada a partir de la plantilla “Sitio de desarrollador” (ver Figura 5-3. Selección de plantilla).

Figura 5-3. Selección de plantilla

Una vez creado nuestro sitio de desarrollador, desde la página principal tenemos un enlace directo a la aplicación de Napa para instalarla (ver Figura 5-4. Acceso directo a la creación de aplicaciones).

Figura 5-4. Acceso directo a la creación de aplicaciones

Una vez agregada la aplicación, solo tenemos que hacer clic sobre el icono de la misma para acceder a ella y comenzar un nuevo proyecto de aplicación para SharePoint. En la primera pantalla de la aplicación, ésta nos ofrece comenzar un tipo de aplicación (de los mencionados

195


anteriormente en este mismo capítulo) y ponerle un nombre al proyecto (ver Figura 5-5. Tipos de aplicación posibles con Napa). En nuestro caso, vamos a crear la aplicación ejemplo SharePoint_5_1_1.

Figura 5-5. Tipos de aplicación posibles con Napa

Una vez le hemos dado nombre a nuestro proyecto y pulsamos en el botón “Crear” (“Create”), la aplicación nos trasladará directamente al entorno integrado de desarrollo en el navegador. Este entorno consta de cuatro partes bien diferenciadas.

196


En la ver Figura 5-6 se presentan todos los componentes de la interfaz principal de Napa etiquetados para referencia del lector.

Figura 5-6. La interfaz de Napa etiquetada parte por parte

Por un lado, está la zona de edición del código fuente, en la que podemos escribir nuestro código y editar los distintos ficheros que componen la aplicación que estamos desarrollando; esta zona queda situada en la zona central de la pantalla a la derecha del navegador de conte-nidos del proyecto. En esta parte, además, disponemos de un Intellisense avanzado, similar al de Visual Studio (ver Figura 5-7. Intellisense en Napa).

Figura 5-7. Intellisense en Napa

El navegador de contenidos queda situado en la columna derecha agrupando los tipos de fichero por tipos: Contenido (Content), Imágenes (Images), Páginas (Pages) y Código (Scripts). Además de mostrar los ficheros que componen nuestra aplicación, nos permite su administra-

197


ción a través de un menú contextual a nivel de grupo (crear o subir nuevos ficheros) y a nivel particular de fichero (renombrar o eliminar el fichero) (ver Figura 5-8. Menu contextual para objetos).

Figura 5-8. Menu contextual para objetos

Una de las partes más importantes es la barra inferior de opciones. En ella podemos encontrar las herramientas para ejecutar, borrar, configurar y compartir nuestra aplicación y nuestro código. Además, existe una opción muy interesante para abrir nuestro código en Visual Studio y no quedar permanentemente limitados a esta interfaz de desarrollo, pudiendo empezar una aplicación en Napa y llegado a un punto de complejidad en el que necesitemos una herramienta más completa podamos pasar a Visual Studio para continuar con el desarrollo.

Vale la pena detenernos a comentar el menú de “Propiedades” (“Properties”) de la barra inferior. Mediante este botón se accede a una ventana de propiedades en la que podemos configurar desde las propiedades más importantes del manifest de nuestra aplicación hasta los endpoints y permisos que necesitará la misma para llevar a cabo su funcionalidad (ver Figura 5-9. Menú de propiedades).

198


Figura 5-9. Menú de propiedades

Otra de las opciones interesantes que cabe destacar de la barra inferior de opciones es el botón para continuar nuestro desarrollo en Visual Studio. Cuando hacemos clic por primera vez en este botón nos muestra una advertencia de que se lanzará el Web Platform Installer. Para asegurarnos de que los componentes necesarios para el desarrollo de aplicaciones están insta-lados, obviamente, necesitamos tener previamente instalado nuestro propio Visual Studio 2012. En la ver Figura 5-10 se puede ver cómo es la apariencia del instalador.

199


Figura 5-10. Proceso de instalación de Web Platform Installer

Una vez abierto el proyecto en Visual Studio 2012, tendremos toda la estructura del mismo disponible y cuando intentemos modificar cualquier cosa del proyecto el propio Visual Studio nos pedirá las credenciales de Office 365 Preview necesarias para mantener el código conectado a la Nube, de forma que se mantenga sincronizado con lo que tenemos en Napa.

Por último, tenemos la barra superior en la que podemos encontrar, por una parte la miga de pan contextual, que nos muestra el nombre del proyecto en el que estamos y nos permite volver al menú principal de Napa, y por otra parte, a la derecha encontramos un menú de opciones que nos da acceso a un perfil de configuración que nos permite configurar el tipo de proyecto en caso de abrirlo en Visual Studio (Visual Basic o C#) y la dirección de correo electrónico que utilizaremos para las pruebas con aplicaciones para Outlook. En nuestro perfil, también encontraremos un botón para eliminar toda la información de los proyectos y dejar de utilizar la aplicación completamente en este entorno, de forma que borremos todo rastro de su uso (ver Figura 5-11. Pantalla de perfil de desarrollo).

200


Figura 5-11. Pantalla de perfil de desarrollo

Una vez tenemos claro todo el entorno de desarrollo de Napa ya estamos listos para eje-cutar nuestra primera aplicación desde la Nube. Por quedar fuera del objeto de este capítulo no desarrollaremos una aplicación nueva para probar la funcionalidad de Napa, utilizaremos el código base que viene incluido de serie en la plantilla de aplicación para SharePoint del mismo entorno, que muestra el nombre del usuario actual por pantalla al ejecutar la aplicación. Así pues, pulsamos sobre el botón “Ejecutar” (“Run Project”) de la barra de opciones inferior y aparecerá una ventana de carga que nos muestra el proceso de subida, compilación y desplie-gue de la aplicación para terminar ofreciéndonos acceder a nuestra aplicación en una nueva ventana.

Una vez salgamos de la ejecución de la aplicación y volvamos a nuestro sitio de desarrollador, en este sitio nos aparecerá un listado con las aplicaciones que hemos creado bajo el subtítulo “Aplicaciones en fase de prueba” (ver Figura 5-12. Aplicaciones disponibles).

201


Figura 5-12. Aplicaciones disponibles

Desde este listado podemos ejecutar las aplicaciones que hemos ejecutado anteriormente desde Napa, haciendo muy sencillo el acceso a estas aplicaciones para las pruebas con usu-arios en este entorno de desarrollo.

La próxima vez que queramos continuar nuestro desarrollo desde Napa debemos entrar de nuevo en nuestro sitio de desarrollador y desde el mismo menú que instalamos Napa (el de “Crear una aplicación” en la página principal de nuestro sitio) ahora accederemos directamente a Napa viendo las aplicaciones que tenemos guardadas de veces anteriores y pudiendo tam-bién comenzar nuevos desarrollos (ver Figura 5-13. Aplicaciones creadas anteriormente).

Figura 5-13. Aplicaciones creadas anteriormente

202


Conclusiones

La plataforma de desarrollo en la Nube para Office 365 Preview, Napa, ha sido posible-mente una de las más gratas sorpresas que nos ha deparado a los desarrolladores la nueva plataforma de desarrollo de aplicaciones para SharePoint y Office. Con Napa Microsoft llega un paso más lejos en la batalla por llevar todo y a todos a la Nube iniciando un camino que posi-blemente acabe en un Visual Studio para la Nube mucho más completo en futuras versiones.

Obviamente, en su versión actual, Napa no remplaza por completo, en ningún caso a Visual Studio 2012, pero sí lo complementa, tal y como hacen las Office Web Apps con el Office de escritorio, flexibilizando la edición y ejecución de nuestro código desde prácticamente cual-quier parte en la que tengamos acceso a Internet y a un navegador soportado. Con todo esto podemos concluir que Napa es el germen de algo mucho más grande, además de enriquecer la actual plataforma de desarrollo de que disponemos los desarrolladores que hacemos apli-caciones para SharePoint y Office.

Eventos en SharePoint 2013

En este capítulo vamos a tratar todo lo relacionado con eventos que trae consigo la nueva versión de SharePoint.

Novedades en Event Receivers

Para comenzar, vamos a definir qué es un Event Receiver. Por Event Receiver entendemos pequeños trozos de código que se ejecutan como reacción a ciertos factores desencadenan-tes que se producen en SharePoint, como puede ser añadir un nuevo ítem, actualizar un ítem, borrar un ítem, etc… A la hora de encontrar una similitud, podríamos compararlos con los eventos que se producen en C# (Click, ItemDataBound, etc…). Resumiendo, el resultado es que un usuario realiza una acción que hace que se ejecute cierto bloque de código. Este tipo de eventos, en SharePoint se bautizan como Event Receivers. Existe ya una extensa lista de eventos para la cual los Events Receivers pueden saltar. En SharePoint 2013 esta lista crece para incluir nuevos eventos relacionados con grupos, permisos y administración de roles.

Antes de nada comentar la diferencia que existe en los eventos terminados con sufijo “-ing” y “-ed”. Los eventos que terminan con el sufijo “-ing” son conocidos también como Before Events y son los de tipo síncrono. Por Before Events entendemos eventos que se lanzan antes de que los datos sean escritos en base de datos. En este tipo de eventos, la operación todavía no ha sido completada, por lo tanto, nos permitirían cancelar el evento. En cambio, los eventos

203


que terminan con el sufijo “-ed” son conocidos como After Events y son de tipo asíncrono. Por After Events entendemos eventos que se lanzan a la respuesta de una acción del usuario y no son guardadas en base de datos hasta que esta acción ha terminado. En este tipo de eventos no se puede cancelar la operación la cual provocó el evento. A continuación, vamos a ver una lista en la que aparecen todos los eventos disponibles en SharePoint 2013.

NUEVOS EVENTOS EN SHAREPOINT 2013

Before Events (antes de la acción) After Events (después de la acción)GroupAdding GroupAddedGroupUpdating GroupUpdatedGroupDeleting GroupDeletedGroupUserAdding GroupUserAddedGroupUserDeleting GroupUserDeletedRoleDefinitionAdding RoleDefinitionAddedRoleDefinitionUpdating RoleDefinitionUpdatedRoleDefinitionDeleting RoleDefinitionDeletedRoleAssignmentAdding RoleAssignmentAddedRoleAssignmentDeleting RoleAssignmentDeletedInheritanceBreaking InheritanceBrokenInheritanceRestoring InheritanceRestored

ItemVersionDeleted

Además de estos nuevos eventos, vamos a poder utilizar Events Receivers Remotos para las apps de SharePoint y otro tipo de evento que quizás es más peculiar, al que llamaremos App Event Receiver, también para las apps de SharePoint. Como podéis ver, los dos nuevos tipos de eventos están aplicados a las apps.

De estos dos nuevos tipos de eventos, los Events Receivers Remotos son los más parecidos a los eventos tradicionales, ya que son eventos que ocurren sobre un objeto de SharePoint, como puede ser una lista, un ítem de la lista, un campo de una lista, un sitio, etc. La mayor diferencia de los Events Receivers Remotos frente a los tradicionales, es que este nuevo tipo de eventos pueden trabajar con componentes remotos de las apps de SharePoint 2013, es decir, pueden reaccionar ante los eventos que se producen, por ejemplo, en una lista que está alojada en la propia app de SharePoint. Otra de las ventajas que nos ofrece es poder ejecutar eventos sobre Listas externas (BCS). Por ejemplo, imaginemos que tenemos una fuente de datos externa, sobre la que nos declaramos una Lista externa, mediante los Events Receivers tradicionales no podríamos capturar los eventos que se produjeran sobre esta lista, ya que en SharePoint 2010 no está soportado. En cambio, en SharePoint 2013, mediante los Events Receivers Remotos ya seremos capaces de capturar esos eventos. Es importante no confundir los términos de componentes SharePoint (listas, workflows, páginas, etc…) con componentes remotos (fuentes de datos externas, lista en una SharePoint-hosted App, etc…). En el siguiente

204


gráfico podemos apreciar la app1 trabajando con componentes remotos y la app2 trabajando con componentes SharePoint.

Figura 5-14. Diferenciación entre componentes SharePoint y com-ponentes remotos

A continuación, vamos a entrar más en detalle en cada uno de los nuevos tipos de eventos, permitiendo así al usuario ser capaz de crearlos y manejarlos.

Events Receivers Remotos

Éste es el nuevo tipo de evento más parecido a lo que ya conocíamos. Los Events Receivers Remotos pueden ser síncronos o asíncronos y serán implementados mediante un servicio web. Es decir, el código que se ejecutará cuando se produzca el evento será servido por un servicio web. Que sea un servicio web, nos aporta mucha versatilidad ya que podríamos tenerlo des-plegado en un servidor y consumirlo entre distintas aplicaciones. Cuando añadamos un Event Receiver Remoto, se añade en el proyecto web un servicio WCF que implemente el código personalizado de nuestro Event Receiver Remoto. Las dos funciones que aparecerán a rellenar en el servicio serán:

Al añadir un Event Receiver Remoto, nuestro proyecto SharePoint también ser verá afec-tado. En concreto, el archivo AppManifest.xml, que será el encargado de enlazar entre el pro-yecto que define al Event Receiver Remoto y el proyecto que almacena el servicio WCF que implementa la lógica del evento. A continuación, un ejemplo del archivo AppManifest.xml al crear un Event Receiver Remoto en el que se ha escogido el evento ItemAdding e ItemUpdating. En este ejemplo, se especifica también el tipo de plantilla de lista para la cual se va a utilizar, el

205


nombre del manejador escogido, tipo de evento a controlar y la URL del servicio WCF bajo la cual se encuentra la lógica.

<?xml version=”1.0” encoding=”utf-8”?> <Elements xmlns=”http://schemas.microsoft.com/sharepoint/”> <Receivers ListTemplateId=”100”> <Receiver> <Name>RemoteEventReceiverItemAdding</Name> <Type>ItemAdding</Type> <SequenceNumber>10000</SequenceNumber> <Url>~remoteAppUrl/RemoteEventReceiver.svc</Url> </Receiver> <Receiver> <Name>RemoteEventReceiverItemUpdating</Name> <Type>ItemUpdating</Type> <SequenceNumber>10000</SequenceNumber> <Url>~remoteAppUrl/RemoteEventReceiver.svc</Url> </Receiver> </Receivers> </Elements>

Una vez vista la forma de implementar la lógica que hay detrás de un Event Receiver Remoto, vamos a explicar el ciclo de ejecución que sigue (para este ejemplo usaremos un evento Before Event, es decir, se lanza antes de que se guarden los datos en BD):

Figura 5-15. Ciclo de ejecución de un Event Receiver Remoto

206


Antes de comenzar a redactar los puntos vistos en la imagen, es imprescindible entender el concepto de ACS (Access Control Service). Por ACS entendemos un servicio que está en la Nube, que nos proporciona una manera fácil de autenticar y autorizar usuarios a nuestras aplicaciones web.

Una vez entendido esto, vamos a pasar a redactar los puntos más en detalle:

1. Ésta es la interacción inicial, un usuario actualiza una lista, es decir, añade, edita o borra un ítem, etc…

2. SharePoint recibe la orden.

3. SharePoint realiza peticiones al ACS para obtener información sobre el contexto y para obtener un código de autorización.

4. En este paso se genera la respuesta con dicha información junto código de autori-zación. Esta información es secreta entre nuestro SharePoint y el ACS.

5. Si la respuesta es positiva, el siguiente paso será llamar al Event Receiver Remoto que básicamente será un servicio WCF, el cual contendrá la lógica del usuario.

6. Éste es el último paso, en el cual el Event Receiver Remoto ataca a un sistema de datos externo realizando las modificaciones oportunas con el fin que fue programado.

A continuación, la tabla con los eventos (en inglés) que podemos elegir en la creación de un Event Receiver Remoto (serán menos, por ejemplo, no están los manejadores de eventos para flujos de trabajo):

NOMBRE DEL EVENTO Sincronía

Eventos Web

A siting deleted Sí

A site is being deleted Sí

A site is being moved Sí

A site is being provisioned Sí

A site collection was deleted No

A site was deleted No

A site was moved No

207


A site was provisioned No

Eventos en listas

A field was added No

A field is being added Sí

A field was removed No

A field is being removed Sí

A field was updated No

A field is being updated Sí

A list is being added Sí

A list is being deleted Sí

A list was added No

A list was deleted No

Eventos en elementos de la lista

A file was moved No

A file was converted No

An attachment is being added to the item Sí

An attachment is being removed from the item Sí

A file is being moved No

An item was added No

An item was updated No

An item was deleted No

An item was checked in No

An item was checked out No

An item was unchecked out No

An attachment was added to the item No

208


An attachment was removed from the item No

A file was moved No

A file was converted No

Para cerrar este apartado, respecto a casos de usos, podríamos decir que utilizaríamos Events Receivers Remotos si quieres controlar desde tu app quien añade cierto elemento en cierta lista. Otro ejemplo de uso sería querer prever que los usuarios no eliminen un elemento de la lista desde tu app.

App Event Receivers

Este tipo de eventos son un tanto más peculiares. Están dedicados a capturar los eventos que se producen en la propia app de SharePoint, es decir, cuando es instalada, actualizada o borrada. Como puedes apreciar, pueden llegar a ser muy útiles para automatizar procesos refe-ridos al despliegue de las apps. Un caso de uso de este tipo de evento, sería por ejemplo que queremos registrar en el fichero de log al usuario que ha desinstalado nuestra app o mandar email cuando un usuario instale nuestra app; con este tipo de evento lo podríamos llevar a cabo. Otro ejemplo podría ser que necesitemos de crear cierta estructura de listas dentro de un sitio de propio SharePoint donde estamos instalando la app.

A la hora de crear una app, explorando en las propiedades de ventana de la app, nos apa-recen 3 tipos de eventos, los cuales podemos instanciar a True o False. Estas propiedades son a nivel de proyecto de Visual Studio, en concreto para un proyecto de una app para SharePoint, los eventos que podemos apreciar son los siguientes:

-

Figura 5-16. Eventos en la propia App

Handle App Installed - Evento que se lanzará al instalar la app.

- Handle App Unistalling - Evento que se lanzará al desinstalar la app.

- Handle App Upgraded - Evento que se lanzará al actualizar la app.

209


Al instanciar el valor de uno de los tres eventos a True, también se añade una nueva entrada en el apartado Properties del archivo AppManifest.xml. Esta entrada es la encar-gada de relacionar el App Event receiver con el servicio WCF. Para terminar, vamos a ver el código que contiene el AppManifest.xml con los 3 tipos de eventos que vimos en el punto anterior instanciados a True. Estos eventos se lanzarán al instalar, actualizar o borrar una app.

<?xml version=”1.0” encoding=”utf-8” ?> <App xmlns=”http://schemas.microsoft.com/sharepoint/2012/app/manifest” Name=”SharePointApp3” ProductID=”{d2ddcb2e-9be2-40c5-a744-eaa95d3d88e4}” Version=”1.0.0.0” SharePointMinVersion=”15.0.0.0”> <Properties> <Title>SharePointApp3</Title> <StartPage>~remoteAppUrl/Pages/Default.aspx?{StandardTokens}</StartPage> <InstalledEventEndpoint>~remoteAppUrl/AppEventReceiver.svc</InstalledEven-tEndpoint> <UninstallingEventEndpoint>~remoteAppUrl/AppEventReceiver.svc</Uninstallin-gEventEndpoint> <UpgradedEventEndpoint>~remoteAppUrl/AppEventReceiver.svc</UpgradedEven-tEndpoint> </Properties> <AppPrincipal> <RemoteWebApplication ClientId=”*” /> </AppPrincipal> </App>

Conclusiones

En este capítulo hemos visto qué novedades trae consigo la nueva versión de SharePoint en cuanto a eventos. Principalmente, esta novedad viene determinada por los dos nuevos tipos de eventos que nos vamos a encontrar en cuanto a apps, los Events Receivers Remotos y los App Events Receivers. Con estos nuevos tipos de eventos, no solo podremos ya manejar even-tos que se produzcan en listas externas, sino que también podremos tener controlados eventos que se produzcan en las propias apps.

210


Novedades de flujos de trabajo para SharePoint 2013

Como habrás leído hasta este punto SharePoint 2013 viene cargado de novedades y cam-bios de filosofía en muchos aspectos. En lo que respecta a flujos de trabajo, también se han hecho cambios significativos y en este punto no se libra nadie; desde el usuario de negocio que diseña procesos sencillos, pasando por el desarrollador que crea aplicaciones o flujos de trabajo complejos, hasta el responsable de IT encargado de instalar, configurar y mantener la granja de SharePoint.

Estos cambios y novedades también están orientados a igualar el modelo de ejecución de flujos de trabajo entre SharePoint 2013 y SharePoint Online facilitando así la migración o reutilización de un flujo de trabajo entre los dos entornos.

Para el diseñador

Entendiendo como diseñador a aquellos usuarios de negocio o analistas de procesos que participan en el proceso de creación de flujos de trabajo, éste tendrá a su disposición un entorno intuitivo con el que crear flujos de trabajo más potentes, de forma más sencilla y empleando menos tiempo.

Para conseguir esta optimización, el diseñador tendrá a su disposición nuevos eventos, acciones y estructuras clásicas de programación. También podrá configurar llamadas a servicios de forma gráfica, algo para lo que hasta el momento era necesario acudir a programación.

En cuanto a las herramientas a utilizar por el diseñador no habrá cambios; estas serán Visio 2013 para modelado de procesos y SharePoint Designer para configuración del flujo de trabajo.

Para el desarrollador

La novedad más importante es que el desarrollador ya no escribirá código para programar sus flujos de trabajo ya que estos pasan a ser puramente declarativos. Dentro de Visual Studio 2012, el desarrollador dispone de la herramienta, Workflow Designer, con la que crea el flujo de trabajo gráficamente. Internamente el flujo de trabajo es código XAML que se interpreta en tiempo de ejecución.

Además, el nuevo motor de ejecución de flujos de trabajo permite controlar el ciclo de ejecución de estos desde cualquier sistema externo, con el objetivo de que el desarrollador pueda integrarlos como parte de la capa de negocio de sus aplicaciones, ya sean aplicaciones de SharePoint o cualquier otro tipo de aplicación.

211


Para el responsable de IT

La novedad más importante para el responsable de IT es que el motor de ejecución de flujos de trabajo de SharePoint 2013 es un componente externo a la plataforma y su instalación y configuración tiene que hacerse por separado. El administrador podrá crear una granja de servidores dedicados a este propósito y asociarlos con su granja de SharePoint obteniendo así una arquitectura robusta y escalable.

Arquitectura

Workflow Manager Client 1.0 es el nombre del nuevo motor de ejecución de flujos de tra-bajo en SharePoint 2013. Usa como framework la versión 4 de Windows Workflow Foundation y como API de mensajería Windows Communication Foundation.

Windows Workflow Foundation 4 define un flujo de trabajo como un conjunto de acti-vidades, representando cada una de ellas un componente funcional del proceso. SharePoint 2013 introduce una capa superior sobre este modelo que permite crear flujos de trabajo no secuenciales similares a flujos de estado de máquina (este modelo se define como “state-gate model”).

No debemos de confundir Actividad con Acción. Una Actividad representa un objeto admi-nistrado (una clase); es lo que ve y maneja el motor de ejecución. Una Acción es un contenedor que encapsula una actividad; es lo que se muestra al usuario en las herramientas de diseño de flujos de trabajo.

212


Figura 5-17. Nueva arquitctura de los flujos de trabajo para SharePoint 2013

Workflow Manager Client 1.0

Se encarga de administrar las definiciones de flujos de trabajo y también aloja los procesos de ejecución de cada instancia de los mismos.

Workflow Manager Service Application Proxy

Workflow Manager Client 1.0 está representado dentro de SharePoint como Workflow Manager Service Application Proxy, componente con el que se comunica autenticándose mediante OAuth.

Windows Azure Service Bus

Es el encargado de escuchar los eventos generados desde SharePoint para trasladárselos al motor de ejecución. Por ejemplo, cuando se crea un nuevo elemento en una lista que tiene asociada un flujo de trabajo para este evento, Azure Service Bus recoge el evento itemCreated y lo notifica a Workflow Manager Client 1.0 para que inicie una instancia nueva de ese flujo de trabajo.

213


Workflow Service Manager

Es la parte del modelo de objetos de SharePoint que proporciona funcionalidad para admi-nistrar flujos de trabajo y controlar su ejecución. Esta funcionalidad incluye el despliegue de los mismos, funciones de mensajería, control de instancias activas y gestión de flujos de trabajo de SharePoint 2010.

Cuando comentábamos anteriormente que los desarrolladores podrán trasladar funcio-nalidad de capa de negocio de sus aplicaciones al motor de ejecución de flujos de trabajo nos referíamos al uso de este componente.

SharePoint 2013

SharePoint 2013 se encarga de proporcionar la parte del framework que no tiene Windows Workflow Foundation 4 para trabajar con objetos de SharePoint, es decir, contenido (listas, usuarios, tareas, etc.) y eventos.

SharePoint 2010 Workflow Host

Se trata de un componente de interoperabilidad que permite ejecutar flujos de trabajo de SharePoint 2010 y llamar a actividades o usar características todavía no implementadas en SharePoint 2013.

Si en tu organización actualmente se encuentran en producción desarrollos a medida que incluyen actividades personalizadas no será un problema migrar a SharePoint 2013 gracias a este componente.

Instalación y configuración del entorno

A día de hoy, SharePoint 2013 cuenta con 3 tipos de plataforma de flujos de trabajo:

- SharePoint 2010

- SharePoint 2013 (requiere Workflow Manager)

- Project Server 2013 (requiere Project Server 2013)

Una vez realizada la instalación inicial de SharePoint 2013, solamente se encontrará dis-ponible SharePoint 2010 como plataforma de destino. Como hemos dicho anteriormente, el

214


motor de ejecución de flujos de trabajo en SharePoint 2013 es un componente externo y es necesario instalarlo por separado.

Es importante tener que cuenta que Workflow Manager no está disponible en SharePoint Foundation 2013.

Podemos planear la instalación de nuestra granja de Workflow Manager con tipologías diversas, pero creemos que no es objetivo de este libro abarcar este asunto. En esta dirección puedes consultar toda la información al respecto: http://technet.microsoft.com/en-us/library/jj658586(v=office.15).aspx.

Lo que vamos a ver es cómo realizar una configuración básica de Workflow Manager para un entorno de desarrollo. En este caso, se trata de un servidor Windows Server 2012 que es controlador de dominio en el que se encuentra instalado SQL Server 2012 y SharePoint 2013.

Planificación

A continuación, veremos cuáles son algunos de los requisitos necesarios para el tipo de instalación que nos ocupa. Para ampliar la información al respecto válida para el resto de imple-mentaciones puede ir a la siguiente dirección: http://technet.microsoft.com/en-us/library/jj193466

Los pre-requisitos se instalan automáticamente desde Web Platform Installer, pero hay varias configuraciones que tendremos que realizar antes de ejecutar el asistente de configura-ción de Workflow Manager:

• SQL Server: habilitar conexiones TCP/IP y canalizaciones con nombre

• Firewall de Windows: habilitado

• Puertos 4446 y 5112: habilitados

Además, dado que este servidor es también controlador de dominio, el usuario que va a configurar Workflow Manager debe ser administrador de dominio y tener permisos de sysAd-min en SQL Server.

http://technet.microsoft.com/en-us/library/ jj658586(v=office.15).aspx

http://technet.microsoft.com/en-us/library/ jj658586(v=office.15).aspx

http://technet.microsoft.com/en-us/library/ jj193466

http://technet.microsoft.com/en-us/library/ jj193466

215


Instalación

La instalación se realizará mediante el asistente de instalación de plataformas web Microsoft Web Platform Installer. Si no se encuentra instalado en el servidor se puede descargar desde la siguiente dirección: http://www.microsoft.com/web/downloads/platform.aspx

1. Abrir el navegador con la siguiente dirección:

http://go.microsoft.com/fwlink/?LinkID=252092

2. Abrir el archivo.

3.

Figura 5-18. Descarga del Workflow Manager

Web Platform Installer se iniciará mostrándonos los datos del componente que se va a instalar.

Figura 5-19. Descargando el Workflow 1.0 Beta desde Web Platform Installer

216


4. En este momento se inicia la instalación de los pre-requisitos y de Workflow Manager Client 1.0.

Figura 5-20. Instalando pre-requisitos de Workflow Manager Client 1.0

Configuración

Una vez instalado, y si no hubo ninguna incidencia, procederemos a iniciar el asistente de configuración de Workflow Manager. Esta configuración consta de dos pasos, primero confi-guraremos la granja de Workflow Manager con el asistente de configuración y después asocia-remos esta granja a nuestro servidor de SharePoint.

Configurar Workflow Manager

1. Iniciar el asistente de configuración.

2. Crear una nueva granja: seleccionar “Create a New Farm” – “Using Default Settings”

217


3.

Figura 5-21. Creación de granja de Workflow para SharePoint 2013

Introducir los datos solicitados y pulsar “Siguiente”.

• SQL Server Instance: nombre del servidor SQL (probar la conexión).

• USER ID: nombre del usuario que ejecutará el proceso. Es muy importante poner el nombre fqnd completo si no, el proceso fallará (ejemplo: [email protected]).

• PASSWORD: contraseña del usuario.

• Allow workflow management over http: al tratarse de un entorno de desarrollo marcamos esta opción para no tener problemas con certificados.

• CERTIFICATE GENERATION KEY: escribir una clave cualquiera para que se genere el certificado.

4. En la página siguiente del asistente vemos los valores de configuración selecciona-dos. También tenemos la opción de obtener el código PowerShell para realizar esa configu-ración, lo que puede ser muy útil para entornos de producción. Verificamos para continuar.

5. Esperamos a que se completen todos los procesos y si todo ha ido bien pasamos al paso siguiente.

218


Configurar SharePoint 2013

Ya tenemos configurada nuestra granja de Workflow Manager a la que hemos añadido un servidor. Ahora solamente nos queda configurar nuestra granja de SharePoint 2013 para esta-blecer la comunicación entre ambas. Para ello, simplemente tenemos que ejecutar el siguiente comando de PowerShell:

Register-SPWorkflowService –SPSite “http://SPSiteURL” –WorkflowHostUri “http://ServerName:XXX” -AllowOAuthHttp

Interfaces de programación

SharePoint 2013 incluye una interfaz de programación para que el desarrollador pueda aprovechar toda la potencia del nuevo motor de ejecución de flujos de trabajo. Este nuevo modelo de objetos permite automatizar el despliegue de flujos de trabajo y administrar ins-tancias de los mismos. Dependiendo del tipo de alojamiento de nuestra SharePoint App acce-deremos a la API de la forma más adecuada:

• Modelo de objetos de servidor.

• Modelo de objetos de cliente (CSOM).

• Modelo de objetos de JavaScript (JSOM).

• REST API.

En la siguiente dirección, puedes descargar un ejemplo completo de cómo interactuar con la plataforma de flujos de trabajo desde una SharePoint App: http://code.msdn.microsoft.com/SharePoint-2013-workflow-050f5211

http://code.msdn.microsoft.com/ SharePoint-2013-workflow-050f5211

http://code.msdn.microsoft.com/ SharePoint-2013-workflow-050f5211


P219

Autores

José Quinto Zamora

José es SharePoint and Search Specialist en SolidQ. Completó sus estudios de Ingeniería Informática Superior por la Universidad de Alicante en 2008. Fue galardonado con el premio especial al mejor expediente de su promoción (2003–2008). Actualmente combina su trabajo en SolidQ con la realización de su tesis doctoral en el campo de “Búsqueda Empresarial y Contextual” también en la Universidad de Alicante en el departamento DLSI. Tiene más de 4 años de expe-riencia en SharePoint. Concretamente, ha trabajado con SharePoint desde su versión 2007, pasando por la versión de 2010 y actualmente está trabajando ya con la versión 2013, especializado en las áreas: gestión, instalación, configuración, branding, inteligencia de negocios, búsqueda empresarial, localización, internacionalización y desarrollo. Además, ha impartido varias sesiones técnicas para Microsoft Ibérica y en los eventos SQLU Summit 2009, 2010, 2011 y 2012, CEUS 2012, SQLServer12. Tiene publicaciones en dNM+ (antes dotNetManía), CodePlex y CompartiMOSS. Además, José es escritor habitual en los blogs de SolidQ de SharePoint y PowerPivot. También es MCP, MCTS, MCITP y MCPD en SharePoint 2010. Es bastante activo en las redes sociales, compartiendo conocimiento de SharePoint, principalmente.

Sigue a José en Twitter: @jquintozamora

Cristian Zaragoza

Cristian cuenta con más de dos años de experiencia de trabajo con SharePoint. Desde que comenzó a trabajar en el departamento de colaboración y búsqueda de SolidQ, ha estado presente en dis-tintos proyectos de desarrollo para distintas empresas, siempre con SharePoint como denominador común. Es colaborador activo en el blog del equipo de SharePoint de SolidQ, así como ponente habitual en las jornadas anuales de ponencias de SolidQ en Madrid, “SolidQ Summit Madrid”. Por otro lado, Cristian cuenta con un Máster con-cluido con éxito en “Desarrollo de Aplicaciones y Servicios Web” en la Universidad de Alicante, así como diversas certificaciones oficiales de Microsoft. En la actualidad, Cristian sigue trabajando en distintos proyectos con SharePoint, habiéndose especializado en la maqueta-ción, diseño y aplicación de estilos corporativos (Branding).

Sigue a Cristian en Twitter: @cmzaragoza


http://blogs.solidq.com/sharepoint/Home.aspx

http://blogs.solidq.com/powerpivot/Home.aspx

https://twitter.com/jquintozamora

http://www.SolidQ.com

https://twitter.com/cmzaragoza

es.linkedin.com/in/jquintozamora

https://twitter.com/jquintozamora

es.linkedin.com/pub/cristian-m-zaragoza-g�mez/58/666/868/en

https://twitter.com/cmzaragoza


P220

Guillermo Bas

Guillermo tiene más de cuatro años de experiencia con SharePoint, comenzó trabajando con la versión 2007 en varias empresas y actual-mente trabaja con las versiones 2010 y 2013 en SolidQ. Además posee los títulos MCTS en desarrollo para WSS 3.0, Administración de SharePoint 2010 y MCPD SharePoint Developer 2010. Actualmente trabaja activamente con SharePoint Server 2010, 2013 y Office 365 además de ser colaborador habitual en los foros de desarrollo de SharePoint en MSDN (en inglés) y en el blog del SharePoint Team de SolidQ.

Sigue a Guillermo en Twitter: @guillebas

Roberto Ramón

Roberto trabaja en SolidQ como SharePoint Developer. Titulado en Ingeniería Técnica en Informática de Sistemas por la Universidad de Alicante. Al acabar sus estudios compaginó el máster de “Desarrollo de Aplicaciones y Servicios Web” con una beca de trabajo en la Universidad de Alicante. Miembro del equipo de SharePoint de SolidQ, trabajando en proyectos tanto en la versión online como en la versión on premise. A su vez, colabora en el blog del equipo de SharePoint de SolidQ. Fue ponente en SolidQ Summit Madrid 2012.

Sigue a Roberto en Twitter: @Rober_Ramon

Iván Paredes

Iván cuenta con un bagaje de 10 años por varios sectores reali-zando principalmente proyectos de desarrollo de software a medida sobre tecnología Microsoft. Actualmente trabaja como desarrollador en el departamento de colaboración de SolidQ. Colabora activamente con la comunidad de Office 365, servicio sobre el que ha desarro-llado diversos proyectos de instalación y configuración. También es colaborador habitual en el blog de SharePoint de SolidQ.

Sigue a Iván en Twitter: @ivanparedes_


http://blogs.solidq.com/sharepoint

http://www.twitter.com/guillebas



https://twitter.com/Rober_Ramon



https://twitter.com/ivanparedes_

es.linkedin.com/pub/guillermo-bas-ortiz/22/4a9/764/en

https://twitter.com/guillebas

es.linkedin.com/pub/roberto-ramon/43/b4/96b

https://twitter.com/Rober_Ramon

es.linkedin.com/in/ivanparedessanmartin

https://twitter.com/ivanparedes_

SolidQ es el proveedor global confiable de servicios de formación y soluciones avanzadas para las aplicaciones de misión crítica, inteligencia de negocio, alta disponibilidad, colabora-ción, búsqueda y soluciones de tecnología avanzada para plataformas de nube.

SolidQ combina una amplia experiencia técnica y de implementación en el mundo real, con un compromiso firme en la transferencia de conocimiento, dada la combinación única de dotes lectivas y experiencia profesional que nuestros mentores ofrecen. De este modo, no solamente ayudamos a nuestros clientes a solventar sus necesidades tecnológicas, sino que somos capaces de incrementar la capacidad técnica de sus profesionales, dándoles una ventaja competitiva en el mercado. Por eso llamamos Mentores a nuestros expertos: por su compromiso en asegurar el éxito de su empresa y de sus equipos profesionales a largo pla-zo.

Nuestros expertos son profesionales reconocidos en el mercado, con más de 100 premios MVP (Most Valuable Professional) obtenidos hasta la fecha. Se trata de autores y ponentes en las conferencias más importantes del sector, con varios centenares de ponencias presenta-das en conferencias internacionales durante los últimos años. Sirva como ejemplo que nuestros expertos han tenido el honor de impartir cursos de formación a empleados de Microsoft en todo el mundo. Además, han participado en más de 20 libros de Microsoft Press en todas las áreas de las plataformas de acceso a datos de Microsoft. Véase un listado completo aquí

Nuestra misión es la de transmitir todo el conocimiento adquirido resolviendo problemas del mundo real para miles de clientes, escribiendo artículos y libros, publicando whitepapers, creando contenidos educativos y formando a decenas de miles de trabajadores de TI en todo el mundo, para que los proyectos de nuestros clientes obtengan los mayores éxitos. Esta trans-ferencia de conocimiento la realizamos fundamentalmente con dos tipos de servicios:

- Formación. Ofreciendo cursos privados presenciales y online, sesiones técnicas, web-casts, y los recientes Masters en SharePoint, en Inteligencia de Negocio y en Relacional.

- Mentoring y consultorías. Servicios de consultoría de alto valor y corta duración.

- SolidQ Journal y Blogs. Ofreciendo a través de nuestra web una revista digital total-mente gratuita llamada “The SolidQ Journal”, así como más de 1000 post en nuestros blogs.

En SolidQ, todos los expertos tienen en mente este lema: “comparte lo que sepas, aprende lo que no conozcas”.

http://www.solidq.com/sqj/books

http://www.solidq.com/sqj

http://blogs.solidq.com

www.solidq.com

Máster en BIhttp://www.solidq.com/es/MasterBI

Da un giro a tu carrera profesional.Es tiempo de oportunidades.

Para más información llama al 800.300.800 o +34 91 414 8950 o bien manda un e-mail a: [email protected]

¡Infórmate Ya!

Máster SQL Server DBAhttp://www.solidq.com/es/MasterSQLServerDBA

Máster en SharePointhttp://www.solidq.com/es/MasterSharePoint

MA

STER

S C

ERTI

FIC

AD

OS

POR

Sol

idQ

Conviértete en un profesional altamente especializado

en tecnologías Microsoft.


http://www.solidq.com/es/MasterBI

http://www.solidq.com/squ/courses/Pages/Master-BI-Certified-Business-Intelligence-Microsoft-Espanol.aspx

http://www.solidq.com/es/MasterSQLServerDBA

http://www.solidq.com/squ/courses/Pages/Master-SQL-Server-DBA-Certified-Microsoft-Espanol.aspx

http://www.solidq.com/es/MasterSharePointhttp://www.solidq.com/es/MasterSharePoint

http://www.solidq.com/squ/courses/Pages/Master-Sharepoint-Formacion-Certified-Microsoft-Espanol.aspx