Se aplica a:
- Winshuttle Foundation
Prácticas recomendadas para el desarrollo de la solución
5. Desarrollar la solución
Guía de prácticas recomendadas para el desarrollo de la solución
Una vez los requisitos se hayan aprobado y estabilizado, se podrá empezar a realizar el desarrollo. Es posible que haya varios desarrolladores trabajando en la solución, así que es importante utilizar un proceso secuencial para el desarrollo.
En esta página
- Crear scripts. (si está realizando la integración con SAP).
Si va a crear una solución que se integrará con SAP y utiliza scripts de Winshuttle Transaction/Query, los scripts serán la base del formulario. Los scripts se tienen que crear y probar antes de desarrollar el flujo de trabajo y el formulario. - Crear la vista del desarrollador .
Cree una vista de desarrollador en el formulario que sirva como vista maestra y que incluya todo el contenido del formulario, incluidas las reglas y cálculos necesarios para la solución. - Crear el flujo de trabajo.
Desarrolle el flujo de trabajo después del formulario porque las dependencias en el formulario encarrilan el flujo de trabajo. - Crear vistas de formulario.
Una vez el formulario se haya completado y se haya probado el flujo de trabajo, deberá saber cuántas vistas tiene que crear y los participantes del flujo de trabajo (es decir, usuario o grupo) a los que se mostrarán estas vistas. - Probar la solución.
Pruebe la solución con un grupo de usuarios para asegurarse de que todo funciona correctamente en el formulario, los scripts y el flujo de trabajo.
1. Crear scripts
Si va a crear una solución que se integrará con SAP y utiliza scripts de Winshuttle Transaction/Query, los scripts serán la base del formulario.
Hay que crear y probar los scripts antes de desarrollar el flujo de trabajo y el formulario. También hay que probar los scripts antes de añadirlos a la solución.
A medida que se vaya creando cada script, realice las siguientes pruebas:
- Pruebe cada script de Winshuttle directamente en Winshuttle Transaction o Query con Microsoft Excel.
- Guarde la asignación de Excel en caso de que haya problemas posteriormente a lo largo del proceso.
- Convierta la asignación del Tipo de origen del script de Winshuttle a XML y pruébela en Transaction o Query.
- Cree un formulario muy sencillo y asigne el flujo de trabajo con cada script de Winshuttle. Ejecute el script directamente en el formulario para asegurarse de que funciona correctamente.
Estas pruebas le ayudarán asegurarse de que las funcionalidades que se usen en Winshuttle Transaction o Query van a funcionar en un formulario o al ejecutarse con el tipo de origen XML.
Si, durante la fase de prueba, se identifica un problema que requiere un script adicional o modificar el script actual, se puede hacer. Sin embargo, en la medida de lo posible, evite volver a generar el formulario para mantener correctas las asignaciones.
2. Crear la vista del desarrollador
Una vez haya terminado de crear y probar los scripts (si los va a utilizar), ya podrá empezar a desarrollar el formulario.
Winshuttle le recomienda crear primero una vista de desarrollador en el formulario que sirva como vista maestra y que incluya el contenido del formulario, incluidas las reglas y cálculos necesarios para la solución. Así, tendrá una vista de formulario sencilla como base y le será más fácil crear vistas adicionales.
Una vez haya terminado la vista del desarrollador, pruebe el formulario con un pequeño grupo de usuarios y compruebe lo siguiente:
- Que los scripts se ejecutan y están asignados a los campos correctos (si utiliza scripts de Winshuttle).
- Que los cálculos, reglas y demás lógicas de negocio del formulario funcionan correctamente.
- Que el diseño o estilo del formulario es correcto.
Se recomienda completar una fase inicial de pruebas antes de crear vistas de formularios adicionales. Si aparecen errores después de terminar todas las vistas de formularios, serán más difíciles de corregir porque tendrá que actualizar todas las vistas del formulario. Si descubre un problema antes de crear vistas adicionales, solo tendrá que actualizar una vista.
Información adicional
Consejos y prácticas recomendadas para diseñar el formulario
Puede leer más consejos sobre cómo optimizar el desarrollo de su formulario.
3. Crear el flujo de trabajo
Después de haber creado y probado la vista de desarrollador, puede comenzar a desarrollar el flujo de trabajo. A veces, el desarrollo del flujo de trabajo lo realiza otra persona distinta al desarrollador del formulario, pero generalmente es la misma persona la que desarrolla el formulario y el flujo de trabajo.
Desarrolle el flujo de trabajo después del formulario porque las dependencias en el formulario encarrilan el flujo de trabajo. Además, podrá tener una mejor percepción de la cantidad de vistas que necesita su formulario y qué tendrá que mostrar cada una. Por ejemplo, si tiene un flujo de trabajo que se enruta siguiendo los valores de campo de su formulario, no podrá configurarlos en el flujo de trabajo hasta que exista el campo.
Una vez terminado el flujo de trabajo, tendrá que realizar unas pruebas sencillas antes de crear las vistas del formulario. Las pruebas dependen principalmente de cómo está creado el flujo de trabajo y cómo ha enrutado el formulario, pero a continuación se describen algunas pruebas recomendadas.
Pruebas de flujo de trabajo recomendadas
- Asegúrese de que los usuarios asignados sean los participantes correctos durante el proceso. Si utiliza el definidor de participantes, asegúrese de que la consulta devuelve lo necesario para asignar las tareas.
- Pruebe todas las rutas del flujo de trabajo. Si el flujo de trabajo se enruta basándose en los datos del formulario, asegúrese de que los valores de los campos estén llenos.
- Asegúrese de que se envían todas las notificaciones y de que los participantes asignados las reciben.
- Si utiliza complementos en el flujo de trabajo, asegúrese de que realizan la/s operación/es correcta/s con el/los resultado/s esperado/s.
- Haga pruebas con los bucles. Asegúrese de que todos los bucles terminan cuando lo deben hacer.
Mientras realiza las pruebas, tenga en cuenta también cómo solucionar los errores. Si existe la posibilidad de que algo vaya mal en el flujo de trabajo, hay propiedades de transiciones como «IsAssignmentValid» u «Otherwise» que son muy útiles a la hora de evitar que el flujo de trabajo se tope con un error.
Si desea obtener más información, consulte Propiedades de las transiciones de Composer.
4. Crear vistas de formulario
Las vistas de formularios son el último paso en el proceso de desarrollo antes de realizar la prueba con la solución. Una vez el formulario se haya completado y se haya probado el flujo de trabajo, deberá saber cuántas vistas tiene que crear y los participantes del flujo de trabajo (es decir, usuario o grupo) a los que se mostrarán estas vistas.
Winshuttle Composer tiene vistas de formulario especiales, predefinidas y reservadas (ver tabla) que se pueden utilizar para determinados casos. No puede tener más de una vista con el mismo nombre, pero puede crear y denominar las vistas dependiendo de sus necesidades.
Winshuttle recomienda, como mínimo, utilizar siempre la Vista del originador y el Proces completado.
Consulte Trabajar con vistas de Composer para obtener más información.
Vistas predeterminadas de Winshuttle Designer/Composer
Vista de Composer |
Descripción |
|
Vista del originador |
Esta vista aparece cuando el Originador lanza el formulario por primera vez. |
|
Vista de reenvío |
Esta vista aparece cuando el formulario se reenvía. |
|
Vista del estado del proceso |
Esta vista aparece cuando un usuario desea ver el formulario pero no tiene ninguna tarea pendiente. |
|
Vista del proceso completado |
Esta vista aparece cuando el proceso termina. |
5. Probar la solución
Una vez terminado el desarrollo, hay que probar la solución con un grupo de usuarios para asegurarse de que todo funciona correctamente en el formulario, los scripts y el flujo de trabajo. A menudo, esto requiere crear casos de prueba específicos para pruebas.
Asegúrese de que mantiene canales de comunicación abiertos con sus usuarios. A medida que los problemas vayan apareciendo en el proceso de pruebas, los desarrolladores de la solución deberán continuar trabajando con los usuarios finales para probarlos.
Tenga en cuenta que probar y validar una solución no es un proceso que los usuarios deben utilizar para solicitar funcionalidades adicionales. Si embargo, si se añaden nuevas funcionalidades en esta fase, habrá que ampliar la fase de pruebas antes de que la solución pueda pasar a producción.
Una vez hayan terminado las pruebas de la solución, comience a planificar la migración de la solución desde el servidor de desarrollo al de producción. Generalmente, se necesita un día para migrar una solución.
Realice pruebas con las solución después de terminar la migración.
Después de migrar correctamente la solución al entorno de producción, debería dejar que un usuario comprobara las dependencias para validar que la migración se ha realizado correctamente. Qué comprobar tras realizar la migración:
- ¿Funcionan los scripts de Winshuttle correctamente?
- Los scripts de Winshuttle, ¿se ejecutan en el sistema de SAP correcto?
- ¿El formulario se enruta correctamente?
- ¿Hay alguna lógica del formulario o flujo de trabajo que se haya roto o necesite más información (es decir, listas desplegables)?
- ¿Se envían las notificaciones de correo electrónico?
Información adicional
- Mover las soluciones de Winshuttle Composer entre entornos
Cómo migrar soluciones creadas en Winshuttle Composer en un entorno de Winshuttle Workflow 10.7 o posterior.