Aplicaciones en SharePoint con InfoPath 2010

Estuve leyendo un artículo de David Gerhardt publicado en MSDN llamado Building SharePoint Applications with InfoPath 2010 (Part 1 of 2). A continuación dejo un breve resumen para aquellos que quieran interiorizarse en el mundo de InfoPath. Como siempre les digo, para analizar el tema en mayor profundidad, no dejen de consultar el artículo original.

Uno de los primeros temas que nos propone analizar este artículo es cómo será capturada y almacenada la información, a través del siguiente árbol de decisión:

Para poder tomar una buena decisión, debemos analizar las características de cada herramienta. ¿En qué se destaca InfoPath?

• No requiere un programador avanzado
• Permite código personalizado C#
• Preparado para navegadores
• Cliente fuera de línea
• Habilidades para imprimir o exportar
• Soporta integración con flujos de trabajo

Ahora bien, si optamos por una solución InfoPath, tendremos que decidir el método de almacenamiento: librería de formularios o lista. ¿Cuáles son las diferencias?

	Formularios	Listas
Estructura de datos	Jerárquica	Plana
Formato	Archivos XML	Ítems de lista
Soporte de código personalizado	Si	No
Soporte de cliente fuera de línea	Info Path filler	SharePoint Workspace
Soporte de firma digital	Sí	No

Un punto importante es que las listas no soportan elementos repetitivos.

Si trabajamos con el almacenamiento de tipo lista, cuando creamos un nuevo campo en InfoPath, se está creando una nueva columna en la lista. En cambio cuando trabajamos con el almacenamiento de tipo formulario, estamos creando en realidad un archivo XML, aunque disponemos de la posibilidad de mapear campos del formulario con columnas de SharePoint, lo que nos posibilita:

• Usar filtros de vistas
• Utilizar flujos de trabajo
• Promover totales para los valores repetitivos

Las diferencias son, a veces, sutiles. El artículo menciona la ventaja de los formularios, si tenemos que enviar los archivos a alguien que no interactúe con el sistema. A favor del modo lista, esta la vista de edición en hoja de datos para cambios masivos, aunque esto no es estrictamente exclusivo del modo lista.

Respecto al código personalizado, debemos saber que el mismo se almacena en el archivo. Es sólo soportado por el método formulario, lo cual nos da una idea de que este método es recomendado a medida que aumenta la complejidad de la solución.

En lo que refiere al soporte fuera de línea contamos con SharePoint Workspace (ex Groove) para la modalidad lista y con InfoPath filler para la modalidad formulario.

Buenas prácticas

Lo primero que debemos saber es que la complejidad de nuestros formularios puede afectar el rendimiento de la aplicación, por ejemplo cuando agregamos formato condicional, conexiones a datos externos o código personalizado. Todo esta lógica se procesa en tiempo de ejecución lo que afecta la forma en que el formulario se muestra.

Otra buena práctica es manejar más de una vista de formulario, por ejemplo para distintos tipos de usuario, en lugar de una sola vista que contenga todas las reglas de negocio, como puede apreciarse en las siguientes imágenes:

Respecto a las conexiones a datos externos, es lógico que cuanto más tengamos, más se degradará el rendimiento. Una buena práctica es no cargar todas las fuentes externas en el momento en que se abre el formulario, sino esperar hasta que realmente lo necesitemos, lo cual puede depender de algún valor cargado en un campo. También tenemos la opción de convertir la información de datos externos en XML estático, lo cual sólo es factible si los datos cambian con poca frecuencia.

Existe una opción para evitar que se realicen postbacks. Si sirve para nuestro escenario, debemos considerar esta configuración. También existen consideraciones respecto al manejo de campos en cascada, que son analizadas en el segundo artículo del autor.

Otras consideraciones

Si trabajan con información de usuarios en los formularios, es importante saber que existen dos enfoques posibles: el selector de persona/grupo y el servicio de perfil de usuario.

En caso que habilitemos las opciones de flujo de trabajo tenemos saber que debemos promover los campos del formulario como columnas de lista para que estén disponibles para el flujo de trabajo. Los campos repetitivos pueden promoverse con funciones de agregación como por ejemplo: primero, último, cuenta o concatenación. No olvidar que en forma predeterminada, los campos se promueven como columnas de sólo lectura, aunque esto podemos cambiarlo.

A nivel de seguridad, tenemos tres niveles: restringido (no se puede acceder contenido externo al formulario), dominio (no se puede acceder contenido en otro máquina) y confianza completa.

Fin

Este fue un breve resumen del artículo de David Gerhardt que pueden encontrar en http://msdn.microsoft.com/en-us/library/ff961896.aspx. Espero que les haya servido para tener un primer contacto con InfoPath 2010. Hasta la próxima!