SharePoint App Catalog And Missing Apps

Another weird SharePoint app bug happened yesterday. The solution was fairly easy once you know what’s going on, but it’s just weird altogether.

SYMPTOMS

You have a custom app in your SharePoint 2013 App Catalog.

A custom app inside app catalog under Apps for SharePoint
A Custom App Inside App Catalog

You want to add this app to a SharePoint site.  You can’t find your app in the “From Your Organization” section when you click at “Add an app” in a site.

The App Is Missing From "Your Apps"
The App Is Missing From “Your Apps”

CAUSE

I first suspected that the current user doesn’t have permissions to add an app. However, the user is the site collection administration and thus has the permission to install an app.

Yet…a slight detail. The App Catalog site is, well, a SharePoint site. With its own permissions. And, by default, containing only the user who created the catalog in the first place (the system admin).

So, the current user, although a site collection admin, doesn’t have permissions to read from the app catalog. (This is the weird part, as I expected SharePoint to do the reading using a system account behind the scenes.)

SOLUTION

Add the users that should be able to install your custom apps to the site permissions of the App Catalog site, with Read permission level. In my case it was “Dani Alves” (yes, I’m a Barcelona fan).

Adding Read Permissions to the App Catalog

Now, the app is visible in “Your Apps” when you try to add it to a site. Yeah!Custom App Is Now Visible

Apps de SharePoint vs Apps de Office 365

En estos últimos días hay un debate calentito sobre el futuro del modelo de apps de SharePoint.

El día 22 de diciembre el gran gurú SharePointero Sahil Malik publicó el siguiente post (SharePoint App Model: Rest in Peace) que abrió un poco la caja de Pandora sobre el modelo de las apps. Su argumento es que el modelo de las apps introducido con SharePoint 2013 está quedando arrinconado a favor del nuevo modelo de apps de Office 365.

Veamos un poco en detalle este debate. Primero voy a presentar a los boxeadores y luego veremos como queda el match.

image

Los contrincantes en el ring

El modelo de apps de SharePoint 2013

Ya llevamos unos años con este modelo, que todavía se usa bien poco para los proyectos "serios". En esencia, tenemos a SharePoint como proveedor de datos y una aplicación remota (provider-hosted) o JS consumiendo esos datos mediante interfaz REST (o su abstracción JSOM/CSOM). Para la autenticación entre la aplicación remota y SharePoint se usan los tokens OAuth, con la posible intermediación de Azure ACS.

Apps for SharePoint hosting options

El modelo de apps de Office 365

Este nuevo modelo introducido en 2014 es una abstracción por encima de los servicios de la plataforma de Office 365. Los servicios se exponen mediante la interfaz REST y están pensados para proporcionar operaciones de alto nivel como "obtener contactos" o "leer documentos". Las aplicaciones pueden hacerse en cualquier tecnología y para autenticar la aplicación con Office 365 se dispone de Azure Active Directory (AAD) que almacena las credenciales de los usuarios y nos devuelve sus tokens para usarlos contra la API de Office 365.

Development stack for creating solutions that use Office 365 APIs. Select your developer environment and language. Then use Azure single sign-on authentication to connect to the Office 365 APIs.

¿En que se diferencian?

En muchas cosas, pero en mi opinión las diferencias básicas son:

Apps de SharePoint

Apps de Office 365

Operaciones de bajo nivel

Operaciones de alto nivel

Usan Azure ACS

Usan Azure AD

Sólo pueden acceder a SharePoint

Pueden acceder a los servicios de O365, Azure Active Directory y a SharePoint

Permiten el modelo high-trust para instalaciones "on premise"

Sólo se puede usar con la instalación cloud o híbrida

 
Si queréis ver una comparativa muy bien ilustrada con pantallazos, este post de Chris O’Brien es el mejor recurso.

Entonces, ¿qué hago?

Visto este percal al que Microsoft nos ha llevado, uno se puede preguntar sobre que esperar en el futuro. ¿Desaparecerá el modelo de las apps en la siguiente versión de SharePoint como ya pasó con las aplicaciones sandbox? Si voy a hacer una app para SharePoint, ¿uso el modelo SharePoint o el de Office 365?

Yo creo que el modelo de las apps de SharePoint 2013 no desaparecerá, sino que será uno más a considerar. Ahora tenemos el modelo Full-trust code (FTC) de toda la vida, soportado 100% on-premise, modelo de apps soportado en el cloud y on-premise y en la nueva versión de SharePoint tendremos la opción de usar el modelo de apps de Office 365, si tenemos un despliegue en la nube o híbrido. Lo que no vamos a ver es "un modelo que los gobierne a todos". Al abrirse el abanico de opciones de hospedaje de SharePoint, Microsoft ha abierto el abanico de soluciones de código a medida para encajar mejor en cada uno de ellos.

El modelo de apps de Office 365 es más limpio que el de apps de SharePoint, pero es comprensible dada su naturaleza. Es un modelo abstracto de servicios sobre toda la plataforma Office 365 y no tiene que preocuparse de detalles técnicos como las insufribles páginas AppRegNew.aspx, ClientIds y tonterías varias. Si estamos haciendo una app empresarial que combina la gestión de documentos, listas, contactos, mails etc., el modelo de Office 365 es más directo y fácil.

El modelo de apps de SharePoint lo veo más bien enfocado a las soluciones que sólo involucren a SharePoint o cuando no estamos en el mundo Office 365, ni siquiera en modo híbrido. Igualmente, si sabemos lo que hacemos y quedemos toda la potencia de SharePoint para nosotros en nuestro datacenter, el modelo de código de servidor no va a desaparecer.

Y vosotros, ¿qué opináis?

Modelo de apps en detalle (III): High-Trust

En los primeros dos posts de esta serie hemos visto la evolución del código personalizado en SharePoint y la arquitectura básica del modelo de apps. También hemos visto a grandes rasgos como la app se autentica con SharePoint utilizando Azure Access Control Service (ACS) como intermediario.

Las apps en SharePoint Online funcionan con este método de autorización de las apps, llamado low-trust.

Modelo Low-Trust: SharePoint + app + ACS

En este modelo, SharePoint es el responsable de pasar un token de contexto a la app, cuando hace la redirección a ella. La app valida el token de contexto y lo intercambia por un token de acceso, haciendo una llamada a ACS. Fijaos que el modelo low-trust deja a la app como un mero transmisor de tokens entre SharePoint y ACS. Por eso mismo se llama de "baja confianza". La app no puede añadir ni quitar nada de la información de autenticación y autorización. Todo esto viene dado en el token inicial que se le pasa a la app desde SharePoint.

