Desarrollo de Apps en Sharepoint 2013 (III) – APIs de Desarrollo

Una de las novedades más llamativas de Sharepoint 2013 es la capacidad de integración con distintos clientes que tiene. Para ello Microsoft ha preparado un conjunto de APIs para los distintos clientes. Así pues antes de ponernos a desarrollar, es conveniente entender bien sobre que clientes podemos desarrollar nuestras Apps y culés son las APIs que Micrososft pone a nuestra disposición para dichos desarrollos.

El siguiente mapa nos muestra una visión general de las distintas APIs de Sharepoint 2013 disponibles así como su integración con los distintos clientes.

Como podemos ver en el mapa se han  puesto a nuestra disposición 6 APIs distintas cada una de ellas orientadas a un tipo de Aplicaciones o clientes distintos.

SERVER OBJECT MODEL (Server OM APIs)

Desde este modelo de Objetos tenemos acceso a todas las características de Sharepoint Server 2013 o Sharepoint Fundation 2013. Dado el grado de accesibilidad de esta API, es necesario que las Apps que hagan uso de esta API se ejecuten  sobre un servidor de la Granja de Sharepoint.

Tal y como podemos observar en el Mapa esta API será usada por Apps del tipo “Web Part”, “Power Shaell script” y “Timer Jobs”.

CLIENT OBJECT MODEL (.NET client OM APIs)

Esta API está pensada para ser usada en el desarrollo de Aplicaciones .NET externas a Sharepoint y que se ejecuten en cualquier cliente diferente de Windows Phone (que ya tiene su propia API), tales como Windows Azure, Windows Server, Servidores de Aplicaciones o Aplicaciones de Escritorio.

Para el desarrollo de estas aplicaciones es necesaria la previa instalación del siguiente SDK

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

En esta página encontraremos algunos ejemplos básicos con los que familiarizarnos con el uso de esta API.

http://msdn.microsoft.com/en-us/library/fp179912

SILVERLIGHT OBJECT MODEL (Silverlight client OM APIs)

Como habréis deducido, este modelo de objetos está destinado al desarrollo de aplicaciones Silverlight independientemente de donde vayan a ejecutarse estas mismas. Esta API proporciona exactamente las mismas funcionalidades del API Client Object Model, con la particularidad que las llamadas a servidor se realizan de forma  asíncrona.

Es importante tener en cuenta que Sharepoint 2013 permite integrar Apps en Silverlight alojadas en el propio Sharepoint (recordar los tipos de alojamientos de Sharepoint Apps) agregando el fichero .xap en una librería.

MOBILE OBJECT MODEL (Mobile Silverlight APIs)

Efectivamente este modelo de objetos será el que usaremos en aquellas Apps para dispositivos en Windows Phone. Este API nos proporcionará la mayoría de las funcionalidades provistas por Client OM API además de lagunas más orientadas dispositivos móviles, como pueden ser registro de notificaciones.

JAVASCRIPT OBJECT MODEL (JavaScript API)

Esta API se ha preparado para poder ser usada desde aplicaciones clientes en Javascript. Las funcionalidades disponibles en esta API son las mismas que las que proporcionan Client OM Api y Silverlight OM API.

Desde la siguiente página podremos encontrar un conjunto de ejemplos de uso de dicha API

http://msdn.microsoft.com/en-us/library/jj163201

REST / ODATA ENDPOINT (REST / OData endpoints)

Una gran novedad en esta nueva versión de Sharepoint 2013 es el servicio REST que haciendo uso del estándar OData permite la comunicación entre diversos clientes o el Server OM por medio de llamadas HTTP RESTful.

En el siguiente enlace podéis ver una explicación más detallada de esta comunicación cliente /servidor por medio de llamadas REST

http://msdn.microsoft.com/en-us/library/fp142385

En este otro enlace encontrareis algunos ejemplos:

http://msdn.microsoft.com/en-us/library/jj164022

WCF DATA SERVICE FRAMEWORK

