SharePoint 2013: Como generar el App Id y App Secret para una aplicación “Provider-Hosted” (I)!

El otro día os comentaba en este post las opciones que tenemos para registrar aplicaciones de tipo Autohosted y Provider-Hosted. En este primer artículo de la serie os voy a detallar como registrar una aplicación “Provider-Hosted” tanto para una instalación On-Premise de SharePoint 2013 como para un tenant de Office 365:

  • Accedemos a la siguiente página de aplicación para una cierta colección de sitios:/_layouts/15/appregnew.aspx
  • En esta página, tendremos que especificar una serie de datos obligatorios como el dominio de la aplicación y el título de la misma. Además, procederemos a generar tanto el Id. de aplicación como el Secreto de aplicación.
  • Tras pulsar “Crear”, ya tendremos la información de registro para poder utilizarla en la aplicación.
image image

Visual Studio 2012: Como resolver el problema en la creación de proyectos de base de datos que introduce SQL Server 2012 SP1!

Si cuando intentáis crear un proyecto de base de datos en Visual Studio 2012 obtienes un error de incompatibilidad relativo a problemas de incompatibilidad con la versión de SQL Server 2012, es muy probable que sea debido a un problema qué introduce en las mismas la instalación del SP1 de SQL Server 2012. Para solucionarlo, os cuento los pasos que seguí:

image image image
    • Tras instalar la versión correcta de las Data Tools, podréis comprobar que se pueden crear proyectos de bases de datos en Visual Studio 2012.

image

SharePoint: Como bloquear el acceso a ciertos servicios web!

Cómo sabéis, SharePoint dispone de una fachada de servicios web pensada para permitir interactuar de forma remota con elementos y servicios de la plataforma. Aunque el acceso a dichos servicios dispone de los mismos mecanismos de seguridad que el acceso a través del navegador, en ocasiones puede ser que se nos pida como requerimiento, sobre todo para sitios Internet, qué se quiere vetar todo acceso anónimo a dichos servicios. ¿Qué posibilidades tenemos para conseguirlo? Pues por suerte varias como las que siguen:

Estas son las opciones que se me han ocurrido a bote pronto y seguro que hay alguna más :-).

SharePoint Online: ¿Cómo quito aplicaciones qué he agregado en mi tenant?

Si se ha agregado una aplicación del Office Store en una colección de sitios del tenant de Office 365, esta aplicación podrá ser agregada en cualquier otra colección de sitios del tenant. Si queremos que una cierta aplicación, una vez quitada de todas las colecciones, no se pueda agregar más tendremos qué realizar los siguientes pasos en la Administración de SharePoint Online en Office 365:

  • Acceder a la sección Aplicaciones y hacer clic sobre “Administrar aplicaciones”.
  • A continuación se muestra el listado de aplicaciones disponibles. Pulsamos sobre la aplicación que queremos quitar.
  • En la página de detalle de la aplicación, simplemente desplegamos las opciones disponibles en ACCIONES y pulsamos sobre “Quitar esta licencia” de manera que automáticamente la aplicación deja de estar disponible para agregar en las Colecciones de Sitios de SharePoint Online en Office 365.
image image image

Office 2013: ¿Cómo funciona una App de contenido cuando comparto mi documento Excel?

A punto de comenzar el Office & SharePoint App Challenge, me preguntaban los compañeros del CIP esta tarde qué pasa si yo comparto un documento Excel en el qué estoy utilizando una aplicación con otra persona…lo primero qué pensé es qué, independientemente de si la aplicación se “comparte” o no entre usuarios es claro que si el destinatario no ha iniciado como mínimo sesión con un LiveID, no va a poder usar esta aplicación. De echo, esto es lo que sucede y aquí va la prueba del algodón:

  • Supongamos que tenemos un documento Excel con datos que estoy visualizando en un par de aplicaciones de tipo contenido como la de Bubles y la de Heap Map.
  • Si este Excel lo compartimos con otro usuario, veremos que las aplicaciones no están operativas y qué para poder utilizarlas es necesario iniciar sesión con un Live ID en la tienda de Office.
  • Hacemos por lo tanto un inicio de sesión con un Live Id diferente al utilizado para abrir el documento Excel con las aplicaciones operativas.
