Automatizaciones como procedimientos

Un viejo adagio sobre la codificación dice que hay que reducir la redundancia en la programación. Durante el desarrollo, si observa que copia las mismas líneas de código en todo el programa, es posible que se haya topado con código redundante. Mantener el código redundante es engorroso. Recordar dónde se encuentra cada referencia al mismo código para futuras actualizaciones o ediciones desperdicia un valioso tiempo de desarrollo. Puede agilizar el desarrollo y la reutilización creando la función al principio del programa con un nombre de función referenciable. Ahora, a medida que desarrolla, cada vez que necesite esa misma lógica de codificación, hará referencia a la función, o la invocará. Mantener una sección de código frente a muchas secciones agiliza el desarrollo.

Pega Robot Studio™ proporciona la misma lógica con las automatizaciones. Al desarrollar automatizaciones, si un proceso lógico es reutilizable, cree el proceso de automatización como un procedimiento que invoque o ejecute cuando sea necesario. Puede declarar parámetros para pasar al procedimiento, así como pasar parámetros fuera del procedimiento.

El uso de automatizaciones como procedimientos le permite anidar automatizaciones dentro de automatizaciones, lo que crea un nivel de jerarquía. Esta estructura mejora el proceso de depuración y pruebas. Probar primero los procesos de nivel inferior le permite revisar los niveles superiores con cierta confianza, ya que sabe que las automatizaciones repetitivas inferiores funcionan correctamente. Esta estructura también enfatiza la importancia de tener automatizaciones cortas, centradas en una tarea específica.

Las automatizaciones creadas como procedimiento deben seguir una convención de nomenclatura que describa lo que hace la función.

1. Use la siguiente convención de nomenclatura: Adapter Shorthand name + P + DescriptiveName (Nombre abreviado del adaptador + P + DescriptiveName).
2. Mantenga las automatizaciones de procedimientos en una carpeta de procedimientos en cada proyecto.
3. Los procedimientos deben tener un punto de entrada y deben tener al menos un punto de salida. Se deben usar múltiples puntos de salida para terminar todos los puntos finales potenciales en la ruta de ejecución.
4. Los puntos de salida se deben etiquetar de manera que tengan un sentido lógico, por ejemplo, Success (Correcto), Failure (Error) y NoResults (Sin resultados).
5. Las etiquetas de salto pueden usarse para consolidar algunas de las rutas de salida si están relacionadas (por ejemplo, Success/Failure [Correcto/Error]).
6. Los procedimientos deben devolver un valor de cadena que indique cualquier mensaje de error que pueda haber ocurrido durante la ejecución. Use el componente Message Manifest para gestionar y mantener los mensajes de la solución.
7. Los procedimientos deben devolver cualquier valor que pueda ser necesario en otra parte de la aplicación con el punto de salida.

La siguiente imagen proporciona un método sugerido para manejar un escenario común de punto de salida Success/Failure (Correcto/Error). La automatización invoca a otra automatización que devuelve un objeto Message Details (Detalles del mensaje), además de generar sus propios mensajes que requieren una conversión a un objeto de detalles del mensaje.