Automations as procedures

An old adage about coding says to reduce programming redundancy. During development, if you notice that you copy the same lines of code throughout the program, you may have stumbled upon redundant code. Maintaining redundant code is cumbersome. Remembering where each reference to the same code is located for future updates or edits wastes valuable development time. You can streamline development and reuse by creating the function at the start of the program with a referenceable function name. Now as you develop, any time that you need that same coding logic, you reference or call the function. Maintaining one section of code versus many sections streamlines the development.

Pega Robot Studio™ provides the same logic with automations. While developing automations, if a logical process is reusable, create the automation process as a procedure that you call or execute when needed. You may declare parameters to pass into the procedure as well as pass parameters out of the procedure.

Using automations as procedures allows you to nest automations within automations, creating a level of hierarchy. This structure improves the debugging and testing process. Testing the lower level processes first allows you to review the higher levels with a degree of confidence, knowing the lower repetitive automations function correctly. This structure also emphasizes the importance of having short automations, focused on one specific task.

Automations created as procedure should following a naming convention that describes what the function does.

1. Use the following naming convention: Adapter Shorthand name + P + DescriptiveName
2. Keep procedure automations in a Procedures folder in each project.
3. Procedures must have an Entry Point and should have at least one Exit Point. Multiple Exit points should be used to terminate all potential end points in the execution path.
4. Exit points should be labeled such that they make logical sense, for example, Success, Failure, and NoResults.
5. Jump labels can be used to consolidate some of the Exit paths if they are related (for example, Success/Failure).
6. Procedures must return a string value indicating any error messages that may have occurred during the execution. Use Message Manifest to manage and maintain the solution messages.
7. Procedures should return any values that may be needed elsewhere in the application with the Exit Point.

The following image provides a suggested method for handling a common Success/Failure Exit Point scenario. The automation calls another automation that returns a Message Details object in addition to generating its own messages that require a conversion to a message details object.