Como ya comentamos en el blog anterior, las tecnologías de Sharepoint hacen posible que podamos centralizar y almacenar cualquier tipo de documento en los repositorios que nos proporciona la plataforma. Bien a través de listas de datos, como a través de galerías de documentos, podremos hacer que nuestros aplicativos almacenen información en la base de datos de Sharepoint y aprovechar todas las características de la plataforma. Pero pongamos ya ejemplos reales y dejémonos de teoría.
Empecemos con un ejemplo asequible, pero que muestra exactamente lo que será nuestro objetivo. La propia suite niña mimada de Microsoft: su suite ofimática Office. La tecnología de Sharepoint, proporciona una infraestructura perfecta para plasmar todos los conceptos que vimos en el blog anterior. Office actúa como ejemplos de clientes ricos cuyo objetivo es generar productos (documentos electrónicos fruto de aplicar un proceso de negocio) en todos los formatos necesarios en una empresa: documentos, hojas de cálculo, formularios… etc. Office es capaz de ver los respositorios de Sharepoint como si de una unidad de almacenamiento más se tratase. Pero no mediante un acceso FTP cualquiera, no… a través de toda la potencia desplegada en los servicios de la plataforma. Para muestra un botón:
Si Office es capaz de integrar en su lógica el almacenamiento de cualquier tipo de recurso en los repositorios de sharepoint, por qué nosotros no. Bien, tendremos dos formas de abordar esta fenomenal característica del producto…
a) Caso en el que no podemos modificar nuestras aplicaciones, pero si nos interesa almacenar los datos en sharepoint. Nos encontramos a su vez con dos casos:
a. La aplicación genera productos en forma de documentos electrónicos. En este caso, podemos aprovechar la integración de las unidades de “red” de sharepoint, que extienden el escritorio de nuestro sistema operativo (a través de los conectores WebDAV integrados). Empleando este mecanismo, nuestras aplicaciones de forma transparente, ya estarán interactuando con sharepoint. Y nuestros usuarios podrán explotar sus datos como auténticos Information Workers.
a. La aplicación es capaz de exportar en formatos conocidos la información que necesitamos almacenar de forma estandarizada. En este caso podemos optar por exportar los datos a una “unidad de red” de sharepoint, o bien podemos optar por procedos de integración empresariales (como los que proporciona Biztalk, sin casi desarrollar una sola línea de código).
b) Caso en el que podemos extender el desarrollo, haciendo posible la integración directa con Sharepoint. En este caso, haremos uso del API de sharepoint y sus servicios web para almacenar los datos y recuperarlos como si de una base de datos de muy alto nivel se tratase.
c) Si no queremos desarrollar aplicación, siempre podremos tirar de los potentísimos servicios de Infopath, el gran desconocido de la familia Office. Por el cual podemos automatizar al límite el concepto de formulario de entrada y almacenar todos sus productos en los repositorios de sharepoint.
Bien, qué nos proponemos abordar en las siguientes entradas del blog: cubrir todo el ciclo. Desarrollaremos una sencilla aplicación que pretende almacenar partes de trabajo de nuestros técnicos. Desarrollaremos la aplicación tanto como cliente rico desarrollado a medida, como cubriremos el mismo desarrollo empleando Infopath. Vosotros juzgaréis la importancia de apostar por las herramientas adecuadas en vuestro contexto, pero sin perder de vista el objetivo: utilizar sharepoint como nuevo repositorio de información (que no de datos, como es el caso de SQL Server).
Nos vemos...