Si en la versión anterior de Sharepoint podíamos consultar información realizando llamadas WCF por medio del servicio listdat.svc, en esta versión se mantiene la posibilidad de continuar realizando estas consultas, además de las ya mencionadas consultas REST que podemos realizar desde los clientes a través de client.svc.

Bueno, hasta aquí un pequeño repaso de las diferentes APIs de desarrollo que Sharepoint 2013 nos provee.

Saludos.-

Desarrollo de Apps en Sharepoint 2013 (II) – Sharepoint Cloud App Model

En el post anterior vimos como configurar nuestro Visual Studio 2012 para desarrollar Apps y nuestro Sharepoint para alojar las Apps desarrolladas.

Pero antes de ponernos a desarrollar lo mejor será entender un poco mejor que es una App de Sharepoint, que tipos de Apps podemos desarrollas.

Básicamente una App de Sharepoint no es más que una Aplicación Web normal y corriente ejecutada en un iframe dentro del SharePoint.

Para la creación de esta App podemos utilizar cualquiera de los lenguajes que normalmente utilizaríamos, tales como HTML, Javascript, PHP o .NET, pudiendo elegir para su creación cualquier herramienta de desarrollo, incluido Visual Studio 2012 o “NAPA”, la nueva herramienta de desarrollo de Office 365.

Una de las principales ventajas que se nos plantean al desarrollar estas Apps, reside en el hecho de que podemos dividir el desarrollo por capas y dividir el desarrollo en diferentes componentes, pudiendo así separar la capa de presentación del resto de componentes.

Estas Apps pueden comunicarse con cualquier Webservice, ya sea público o privado. Además de comunicarse Sharepoint haciendo uso de REST y de Cliemt Api de Sharepoint.

A la hora de desarrollar Apps se nos permiten diferentes opciones de Hosting de nuestras Apps.

En el denominado “Cloud App Model” se han definido tres tipos diferentes de Hosting de Apps, cada uno de ellos con sus propias características. Es muy importante entenderlos bien ya que antes de empezar a desarrollar una App debemos tener muy claro dónde va a estar hospedada.

El siguiente esquema defino los diferentes tipos de Hosting, así como sus características:

Vamos a ver un poco por encima cada uno de los tipos de Hosting y sus características

Provider-hosted

Las Apps se hospedan en un servidor dedicado por el proveedor o el desarrollador, siendo este el encargado del mantenimiento de la infraestructura necesaria para el correcto funcionamiento de la Apps.

Este tipo de Hospedaje otorga más flexibilidad al desarrollador, pero requiere un mayor grado de responsabilidad, sobre todo a la hora de tratar con datos cliente, etc.

El desarrollador es el responsable del aislamiento del tenant.

Este tipo de apps puede comunicarse con Sharepoint haciendo uso de REST y OAuth o Client Object Model, pudiendo usar elementos del Sitio tales como listas, ficheros, webparts, etc.

Autohosted

Las Apps se alojan en Azure, ya sea Windows Azure o SQL Azure, siendo el hospedaje totalmente invisible para el desarrollador.

Este tipo de apps puede comunicarse con Sharepoint haciendo uso de REST y OAuth o Client Object Model, pudiendo usar elementos del Sitio tales como listas, ficheros, webparts, etc.

Sharepoint-Hosted

Las Apps se hospedan en el mismo Sharepoint.

Estas Apps pueden usar directamente elementos del Sharepoint, tales como listas, archivos, webparts, etc.

Pueden usar HTML y Javascript.

Es importante destacar que podemos mezclar y combinar el uso de componentes hospedados en nuestro Sharepoint con el de componentes alojados en Azure.

Una App se crea viene a ser una pequeña aplicación, fácil de usar que bien a cubrir una necesidad del usuario.

En base a esta definición todo en Sharepoint pasa a ser una App.

Así pues una App en esencia se ejecuta en un “iframe” el cual esta incrustado en una página de Sharepoint.

Sharepoint nos provee de una serie de Interfaces de las que extender nuestra App, las cuales definirán como se mostrará nuestra App dentro de la página de Sharepoint.

Immersive Full Page: La App se ejecuta en pantalla completa ocupando la totalidad de la pantalla del Navegador.

