Recommended Solution Architecture

This section provides recommendations on how to plan the architecture of an Automation Studio solution.

The recommended solution architecture involves dividing a solution into multiple projects that are then linked into a hierarchy using the packages feature.

The recommended solution architecture is illustrated below. It consists of a hierarchy of projects where lower projects are imported as packages into the projects above them.

The components of the recommended solution architecture include:

• Multiple feature projects, each of which automates a different feature or set of related features.
• A central project that coordinates the feature projects.
• A repository project to store common user-defined types needed by the other projects.
• A repository project to store common user-defined functions needed by the other projects.
• Repository projects to store the screen elements needed by the feature projects. The screen elements of each application are stored in their own repository.

The process of planning a solution architecture can be divided into the steps below.

1. Plan the Feature Projects

2. Plan Repository Projects for Shared Resources

3. Plan Screen Element Repository Projects

4. Plan the Central Project

5. Plan Maintenance of the Solution

1. Plan the Feature Projects

The recommended best practice is to divide the solution across multiple feature projects that will later be imported as packages into a central project.

Each feature project is responsible for automating a specific feature or set of related features of the overall solution.

For example, separate feature projects may be created to:

• Automate customer management processes
• Automate sales processes
• Automate supplier management and payment

Each feature project includes all solution components required to automate the relevant features, including workflows, user-defined functions, callouts, and variables. (Each feature project can also import resources such as user-defined types, user-defined functions, and screen elements from other projects called Resource Repository projects, described in the following steps.)

Guidelines on how to divide features between feature projects are provided here.

The solution below includes two feature projects that are both imported into a central project.

2. Plan Repository Projects for Shared Resources

A repository project only stores commonly used resources and does not automate any processes on its own.

Identify resources that will be required in multiple places within the solution and divide those resources into one or more repository projects.

The following solution components are commonly required by multiple feature projects and should be stored in repository projects:

• User-Defined Types

  User-defined types are commonly used throughout an automation solution. For example, types for Address, Customer, Service Call, etc. may be required within multiple processes.

  Creating user-defined types centrally saves you from having to rebuild them in each project in which they are required. You will also be assured that those entities are described consistently throughout your business.

  For most solutions, a single repository project is used to store all user-defined types. In large solutions, multiple repository projects may be used to store groups of unrelated user-defined types.

• User-Defined Functions

  Some user-defined functions may be used within multiple processes and thus might be required by multiple feature projects.

  User-defined functions that are created and stored centrally in a repository project only have to be developed and maintained in one location.

User-defined types and user-defined functions can either be included in the same repository project or separate repository projects, depending on the size and complexity of the solution.

The solution below includes two feature projects. Both feature projects import user-defined types from the User Type Repository project. Only Feature Project 2 imports user-defined functions from the User Function Repository project. The Central Project also imports types from the User Type Repository project.

3. Plan Screen Element Repository Projects

The recommended best practice is to create a separate repository project to store all screen elements of each application involved in the processes to be automated.

The solution below automates processes in two applications: Application A and Application B. The project includes one screen element repository project for the screen elements of each application.

Feature Project 1 automates processes in both applications, so imports both screen element repository projects. Feature Project 2 automates processes in Application B only, so imports only Screen Element Repository B.

The recommended solution architecture for screen elements is as above, although other architectures can be implemented. However, when deviating from the above architecture, screen element recognition may fail during run-time under certain circumstances. For more information, see Alternative Architectures for Screen Elements

4. Plan the Central Project

The various feature projects should be imported into a central project as shown in the examples for the previous steps.

The central project is responsible for:

• Initiating the processes automated by the feature projects, for example, starting a workflow in a feature project.

• Passing data from one feature project to another. For example, the central project may start a workflow in one feature project, receive the output value of that workflow, and then pass that value as an input to a workflow in a second feature project. For technical details on how to pass complex variable data between workflows, see here.

For large solutions, multiple levels of central projects can be used to provide an effective and maintainable architecture. In the solution below, an overall central project coordinates two secondary central projects, which in turn coordinate their feature projects. Repository Project A is used by only one of the central projects, Repository Project B is used by all three central projects.

5. Plan Maintenance of the Solution

Maintaining a solution that consists of a hierarchy of separate projects requires careful planning and management.

When any project is updated, that project must be re-imported into all other projects that make use of its resources. The entire solution must then be republished so that all clients can benefit from the updates made.

Care must therefore be taken to keep track of which imported projects each project contains.

Strict version control should also be put in place for managing all projects in case there is a need to revert to a previous version.