Junto a las ya conocidas Soluciones de Granja (Farm Solutions) y Soluciones Sandboxed (Sandboxed Solutions), en SharePoint 2013 tenemos disponible un nuevo modelo de desarrollo de aplicaciones para SharePoint: podemos desarrollar Apps.
Las Apps son desarrollos que pueden publicarse en el Market de Microsoft (Office Store), de tal modo que a través de dicho Market, los usuarios puedan descargarse nuestra Aplicación para hacerla disponible y desplegarla en sus Sites, de una forma muy sencilla.
Al acceder a una App publicada en un Site de SharePoint 2013, si comprobamos la URL utilizada por dicha App, podremos observar que se trata de una URL distinta a la URL del Site. Por ejemplo, si nuestro Site es http://intranet.guillesql.local, nuestra App podría estar hospedada bajo http://prefix-apphash.apps.guillesql.local (es decir, utilizando un subdominio DNS) o quizás podría estar hospedada bajo http://prefix-apphash.guilleapps.local (es decir, bajo un dominio completamente distinto). En cualquiera de los casos, nuestra App estará hospedada bajo un dominio distinto al del Site (sea un subdominio o un dominio completamente distinto), para lo que suele utilizarse Nombres DNS Wildcard.
Debemos tener en cuenta los siguientes detalles cara a elegir qué dominio deseamos utilizar para hospedar nuestras Apps:
- Utilizar un dominio completamente distinto al utilizando por SharePoint, en lugar de utilizar un subdominio. Se trata de una recomendación de seguridad, ya que al compartir el mismo dominio raíz, un código malicioso que se ejecute en la App o en el propio Site, podría acceder a las Cookies de cualquier Sitio Web o Aplicación existente bajo el mismo dominio, para leerlas o incluso modificarlas. Esto sumado al Cross-Site Scripting (XSS), hace que sea más recomendable la utilización de un dominio completamente diferente.
- Es recomendable que el dominio que hospede nuestras Apps pertenezca a la zona Internet o Sitios Restringidos de Internet Explorer. Igualmente, es por motivos de seguridad, para garantizar un mayor aislamiento de nuestras Apps.
Descripción del escenario
Partimos de un entorno de desarrollo de SharePoint 2013 formado por un único servidor ejecutando Windows Server 2012 RTM, SQL Server 2012 RTM, Visual Studio 2012 RTM (incluyendo las Microsoft Office Developer Tools for Visual Studio 2012) y SharePoint 2013 RTM. Este servidor es miembro de un dominio Windows Server 2003 R2 SP2 (guillesql.local).
A nivel de SharePoint 2013, se ha realizado una configuración muy básica, creando una única Aplicación Web en el puerto 80 (con un único Site en su raíz) y configurando varios Servicios como el Secure Store Service.
A nivel de IIS, el Site de SharePoint que da servicio a nuestra Aplicación Web en el puerto 80, no está utilizando Host Headers. Este detalle es importante, ya que si dicho Site está configurado sólo para ser accedido utilizando Host Headers, cuando intentemos ejecutar una App de SharePoint 2013 nos encontraremos con un mensaje de error como el siguiente: Not Found. HTTP Error 404. The requested resource is not found.
Por ello, en caso de tener múltiples Aplicaciones Web, si deseamos poder utilizar las Apps en todas ellas, una recomendación podría ser utilizar diferentes direcciones IP (una para cada Aplicación Web), de tal modo que cada Sitio Web de IIS pueda ser configurado para responder sólo a la dirección IP que le corresponde, evitando así la utilización de Host Headers.
Configuración de SharePoint 2013 para soportar las Apps
A continuación vamos a realizar las configuraciones necesarias para soportar el nuevo modelo de Apps en una Granja de SharePoint 2013 utilizada como entornos de pruebas y desarrollo. Básicamente deberemos realizar los siguientes pasos:
- Realizar la configuración DNS necesaria, que básicamente se reducirá a la creación de un nombre o alias WildCard.
- Arrancar los servicios App Management Service y Microsoft SharePoint Foundation Subscription Settings Service en SharePoint, por ejemplo desde la pantalla Services on Server de la Central Administration.
- Configurar el Subscription Settings service application desde PowerShell (solo puede realizarse desde PowerShell), si no estaba realizado ya de antes.
- Configurar el App Management Service Application (desde PowerShell o desde la Central Admin), si no estaba realizado ya de antes.
- Configurar las URLs de las Apps (nombre de dominio y prefijo).
- Configurar el App Catalog para nuestra Aplicación Web.
Lo primero que deberemos realizar es configurar un Nombre DNS Wildcard (Wildcard DNS Name). En nuestro caso de ejemplo, nuestra Granja de SharePoint responde a los nombres http://vmoss2013.guillesql.local y http://vmoss2013, por lo que crearemos un Nombre DNS Wildcard para *.guilleapps.local, tal y como se describe en el artículo Wildcard DNS Domain Names.
Comprobaremos que los siguientes servicios de Windows están arrancados, y en caso de estar parados los arrancaremos, para lo cual podemos utilizar la herramienta administrativa Services (es puro protocolo, ya que muy probablemente estarán arrancados, como estaba en mi caso de ejemplo):
- SharePoint Administration (spadmin).
- SharePoint Timer (sptimer).
Realizado esto, en la Central Administration, seleccionaremos la opción Manage Services on Server de la sección System Settings. Seguidamente, en la pantalla Services on Server, comprobaremos que están arrancados los siguientes servicios, y en caso de estar parados los arrancaremos:
- App Management Service
- Microsoft SharePoint Foundation Subscription Settings Service
Si no lo hemos realizado antes, deberemos configurar el Subscription Settings service application, lo cual sólo puede realizarse desde PowerShell. En mi caso de ejemplo ejecuté las siguientes líneas de PowerShell desde la SharePoint 2013 Management Shell.
$account = Get-SPManagedAccount "GUILLESQL\MOSSSvc"
$appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account
$appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName SettingsService_DB
$proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc |
Si no lo hemos realizado antes, deberemos configurar el App Management service application, lo cual puede realizarse tanto desde la Central Administration como desde PowerShell. En mi caso de ejemplo ejecuté las siguientes líneas de PowerShell desde la SharePoint 2013 Management Shell.
$account = Get-SPManagedAccount "GUILLESQL\MOSSSvc"
$appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account
$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName AppService_DB
$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc |
Ahora deberemos configurar el patrón de URL que deseamos que utilicen las Apps en nuestra Granja, y además deberemos crear el App Catalog. Vamos a realizar estas configuraciones desde la Central Administration, para lo cual, utilizaremos la opción Apps del menú lateral izquierdo. Seguidamente, seleccionaremos la opción Configure App URLs.
En la pantalla Configure App URLs deberemos especificar el nombre DNS que deseamos utilizar para nuestras Apps (ej: guillesapps.local), así como un prefijo (apps). Click OK para continuar.
Seguidamente, en el menú Apps de la Central Administration, seleccionaremos la opción Manage App Catalog. En la pantalla Manage App Catalog, seleccionaremos la Aplicación Web para la que deseamos configurar el App Catalag, seguidamente seleccionaremos la opción Create a new app catalog site, y click en OK.
En la pantalla Create App Catalog, especificaremos los datos necesarios para su creación, en función de nuestras necesidades y requisitos. Una configuración típica en entornos de desarrollo, es especificar Everyone en la opción End Users.
Tras unos instantes, el App Catalog habrá sido creado con éxito.
Si lo deseamos, seguidamente en el menú Apps de la Central Administration, seleccionaremos la opción Configure Store Settings. En la pantalla SharePoint Store Setting, tenemos disponibles algunas opciones de configuración.
Realizado todo esto, habremos finalizado una configuración básica para soportar el nuevo modelo de Apps en nuestra Granja de SharePoint On-Premise.
Despedida y Cierre
Hasta aquí llega el presente artículo. Ahora tenemos varias tareas por las que podemos continuar (aunque quedan fuera del alcance del presente artículo), como por ejemplo crear un Sitio de Desarrollador, subir Apps a nuestro Catálogo, etc.
Antes de finalizar quería aprovechar para incluir varios enlaces de interés, para quienes deseen ampliar información:
Poco más por hoy. Como siempre, confío que la lectura resulte de interés.