image image image
  • Una vez iniciada sesión, el estado de la aplicación sigue siendo que no se puede iniciar. Pero ahora, el mensaje cambia y se muestra un panel informativo, que tras pulsar “Iniciar”, nos permite utilizar la aplicación.
  • Este proceso tendremos que repetirlo por cada aplicación disponible en el documento.
  • Además, si agregamos una aplicación nueva al documento Excel podremos comprobar como se interpreta qué las aplicaciones ya existentes en el mismo entran a formar parte del conjunto de aplicaciones de Office qué el usuario puede agregar independientemente de qué en origen fuese otro usuario quién las añadió
image image image
Por lo tanto, la moraleja es qué podremos tener una experiencia completa de uso del documento con las aplicaciones siempre y cuando iniciemos sesión con un LiveID. Esto lo he comprobado para aplicaciones gratuitas. La prueba para aplicaciones de pago lo dejo para otro post 😉

SharePoint 2013: Políticas de validación de aplicaciones enviadas al Office Store!

Una duda qué tendrá todo aquel que quiera publicar aplicaciones para Office y SharePoint en el Office Store es la relativa a aquellos aspectos que Microsoft va a tener en cuenta a la hora de validar si una aplicación está lista para publicar o no. Para conocer estos aspectos, o más bien políticas de validación, os recomiendo revisar los siguientes enlaces:

image

SharePoint 2013: Novedades en manejadores de eventos (II)!

Como continuación del post qué escribí hace tiempo en relación a las novedades en manejadores de eventos para SharePoint 2013, en este nuevo artículo quería explicar como quedaría el trabajo con dichos manejadores tanto para SharePoint 2013 RTM como para SharePoint Online en Office 365. Al lío pues:

using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Net;
  • A continuación, procederemos a codificar los dos métodos del servicio qué nos permiten responder a eventos de naturaleza síncrona (ing) y asíncrona(ed). Para los eventos síncronos, tenemos que codificar el método ProcessEvent siguiendo por ejemplo el primer post de la serie.
  • En cambio, para los eventos asíncronos tendremos que codificar el método ProcessOneWayEvent de acuerdo al siguiente fragmento de código:
            HttpRequestMessageProperty requestProperty =
                (HttpRequestMessageProperty)OperationContext.Current.IncomingMessageProperties[HttpRequestMessageProperty.Name];
            string contextTokenString = 
                requestProperty.Headers["X-SP-ContextToken"];
 
            // If there is a valid token, continue. 
            if (contextTokenString != null)
            {
                SharePointContextToken contextToken =
                    TokenHelper.ReadAndValidateContextToken(
                        contextTokenString, requestProperty.Headers[HttpRequestHeader.Host]);
                Uri sharepointUrl =
                new Uri(properties.ItemEventProperties.WebUrl);
                string accessToken =
                TokenHelper.GetAccessToken(contextToken, sharepointUrl.Authority).AccessToken;
                using (ClientContext ctx = 
                    TokenHelper.GetClientContextWithAccessToken(sharepointUrl.ToString(), accessToken))
                {
                    if (properties.EventType == SPRemoteEventType.ItemAdded)
                    {
                        List lList =
                            ctx.Web.Lists.GetByTitle(
                                properties.ItemEventProperties.ListTitle);
                        ctx.Load(lList);
                        ListItem liItem =
                            lList.GetItemById(
                                properties.ItemEventProperties.ListItemId);
                        ctx.Load(liItem);
                        ctx.ExecuteQuery();
                        liItem["Title"] +=
                            " - Elemento Añadido";
 
                        liItem.Update();
                        ctx.ExecuteQuery();
                    }
                }
            }
  • Cómo veis, frente al primer artículo de la serie basado en la versión Preview de SharePoint 2013, en este caso hacemos uso de la clase TokenHelper proporcionada al crear el proyecto de aplicación qué nos da las clases y métodos necesarios para poder interactuar de vuelta con SharePoint mediante OAuth dado qué en este caso estamos actualizando información del elemento de lista que se ha añadido. Fijaros en la mecánica a seguir:
    • En primer lugar, al realizar una petición a SharePoint desde una aplicación (en este caso desde el servicio WCF qué implementa la lógica del manejador de eventos remoto), necesitamos disponer de un Token de Contexto qué es generado por ACS (Azure Token Service).
    • Con el Token de contexto disponible, estamos en disposición de poder hacer operaciones “de vuelta” (callback) contra SharePoint para lo que necesitamos disponer de un Token de Acceso. Fijaros en como este Token de Acceso es obtenido por la aplicación partiendo del Token de Contexto y de nuevo a través de ACS.
    • Con el Token de Acceso, ya podemos crear una instancia de ClientContext y empezar a interactuar con SharePoint.
  • Dicho esto, ya sólo queda comenzar a probar el manejador de eventos remoto y verificar que funciona de forma correcta.

