Elemento web visualizador de notificaciones

De un tiempo a esta parte he estado trabajando la parte de autenticación de SharePoint 2010 para comprobar de primera mano las novedades que se nos ofrecen. Básicamente, la novedad principal es que esta versión de SharePoint se ha construido sobre WIF (Windows Identity Foundation) y, por lo tanto, soporta autenticación basada en notificaciones, o claims based authentication, como yo lo he conocido toda la vida. Próximamente publicaré alguna entrada donde explique algo acerca de este nuevo mecanismo de autenticación (nuevo para SharePoint, pero no nuevo para el mundo) pero, por ahora, os voy a explicar como crear un elemento web para visualizar la información que nos ofrece un sistema de estas características para ir abriendo boca.

Lo primero que debemos hacer es crear un nuevo proyecto de tipo Visual Web Part que encontraremos en la sección SharePoint | 2010 de Visual Studio 2010. Al igual que con cualquier proyecto que construyamos sobre la nueva plataforma de Microsoft, es imprescindible que seleccionemos .NET Framework 3.5, ya que es sobre esta versión sobre la cual está construido el producto.

Como estamos creando un elemento web visual sólo tendremos la opción de desplegarlo dentro de una solución de tipo granja, y así lo haremos.

Visual Studio creará un proyecto con varios elementos para nosotros. En mi caso, y por claridad, he cambiado las referencias a VisualWebPart1 por ClaimsListWebPart. Esto no es necesario pero, si lo hacéis, comprobad que adecuáis todo el código al cambio que habéis hecho. En mi caso, el explorador de soluciones ha quedado tal y como muestra la siguiente figura:

Ahora necesitamos añadir un control para visualizar una lista de reclamaciones o claims y, para ello, qué mejor que un GridView. Lo primero que tendremos que hacer es añadirlo al final del fichero ClaimsListUserControl.ascx.

<%@ Assembly Name="$SharePoint.Project.AssemblyFullName$" %>

<%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> 

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> 

<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>

<%@ Import Namespace="Microsoft.SharePoint" %> 

<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="ClaimsListUserControl.ascx.cs" Inherits="ClaimsListWebPart.ClaimsListUserControl" %>

<asp:gridview id="ClaimsGridView" runat="server"></asp:gridview>

Antes de poder acceder a las funcionalidades relacionadas con los proveedores de autenticación del nuevo modelo de SharePoint 2010 deberemos añadir la referencia al ensamblado Microsoft.IdentityModel.dll. Lo encontraréis en la siguiente ubicación:

c:\program files\reference assemblies\microsoft\windows identity foundation\v3.5\Microsoft.IdentityModel.dll

Una vez hecho esto abrimos el fichero ClaimsListUserControl.ascx.cs y añadimos los dos siguientes trozos de código. Primero, incluyo la referencia al espacio de nombres Microsoft.IdentityModel.Claims.

using Microsoft.IdentityModel.Claims;

A continuación, inserto en el cuerpo del método Page_Load() lo siguiente:

IClaimsPrincipal claimsPrincipal = Page.User as IClaimsPrincipal;

IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity;

ClaimsGridView.DataSource = claimsIdentity.Claims;

Page.DataBind(); 

Como véis, no cambia demasiado de la manera típica de acceder a perfiles o identidades en el modelo clásico de autenticación que conocíamos hasta ahora. Ahora estamos listos para desplegar la solución pulsando con el botón derecho del ratón sobre nuestro proyecto y seleccionando la opción desplegar. Lo único que nos quedará entonces por hacer será acceder a algún portal que tengamos configurado para usar autenticación basada en notificaciones y añadir el elemento web que acabamos de desarrollar. Lo encontraremos, si no hemos hecho ningún cambio, en la categoría Custom y bajo el nombre VisualWebPart1.

El resultado de añadir el webpart es similar a lo siguiente:

Para dar algún detalle sobre lo que estamos viendo, podemos ver los siguientes campos en la tabla que se nos muestra:

• ClaimType que podríamos entender como nombre del atributo o propiedad del perfil.
• Issuer que identifica a la entidad que nos está ofreciendo la información. En este caso, nosotros se la estamos pidiendo siempre a SharePoint.
• OriginalIssuer que identifica a la primera entidad que está ofreciendo la información o, con otras palabras, la entidad que conoce realmente la información. Como véis, algunos datos los da Windows como, por ejemplo, el nombre de inicio de sesión (userlogonname), otros los da el SecurityTokenService y otros los da directamente SharePoint.
• Value que indica el valor del atributo o propiedad que nos está llegando.
• ValueType que hace referencia al tipo de datos del atributo o propiedad.

Otra cosa que merece la pena comentar es el formato de algunos valores como, por ejemplo, userid, name o tokenreference. En la figura podéis ver cosas como 0#.w|2010rc\administrator. Pues bien, la letra “w” indica que nos hemos estamos utilizando autenticación Windows. Veamos lo que pasa cuando accedemos con el mismo usuario mediante autenticación basada en formularios (recordad que estamos usando LDAP para autenticar contra el mismo directorio activo).

Como véis, aquellos atributos que antes contenían la cadena 0#.w han pasado a contener la cadena 0#.f (de forms). Además, vemos que ahora ningún atributo proviene en su origen de Windows, mientras que aparecen algunos que provienen de Forms:LDAPMembershipProvider o de Forms:LDAPRoleProvider, que son los nombres del proveedor de perfiles y del proveedor de roles, respectivamente, que tenemos configurados en nuestra aplicación web.

En próximas entradas explicaré cómo configurar una aplicación web para que acepte autenticación basada en reclamaciones, o posibles usos de esta tecnología en el mundo real.

Read More

Creando flujos de trabajo con Visio 2010

Cuando escuchas opiniones sobre la manera en que se trabajaba con flujos de trabajo en MOSS,  lo más común era oir lo siguiente: “SharePoint Designer 2007 te permite crear flujos de manera simple, pero el resultado no es reutilizable y la potencia de lo que puedes desarrollar es limitada. Por contra, con Visual Studio puedes crear cualquier tipo de flujo que, además, es reutilizable. Eso sí, de una manera mucho más compleja”. O también cosas del estilo de “Si quieres una experiencia positiva al trabajar con flujos de trabajo en MOSS tienes que recurrir a productos de terceros”.

Tengo que decir que personalmente no he tenido que lidiar con este tipo de problemas, puesto que me he especializado sobretodo en entornos de publicación, y los flujos de trabajo que suelo utilizar son los propios de SharePoint. De todas maneras, después de escuchar algunas de las nuevas características que incorpora SharePoint 2010 en este sentido quise hacer una prueba rápida para ver cómo se comportaba. El escenario que me planteé fue el siguiente:

Necesito un sistema que permita que usuarios que no tengan conocimientos de desarrollo sobre SharePoint sean capaces de definir sus procesos de manera simple. Que después estos procesos puedan incorporarse a SharePoint de una manera intuitiva y que finalmente la experiencia del usuario sea rica.

El primer paso: definir el proceso de negocio. Como todos sabréis, Microsoft dispone de una herramienta para modelar procesos llamada Visio. Veamos como podemos utilizar Microsoft Visio 2010 para modelar un proceso sencillo. Para ello, abrimos la aplicación y, a la hora de seleccionar la plantilla especificamos Microsoft SharePoint Workflow dentro de la categoría Flowchart.

Una vez se crea el documento en blanco, podemos ver como nos aparece una barra de herramientas con elementos específicos de flujos de trabajo, tales como acciones, condiciones o terminadores.

Haciendo uso de estos elementos montamos un flujo de trabajo como el de la figura, con una comparación de un campo de documento que, en un caso asigne una tarea a hacer, y en el otro solicite información al usuario. El diagrama quedaría más o menos así:

Una vez terminado nuestro diagrama, lo exportamos haciendo uso del botón Export que encontraremos dentro de la pestaña Process. El sistema nos pedirá una ubicación donde exportar el documento y creará un fichero de intercambio de flujo de trabajo (.vwi)

Una vez hecho esto, abriremos SharePoint Designer 2010 para detallar el flujo que acabamos de crear.  Desde la aplicación, navegaremos hasta el apartado Workflows de nuestra colección de sitios y pulsaremos el botón Import from visio de la cinta o Ribbon.

SharePoint Designer nos pedirá ahora que indiquemos el fichero de intercambio que hemos creado previamente.

 

Una vez seleccionado, podremos elegir si queremos asociar el flujo de trabajo a una lista concreta o crear un flujo de trabajo reutilizable. Por ahora nos quedaremos con el ejemplo más sencillo, y asociaremos el flujo a una lista.

Una vez hecho nos aparecerá el diseñador del flujo de trabajo. Como veréis, el esqueleto está totalmente definido según el diagrama que diseñamos antes con Visio.

 

En este momento deberíamos acabar de asignar todos los elementos concretos del flujo de trabajo, como los detalles del campo a comprobar, cómo será la tarea que crearemos en un caso o qué información solicitaremos en el otro. A final, el flujo de trabajo quedará de una manera similar a la de la siguiente figura.

Sólo nos quedará publicar el flujo de trabajo en nuestra colección de sitios utilizando la acción Publish de la cinta. SharePoint Designer asociará directamente el flujo de trabajo a la lista que hemos especificado previamente.

Con esto tenemos cubierto el segundo de nuestros objetivos: incorporar el flujo de trabajo a SharePoint de una manera simple. Finalmente, veremos como se comporta en términos de experiencia de usuario. Para ello crearemos un nuevo documento en la librería a la cual hemos asociado el flujo de trabajo. Una vez hecho, desplegaremos el menú contextual relativo al nuevo documento y seleccionaremos la opción Workflows.

Como veremos, nuestro flujo de trabajo (Test workflow) está disponible en la página que nos aparece. A partir de ahora podemos trabajar con este flujo de la misma manera que hacíamos en MOSS.

Sin embargo, hay una cosa que nos llama mucho la atención en cuanto a experiencia de usuario, que viene a solucionar nuestro tercer objetivo. Si entramos en el detalle del estado del flujo de trabajo veremos una página que incluye un gráfico indicándonos el punto donde nos encontramos a cada momento. Para disponer de algo similar a esto en SharePoint 2007 debíamos acudir a productos de terceros.

En fin, esto es únicamente una introducción para que veáis un ejemplo rápido de flujo de trabajo en SharePoint 2010. Se podría escribir un libro con las posibilidades que se nos ofrecen y con las novedades que incorpora esta nueva versión pero, por ahora, con esto nos sirve para hacernos una idea. La primera pregunta que podría surgir al ver esto es: ¿significa esto que lo vamos a poder hacer todo únicamente con SharePoint y ya no necesitaremos productos de terceros? Evidentemente la respuesta es NO. El sistema tiene limitaciones que irán apareciendo a medida que lo trabajemos. Lo que sí es seguro es que no necesitaremos productos extra para cualquier pequeño detalle.

 

Cosas a tener en cuenta si nos encontramos con algún problema

Lo primero, revisad que la aplicación de servicio de Visio Graphics Service está correctamente iniciada. Os dejo aquí otro enlace por si os encontráis con algún problema en este punto.

Además de esto, os tenéis que asegurar que las características de SharePoint Server Enterprise están activadas a nivel de sitio y de colección de sitios. Si vuestra colección de sitios es una Wiki empresarial que es la plantilla que se suele utilizar para montar intranets ya las tendréis habilitadas por defecto.

Read More