jueves, 12 de junio de 2014

¿Formularios en SharePoint? Un momento, por favor... (necesito pensar)


A estas alturas ya sabemos todos que Microsoft ha “condenado a muerte” a Infopath. A pesar de que le hicieron un “entierro” simbólico en la pasada SharePoint Conference, el soporte oficial está garantizado hasta el año 2023, un nuevo sustituto está cocinándose a fuego lento (una primera versión debería estar lista a finales de verano), y algunas alternativas han sido presentadas para ir paliando las necesidades actuales. Sin embargo son tiempos confusos para el “hacedor” de formularios en SharePoint. Si te sientes perdido, si dudas entre usar Infopath u otra alternativa… hoy voy analizar todas ellas, y a dar mi humilde opinión personal al respecto.

Ya lo anunció Microsoft en su conferencia: Esto es un viaje (largo) y todavía no hay un sustituto de InfoPath. Sin embargo, todos conocemos ya (y hemos sufrido) las limitaciones de InfoPath. Está claro que necesitaba un relevo de nuevo formato, integrado con SharePoint, más intuitivo, ágil y dinámico que construya un código HTML limpio y optimice el rendimiento de la renderización y comunicación de los formularios. Solo por emprender este viaje, mis respetos y mis aplausos hacia Microsoft.

También es muy buena señal que Microsoft inicie el viaje con total transparencia y solicitando el feedback y colaboración de la comunidad de SharePoint. Dicen que nos van a tener en cuenta para tomar decisiones en la arquitectura y el roadmap del FoSL, lo cual sería realmente de muy buen hacer y agradecer.

Sin embargo, al mismo tiempo tenemos la bomba sobre la mesa: Nuestros clientes nos siguen pidiendo la implantación de procesos empresariales que requieren de formularios repletos de lógica de negocio y un nivel de complejidad a tener en cuenta. ¿Qué hacemos ahora? ¿Les seguimos implantando InfoPath a riesgo de que en un plazo corto de tiempo consultorías externas puedan tacharnos de implantar soluciones "deprecated" o en desuso? ¿Los convencemos de que prioricen otro tipo de proyectos hasta que llegue FoSL? ¿Les desarrollamos custom forms a pesar de que siempre nos ponen la premisa del uso de componentes Out Of The Box?

Vamos primero a analizar el abanico de opciones disponible y el que está por venir, y finalmente podremos sacar algunas conclusiones.

Formularios de lista
Los formularios de lista que vienen incluidos de forma estándar en SharePoint son viejos conocidos por todos nosotros. Ofrecen la base sobre la cual podemos construir cualquier aplicación en SharePoint, pero tienen muchísimas carencias, tales como la imposibilidad de mejorar su diseño (si no es con Infopath), la carencia de estructuras de repetición, la limitación de un campo por cada fila, la imposibilidad de añadir cualquier tipo de lógica de formulario (excepto campos obligatorios y validaciones simples de valores introducidos). Por la integración nativa que tienen con SharePoint, su velocidad de respuesta, la sencillez de su creación y la total garantía de que lo que construyamos con ellos serán fácilmente migrables a cualquier versión posterior de SharePoint, son ideales para formularios sencillos y siempre deben utilizarse si los requerimientos son sencillos y nos lo permiten, sin embargo suelen ser insuficientes cuando los requerimientos se vuelven algo más exigentes y complejos. Está claro que todo esto cambiará cuando llegue FoSL y el nuevo editor de formularios esté igualmente integrado a un simple click del botón "Custom Form" de la Ribbon.

