Alternative Architectures for Screen Elements

This topic provides guidelines on how to include screen elements in a solution architecture differently from the recommended solution architecture.

In the recommended solution architecture, screen elements are stored in repository projects only. See here.

Technical Considerations for Screen Element Architecture

It is important to know that if multiple projects that include screen elements from the same application are open at the same time during run-time, recognition of screen elements from that application might fail unexpectedly.

More specifically, if multiple running projects include the same screen elements or screen elements that have shared ancestors, recognition of those screen elements is likely to fail.

The recommended solution architecture avoids this issue by locating all screen elements for each application in a single project only.

If you choose to use one of the alternative architectures below, you will need to take the above into account.

Alternative Architecture 1

In this architecture, all screen elements needed by a feature project are captured and stored within that feature project and not in a repository project. Any screen element that is required by multiple feature projects is captured and stored in each of those projects.

To avoid the risk of recognition of shared screen elements failing during run-time, the screen elements in all projects that are not currently active should be disabled. Only the screen elements in the project that is currently active should be enabled. Screen elements are enabled and disabled using the functions in the Screen Element Support built- in service.

In the solution below, both feature projects automate processes in the same email application and include shared screen elements from that application. Currently, the solution is automating a process defined in the Send Email project, so screen elements in that project are enabled while screen elements in the Receive Email project are disabled.

Alternative Architecture 2

In this architecture, all processes that are automated in an application are handled by a single feature project, and all required screen elements from that application are captured and stored in that feature project.

Because each screen element is captured and stored within just one project, there is no risk of recognition of shared screen elements failing during run-time, and there is no need to enable or disable screen elements.

However, this approach is often not practical and can prevent you from dividing a solution into multiple projects effectively and efficiently.

In the example solution below, one feature project automates all operations in an email application and another automates all operations in a CRM application. Each feature project includes all the screen elements it requires for the application it automates.