Robotic solutions and projects
A robotic solution is a container for Pega Robot Studio projects and project items, such as application adapters, automations, and configurations. For example, solutions can be created around business roles where one solution provides functionality for Call Center Representatives that handle Loan Inquiries, while another solution provides functionality for representatives that deal with Credit Card customers. Robotic solutions are named to identify the overall functionality or purpose of the solution. Best practice is to use the naming convention descriptive name + Sln, such as LoanSln, CreditCardSln, or CallCenterSln, depending on the purpose of the solution.
Projects
Projects can be thought of as modules that you use to build the overall Robotic solution. Projects fall into two categories: Controller and Adapter.
Controller
This is the main project of a solution. The controller project provides control of all of the other projects. A solution will have only one main controller project, which contains the majority of the UI (anything not specific to a particular application), along with the logic required to connect the individual project applications.
Adapter
The adapter project automates the functions to be performed upon a single application. An adapter project will contain at least a single adapter. In some cases, multiple individual applications will be logically grouped together for performance reasons (for example, all Internet Explorer applications). However, for the majority of solutions a single application should be automated within its own adapter project.
Project naming convention
Projects should be named after the application that they are automating. When naming a controller project, it should be named after the solution. Best practice is to use the naming convention descriptive name + Prj. The following table shows some example project names:
Type | Purpose | Example name(s) |
---|---|---|
Controller | Loan support | LoanSupportPrj, LoanPrj |
Business Logic | Validate customer | ValidateCustomerPrj |
Application | Automate Siebel | SiebelPrj |
Best practices
Best practices for naming projects and solutions include the following:
- Always use descriptive names. Descriptive names are not a bad thing and can help self-document what the item is for.
- Names should use abbreviation, shorthand, and acronyms whenever possible however as there is a limit on the length of items within a solution.
- Use Pascal casing for component names with no spaces or underscores (except where underscores form part of naming convention). For example, InsuranceClaimSln, SiebelPrj, LoanSupportPrj.
- When possible, create a separate project for each adapter so that you can easily reuse them in other solutions.