Infopath
Hasta ahora era la solución habitual para resolver aplicaciones de negocio de relativa complejidad siempre y cuando no quisieras a entrar a desarrollar formularios con Visual Studio y código personalizado (una opción muy válida y ciertamente recomendable en la mayoría de escenarios). Es cierto que durante años hemos sufrido sus carencias y sus defectos, entre los más sonados la complejidad del código que genera al renderizarse como HTML, la lentitud de respuesta en formularios pesados, la dificultad para añadir código personalizado en el interior del formulario o la escasa evolución del mismo en el transcurso de los años. Sin embargo es una solución muy válida para muchos escenarios en los que el volumen de solicitudes no sea demasiado alto o la complejidad del formulario no sea excesiva (excesivas llamadas a fuentes externas darían como resultado un formulario de extrema lentitud de carga, por ejemplo). A su favor cuentan la relativa facilidad para incluir mejoras en el diseño (fondos, tablas, imágenes, redimensión de campos...) y la notable variedad de campos y lógica que le podemos añadir (repeating tables, botones de imagen, secciones...). Sin embargo la sentencia a muerte de Microsoft va a hacer que cada vez se desaconseje más su uso, pues pese a que han asegurado soporte a Infopath hasta 2023, elaborar hoy aplicaciones con una aplicación que se sabe que estará "deprecated" en breve va a salir en amarillo tirando a rojo en cualquier auditoría que nos hagan a partir del 2015. Es por eso que deberíamos evitarlo de ser posible de ahora en adelante, e intentar implantar algún tipo de solución alternativa.

Encuestas de Excel
Tal y como comenté en un post anterior, las encuestas de Excel (Excel Surveys) no son un editor de formularios para aplicaciones de negocio. Únicamente permiten crear (de forma muy rápida y sencilla, eso sí), encuestas que puedes compartir de forma inmediata con personas de todo el mundo simplemente a través de una URL de internet. Las respuestas creadas por los usuarios serán almacenadas en el interior del propio Excel. Es un producto independiente de SharePoint y no puede vincularse ni a sus listas ni a sus flujos de trabajo. Además, las encuestas son extremadamente sencillas y no permiten lógica, ni cambios en el diseño (muy básico) o tipos de campos complejos. Tampoco permite establecer ningún tipo de seguridad: Cualquier persona que acceda a la URL de la encuesta podrá contestarla. Por todos esos motivos, y sobre todo porque "encuesta" no es lo mismo que "formulario de negocio" descartamos esta solución como posible para nuestros requerimientos de implantar formularios de cierta entidad en un cliente para una granja SharePoint.

Documentos estructurados
Realmente se explicó muy poco sobre ellos, así que todavía se sabe a penas nada. Se supone que será una alternativa a los documentos en PDF, que se podrá realizar con Word. Imaginaos pues un documento tipo "plantilla" de Word, con una serie de metadatos que se repiten por el contenido del mismo. Los documento se almacenarán en bibliotecas de SharePoint y los metadatos podrán rellenarse desde el propio SharePoint sin tener que entrar en el Word. Es cierto que esto ya puede hacerse actualmente asignando una plantilla de Word a un Tipo de Contenido, pero se van a incluir nuevas funcionalidades para que no tengas que volver a pensar en los formularios tipo "PDF".

Por lo tanto, se perfila como un tipo de formulario pensado más para imprimir o conservar en "formato tipo papel", pero no lo veo integrándose en procesos empresariales con flujos de trabajo y vistas dinámicas o lógica de campos. Será algo más "simple" y "robusto", que vendrá bien para casuísticas muy concretas (plantillas de contratos de confidencialidad, por ejemplo).

Formularios Access (App Forms)
Los formularios que se pueden hacer con Access Services 2013 suelen ser un gran desconocido por la mayoría, seguramente por el anacronismo que la propia palabra "Access" nos provoca en el subconsciente. Todos pensamos en Access como algo del pasado remoto, y sin embargo es cierto que en la versión 2013 Microsoft ha conseguido con Access un editor web robusto y potente de formularios que gestionan tablas relacionales. Prueba de ello es que parte del editor del formulario de Access Services formará parte de la nueva arquitectura de FoSL. De todas las alternativas que Microsoft ha presentado para sustituir Infopath, esta sería una de las más válidas, aunque tiene una gran limitación: No puede participar en procesos de negocios (WorkFlows) porque los datos se almacenan directamente dentro de la propia base de datos Access. Es un formulario imbuido en el propio Access, por lo tanto no es válido para escenarios donde tengamos que interactuar con SharePoint, flujos de trabajo, formularios... pero es perfectamente válido para cuando lo único que necesitemos sea generar bases de datos relacionales y formularios para su manejo. Un buen ejemplo sería la gestión (a nivel informativo) de un inventario de productos. Hay que tener también en cuenta que la seguridad es a nivel de acceso al formulario (quien puede verlo, utilizarlo o administrarlo), pero no permite indicar quien puede acceder o no a determinadas vistas o campos (no hay más posibilidades de configurar la seguridad una vez estás dentro del formulario).