Part App: La App se muestra ocupando únicamente un trozo de la página (como WebPart), pudiendo interactuar con el resto de elementos de la misma.

UI Custom Actions: La usaremos para Menús Contextuales, Botones de la Ribbon o aplicaciones tipo Extensión.

Resumen de características de las Apps de Sharepoint 2013:

• Las Apps de Sharepoint 2013 no tienen por qué vivir en Sharepoint.
• La comunicación entre App y Sharepoint se realiza mediante REST / CSOM, _api.
• Las Apps se adquieren mediante Marketplace, ya sea este público o privado.
• La autenticación pasa a ser OAuth

Con esto concluye este pequeño análisis de las características de las Apps de Sharepoint 2013, necesario de cara a elegir la opción que más se ajuste a nuestras necesidades antes de que iniciemos el desarrollo.

Espero que os sea útil. 

Desarrollo de Apps en Sharepoint 2013 (I) – Preparando el entorno

Como recientemente me he tenido que iniciar en el mundo de Sharepoint 2013 he decidido crear una serie de post donde tratare de plasmar el resultado de mis conclusiones y experiencias en el desarrollo de Apps para Sharepoint 2013

Antes de ponernos a escribir código como locos es muy importante disponer de un entorno que cumpla con los requisitos necesarios para poder desarrollar dichas Apps

Visual Studio 2012

El desarrollo lo realizaremos con Visual Studio 2012, así que será necesario que aquellos que no lo tenga instalado lo descarguen y lo instalen.

Para poder empezar a desarrollar necesitamos que tener instalados los siguientes paquetes de Visual Studio 2012:

Microsoft Office Developer Tools for Visual Studio 2012 RC – Preview

SharePoint Server 2013 Client Components SDK

Para instalar el primero deberemos hacerlo a través de “Microsoft Web Platform Installer 4.0”.

El que no lo tenga instalado que lo descargue desde esta URL:

http://www.microsoft.com/web/downloads/platform.aspx

Abrimos Web Installer y buscamos “Office”

Una vez haya finalizado la búsqueda nos aparecerá en el resultado. Pulsamos el botón “Agregar” y finalmente “Instalar”, con lo que empezará el proceso de descarga e instalación de Microsoft Office Developer Tools para Visual Studio 2012.

Pasados unos minutos finalizará la instalación, la cual tendría que haber ido correctamente.

En caso de que no fuese bien y se quejase de la falta de algún otro paquete, lo buscaremos, lo instalaremos y volveremos a tratar de Instalar Microsoft Office Developer Tools como hemos hecho antes.

El siguiente paso es instalar “Sharepoint Server 2013 Client Components SDK”.

Accedemos a la URL de descarga:

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

Descargamos e instalamos…no hay más secreto.

Ahora ya deberíamos tener Visual Studio listo para desarrollar Apps de Sharepoint.

Comprobémoslo.

Abrimos Visual Studio 2012 à File à New à Project

Como podemos ver, ya nos aparecen los tipos de proyectos de Sharepoint 2013.

Pero no corramos ya que aún no podemos empezar a desarrollar.

Antes debemos configurar Sharepoint para poder alojar las Apps que desarrollemos. Si intentamos desplegar Apps en Sharepoint sin que este esté correctamente configurado, dichas Apps no solo no funcionaran sino que tendremos problemas para desinstalarlas de Sharepoint.

Configurando Sharepoint 2013

Lo primero que vamos a necesitar es un Site Collection en el que desplegar las Apps que desarrollemos.

Sharepoint 2013 ya nos provee una plantilla para tal efecto (“Developr Site”), la cual permitirá crear sites en los que instalar y testear de las Apps que desarrollemos.

Así pues desde la Administración Central de Sharepoint pulsamos sobre el enlace “Create Site Collection” donde podremos proceder a crear nuestro site de desarrollo.

Completamos el formulario asignándole un título y una descripción a nuestro Site.

En el campo “URL” le asignaremos el nombre del site en la url.

Finalmente seleccionaremos la plantilla de creación del Site. Para ello seleccionaremos la plantilla “Developer Site” de las de la versión “2013” de Sharepoint.