image

Referencia: http://code.msdn.microsoft.com/office/SharePoint-2013-Use-event-8b5a551f/sourcecode?fileId=72211&pathId=989899932

SharePoint 2013 & SharePoint Online: Guías para registrar aplicaciones “Autohosted” y “Provider-Hosted”!

Si estás pensando en crear aplicaciones tanto para SharePoint 2013 como para SharePoint Online, un concepto que tienes qué tener muy claro es qué si se trata de aplicaciones remotas necesitas hacer uso de OAuth para poder interactuar de vuelta con contenido de SharePoint lo qué implica qué es necesario darle una identidad a la aplicación. Para darle una identidad a una aplicación, es necesario configurar la siguiente información básica:

  • Un ID de aplicación.
  • Una contraseña de aplicación.
  • Un nombre para mostrar.
  • El nombre del dominio remoto dónde la aplicación se hospeda.

(Nota: Opcionalmente, se puede indicar también una Url de redirección a la que dirigir al usuario cuándo se “confia” o no en una aplicación a la hora de añadirla en un sitio de SharePoint).

Y ahora viene la parte relativa a como generar esa información qué depende del tipo de aplicación y de la forma en la qué la despleguemos. Básicamente, las pautas a tener en cuenta son las siguientes:

  • En el caso de depurar una aplicación:
    • Visual Studio se encarga de generar por nosotros tanto el ID de aplicación como la contraseña. En este caso no es necesario especificar ni el nombre para mostrar ni el dominio remoto donde se hospeda la aplicación qué en este caso es nuestro IIS Express local.
  • En el caso de desplegar la aplicación:
    • Si se trata de una aplicación de tipo Autohosted, es Office 365 quién se encarga de forma transparente para el desarrollador de generar ambos parámetros.
    • Si se trata de una aplicación de tipo Provider-Hosted, el abanico de posibilidades se amplia y tenemos las siguientes opciones:
      • A nivel de tenant de Office 365, usar la página de LAYOUTS appregnew.aspx. Esta página también la podemos usar en despliegues On-Premise de SharePoint 2013.
      • Si nuestra aplicación es independiente del Tenant porque queremos qué esté disponible en el Office Store, usaremos el Seller Dashboard.
      • Finalmente, añadido a las opciones anteriores podemos generar los parámetros mediante comandos PowerShell.

Toda la información sobre registro de aplicaciones Autohosted y Provider-Hosted la podéis ver en el siguiente enlace de MSDN: http://msdn.microsoft.com/en-us/library/jj687469.aspx

SharePoint 2013: ¿Está soportado el acceso anónimo a informes de Reporting Services?

Esta es la pregunta qué me hicieron el otro día, y qué con mis dudas sobre la mesa, me llevo a hacer pruebas de si era posible o no acceder de forma anónima a informes de Reporting Services. Ya os adelanto que no está soportado por Microsoft como podéis leer en este enlace en el que se detalla un workaround no soportado que en cualquier caso habría que probar si es válido para una integración de SSRS y SharePoint. Aún así os dejo las pruebas que hice para ver si era posible o no dicho acceso anónimo:

  • En primer lugar, crear una cuenta de ejecución de informes de SQL para no utilizar autenticación Windows. En un escenario de Reporting Services 2012 integrado con SharePoint (por medio de la correspondiente aplicación de servicio), es necesario crear dicha cuenta en cada una de las BDs asociadas a la aplicación de servicio además de en las BDs master y msdb. Por supuesto, la cuenta se tiene que añadir a la BD qué contiene los datos que mostrará el informe.
   1:  exec sp_droplogin @loginame='ReportExecution'
   2:  exec sp_addlogin @loginame='ReportExecution', @passwd='pass@word1'
   3:   
   4:  --En AdventureWorksDW
   5:  use AdventureWorks
   6:  if exists(select * from sysusers where name='ReportExecution')
   7:      exec sp_dropuser @name_in_db='ReportExecution'
   8:  exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader'
   9:   
  10:  --En msdb
  11:  use msdb
  12:  if exists(select * from sysusers where name='ReportExecution')
  13:      exec sp_dropuser @name_in_db='ReportExecution'
  14:  --add the users to the databases and give them permissions
  15:  exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader' 
  16:   
  17:  --En ReportingService_SABD
  18:  use ReportingService_SABD
  19:  if exists(select * from sysusers where name='ReportExecution')
  20:      exec sp_dropuser @name_in_db='ReportExecution'
  21:  --add the users to the databases and give them permissions
  22:  exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader'
  23:   
  24:  --En ReportingService_SABDTempDB
  25:  use ReportingService_SABDTempDB
  26:  if exists(select * from sysusers where name='ReportExecution')
  27:      exec sp_dropuser @name_in_db='ReportExecution'
  28:  --add the users to the databases and give them permissions
  29:  exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader'

  • Las BDs asociadas a la aplicación de servicio de Reporting Services son 3 en total: la que contiene las definiciones de informes, la de alertas y la BD temporal para cuestiones de procesado.
  • Crear con Report Builder 3.0 un informe en el que usemos la cuenta de ejecución de SQL qué hemos creado con el script anterior.