FoSL (Forms over SharePoint Lists)
Sobre el papel, es el futuro, la "tierra prometida" que debe fusionar aspectos básicos como:
  • Integración nativa de los formularios de listas de SharePoint
  • Flexibilidad en diseño (drag & drop, resize directo de los campos, situar campos donde arrastre el puntero...)
  • Interface moderna (HTML5), ágil y sencilla de utilizar
  • Lógica de campos, reglas y formato condicional incluido
  • Acceso a fuentes externas de datos (no en la primera versión)
  • Estructuras de repetición (no en las primeras versiones)
Aun así, seguro que no llega a ser tan fantástico ni tan potente como los productos que han desarrollado las grandes compañías de terceros, porque si no... ¿De qué vivirían esos partners de Microsoft? Hay que seguir alimentando el ecosistema, y estoy convencido que seguirá siendo así en todos y cada uno de los aspectos de las nuevas versiones que SharePoint nos siga brindando. Así que tendremos que estar atentos a las limitaciones y al roadmap de features que irán entregando para saber del cierto hasta dónde llega FoSL. De momento no existe y la primera experiencia será seguramente a finales de verano (¿septiembre? ¿octubre?) cuando lo incorporen en un upgrade de SharePoint Online.

Custom code (HTML5, aspx...)
Sin duda es una de las grandes soluciones a tener en cuenta, siempre y cuando nuestro cliente no ponga impedimentos al desarrollo personalizado con Visual Studio (hay que tener en cuenta que en una migración a versión posterior lo primero que suele decir Microsoft es que sólo garantizan la correcta migración del "out of the box").

Los límites funcionales desaparecen cuando desarrollamos nosotros los formularios, pues carecemos de las limitaciones de un servicio o aplicación ya construidos, y en función de las horas asignadas para el desarrollo, podremos crear formularios más o menos espectaculares. Sin embargo requeriremos depender de un equipo técnico altamente especializado para su desarrollo (programadores). Para crear nuestras páginas aspx personalizadas podemos recurrir a diversos recursos, aunque conociendo que FoSL tendrá un alto componente de HTML5, puede que este sea una buena opción de cara a una futura compatibilidad/migración de nuestro formulario.

 Software de terceros
Esta es una solución que nos hace plantear profundamente cuestiones existenciales del tipo. ¿Por qué si este partner ha podido desarrollar este diseñador de formularios tan fantástico Microsoft no puede (o no lo "compra y fagocita")? (aunque ya me he respondido a mí mismo en la sección de FoSL). Si has tenido la suerte de poder trabajar con soluciones de terceros tipo Nintex Forms o Infowise ultimate forms, sabrás a lo que me refiero: Interface ágil e intuitiva integrada en el navegador, todo tipo de campos, lógica, reglas, formato condicional, diseño libre, pestañas, estructuras de repetición, código limpio, ejecución rápida... En fin, todo lo que podamos pedir, que además se irá actualizando periódicamente con nuevas funcionalidades y bugfixing si tenemos contrato de mantenimiento contratado. El gran contra, claro está es el elevado coste del licenciamiento de este tipo de soluciones, así como el no tener una respuesta clara a la pregunta ¿Qué pasará con todos estos formularios cuando migre a SharePoint 2016? Seguro que si has contratado alguna de las grandes mencionadas, habrá continuidad de versión y herramientas de migración, pero a un coste adicional. Además, aquí en España no somos muy partidarios de vincularnos hasta la eternidad con un partner de servicios.

 Conclusiones