Este modelo es muy útil para apps públicas sobre las que no tenemos ningún control. Por ello es el modelo usado para la SharePoint Store y las apps disponibles en SharePoint Online. En los entornos on-premise corporativos, este modelo requiere dar conectividad a Internet a los servidores de SharePoint y los servidores de las apps así como establecer una relación de confianza entre SharePoint on-premise y el servicio ACS de Azure.

Modelo High-Trust: SharePoint + app

En los entornos corporativos on-premise de SharePoint, podemos usar otro modelo de autorización y autenticación de las apps, en el que SharePoint establece una relación de confianza con la app y delega en ella la autenticación del usuario. Este modelo es el llamado high-trust o de alta confianza. También se le llama S2S (Server-to-Server).

No hay que confundir el modelo de high-trust con full-trust. Full-trust es el código personalizado de servidor de SharePoint que desplegamos en la GAC, y por lo que tiene todos los permisos que tiene SharePoint. Una app high-trust tendrá como mucho los permisos que se le han otorgado durante su instalación, ni más ni menos, idéntico al caso de las low-trust apps.

Entonces, ¿por qué se llama "de alta confianza"? Es así debido a que no hay un intermediario (como ACS) y que SharePoint se fía de la app para que le construya el token de acceso adecuado.

Para que el modelo high-trust funcione, tenemos que habilitar una relación de confianza entre la app y SharePoint. Esto se consigue utilizando un certificado digital. La parte pública de este certificado se registra en SharePoint como "trusted token issuer" o emisor de tokens de confianza. En el caso de las low-trust apps, el único "emisor de tokens de confianza" es el ACS. La parte privada del certificado se usará en la app para firmar los tokens emitidios por ella.

Al ser la app un emisor de tokens de confianza, SharePoint aceptará los tokens que ella misma construya. Previamente los validará con la clave pública del certificado, lo que comprueba que no han estados modificados durante el tránsito. Luego, aplicará los permisos que tiene la app en SharePoint (que se le han dado al instalarla) e incluirá la información del usuario actual (que está contenida en el token de acceso que construye la app).

Fijaos que la app puede construir el token de acceso para cualquier usuario. Esta es la parte en la que nos tenemos que "fiar" de la app. Sin embargo, el ámbito de actuación de la app está limitado a los permisos que se le han dado al instalar, así que aunque la app puede "falsear" la información del usuario (como decir que viene de parte de la cuenta del sistema), como mucho puede hacer lo que se le permite a la app, sin poder saltárselo.

Vayamos a ver el "baile" de conversación entre SharePoint y una app high-trust al abrir la app desde el navegador.

image

  1. El usuario abre una página de SharePoint y clica en el enlace de la app.
  2. SharePoint hace la redirección a la URL de la app (respuesta 302 de HTTP). No incluye ningún token de contexto (como en el caso de las low-trust apps).
  3. El navegador realiza la petición a la URL de MiApp.com como respuesta a la redirección.
  4. La aplicación recibe la petición HTTP. Para acceder a SharePoint mediante CSOM o REST, la aplicación necesita un token de acceso. La aplicación construye el token de acceso y lo firma con la clave privada de su certificado. Incluye este token en la petición a SharePoint.
  5. SharePoint comprueba la validez del token de acceso con la clave pública del certificado de la aplicación y devuelve los datos que la aplicación le ha pedido.
  6. La aplicación renderiza el HTML que se va a visualizar y lo devuelve al navegador.

Construyendo los tokens de acceso

La misma clase auxiliar TokenHelper.cs que usamos en las apps de ASP.NET contiene los métodos para construir los tokens de acceso de high-trust apps. Si miramos el código fuente del mismomiramos el código fuente del mismo, veremos dos métodos:

  • GetS2SAccessTokenWithWindowsIdentity
  • GetS2SClientContextWithWindowsIdentity

El primer método devuelve un token de acceso para un usuario concreto, firmado con la clave privada del certificado de la app. El segundo devuelve un contexto de SharePoint CSOM (ClientContext) inicializado para un usuario concreto.

El usuario se le pasa como parámetro al método, y es una instancia de WindowsIdentity. Internamente, la clase TokenHelper convierte este usuario en un conjunto de claims y construye el token con estos claims. Este detalle de implementación obliga a que la app esté alojada con la autenticación Windows habilitada, ya que sin ella la app no podría obtener una instancia de WindowsIdentity. Sin embargo, es posible cambiar la clase TokenHelper para que expida tokens con un ClaimsIdentity (identidad procedente de claims) si usamos ADFS o algún otro proveedor de identidad (STS) compatible con credenciales SAML. Lo veremos en uno de los próximos posts.

Pero, ¿cómo sabe TokenHelper donde está el certificado para firmar? Bueno, se lo tenemos que decir nosotros usando el fichero web.config. Hay que añadir unas entradas adicionales, a parte de las obligatorias para la app (como el ID de la app y su URI), especificando una ruta de certificado y una contraseña para firmar con la clave privada. Además, el application pool de la app tiene que tener permisos suficientes sobre la carpeta donde se halla el certificado.

Resumen

Hemos visto como las apps high-trust simplifican la autorización y autenticación en un entorno on-premise. En el próximo post veremos como configurar un entorno de SharePoint on-premise y haremos una app high-trust desde cero.

Modelo de apps en detalle (II): Las piezas

En el primer post de esta serie sobre el modelo de apps de SharePoint 2013, expliqué la problemática de tener código a medida en SharePoint y como SharePoint ha evolucionado para acomodarla, hasta llegar al modelo de apps en SharePoint 2013.

En este segundo post voy a explicar las piezas clave del modelo de apps, para asentar los conocimientos básicos antes de meternos en detalle con la autorización y la autenticación de la app.

Los "webs" del modelo de apps

A grandes rasgos, el modelo de apps involucra tres piezas básicas en forma de sitio web:

  • "host web" (SharePoint)
  • "app web" (SharePoint)
  • "remote web"

Voy a poner un diagrama completo de las piezas de las apps y lo comentaremos a lo largo de este post. Entender bien estas piezas y su relación es tener la mitad del trabajo hecho. Vayamos por partes.

image 

Host Web

Las apps se instalan en un sitio de SharePoint y se lanzan desde allí. Ese sitio web, en el que la app está instalada y tiene ciertos permisos, se llama host web.

App Web

Una app al instalarse puede crear un sitio de SharePoint para su propio uso. Este sitio, si existe, se llama app web y tiene la URL con un dominio diferente al de host web. Esto se hace para impedir llamadas cross-site de JavaScript.

¿Para qué nos sirve un app web? La idea es guardar aquí los datos propios de la app, como los resultados parciales, configuraciones, perfiles de usuarios etc. La app web es invisible para el usuario normal de SharePoint, y no se puede acceder a ella mediante la interfaz de usuario.