image image image
  • Configurar el origen de datos para que el informe use esas credenciales (pestaña Credenciales) y no las intente usar como credenciales Windows. Por supuesto, a partir de aquí crear el informe de acuerdo a los requerimientos qué tengamos establecidos.
  • Publicar el informe en la Colección de Sitios en concreto.
  • A nivel de SharePoint, configurar el acceso anónimo a nivel de Aplicación Web y del Sitio dónde hemos desplegado el informe.
image image

Tras realizar todos estos cambios, si accedéis al informe publicado:

  • Comprobaréis que no se visualiza y se muestra un error en la ejecución del informe.
  • Si intentáis editar el informe con Report Builder, observaréis que no es posible y qué da un error de acceso al informe dado que identifica que es un usuario anónimo el que quiere acceder a configurar el informe.

Para hacer una vuelta atrás y que el informe se pueda visualizar y editar, es necesario que quitéis el acceso anónimo tanto a nivel de aplicación web como de sitio, es decir, no es suficiente con quitarlo a nivel de sitio (o de colección de sitios).

SharePoint 2013: Como probar una aplicación Provider-Hosted sin desplegarla!

Si el otro día comentaba como depurar una aplicación para SharePoint de tipo Autohosted, en esta ocasión vamos a ver como probar una aplicación de tipo Provider-Hosted sin tener que desplegarla en el proveedor (en Windows Azure por ejemplo). Para ello, vamos a seguir las pautas que podéis ver en este artículo de MSDN. Al lío pues:

  • En Visual Studio 2012, creamos un proyecto de tipo Aplicación para SharePoint 2013.
  • En el asistente de configuración especificamos la Url del sitio de SharePoint 2013 On-Premise u Online qué usaremos para depurar o bien para desplegar la aplicación. En mi caso, he indicado la Url de un sitio de desarrollador de SharePoint Online. Indicamos también el tipo de hosting que en este caso es “Hospedada por el proveedor” (Provider-Hosted).
  • Revisamos la estructura de la solución, veremos que consta de dos proyectos: el de la aplicación de SharePoint y el proyecto web (ASP.NET).
image image image
  • Lo siguiente que tendremos que hacer es programas nuestra aplicación como necesitemos. Por ejemplo, podemos modificar tanto el aspecto gráfico de la página Default.aspx como la lógica de la misma. Por ejemplo, en este caso en el Page_Load() de la página se ha añadido el código necesario para acceder al conjunto de listas del sitio en el qué se está agregando la aplicación.
   1:              var contextToken =
   2:              TokenHelper.GetContextTokenFromRequest(Page.Request);
   3:              var hostWeb = Page.Request["SPHostUrl"];
   4:   
   5:              using (var clientContext =
   6:                    TokenHelper.GetClientContextWithContextToken(hostWeb,
   7:                          contextToken, Request.Url.Authority))
   8:              {
   9:                  clientContext.Load(clientContext.Web.Lists,
  10:                        lists => lists.Include(
  11:                        list => list.Title,
  12:                        list => list.DefaultViewUrl)
  13:                  );
  14:                  clientContext.ExecuteQuery();
  15:                  AppWebLists.DataSource = clientContext.Web.Lists;
  16:                  AppWebLists.DataBind();
  17:              }     
  • Y ahora viene lo importante: ¿Cómo depuramos la aplicación? Pues pulsando F5 en Visual Studio :P, de manera que se lanza el navegador y en este caso se muestra en primer lugar el inicio de sesión de Office 365.
  • A continuación, se muestra la aplicación completamente operativa. Fijaros en qué la Url de la misma es https://localhost:<NumeroPuerto>, es decir, la aplicación se está ejecutando en nuestro entorno de desarrollo local…coool!
image image

Para finalizar, os dejo algunos ejemplos de despliegue de aplicaciones Provider-Hosted en Azure: