Mejorar el rendimiento de los formularios de Composer

Las recomendaciones siguientes le ayudarán a solucionar problemas y a mejorar el rendimiento de la solución.

Muchas de estas opciones de solución de problemas también se aplican a soluciones basadas en Designer, pero en esta sección se hará a referencia a Composer como la herramienta de diseño de soluciones.

En esta página

• Mejorar los tiempos de carga de los formularios
• Limitar las conexiones de datos
• Reducir el tamaño de XML/HTML
• Reducir calles y mejorar el rendimiento de las resoluciones de participantes
• Minimizar el procesamiento en los formularios
• Usar la paginación para grandes conjuntos de datos
• Considerar el uso de orígenes de datos alternativos
• Optimizar Winshuttle Query
• Actualizar las claves de configuración
• Optimizar las reglas

Mejorar los tiempos de carga de los formularios

Limitar las conexiones de datos

Volver al principio

Las conexiones de datos de Winshuttle Composer (listas de SharePoint, una base de datos SQL, archivos de Excel, etc.) se pueden usar como orígenes o destinos de datos de proceso. Por ejemplo, puede usar conexiones de datos para realizar algunas acciones, como rellenar campos desplegables o buscar en una base de datos.

Cada conexión de datos puede afectar al rendimiento de la solución en distinta medida.

Al añadir una nueva conexión de datos a la solución, aparece la casilla con la etiqueta Recuperar datos automáticamente al abrir un formulario.

Cuando se marque la casilla, el formulario abrirá la conexión de datos, aunque no sean necesarios cuando se abra el formulario.

Esta configuración puede suponer una enorme diferencia en el rendimiento a la hora de abrir un formulario.

Por ejemplo, si una conexión de datos es el origen de un control de consulta que se ejecuta en un cambio de campo, los datos no son necesarios hasta que se desencadena el control de la consulta, es decir, el usuario interactúa de forma activa con el formulario, de manera que la conexión de datos no debe cargarse al abrir el formulario.

Permitir que se abran las conexiones de datos solo cuando son necesarias puede mejorar drásticamente el tiempo de carga inicial de los formularios.

Recomendaciones

• En la mayoría de los casos, esta casilla debe estar marcada cuando actúa como el origen de datos de un campo desplegable. (De lo contrario, los datos nunca se cargan en la lista desplegable y el usuario no podrá seleccionar nada).
• Si hay varias conexiones de datos que actúan como el origen de muchos campos desplegables, considere la posibilidad de cambiar el tipo de campo de uno desplegable a uno de texto con un control Buscar. Al seleccionar el control Buscar, se llama a la conexión de datos en el momento de usarse, de manera que los datos no deben recuperarse al cargar el formulario.
• Es una buena práctica para reducir el número de columnas de la conexión de datos únicamente a los campos necesarios. Esto puede ayudar a reducir el tiempo necesario para recuperar los datos del origen.

Reducir el tamaño de XML y HTML

Volver al principio

La combinación exclusiva de XML y HTML ayuda a los diseñadores a recopilar datos de formulario, pero muchos no entienden del todo la relación entre XML y HTML en una solución ni su impacto en el rendimiento.

Ver el código XML de un formulario de Winshuttle

1. Abra la lista (SharePoint) de formularios de Winshuttle.
2. En la lista de SharePoint, pase el ratón por encima de la columna Título.
3. Haga clic en Ver elemento.

Cuando se abre un formulario, también se abre el código XML del formulario. En función de los campos diseñados en esa vista del formulario, el código XML se representa como código HTML para mostrarlo al usuario.

Cuanto más código XML contenga un formulario, más tardará en cargarse, ya que se debe representar más código XML en HTML.

A menudo, cuando se diseñan las soluciones, se usan campos o reglas que no funcionan en las pruebas o se usa un proceso que sustituye varios campos o reglas. Sin embargo, si esos campos no usados no se quitan de la solución, el formulario tardará más en cargarse.

Eliminar los «residuos» de una solución contribuye a mejorar el rendimiento.

Mostrar y ocultar campos y grupos es una función útil de Composer, pero ocultar los campos innecesarios de una vista, en lugar de quitarlos, puede afectar negativamente al rendimiento del formulario. Es posible que quitar los campos no usados no reduzca de forma sustancial el tiempo de carga de los formularios, pero cada segundo (o milisegundo) cuenta.

Reducir calles y mejorar el rendimiento de las resoluciones de participantes

Volver al principio