El futuro está claro que es de FoSL. El resto es pirotecnia de distracción. La teoría nos dice que tendrá todo lo que realmente estábamos deseando como sustituto perfecto de InfoPath, ya que tendrá una interface intuitiva integrada con el navegador, mezclando la Ribbon con paneles laterales de detalles y motor de construcción de formularios de Acces Services, que evitarán la ejecución de cualquier software ajeno al navegador. Permitirá también un diseño fluido, con drag & drop, poder situar los componentes allá donde los "soltemos", redimensionarlos al gusto, e incluir lógica, reglas, formato condicional, invocación a datos externos, estructuras de repetición... eso sí, dichas funcionalidades irán saliendo en cuentagotas con diversas versiones, y puede pasar todavía mucho tiempo hasta que podamos hacer una repeating table con FoSL. Seguro que tiene limitaciones funcionales, como suele ser habitual en el mundo SharePoint: Microsoft te da hasta cierto punto y más allá necesitas la ayuda de un developer/proveedor/software de terceros. La gran pega es que actualmente no existe y no hay datas claras sobre su disponibilidad.
Así que mientras tanto, hay diversos escenarios que hay que tener en cuenta:
  • ¿El cliente tiene ya una solución de terceros / puede encajar su instalación? (asumiendo presupuesto de licenciamiento, costes de migración a futuras versiones asumido y no reticencia a la dependencia de terceros) = Soluciones de terceros como Nintex Forms o Infowise ultimate forms.
  • ¿El cliente acepta que se desarrolle código personalizado en SharePoint? (asumiendo posibles costes de migración a futuras versiones y costes de desarrollo) = Formularios con desarrollo personalizado (HTML5 o ASP.NET)
  • ¿Los formularios no forman parte de ningún flujo de trabajo y trabajan meramente con datos relacionales de fuentes de datos externas o tablas? = Access Services
  • ¿Los requerimientos funcionales y de diseño son suficientemente sencillos como para ser implantados por formularios estándar de SharePoint? = Formularios de lista
  • ¿El cliente tiene SharePoint Online y el proyecto puede empezar a partir de septiembre/octubre 2014? Podemos arriesgarnos a ser los primeros en usar FoSL (aunque sabemos que será una versión básica).
  • ¿Ninguna de las anteriores? Ya solo nos queda el "viejo y moribundo" Infopath... aunque en este caso el cliente agradecerá nuestra preocupación y honestidad al aclarar nuestra inquietud por usar una tecnología que en pocos años estará en desuso.
A continuación dejo una tabla de PROS y Contras que he ido dilucidando a medida que iba desarrollando el tema de este post. Es susceptible a updates a medida que vaya apareciendo información sobre los nuevos productos, o se enciendan nuevas luces/inquietudes en mi cabeza. 

Solución
PROS
Contras
Formularios de lista
·         Completamente integrados con SP
·         Son realmente sencillos de construir
·         Se integran con Workflows
 
·         Imposible incluir lógica o formato condicional (salvo indicar qué campos son obligatorios)
·         Imposible incluir estructuras de repetición
·         Imposible modificar el diseño
·         Forzado a un único campo por fila
·         Es complejo disponer de columnas de datos de fuentes externas (no SharePoint)
Infopath
·         Se integra bastante bien con SP
·         Interface tipo Office.
·         Incorpora lógica / formato condicional.
·         Permite incluir estructuras de repetición (repeating tables, repeating zones)
·         Permite obtener datos externos con relativa facilidad.
·         El código HTML que genera es complejo.
·         Añadir código personalizado .NET es posible, pero complejo (lo desaconsejo).
·         El rendimiento es lento para casos de uso intensivos.
·         Tiene importantes limitaciones si la lista asociada no es una “form list”
·         Los controles que maneja no son tan intuitivos como los de SharePoint (peoplepicker, por ejemplo)
·         Ha sido condenado a “muerte”. Darán soporte pero no lo evolucionarán más
Encuestas de Excel
·         Interface muy intuitiva
·         No tiene dependencia de SharePoint
·         Facilidad de acceso a usuarios
·         Formularios listos en “5 minutos”
·         Los formularios resultantes son excesivamente sencillos. Solo permite construir tipos de campos básicos
·         Sin opciones de diseño del form.
·         El formato de presentación no se adapta a la naturaleza del campo (fechas o números los muestra como texto plano y no hay selector de fechas, por ejemplo).
·         No puede integrarse con Workflows u otras entidades de SharePoint.
·         Actualmente solo disponible en Excel Online y OneDrive.
·         Carencia de seguridad (puede acceder cualquier persona via URL)
Documentos estructurados
·         Integración nativa entre SharePoint (metadatos) y Word (documento y contenidos).
·         Todavía no disponible.
·         Hay poca información al respecto
·         Casuística de uso limitada (documentos tipo “papel” de alta fiabilidad, imprimibles, archivables).
Formularios Access
·         Access 2013 se integra perfectamente con SharePoint.
·         Ideal para gestionar tablas de datos relacionales.
·         Interface amigable. No requiere código.
·         Plantillas de tablas disponibles para acelerar la creación de nuevos forms.
·         Se pueden paquetizar las aplicaciones y subirlas a la Microsoft App Marketplace
·         Un Workflow no puede acceder a los campos del formulario.
·         No incorpora seguridad interna (vistas, campos…)
·         La App resultante pertenece a la BD y no se puede utilizar como frontend de una fuente de datos externa a ella (SharePoint List, por ejemplo).
FoSL
·         Se integrará perfectamente con SharePoint en futuras versiones.
·         Completamente integrado en el navegador. Sin invocar aplicaciones externas.
·         Estará desarrollado en HTML5, supuestamente un estándar web por muchos años.
·         Interface muy intuitiva Ribbon integrated.
·         Drag & Drop, se podrán mover y redimensionar libremente los campos del formulario.
·         Integración con fuentes de datos externas.
·         Se adaptará para dispositivos móviles.
·         No disponible actualmente.
·         Las primeras versiones serán muy limitadas en funcionalidad.
·         No está claro que proporcionen herramientas de migración para “antiguos” Infopaths.
·         Se intuyen limitaciones funcionales también a largo plazo (habrá que estar atentos al roadmap).
 
Desarrollo personalizado en Visual Studio y HTML5 / ASP.NET
·         Los únicos límites funcionales son los que impone el propio modelo y herramientas de desarrollo. Podemos construir cualquier formulario, con cualquier funcionalidad.
·         Desde HTML5 no debería ser compleja una posible futura migración a FoSL.
·         Requiere “picar código”, con todo lo que ello supone (especialización técnica requerida, entorno/licencias de desarrollo, posibles dificultades de migraciones a futuras versiones, dependencia del desarrollador…)
·          
Software de terceros
·         Suelen cubrir todas las funcionalidades que el usuario requiere para la construcción de los formularios.
·         Interfaces sencillas e intuitivas.
·         Incorpora lógica / formato condicional.
·         Permite incluir estructuras de repetición (repeating tables, repeating zones)
·         Permite obtener datos externos (Web Services)
·         Servicio de mantenimiento (actualizaciones periódicas y consultas incluido).
·         Adaptación a dispositivos móviles.
·         Coste de licenciamiento.
·         Coste de migración.

 Ahora sí os dejo, tras todo esta deserción sobre los formularios en SharePoint.
¡Salud! 

1 comentario:

Anónimo dijo...

apenas en 2016, continuamos con la misma incertidumbre, al contar con Sharepoint 2010 en la compañía, el departamento de IT prohibe la utilización de código, por lo que se ha usado infopath, Excel, y Access Web para desarrollar.

en los últimos meses, se ha dado la señal de no utilizar infopath, sin embargo el desarrollo de código también está prohibido. por lo que existe incertidumbre