Remote Web

Para las aplicaciones provider-hosted (es decir, las que tienen código y no sólo JavaScript), la invocación de la app tiene forma de redirect hacia una URL en la que está alojada la aplicación. Este sitio donde está alojada la app se llama remote web. Lo más probable es que la app esté alojada en un IIS (on-premise o en Azure) pero podría estar alojada en cualquier tecnología web (Apache, Linux, Node.js…). Sin embargo, si usamos ASP.NET como la plataforma para la app, se nos simplifica la comunicación con SharePoint ya que disponemos de librerías y helpers.

Los permisos

Pongamos como ejemplo que acabamos de clicar el enlace de la app en SharePoint, concretamente en http://contoso/site1. . Como ya sabéis, esto implica que la app está instalada en http://contoso/site1, que es la host web de la app.

La app también tiene ciertos permisos sobre la host web, que se le otorgan al instalarla. Los permisos pueden ser de leer algunas listas de la host web hasta tener control total sobre la tenancy o la site collection en la que está la host web. Los permisos de declaran en el paquete de la app (que veremos más adelante) y la persona que instala la app tiene que tener la potestad de otorgarlos.

Resumiendo, la app tiene los permisos sobre la host web que le hayamos dado al instalarla. Ni uno más ni uno menos.

Si la app dispone de una app web (que es otro de los parámetros que podemos poner en el paquete de la app), la app tiene el control total sobre la app web. Puede hacer y deshacer lo que le dé la gana. Como la app web no se muestra al usuario y sirve como un mero repositorio de datos para la app, no hay peligro en darle control total sobre esa parte de SharePoint.

Para nuestro ejemplo, imaginemos que la app web tiene la url http://app123.contosoapps.

La comunicación entre SharePoint y la app

Volvamos al ejemplo. Hemos clicado la app en http://contoso/site1 y nos ha llevado a https://wingtip/app1/start.aspx. Esta URL es parte del paquete de la app, y es la que lleva a la remote web de la app. En este caso, imaginemos que https://wingtip/app1 es un sitio IIS en una máquina dentro del datacenter de Contoso. Una máquina que no tiene ni idea de SharePoint y que contiene una app hecha en ASP.NET WebForms.

ASP.NET carga la página start.aspx. En este momento la app tiene que establecer la conexión con SharePoint para cargar los datos que necesita de allí. Veamos como lo hace.

Lo primero que necesita la app en remote web es saber a qué URLs tiene que llamar para obtener los datos de la host web y la app web.

¿Cómo lo sabe? Podríamos guardar estas URLs en la configuración de la app (en web.config o en la base de datos) pero lo más habitual es que al llamar la app desde SharePoint se incluyan estas URLs en la URL con la que se llama a la app. Así, nuestra app no se llama con un redirect a https://wingtip/app1/start.aspx sino a https://wingtip/app1/start.aspx?SPHostUrl=http://contoso/site1&SPAppWebUrl=http://app123.contosoapps. Como podéis ver, en los parámetros SPHostUrl y SPAppWebUrl tenemos las URLs de la host web y de la app web, respectivamente.

image

Usando el modelo de objetos de cliente de SharePoint podríamos instanciar un contexto a través de esas URLs, pero nos faltaría la autenticación. Es decir, ¿con qué credenciales de usuario abrimos el contexto de SharePoint? Vamos a ver como lo resuelve el modelo de apps.

Autenticación de la app

En el primer post de esta seria dije que las apps de SharePoint 2013 tienen identidad propia y se les pueden asignar permisos. Pues este es el mecanismo con el que se resuelve el problema de las credenciales: el contexto de SharePoint se abrirá con las credenciales de la app.

¿De dónde vamos a sacar las credenciales de la app? Esto depende de si estamos usando las apps en SharePoint Online o una granja on-premise federada con Azure Access Control Service (ACS) o bien estamos usando las apps en un entorno on-premise con certificados.

El primer caso es el más frecuente y se llama "low-trust" (baja confianza). En este caso, SharePoint usa un servicio de Azure llamado ACS (Access Control Service) para confimar la identidad de la app. ¿Cómo? Pues sencillamente antes de hacer el redirect a la app, inyecta en la cabecera de la petición HTTP un pequeño fragmento de texto, un token de contexto, que le servirá a la app luego para sacar las credenciales.

image

Este token de contexto contiene la información sobre la identidad de la app. La app (ASP.NET) tiene que extraer este token de la petición inicial HTTP, hacer una petición a ACS e intercambiarlo por otro token, llamado token de acceso. El token de acceso nos sirve para instanciar un contexto de SharePoint, ya que es un token OAuth que SharePoint 2013 acepta. Este token se incorpora en la cabecera de la petición a la interfaz REST de SharePoint 2013 con el nombre de "Bearer".

image

Podéis ver el contenido exacto de los tokens de contexto y acceso en el siguiente enlace: http://msdn.microsoft.com/library/office/fp179932.aspx#Tokens.

Todo este proceso de extraer los tokens, validarlos, intercambiarlos y crear el contexto de SharePoint está encapsulado en una clase autogenerada por Visual Studio al hacer una app de SharePoint, que se llama TokenHelper.cs. Podéis examinarlo y ver como hace la petición a ACS y que luego incorpora el token de acceso para llamar a SharePoint.

Si estamos en una plataforma que no es .NET (como PHP por ejemplo), podemos hacer el mismo proceso pero no tendremos un TokenHelper mágico. Tendremos que hacer la extracción y construcción de tokens y de llamadas a ACS de manera manual, pero no hay nada intrínsecamente difícil en ello.

Resumiendo

Como podéis ver, el "baile" entre las piezas de las apps es delicado y hay muchos conceptos involucrados. Os recomiendo releer este post hasta que os quede claro la interacción entre host web, app web y remote web, así como el papel de los tokens. Si queréis más detalles sobre los tokens y la autenticación low-trust, os recomiendo el artículo siguiente de Kirk Evans del equipo de SharePoint (en inglés): http://blogs.msdn.com/b/kaevans/archive/2013/04/05/inside-sharepoint-2013-oauth-context-tokens.aspx.

En el siguiente post veremos como las aplicaciones "high-trust" resuelven el problema de la autenticación sin delegarlo a un servicio de terceros como ACS.

Modelo de apps en detalle (I): Introducción

Hola a todos,

En un reciente proyecto me he visto involucrado en mucho detalle en el modelo de apps de SharePoint 2013 en entornos corporativos, con aplicaciones de alta confianza (high-trust) y autenticación federada con Claims. Mi idea en esta serie de artículos en el blog es compartir estos conocimientos ya que creo que existe poca información de primera mano sobre la utilización real del modelo de apps, fuera de las apps de demostración.