Los procesos de Winshuttle intentan resolver todas las calles de un flujo de trabajo cada vez que se inicia el formulario. El tiempo de cada resolución puede variar en función de lo que esté haciendo, por ejemplo, consultar SharePoint o Active Directory. Recuerde lo siguiente:

• Añadir más calles a un flujo de trabajo aumentará el tiempo de carga del formulario.
• Aumentar el número de usuarios de una calle puede reducir el rendimiento.
• Reducir la cantidad de datos que un formulario debe procesar para resolver una calle aumentará el rendimiento del procesamiento de los formularios.
• Quitar calles innecesarias de un proceso o usar diferentes métodos para resolver calles puede mejorar (reducir) los tiempos de carga de los formularios.

Por ejemplo, al usar SiteGroupDriven con las opciones de control del sistema de SelectFromRole, la calle tardará más en resolverse, ya que aumenta el número de usuarios del grupo de SharePoint.

Sugerencia: Evite seleccionar listas que incluyan a todos los empleados. En su lugar, considere la posibilidad de usar una consulta de SharePoint con un control de Resolución de participantes en la vista de formulario.

Minimizar el procesamiento en los formularios

Volver al principio

Si un formulario se carga rápidamente, pero una consulta tarda 60 segundos en devolver datos, también ofrece una experiencia de usuario poco satisfactoria, independientemente de cuánto tiempo ahorre al usuario, en general. En las secciones siguientes se describe cómo mejorar el procesamiento en el formulario para ofrecer una experiencia de usuario mejor y más rápida.

Usar la paginación para grandes conjuntos de datos

Volver al principio

Composer 11.0.1 ha incluido una opción de paginación para los resultados de búsqueda. Paginar los resultados de la búsqueda de datos permite que un formulario solo muestre un número limitado de registros a la vez, lo que reduce el tiempo que tarda en buscar y mostrar los resultados al usuario del formulario.

Esto significa que, aunque haya un gran conjunto de datos (y, por lo tanto, un código XML de gran tamaño), el formulario solo representa una parte de ese código XML y únicamente representará el próximo conjunto de filas cuando el usuario pase por las páginas del conjunto de resultados. Esto puede tener un impacto importante en el rendimiento del formulario con grandes tamaños de datos.

Si se deben mostrar grandes conjuntos de datos en un formulario, considere la posibilidad de usar la paginación.

Considerar el uso de orígenes de datos alternativos

Volver al principio

El origen de una consulta también puede desempeñar un papel en el tiempo de procesamiento en formularios. No todos los orígenes de datos funcionan de la misma forma.

Por ejemplo, tal vez no desee usar un control de búsqueda F4 de SAP en un campo porque quiera limitar las opciones que un usuario puede seleccionar en función de la sociedad. El control de búsqueda F4 de SAP proporciona todas las opciones disponibles, pero el usuario no puede manipularlas. En su lugar, puede crear una consulta de Winshuttle que se ejecute por las noches y organice el conjunto de datos en una lista de SharePoint, donde puede aplicar un filtro por sociedad.

Explorar otras opciones

Query también tiene la capacidad de organizar esos mismos datos en una base de datos SQL y los profesionales de las bases de datos han afirmado que las consultas SQL son más rápidas que las consultas de SharePoint (CAML).

Puede que cambiar de SharePoint a SQL no afecte a los conjuntos de datos pequeños o sin procesar, pero sí a los conjuntos de datos más grandes o a los que se aplican varios filtros antes de devolver los datos.

Otra ventaja de usar SQL (u otras bases de datos como Oracle) en lugar de SharePoint es la capacidad de crear vistas (un conjunto de datos predefinido creado mediante una consulta en el servidor que se puede usar como una origen de datos, como cualquier otra tabla).

Usar vistas puede ayudar a reducir el tiempo de consulta porque pueden contener datos de varias tablas. También pueden contener datos a los que ya se han aplicado los filtros necesarios.

Considere la posibilidad de crear vistas en la base de datos SQL para reducir el tiempo de procesamiento en formularios. Si una tabla SQL de origen contiene 100.000 registros y su proceso solo necesita un subconjunto de ellos, la consulta debe analizar todos los registros antes de devolver los datos. Si crea una vista en la base de datos de SQL que solo contenga el mismo subconjunto, la consulta debe analizar menos datos y el tiempo de procesamiento disminuye.

Optimizar Winshuttle Query

Volver al principio