Solo nos quedará asignar el usuario administrador.

Pulsamos OK y ya tendremos el Site donde desplegar las Apps que desarrollaremos.

Esto no acaba aquí….aún nos quedan más pasos por hacer.

Ahora necesitaremos crear nuestro Dominio Aislado de Aplicaciones (Isolated App Domain)

Para ello vamos a necesitar arrancar la Consola de Administración de Sharepoint 2013 como Administrador a través de la cual procederemos a lanzar los comandos de creación y configuración de nuestro dominio aislado.

Lo primero que necesitamos hacer es asegurarnos que los servicios “spadmin” y sptimer” están arrancado ejecutando los siguientes comandos en la consola:

net start spadminv4 net start sptimerv4

Una vez comprobados que disco servicios están arrancados procedemos a crear el dominio aislado.

Este dominio debe formar parte del dominio principal de nuestro sharepoint, así pues si nuestro sharepoint está bajo el dominio “sp2013” el dominio que crearemos podríamos llamarle “apps.sp2013” (aunque podéis cambiar el “apps” por la palabra que creáis más conveniente).

Lanzamos el siguiente comando para la creación del dominio:

Set-SPAppDomain "apps.sp2013"

Antes de continuar deberemos arrancar los servicios SPSubscriptionSettingsService y AppManagementServiceInstance. Para ello ejecutamos el siguiente comando:

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

Verificaremos que los servicios SPSubscriptionSettingsService y AppManagementServiceInstance arrancados y  “online” lanzando el siguiente comando:

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

Ahora deberemos especificar la cuenta bajo la cual van a funcionar los servicios SPSubscriptionSettingsService y AppManagementServiceInstance arrancados. Esta cuenta deberá ser “SPManagedAccount”. Si lo deseamos podemos o bien usar una cuenta existente o bien crear una nueva. Para crear dicha cuenta usaremos el siguiente comando:

$account = New-SPManagedAccount

Ahora procederemos a especificar la cuenta, el pool de aplicación y la base de datos para los servicios SPSubscriptionService y AppManagementServiceInstance. Para ello ejecutaremos el siguiente código desde la consola, poniendo especial atención en especificar correctamente la cuenta de usuario en la primera línea:

$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

Ahora debemos especificar el “Tenant” de las aplicaciones.  Pero que es el “tenant”?

Cuando accedamos a una de las aplicaciones que instalamos la URL que nos generará será algo parecido a esta:

http://app-ee81e064c3ed97.apps.sp2013b/sites/appsdevsite/SharePointAppMAT/Pages/Default.aspx?SPHostUrl=http%3A%2F%2Fsp2013b%2Fsites%2Fappsdevsite&SPLanguage=en%2DUS&SPAppWebUrl=http%3A%2F%2Fapp%2Dee81e064c3ed97%2Eapps%2Esp2013b%2Fsites%2Fappsdevsite%2FSharePointAppMAT

Básicamente el formato de la URL se compone de las siguientes partes:

http://[tenant]-[AplicationID].[Dominio]/sites/[DeveloperSite]/[AppName]/[URL_Pagina]

Para especificar el “tenant” de la aplicación ejecutaremos el siguiente comando sustituyendo “[tenant]” por el nombre que deseamos especificar (yo he usado “app”):

Set-SPAppSiteSubscriptionName -Name "app" -Confirm:$false

Ya casi hemos acabado, solo nos queda añadir el dominio  a la lista de “bypass” de Internet Explorer. Esto nos asegurará que podemos navegar por nuestra aplicación una vez desplegada en Sharepoint.

Intenet Explorer à Tools à Internet Options

Pestaña “Connections” à LAN Settings

Desmarcamos “Automatic detect settings” y marcamos “Use proxy server for your LAN”.

Pulsamos “Advanced”.

En “Excaptions” agregamos “*.” + el dominio de sharepoint (en mi caso “*.sp2013”).

Aceptamos todo y ya estaremos listos para desarrollar y desplegar Apps en nuestro Sharepoint.

Ahora si….ya podemos empezar a desarrollar……Suerte.