En este primer post voy a recordar la evolución del modelo de programación de SharePoint.

Antes de SharePoint 2010

Para un programador "veterano" en SharePoint, la programación en SharePoint siempre implica poner el código NET en el servidor de SharePoint. Desde que SharePoint abrazó el modelo de programación NET en la versión 2003, siempre ha sido así. El código de nuestras soluciones SharePoint se pone en la carpeta BIN de la aplicación web de SharePoint o bien en la GAC del servidor.

image

Los beneficios de este enfoque son el acceso a toda la potencia del modelo de objetos de SharePoint de servidor (Server Object Model) y de NET. Sin embargo, nos exponemos a que nuestro código ralentize el servidor (ya que se ejecuta en el mismo proceso que el código propio de SharePoint) y a que tengamos que preparar bien las actualizaciones de SharePoint. Solo hay que recordar las migraciones de una versión de SharePoint a otra y la caza y captura de código a medida para actualizarlo al nuevo modelo.

La raíz del problema es que SharePoint "puro" sin código a medida tiene un rendimiento muy bueno y que SharePoint con código a medida que no esté bien optimizado (y la verdad es que la mayoría del código a medida en SharePoint que circula por ahí no lo está) puede castigar el rendimiento de tal manera que no sea usable. En esencia: no hay nada que nos impida "frenar" a SharePoint con nuestro código lento. (como ejercicio podéis poner una webpart en SharePoint que haga un Thread.Sleep(5000) y SharePoint se volverá 5 segundos más lento).

SharePoint 2010: CSOM y Sandboxed

Para solventar de alguna manera este acoplamiento fuerte entre SharePoint y nuestro código, en SharePoint 2010 aparecen dos componentes arquitectónicos nuevos.

En primer lugar, tenemos un modelo de objetos de cliente (Client-side Object Model, CSOM) disponible en NET, Silverlight y JavaScript. De esta manera podemos crear código que se ejecute fuera de SharePoint. El modelo de objetos de cliente no es tan potente como el modelo de objetos de servidor, pero es usable en muchos escenarios comunes.

En segundo lugar, aparece el concepto de código sandboxed. Por primera vez, el código a medida se puede ejecutar en un proceso separado de SharePoint y por tanto sometido a restricciones de tiempo de CPU y memoria. De esta manera podemos mantener estable el entorno propio de SharePoint y protegerlo de cierta manera de nuestro código potencialmente acaparador de recursos.

modelo_sandbox

Las aplicaciones sandboxed prometían lo mejor de los dos mundos: acceso al modelo de objetos de servidor y a la vez un control sobre el uso de recursos del código que lo utiliza.

SharePoint 2013: Cloud-based Apps (CBA)

¡Y llegó SharePoint 2013! De buenas a primeras, se cargó de un plumazo "deprecador" el modelo sandbox que tanto prometía. Para sustituirlo, optó por desterrar el código a medida fuera del servidor de SharePoint en el nuevo modelo de apps (cloud-based applications, CBA).

Por tanto, el modelo de desarrollo preferente en SharePoint 2013 es tener todo el código fuera de SharePoint (en apps) y puesto en otro proceso que potencialmente esté en otra máquina así como utilizar el modelo de objetos de cliente (ya introducido en SharePoint 2010) para interactuar con los datos en SharePoint. De esta manera se cumple el objetivo importante de no que el código a medida lento no haga lento a SharePoint, pero a costa de tener que utilizar una API de cliente incompleta y que no está a la par del modelo de objetos de servidor.

modelo_apps

Para que el código a medida de las apps pueda llamar a SharePoint sin tener en cuenta el usuario concreto, se adaptó el estándar OAuth para crear las credenciales de las apps. En SharePoint 2013 una app tiene una identidad propia y permisos propios. En tiempo de ejecución, se combinan los permisos de la app y los permisos del usuario que utiliza la app para determinar los permisos efectivos.

Cuando apareció el modelo de las apps, había 3 "sabores" de las mismas: SharePoint-hosted, auto-hosted y provider-hosted. En junio de 2014 desapareció la opción auto-hosted. Las apps SharePoint-hosted sólo pueden contener código JavaScript así que para las aplicaciones corporativas son más bien inútiles. Esto nos deja con el modelo provider-hosted como el único realmente utilizado para hacer una app de cierta relevancia en SharePoint 2013.

Resumen

En este post hemos revisado la evolución de los modelos de desarrollo a medida de SharePoint, hasta el modelo de apps de SharePoint 2013. En el post siguiente abordaré el modelo de las apps en detalle para explicar las piezas que lo componen e ir introduciendo el concepto de low-trust y high-trust apps. ¡Hasta pronto!

Las apps de SharePoint 2013 (V): Una app provider-hosted en Azure

En la serie de posts sobre el desarrollo de apps de SharePoint 2013, hemos visto hasta ahora un ejemplo de app de SharePoint 2013 para niños alojada en SharePoint mismo y otro ejemplo de app alojada “automágicamente” en Azure. Ahora falta una vuelta de tuerca más para ver el modelo que nos queda: las llamadas aplicaciones provider-hosted.

Si recordamos los tres modelos de alojamiento de apps que hay en SharePoint 2013, las aplicaciones provider-hosted requieren intervención manual para que SharePoint y la parte servidora se hablen entre ellos. En el caso de Azure esto se reduce bastante porque las herramientas de SharePoint y de Azure nos lo facilitan, pero si hacemos una subida a la nube de Amazon o a nuestro propio datacenter, la cosa se nos hace un poquito más engorrosa, sin llegar a ser difícil en ningún caso.

El punto de partida

Vamos a empezar con la aplicación desarrollada para el modelo autohosted en Azure, para ir más ágiles y para seguir usando ASP.NET MVC (que es lo que mola ahora).

image

La vamos a subir “manualmente” a Azure Web Sites y le vamos a decir a SharePoint que se conecte a ella cuando el usuario clica la app.

Nota: A los que ya conocéis Azure y pensáis que estoy mostrando solo la parte “express”, os comento que estoy dejano para una próxima entrega de la serie de posts una app totalmente “Azure” que use servicios más avanzados como Storage, SQL Azure etc.

Configuración de Azure

El primer paso es ir a nuestro panel de control de Azure (o darnos de alta en la prueba gratis de Azure de 90 días y luego ir al panel de control). Allí crearemos un sitio web de Azure, sencillo, y usaremos los detalles del sitio para configurar el proyecto MVC en Visual Studio.

Iremos a la opción Sitios Web y crearemos uno nuevo con el nombre EdinSpMvc-Provider.

image

Esperamos unos momentos y el sitio se habrá creado correctamente

image

Ahora vamos a clicar la flecha al lado del nombre del sitio web para ver el panel de control del sitio y descargaremos el perfil de publicación (en Vista Rápida) para usarlo en Visual Studio más adelante.

image

Creación de la app en SharePoint

Ahora iremos a nuestro sitio en SharePoint 365 Developer Site (en mi caso es https://edinkapic.sharepoint.com/sites/dev). Tenemos que hacer un “truquillo” para registrar una app manualmente: añadiremos a la URL del sitio el sufijo /_layouts/15/appregnew.aspx.

Se nos abre la ventana de registro de una nueva app.

image

Esta es “la madre del cordero” que enlaza SharePoint con nuestra app. Explicaré los conceptos que tenemos que introducir (para más detalles está la MSDN):

  • App Id: esto es un Guid que identifica la app de manera única. Generaremos uno al azar dándole al botón Generar.
  • App Secret: esto la parte pública de una clave asimétrica que usa SharePoint para validar que nuestra app tiene permisos para conectarse. Nuestra app en MVC se conectará a SharePoint pasándole la este secreto junto con más parámetros y SharePoint comprobará que es efectivamente la app que él autorizó. Generaremos una al azar dándole al botón Generar.
  • Title: El título de la app. Pondremos App Provider-Hosted en Azure y MVC
  • App Domain: aquí irá el dominio de nuestro hosting (Azure Web Sites). Pondremos edinspmvc-provider.azurewebsites.net
  • Redirect URL: aquí pondremos la página de inicio de nuestra aplicación MVC, en nuestro caso https://edinspmvc-provider.azurewebsites.net/Home. Es imprescindible poner HTTPS (en Azure no tenemos que preocuparnos porque automáticamente tenemos HTTPS en Web Sites, pero si lo subimos a otro hosting tenemos que asegurarnos de que disponga de HTTPS habilitado).

image

Le damos a Create y nos aparecerán los detalles una app que lamentablemente no será funcional porque todavía no hemos subido nada a Azure. Apuntamos estos detalles para más adelante.

image

Intercambio de cromos

Ahora nos toca retocar un poco nuestra solución en Visual Studio para pasar estos datos de la app manualmente a nuestros proyectos.

En el proyecto de SharePoint App (EdinSpMvc)

Primero vamos a cambiar el tipo del proyecto de app de SharePoint 2013 de Autohosted a Provider-hosted. No hay ninguna UI para hacerlo, pero afortunadamente editando el AppManifest.xml lo podemos conseguir. Sólo hay que:

  • Eliminar la sección AppPrerequisites
  • Reemplazar el elemento AutoDeployedWebApplication dentro de AppPrincipal por <RemoteWebApplication ClientId="508e1afa-40d8-4e2b-99dc-7604460cf864" />. Si habéis prestado atención, es el AppId que nos ha generado SharePoint para la app.
  • Sustituir la URL en el elemento StartPage por la URL completa del sitio, quedando así: https://edinspmvc-provider.azurewebsites.net/Home?{StandardTokens}

image

En el proyecto web MVC (EdinSpMvc4Web)

Aquí tenemos que añadir los valores reales de AppId y AppSecret dentro del fichero web.config (en los elementos ClientId y ClientSecret):

image

Ahora procederemos a subir el proyecto web a Azure. Para ello haremos botón derecho en el proyecto web, clicar Publish y en la pantalla que se nos abre elegir el fichero que previamente descargamos de Azure.

imageimage

Le damos a Publish y veremos que Visual Studio sube nuestra app a Azure y la abre. No os preocupéis que esté dando errores al abrirse, es normal porque le falta el contexto de app de SharePoint.

image

Aún nos queda un pequeño paso: meter el AppId y AppSecret otra vez en Azure ya que al subir la web se “pierde” el valor de los appSettings. Para ello hay que ir a la pantalla de gestión de Sitios Web de Azure y en el enlace Configuración de nuestro sitio añadir las dos entradas idénticas a las del web.config. ¡No os olvidéis de darle a Guardar en la botonera inferior!

image 

Pasos finales y el resultado

Ahora podemos hacer un Deploy de la solución desde Visual Studio 2012 y ocurrirá la magia, esta vez con un poco más de preparativos que la última vez.

imageimage

Como es habitual, os dejo el código de esta aplicación en mi cuenta de SkyDrive.

¡Hasta la próxima entrega!

Las apps de SharePoint 2013 (IV): Una app en MVC y en Azure

En la serie de posts sobre el desarrollo de apps de SharePoint 2013, hasta ahora hemos visto como se desarrolla una app sencilla y alojada en SharePoint (es decir, las “SharePoint-hosted” apps). Ahora vamos a subir un poco la dificultad (no mucho, os lo prometo) y vamos a hacer una app que se ejecuta fuera de SharePoint.

Para que el ejemplo sea más interesante, vamos a hacerlo en un “sabor” de ASP.NET al que no estamos tan acostumbrados los SharePointeros: ASP.NET MVC 4. Como la app fuera de SharePoint puede estar escrita en cualquier lenguaje que se nos antoje, usaremos MVC 4 para aprovecharnos de la librería de modelo de objetos de cliente de SharePoint 2013 (CSOM) y ahorrarnos trabajo.

SharePoint 2013 y Azure

En estos momentos Microsoft ofrece una cuenta de desarrollador de Office (incluyendo SharePoint) gratis si nos apuntamos en este enlace. Con ello se nos dará un sitio en Office 365 Preview (es decir la versión 2013) ya preparado para alojar apps de SharePoint 2013. Además, se nos dará una cuenta “invisible” en Azure para nuestras apps. Digo que es invisible porque no hay manera (de momento) de gestionar la suscripción para estas apps.

image

Para las apps que se consideran “Autohosted”, Visual Studio 2012 con las herramientas de SharePoint va a hacer una doble función:

  • Si estamos desarrollando y le damos a F5, VS2012 va a subir el descriptor de nuestra app a la cuenta de Office 365 de desarrollador (esto lo configuramos nosotros en el proyecto de app) pero la apuntará a nuestro localhost donde se ejecutará el proyecto web de ASP.NET que contiene la lógica de la app.
  • Si hacemos un Deploy de la solución, VS2012 subirá el descriptor de la app a Office 365 (como antes) pero además subirá el proyecto web a un subdominio de o365apps.net, que es una suscripción especial de Azure Web Sites disponible a nosotros como desarrolladores de la app. El subdominio será un GUID creado de manera automática al deployar la app. Además, va a cambiar el descriptor de la app para que apunte a Azure y no a nuestro localhost.

Vale la pena recalcar que la suscripción “invisible” de Azure para apps de Office/SharePoint sólo incluye Web Sites (un hosting de IIS, vamos) y SQL Azure (mediante scripts), sin incluir nada de Media Services, Mobile Services, Storage, Compute y otras maravillas de Azure.

La app en Azure y MVC, paso a paso

Para que todo esto resulte más fácil de digerir, vamos a hacer un pequeño ejemplo que muestre las listas y bibliotecas que hay en el SharePoint donde está alojada la app. Lo codificaremos en MVC 4 y lo “subiremos automágicamente” a Azure. El prerrequisito es, como siempre, tener instaladas las herramientas de desarrollo de SharePoint 2013 con Visual Studio 2012 y tener la suscripción de desarrollador de Office 365.

Abrimos Visual Studio 2012 como Administrador y creamos un proyecto nuevo de Aplicación de SharePoint 2013. Le decimos a VS2012 que la app es de tipo Autohosted y le pasamos la URL de nuestro Developer Site de Office 365.

imageimage

Visual Studio creará dos proyectos: el de la app (EdinSpMvc, poco más que un manifest) y el proyecto ASP.NET WebForms (EdinSpMvcWeb) con la parte de la app que se ejecuta fuera de SharePoint. Como podéis ver, contiene una página Default.aspx de toda la vida.

image

Como esta basura tecnología no nos interesa, vamos a agregar otro proyecto web, esta vez una aplicación web de MVC 4. Es importante seleccionar NET Framework 4 en vez de 4.5 que nos sale por defecto, ya que el Azure que nos da Office Developer no tiene todavía soporte para NET 4.5. A continuación, elegimos Basic como plantilla por defecto de la aplicación MVC.

imageimage

Ya tenemos 3 proyectos: el de la app, el de web ASP.NET y el de web MVC 4.

image

Vamos a configurar el proyecto web MVC con algunos detallitos para que funcione bien con SharePoint 2013. Tenemos la suerte de que las herramientas de VS2012 ya lo hacen automáticamente por nosotros.

Primero, vamos a las propiedades del proyecto de app de SharePoint para asociar el proyecto web MVC en la propiedad Web Project. En este momento VS2012 nos preguntará si queremos que nos adjunte las referencias de SharePoint y que quite la página por defecto, a lo de que vamos a contestar que sí.

imageimage

Fijaos que el proyecto MVC ahora tiene las referencias de SharePoint 2013 y de Identity Framework, así como el fichero auxiliar TokenHelper.cs que nos ayudará a hacer la autenticación contra SharePoint. Además, la propiedad SSL Enabled del proyecto MVC está puesta a True porque es necesario HTTPS para que funcione el paso de credenciales.

Por último, hay que corregir la Start URL de la app (que apunta ahora a EdinSpMvc4Web/Pages/Default.aspx) editando el fichero AppManifest.xml del proyecto de app de SharePoint. Ponemos EdinSpMvc4Web/Home para apuntar al controller Home.

image

Podemos eliminar el proyecto de ASP.NET WebForms, porque ya no lo necesitamos.

Ahora vamos a agregar la “chicha”, la lógica de negocio en nuestra aplicación MVC. Para ello crearemos un controller nuevo llamado HomeController y una vista asociada llamada Index en su carpeta ViewsHome.

imageimageimageimage

En la acción Index del HomeController, vamos a ponerle el siguiente código, sin olvidarnos de poner la clausula using Microsoft.SharePoint.Client:

var contextToken = TokenHelper.GetContextTokenFromRequest(System.Web.HttpContext.Current.Request);
var hostWeb = System.Web.HttpContext.Current.Request["SPHostUrl"];

using (var clientContext = TokenHelper.GetClientContextWithContextToken(hostWeb, contextToken, Request.Url.Authority))
{
    var web = clientContext.Web;

    clientContext.Load(web, w => w.Lists.Include(l => l.Title).Where(l => !l.Hidden));
    clientContext.ExecuteQuery();
    clientContext.Dispose();

    return View(web.Lists);
}

En este ejemplo lo que hacemos es obtener el token de contexto (proporcionado por SharePoint 2013 al redireccionar a la app en Azure) y con este token de contexto abrimos un contexto de cliente (lo que necesitamos para usar el modelo de objetos de cliente de SharePoint 2013). Fijaos que no estamos proporcionando ninguna credencial de cliente, sino que la propia app se autentica contra SharePoint.

Ahora nos falta hacer que la vista muestre las listas que le hemos pasado en la acción. Abrimos la vista y le añadimos:

@{
    ViewBag.Title = "App de SharePoint con MVC";
}

<div>
    <ul>
        @foreach (var list in Model)
        {
            <li>@list.Title</li>
        }
    </ul>
</div>

Con este código conseguimos que la vista muestra las listas que le pasa el controlador. Le damos a F5 y nuestra app se ejecuta en SharePoint 2013 pero apuntando a nuestro localhost:

image

Confirmamos que nuestra app es de confianza…y vemos la app ejecutándose en MVC (en nuestra máquina):

image

Para los curiosos: el VS2012 ha agregado un ClientId y ClientSecret a nuestro web.config automáticamente (y también los ha registrado en el servidor de SharePoint). De esta manera la llamada de nuestra aplicación MVC a SharePoint está autorizada porque se basa en un ID y secreto conocidos por SharePoint.

image

El último paso que nos queda es darle un poco de aspecto de SharePoint a la app, cambiando la “master” (la vista _layout.cshtml) para incluir la barra de herramientas de SharePoint 2013.

En la sección BODY añadiremos un DIV a modo de “placeholder” donde insertaremos la barra de herramientas.

<div id="barraSharePoint"></div>

En la sección HEAD, debajo de la referencia a @Scripts.Render("~/bundles/modernizr"), agregaremos el código siguiente:

<script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/4.0/1/MicrosoftAjax.js"></script>
<script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js"></script>     
    
<script type="text/javascript">
  var hostweburl;
  $(document).ready(function () {
      hostweburl = decodeURIComponent(getQueryStringParameter("SPHostUrl"));
      var scriptbase = hostweburl + "/_layouts/15/";
      $.getScript(scriptbase + "SP.UI.Controls.js", renderChrome)
  });
  function renderChrome() {
      var options = {
          "appIconUrl": "/Content/Images/user-logo.png",
          "appTitle": "@ViewBag.Title",
          "settingsLinks": [
              {
                  "linkUrl": "http://spblogedin.blogspot.com",
                  "displayName": "Blog de Edin"
              }
          ]
      };
      var nav = new SP.UI.Controls.Navigation("barraSharePoint", options);
      nav.setVisible(true);
  }
  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>

Lo que hace este código es obtener la URL del SharePoint (el parámetro SPHostUrl)  y llamar a su script SP.UI.Controls.js que se encarga de dibujar la UI. Lo llamamos desde SharePoint mediante una llamada a $.getScript (para evitar el problema de JS cross-domain) y en la función de callback pintamos una barra (un control SP.UI.Controls.Navigation). Para construir este control le pasamos un objeto JS con las propiedades que van a controlar la manera en la que se va a dibujar. He aprovechado también para agregar un pequeño logo para la aplicación, creando una carpeta Images dentro de Content en el proyecto MVC y subiendo el logo por defecto de una aplicación de LightSwitch.

Ahora ya estamos preparados para hacer un Deploy Solution en vez de un F5. Se nos vuelve a abrir una instancia del navegador pidiendo autorización para la app. La sorpresa es que esta vez nuestra aplicación de MVC está en el sitio web de Azure para Office Developers (dominio o365apps.net), como podéis observar:

image

Además, la aplicación ahora tiene una pinta más “SharePointera” y con un menú de control que tiene el enlace a este blog Winking smile

image

Os dejo el código fuente en mi SkyDrive, por si no tenéis ganas de escribir código, jeje.

En la próxima entrega de esta serie veremos como hacer una aplicación Provider-hosted en Azure, con lo que podemos aprovechar todos los servicios que nos ofrece Azure para construir nuestra app.

Evento “SharePoint 2013: Novedades y más allá”

Después de tantas semanas intentando cerrar un evento con un poco de consistencia para la comunidad de SharePoint en Catalunya, ya tenemos el primer evento importante para el día 29 de noviembre a las 9:00h.

sugcat

Gracias a nuestro sponsor exclusivo para el evento, AvePoint (www.avepoint.com), podemos organizar el evento en un espacio apropiado (Espai Pujades 350) y con un catering de coffee break para reponer fuerzas. Además, AvePoint sorteará un tablet Microsoft Surface entre los asistentes. ¡Menudo regalazo!

avepoint logo_hires

El temario

  • Introducción y presentación del SUG.CAT (Edin Kapic)
  • Novedades de SharePoint 2013
    • Vista general (David Martos/Ramon Torras)
    • Social (David Martos)
    • Cross-Site Publishing (Ramon Torras)
    • Demo SharePoint 2013 (David Martos)
  • Migración a SharePoint 2013: consideraciones y estrategias (Roberto Delgado)
  • Niveles de madurez de SharePoint (Edin Kapic)

El evento durará de 9:00h a 14:00h, con un coffee-break en medio.

La ubicación


Ver mapa más grande

¿Cómo apuntarse?

Fácil. Entra en https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032536875&Culture=es-ES&community=0 y apúntate para asistir al evento. El evento es gratuito.

SPC12: El último día

Hoy se ha acabado la SharePoint Conference 2012. Ha sido un día más corto, con sólo tres sesiones. Hoy también he tenido el honor de hablar con Joel Oleson (el SharePointero más famoso del mundo), como podéis ver en la foto.

 DSC_0170

Arquitectura de los sitios web en SharePoint 2013

La sesión fue presentada por Ethan Gur-esh de Microsoft, que se preocupó de despejar todas las dudas que tenían los asistentes. La sesión iba sobre los sitios alimentados por búsqueda (search-driven) que son la novedad más visible en gestión de contenido web para SharePoint.

Hay 3 arquetipos de páginas en SharePoint

  • Dinámica con una URL (home). La página muestra datos dinámicos pero sólo hay una página.
  • Dinámica con múltiples URL (categorías, detalles de producto…). Aquí la página tiene parámetros de query string para distinguir entre unos datos y otros. P.ej. Producto.aspx?ID=5.
  • Estática con una URL (faq). Este es el modelo clásico del 2010 y otros.

Hay una colección de sitios de la que se alimenta la búsqueda (la de contenido) y otra colección de sitios en la que se muestra el contenido (la de renderizado).

DSC_0160 DSC_0161 DSC_0162 DSC_0163

Navegación

La navegación con las URLs cortas va al almacén de términos (Term Store) para buscar la URL larga (la URL de la página). Esa página tiene una webpart de búsqueda de contenido. La webpart consulta el indice y monta el contenido en HTML, aunque no va directamente al contenido (imagenes o JS) sino que aplica URLs). Si la webpart es síncrona, se guarda toda la pagina en caché y se gana en velocidad.

La jerarquía de navegación debería llegar a nivel de categorías, no de productos, porque el último nivel de navegación ya se le crean las URLs “amigables”.

El resultado de la búsqueda de contenido usa caché anónima mara minimizar las llamadas al indice de contenido. Los resultados se procesan según las reglas de consulta y se pasan a la webpart que las renderiza. Ademas, se actualizan las analiticas y se usa esa informacion para mejorar los resultados automáticamente.

La indexación contínua puede hacer que el contenido aparezca en menos de dos minutos para mostrar los resultados refrescados. El factor limitante de la búsqueda es la indexacion completa, no la incremental o contínua.

La renderización de los resultados

Se pueden definir canales por disositivo para usar otras master y renderización condicional. Se han mejorado las herramientas para crear master apages pero msin muchos cambios tecnologicos. La webpart y refiners usan javascript y plantillas html.

Se puede empaquetar todo el diseño (masters, layouts etc) como wsp para exportar diseños entre entornos.

Las imagenes en l renderización se tienen que almacenar en otro stio y acceder por urls. Se pueden usar las "renditions" para renderizar las imagenes y videos ara cada canal o contexto (miniaturas, etc). Si usamos crosssite publishing, hay que llevarse las imagenes a la sitecoll donde se muestra el contenido.

Se pueden almacenar los binarios en CDN para agulizar los tiempos de respuesta en entronsa geodisttibuqidos. Hasta un 98% de las llamadas pueden ser servidas desde CDN.

“Trucar el mecanismo”

Nos puede interesar no usar el modelo de 1 colección de sitio de contenido con 1 colección de renderizado, en una serie de casos especícos.

Opción 1: Tener muchas colecciones de renderizado por una de contenido

  • Marcas separadas
  • Microsites (windows.com, microsoft.com)
  • Multiidioma con diferente dominio (fr, es, de…)

Opción 2: Muchas colecciones de contenido y pocas de renderizado

  • Cuando hay diferentes permisos para diferentes destinatarios
  • Cuando se usa el “Content deployment” de SharePoint

Content deployment

Ahora se recomienda sólo para desplegar las colecciones de sitios de contenido, no para distribuir hacia la parte pública como el 2007 (ahora se usan las webparts de resultados de búsqueda). Ya no se tiene que replicar todo. Por fin, sólo se replica el contenido, no las páginas maestras, los workflows, los tipos de contenido….y el proceso es mucho más fiable.

Política de customizaciones de SharePoint

Esta sesión no la pude acabar por tener que ausentarme durante la última parte. Fue presentada por Oleg Kofman y Jon Epstein, ambos de Microsoft.

DSC_0164

¿Qué es governance? Personas, procesos, tecnologia y politicas.

Hay que definir bien los SLA y los OLA (operating level agreement) en la empresa. Es buen momento de montar un Centro de Excelencia de SharePoint a nivel corporativo.