A menudo, una consulta puede usarse para extraer solo un registro que se usará en un formulario, por ejemplo, detalles de nivel de centro de un material de un determinado centro. ¿Cómo se puede optimizar?

Revise el diseño de Query para determinar si es posible buscar en campos indexados, en lugar de en campos no indexados. Buscar en campos indexados mejora el rendimiento.

Además, si se usan varias consultas para unir diversas tablas, intente usar scripts de Query individuales para cada tabla, en lugar de un script que una varias tablas. Puede ser muy beneficioso cuando la unión entre la tabla A de SAP y la tabla B utiliza una unión incompatible, una unión en la que los campos no tienen la misma definición.

Un buen ejemplo de esto es recuperar los datos de clasificación de SAP. Los datos de clasificación de muchos objetos SAP (materiales, acreedores, etc.) se guardan en las mismas tablas y los campos que se usan para unirlos a los datos de clasificación son diferentes.

Algunas configuraciones de SAP necesitan el uso de la tabla de números de objetos internos (INOB) para buscar datos de clasificación de un material. Las uniones adecuadas son MARA.MATNR => INOB.CUOBJ => AUSP.OBJEK. El campo INOB.CUOBJ tiene 18 caracteres mientras que la unión a AUSP.OBJEK tiene 40 caracteres. Esta discrepancia afecta gravemente al rendimiento del procesamiento en formularios.

En este caso, la experiencia ha demostrado que es más rápido consultar, en primer lugar, MARA e INOB para recuperar el valor de CUOBJ y, a continuación, usar el valor en una segunda consulta para recuperar los datos de AUSP. Dividir la consulta en varias no siempre ofrece resultados más rápidos, pero es otra herramienta de la caja de herramientas.

Actualizar las claves de configuración

Volver al principio

A menudo, un formulario ejecuta varios servicios web de forma consecutiva con solo pulsar un botón. Esto puede reducir la capacidad de respuesta de la página y, en última instancia, puede provocar que se agote el tiempo de espera del servicio web.

El valor predeterminado de tiempo de espera del servicio web es de 500 segundos. Sin embargo, se puede cambiar, pero no resuelve al problema de la capacidad de respuesta. No obstante, Winshuttle proporciona numerosas claves de configuración que puede usar un desarrollador de soluciones para cambiar cómo se ejecutan un proceso y un sistema.

Una clave de ese tipo (WebServiceProgressiveResponse) permite especificar cómo se actualiza una página cuando varios servicios web se ejecutan desde un solo botón. Al configurar WebServiceProgressiveResponse como True se fuerza a una página a que espere hasta que se hayan completado todos los servicios web antes de actualizarse.

Al configurar WebServiceProgressiveResponse como False se permite a la página que se actualice mientras se completa cada servicio web, lo que puede mejorar los tiempos de respuesta y proporcionar una mejor experiencia de usuario.

Optimizar las reglas

Volver al principio

Las reglas de formularios y sus diferentes funciones pueden variar ampliamente. Algunas son reglas estrictamente de JavaScript que actualizan valores de campos de formularios en función de otros parámetros o valores de campos de formulario. Estas reglas básicas de JavaScript, por lo general, no siempre, solo se ejecutan en la parte del cliente, lo que significa que la acción usa recursos locales del sistema (es decir, el PC del usuario). Debido a que las reglas en el lado del cliente no se comunican con otros servidores, su capacidad de respuesta siempre es buena.

Centrarse en las reglas que solo se ejecutan en el lado del cliente no proporcionará muchas mejoras (si es que proporciona alguna) a menos que haya errores en el código personalizado.

Las reglas que dependen de la interacción del servidor, por ejemplo, consultas externas o búsquedas de datos, se pueden optimizar independientemente en relación con el rendimiento.

Una buena opción es examinar las reglas que dependen de la interacción del servidor para saber cuándo se puede ejecutar cada uno de estos procesos. Por ejemplo, ¿se puede ejecutar la regla al final del formulario cuando el usuario lo envía o la puede ejecutar el flujo de trabajo en segundo plano?

Si un formulario tiene consultas que se ejecutan en la carga del formulario y este tarda diez segundos en cargarse, aunque tenga la misma cantidad de tiempo de espera, es más probable que un usuario tenga una experiencia mejor que si tarda cinco segundos en cargar el formulario y cinco segundos en enviarlo.

El tiempo de espera total también es de diez segundos, pero cada espera es corta. Ejecutar reglas al final puede que no ayude a tener tiempos de espera acumulativos, pero podría contribuir a que la experiencia de usuario fuera mejor.