Pablo

Sé que es un título muy fuerte para un primer post, así que les contaré la historia completa. Se trata de un proyecto montado sobre SharePoint 2007 (MOSS para ser mas especifico) que básicamente realiza el control de facturas por pagar a proveedores, sin entrar en mucho detalle irrelevante para lo que quiero contarles, les diré que es una aplicación típica en la cual hay un flujo de aprobación simple (el flujo de aprobación que viene nativo con SharePoint). En el cual se tienen que dar de alta facturas pertenecientes a un proveedor, bueno acá pensé es un buen momento de aplicar el servicio de Form Services del cual había leído que es ideal para estos casos.

Y acá realmente empieza la historia. El formulario no tenía mucha complejidad, debía conectarse a una base de datos para extraer datos de proveedores, además de traer datos de dos tablas en esa base de datos para llenar dos combos (dropdown list), y además dar la posibilidad de llenar un campo de texto de múltiple línea, luego este formulario se almacenaría y daba inicio al flujo de aprobación del pago. Hasta acá ningún problema un poco de dificultad para alojar las conexiones a la base de datos en un lugar apropiado, y otras dificultades menores para habilitar que los formularios se muestren sin necesidad del cliente InfoPath, pero eso serán motivo de otro post.

Una de las grandes ventajas publicitadas con InfoPath 2007 y Form Services de MOSS es precisamente que la utilización del cliente InfoPath es opcional, esto quiere decir que: Los formularios InfoPath se utilizan desde navegadores, el poco uso (hasta donde tengo entendido) de InfoPath 2003 era precisamente porque necesitaba obligatoriamente el cliente InfoPath para poder interactuar con sus formularios.

Los formularios se conectaban a la base de datos, llenaban los combos, traían información de los proveedores, se almacenaban correctamente e iniciaban el flujo, todo sin ningún problema (o con todos los problemas superados). Hasta que llego el momento de ponerlo a producción. Me empezaron a reportar problemas de performance con los formularios, e incluso que a causa de la aplicación en SharePoint las estaciones de trabajo se colgaban, upsss :s que podría estar pasando?.

Lo primero que hice fue hacer una réplica idéntica del entorno de producción, note que la información de las tablas que llenaban a los combos era más de la que realmente esperaba, pero esto pueda colgar a un sistema de 1GB de RAM?. Inicie mis pruebas de performance, la verdad es que mi cliente tenía razón, luego de un uso intensivo de los formularios de InfoPath el sistema se iba tornando lento, inmediatamente me puse a monitorear el proceso de Internet Explorer, note que básicamente este proceso IExplorer.exe se estaba comiendo la memoria, llegando a ocupar 700MB!. Bueno dije, la causa puede ser una forma ineficiente de serializar la información dentro de los combos, leí por ahí que es aconsejable si vas a utilizar combos con mucha información, llenarlos a partir de un archivo XML, y eso hice. Debo decir que note una mejora en la velocidad de respuesta, pero la memoria tomada por IExplorer.exe seguía siendo similar. Ante este tipo de problemas lo mejor es aislar las posibles causas. Así que desarrollé (o configuré) rápidamente un formulario de que solo tenga los dos combos, y a probar nuevamente. Si bien la utilización de memoria en la carga del formulario era muy similar al del formulario en producción, esta memoria se liberaba inmediatamente luego de cerrar el formulario, cosa que no pasaba con el formulario original, bueno ahí está la causa del problema, IExplorer no está liberando la memoria utilizada, es decir que cada carga de formulario simplemente va multiplicando el uso de memoria de IExplorer, obviamente todo este problema se solucionaba abriendo y cerrando Internet Explorer pero eso no le podía decir a mi cliente :S

Empecé a mirar que es lo que además de los combos tenía mi formulario, porque era evidente que la causa del problema no era de la mucha información que tenían los combos, o de la forma de obtener esa información. Como les comentaba anteriormente uno de los campos del formulario se llenaba texto de múltiple línea, para el cual había puesto un Rich Text Box que estaba permitido para mantener la compatibilidad Web (que se mostrará en navegadores, muchos controles solo sirven cuando se utiliza el cliente InfoPath), lo primero que hice fue poner un control de texto enriquecido en el formulario que solo tenía los combos, ese formulario que me sirvió para aislar el problema, y adivinen que… el formulario dejo de liberar memoria. Ya tenía el culpable.

Por algún motivo esté control impedía que IE liberara memoria, imagino que hay una causa, o una razón, aun la desconozco, desconozco también si hay algún hotfix que solucione este comportamiento. Me olvide comentar que una de las pruebas fue actualizar a IE 7, note que la performance del formulario en general mejoro mucho, pero el manejo de memoria seguía siendo el mismo. Considerando que ahora no puedo reemplazar el control por uno de "texto simple" porque ya hay muchos formularios cargados (hasta ahora encontre la causa, pero no la solución L ). He decidido prescindir de este control hasta nuevo aviso.