Ahora tenemos 3 grandes modos para hacer aplicaciones de SharePoint:

DSC_0166

El modelo de las soluciones sandbox esta deprecated y en la próxima version no estará.

PowerPivot en detalle

Esta fue una de las sesiones “espectaculares” visualmente, con una aplicación de BI que analizaba los tweets sobre la conferencia en tiempo real (XLTweet). Hecha con SharePoint y PowerPivot. Punto de partida ha sido la solución Analytics for Twitter y blog de Analysis Services.

DSC_0169

Tecnología usada: Office Apps, PowerPivot, Data feeds, timer jobs.

Desde PowerShell se puede conectar un libro de Excel en SharePoint a Analysis Services de SQL Server via el driver de ADOMD.NET. Se conecta con la API pública de Excel Services y Excel services se conecta via MSOLAP al modelo de datos del cubo de Analysis Services.

En esta versión los datos de los libros de Excel en Excel Services se pueden refrescar bajo petición o por código.

Para hacer la interfaz de usuario en Excel, se usan las funciones de cubo (Cube Functions).

SPC12: El tercer día

El tercer día de la SharePoint Conference en Las Vegas ha sido bastante ajetreado, para mí. He podido participar en el feedback que recoge el equipo de Visual Studio para mejorar las herramientas de desarrollo para SharePoint. No puedo desvelar más detalles por haber firmado la NDA, pero os puedo decir que los chicos del equipo de Visual Studio realmente son de lo más atento y se preocupan de como se usan sus herramientas en el mundo real (aparte de ser unos cerebritos).

La buena noticia del día en realidad son dos:

  • La licencia para sitios públicos en Internet YA NO EXISTE. Sí, la de los 40.000 €. Ahora, si tienes una licencia de servidor, ya tienes una licencia para sitio público (con usuarios anónimos). ¡Cuanto dinero nos vamos a ahorrar!
  • Las herramientas de desarrollo de SharePoint para Visual Studio ahora incluyen LIGHTSWITCH PARA SHAREPOINT. Con esto se puede crear fácilmente una capa CRUD para SharePoint, customizada para nuestras necesidades.

Hoy he hecho un poco de vida social y me he reunido con algunos MCTs de SharePoint y he podido discutir los problemas con los que nos encontramos los MCTs y los MCT Regional Leads en el día a día. También he estado con dos MVPs “vecinos”: uno de Sudáfrica (pero de origen bosnio) y otro de Croacia.

DSC_0152 DSC_0156

Actualización a SharePoint 2013 en detalle (Deep Dive)

Esta sesión, igual que la del lunes, fue presentada por Sean Livingston. Ha sido una sesión de nivel 400 (experto), con mucho detalle técnico.

Actualización diferida de site collections es la pieza más importante que han hecho para dar soporte a las actualizaciones en esta versión.

clip_image001
(Menudo diagrama…)

CompatibilityLevel es la nueva encarnación o sucesor espiritual de UIVersion del 2010. Tiene el valor de 14 o 15. Las web templates tienen CompatibiltyLevel. Las features tienen que ser la misma versión o menor que la site collection.

image DSC_0139 DSC_0140 DSC_0137

SP2013 tiene un conjunto de ficheros del 2010 y por tanto soporta "experiencias de 2010". El parámetro CompatibilityRange indica que versiones de plantillas se permiten de site collection.

Se ha puesto un sistema de colas para evitar la presión en el servidor al actualizar las site collections, para que no se hagan demasiadas actualizaciones en paralelo.

Curioso, acaban de comentar que el límite práctico de tamaño de un backup/restore de una site collection es de unos 85 GB.

 

Gestión documental y colaboración con SharePoint, Office, Yammer y Dynamics CRM

La otra sesión del día a la que asistí fue la de Reuben Krippner (del equipo de MS Dynamics CRM). Habló sobre como enlazar CRM, SharePoint, Office y Yammer para dar una solución de gestión documental.

La colaboración es imprescindible en marketing, ventas y procesos de servicios.

DSC_0141 DSC_0142 DSC_0145 DSC_0148  DSC_0146 DSC_0143

Las opciones de gestión documental en CRM son:

  • Adjuntos en CRM
  • Bibliotecas de SharePoint a las que accede CRM
  • Documentos en Yammer (en diciembre)

Se está preparando un nuevo cliente CRM para Windows 8, con una UI mucho más cuidada y limpia.

DSC_0149

Renderizado en el cliente

La última sesión del día (antes de ir a hablar con el equipo de Visual Studio) ha sido la del nuevo sistema de renderizado de listas en JS.

Minimal Download Strategy (MDS)

El nuevo sistema de navegación Minimal Download Strategy añade el parámetro AjaxDelta=1 a la petición y se trae sólo lo que necesita y no toda la página. En el request hay un parámetro deltaBoundary que indica los datos que se van a actualizar en la página. El MDS va a una página start.aspx que es la que procesa la petición y renderiza la página. En la URL se le pasa un parámetro marcado con # para que la página sepa que contenido procesar.

MDS es opcional y se puede desactivar. Por defecto está activado.

Client Side Rendering

Si hay una cosa que en Microsoft han aprendido, es que XLST no es fácil para los programadores. Para ello han creado un mecanismo sucesor del XsltLink del SharePoint 2010: JSLink.

El parámetro JSLink de una webpart de vista de lista permite cambiar la plantilla con la que se renderiza la lista. Lo que hace es invocar otra función JS que haga el renderizado. Esa función JavaScript coge el CurrentItem del contexto que se le pasa y pinta el DOM correspondiente, según lo decida el programador.

El parámetro JSLink se puede poner por cada campo, o por tipo de contenido. Permite controlar el renderizado hasta un detalle muy concreto y sin ningún código de servidor.

La nueva API REST (_api) permite hacer consultas más avanzadas que la REST de SP2010.

Se han visto dos trucos en la sesión. El primero es que poner "debugger;" en nuestro código JS dispara el Visual Studio en la máquina para facilitar el debug. El otro es que ahora hay un comando PowerShell para asociar SharePoint con una cuenta Bing Maps (Set-SPBingMapsKey) y así poder utilizar los campos geolocalizados que trae la nueva versión de SharePoint.

DSC_0153