Proveedor de notificaciones personalizado Azure para el proyecto de SharePoint Project: parte 1

Artículo original publicado el sábado, 11 de febrero de 2012

Hola a todos. Hace tiempo que no he agregado nuevo contenido sobre las notificaciones SAML, por lo que decidí volver y escribir más sobre la manera en que se unen algunos de mis temas preferidos; SharePoint, SAML, proveedores de notificaciones personalizados, el CASI Kit y Azure. Esta es la primera parte de una serie en la que proporcionaré una prueba de concepto, junto con código de origen que podrá usar libremente como quiera y que mostrará cómo crear un proveedor de notificaciones personalizados para SharePoint que usa Windows Azure como origen de datos. En un nivel elevado, la implementación tendrá el aspecto siguiente:

• Los usuarios iniciarán sesión en el sitio mediante la federación SAML con ACS. En el lado ACS, configuraré varios proveedores de identidades diferentes, probablemente Google, Yahoo y Facebook. Por tanto, los usuarios iniciarán sesión mediante su dirección de correo electrónico de Google, por ejemplo, y una vez autenticados, serán redirigidos al sitio.
• Usaré colas de Azure para enrutar la información de notificación acerca de los usuarios y poblar el almacenamiento de tablas de Azure.
• Dispondré de una aplicación WCF que uso para las solicitudes front-end de los datos en el almacenamiento de tablas de Azure, así como para colocar nuevos elementos en la cola. Estableceré una relación de confianza entre el sitio SharePoint y esta aplicación WCF para controlar qué usuarios pueden entrar y qué podrán ver y hacer.
• En el extremo de SharePoint, crearé un proveedor de notificaciones personalizado. Este obtendrá la lista de tipos de notificaciones que admito. También realizará la búsqueda y la resolución de nombres del selector de personas. En segundo plano, usará el CASI Kit para comunicarse con Windows Azure.

Una vez que hayamos terminado, tendremos un entorno integrado completo de SharePoint a la nube. Espero que disfrute de los resultados.

En la parte 2, describí todos los componentes que se ejecutan en la nube; las clases de datos que se usan para trabajar con almacenamiento de tablas y colas de Azure, un rol de trabajo para leer los elementos de las colas y poblar el almacenamiento de tablas y un front-end de WCF que permite a una aplicación cliente crear nuevos elementos en la cola, así como hacer todas las tareas de selección de usuarios estándar de SharePoint, como por ejemplo, proporcionar una lista de tipos de notificaciones admitidas, buscar de valores de notificación y resolver notificaciones.

En la parte 3 creo todos los componentes que se usan en la granja de servidores de SharePoint. Eso incluye un componente personalizado basado en el CASI Kit que administra todas las comunicaciones entre SharePoint y Azure. Existe un elemento web personalizado que captura información acerca de nuevos usuarios y la inserta en una cola de Azure. Por último, hay un proveedor de notificaciones personalizado que se comunica con el almacenamiento de tablas de Azure a través de WCF (mediante el componente personalizado del CASI Kit) para permitir la funcionalidad del tipo en control y selector de personas.

Esta entrada de blog es una traducción. Puede consultar el artículo original en The Azure Custom Claim Provider for SharePoint Project Part 1