This release started with a simple goal to implement scenario support, but the journey brought many other features and enhancements along with it that properly enable the scenario feature to shine.
We’ll start by introducing the big new feature… scenarios. Until now, the only way to execute your automated process was to open each Process individually and run it. With a scenario, you can now group multiple processes into a single scenario and run them all! Just like how you can call activities from a process, your scenario allows you to call processes. Perhaps most importantly, you can configure how the process will execute. Let’s take a look!
The above screen shot shows an example scenario. The UI layout is very similar to a process where you have a list of calls at the top and the instructions for the call detailed on various tabs at the bottom. In this example, the same “CaptureWebPage” process is being called five times, but each call is different. This purpose of the “CaptureWebPage” process is to open a URL and capture the screen shot of the resulting page. By using a scenario, I am able to reuse the same process to capture screen shots for any URL, set the browser width, and control which web browser is used. In the first three process calls, I visit the same URL but change between three different browsers (see the “Options” column in the call list and more about browser control listed below).
Just like a process, you can create variables to store dynamic data. In the last two process calls, I used a scenario variable to define the URL to be captured and included a non-default argument for “BrowserWidth” (see the “Input” column in the call list to see which values are being passed). It is worth noting that scenario values are not visible to the process. You must explicitly pass values from the scenario to the process through parameters. This decision was very intentional to allow a process to continue to be a self-contained set of instructions.
Exposing parameters to a process is very easy and utilizes process variables.
Above is the standard view for the Variables tool window with a process variable selected. The “Parameter Details” section at the bottom is only available on process variables and can be toggled to show/hide the information. By checking the “Allow values to be passed as Input Parameter”, the default value of the variable can be assigned through an Input Parameter. The default value and description you provide for your parameter will also be visible on the Arguments tab of the process call, so you will always be well-informed about the data you can provide. Input parameters can optionally be marked as required, and doing so will generate an error in the Error List if the user calls the process without providing the input parameter. The final value of a variable can even be exposed as an output parameter to allow a value from one process call to be used as input in a later process call.
Some other highlights of scenarios…
- You can disable an individual process call if you need to stop it from running in your scenario
- You can run one or more individual processes by selecting only the process calls you want to run and using the “Run Selection” command on the context menu.
- An error or warning icon will display in the process call list if there are any issues with the process you want to call
Error Handling and Execution Status
We have greatly expanded the error handling capabilities in this release. There is now a global setting (under Options –> Run) that defines the default error response for when there is an issue executing an activity. By default, the user will be prompted as before. When calling a process or an activity, you can choose to override the default setting with an explicit response instead. In addition to the prior response, two new general responses have been added to “continue as warning” or “continue as ignored”. Both options allow execution to attempt to continue but will change the result of the activity call to either a “warning” or a general “ignored” status.
When running a scenario or process, the status of the last executed item will appear in the view.
Above is the result of a scenario run (two documents docked side-by-side). On the left is the standard scenario editor where the status of each executed process is clearly displayed in the margin. On the right is the detailed results view that has been expanded to support scenarios. All the activities from each process are aggregated together to produce the summary information at the top and you can drill down into individual processes to see the activity details from that process.
In the scenario editor of the above screen shot, note how the non-default “OnError” settings for two process calls are displayed in the options column. The “RunTimeError” process is specifically designed with an activity that will generate an error, but the “OnError” setting changed the status from “Error” to either “Warning” or “Ignored”.
Status indicators are also visible for individual activities in a process.
The screen shot above shows several activities that were successfully executed, but the selected activity in the conditional block was never executed. Since conditional blocks and loops may not always be executed, these visual indicators allow you to quickly see which activities were executed. In this case, I know that my condition was not met, and I might need to research if that was the desired result.
Finally, the user prompt for when an error is encountered has been expanded to support the new options.
The “Retry” option has not changed and will continue to allow you to repeat an activity call. The previous “Continue” option has been replaced with three individual options dictating the Error, Warning, or Ignored status to be assigned before continuing. The “Fail Process” response is only shown when executing a scenario. That option will fail the current process while continuing to the next process in the scenario. The “Stop Execution” option remains unchanged and will abort any further executions, but a new “Stopped” status has been added to the results to indicate that a process was stopped before it was completed.
Until now, the only way to control which web browser was used during playback was to change the default browser for the application. This complicated multi-browser testing or automating processes on a site that expected a certain browser. You now have two ways control the browser that is used for a process.
First, the “Launch browser” activity has been expanded to support “Browser” as an argument. If not populated, the default browser will still be used, but you can now indicate either “Chrome”, “Firefox” or “Internet Explorer” as the browser. Like all arguments, this can be replaced by a parameter to vary the browser.
Second, a process call in a scenario can change the default browser for a process. This is defined on the Options tab for the process call instructions as shown below:
In the screen shot above, the default browser has been explicitly set as “Internet Explorer”. Unless the process uses the “Launch browser” activity with a non-default browser, the process will execute in the “Internet Explorer” browser even if the application default is set to something else. The “Browser” option also supports expression syntax, so the hard-coded value could be replaced by a scenario or environment variable.
The following updates and enhancements were also included in this release
- A new “Report message” activity (in the Other category) that can write any message, status, and optional image to the results.
- Activity calls that are not enabled will be excluded from rule analysis
- A new “Home” tab on the back-stage menu combines the “New” and “Recent Files” lists into a single location.
- A new “Run” option added to control if page source is output after element identification issues. This was previously always enabled and is now off by default.
- Using the “Open containing folder” command will now select the corresponding file in the folder after it is opened.
- A process can be reloaded without closing and reopening it.
- When navigating to the source of an error, the document will be opened in “preview” mode if not already opened. Preview documents are temporary and automatically closed the next time a preview document is opened, so this can prevent opening too many files by accident. As always, pin the preview document to keep it open.
- Lots of performance improvements and fixes