To prepare the implementation environment and to create your application, complete the following preparation tasks:
Creating the application
Run the New Application wizard to create your application.
- To create a new operator ID for running the New Application wizard,
complete the following steps:
- Log in to Dev Studio by using the operator ID [email protected] and the password that you specified for that operator.
- Save a copy of the existing [email protected] operator and give it a name that identifies it as an Application Setup operator.
- Add the PegaGPCosmos:Administrators access group to the new operator record, and then click the radio button to the left of the access group to select it as the default access group.
- Save the new Application Setup operator.
- Log in as the Application Setup operator.
- In the header of Dev Studio, click the name of the application, and then click New Application.
- Follow the New Application wizard instructions until the Name
your application page opens, and then follow the steps below.
For more information about each step of the wizard, see Creating an application.
- On the Name your application page, enter the name of the application, and then click Advanced configuration.
- In the Organization settings section, enter the
Organization name, Division name, and
Unit name for this application.
The New Application wizard creates the application class structure for you based on the organization settings that you enter. For more information, see Class layers and Class hierarchy and inheritance.
If you have not already defined the organization entities (for example, if you have not already defined the division), type the name of the new entity in the appropriate field. The application saves the new values when you create the new application.
- Click Save.
- Click Create application.
The Application Wizard creates the implementation application. The application includes one system administrator operator so that you can log into the application after you complete the wizard.
- To open the new application, click Go to app.
Implementing the security model
Security planning involves defining authorization and authentication strategies for your application.
Optional: Defining the security model and organization structure
Define the authorization and authentication strategies for your application.
- Proves to the application that you are who you say you are.
- Determines the functions that you can perform in the application. This corresponds to an access group and role configuration.
Security planning involves defining authorization and authentication strategies for your application. It is a best practice to create new access groups and roles that are based on the default access groups and roles that come with the product.
Security planning also involves setting up the organization structure and operator attributes. The application provides security in the form of access settings and denial rules. Many integration rules also incorporate authentication.
For more information about the additional aspects of security, enroll in the Lead System Architect course on Pega Academy.
The Pega Platform offers the following authentication types:
- Based on passwords in the Operator ID data instances and the login form. This is defined by the HTML @baseclass.Web-Login rule, which your application can override.
- Similar to PRBasic, but passes credentials by using Secure Sockets Layer (SSL) with Basic HTTP authentication. The login form is defined by the HTML @baseclass.Web-Login-SecuredBasic rule, which your application can override.
- Supports access to an external LDAP directory or a custom authentication scheme.
- Supports external assignments (Directed Web Access).
- Specifies that the application server in which the Pega Platform is deployed uses JAAS to authenticate users.
Defining your authentication scheme
Your site can use a centralized, automated means of maintaining operator data instead of maintaining it manually in your application.
- Discuss the authentication schemes with your site's security and application server teams.
- Determine the appropriate authentication type.
For more information on authentication scheme planning, see Authentication.
Defining the organization structure
Use the organization structure for routing and reporting within the application. Typically, the application organization structure does not map operators exactly to the site's organization chart but instead, it maps the work that those operators do.
- In the header of Dev Studio, click .
- Review the existing structure.
- Determine the organization, division, and unit levels of the hierarchy.
Defining the operator attributes
An operator's access group affects what the operator can do in the application. In addition to the access group, the following fields in the operator record influence how the application handles assignment of work to the user.
For more information, see Operators.
Defining the operator work group
The work group setting in the operator record affects how your application delivers work to the operator. Review the Operator record and determine the rules for assigning a work group to an operator or the role that multiple operators hold.
- In the header of Dev Studio, click .
- Select an operator ID.
- On the Work tab, review the work group information for the operator record.
- Determine your policy for assigning a work group to an operator or the role that multiple operators hold.For more information, see Fields for operator work groups, work queues, and schedules.
Defining the operator skills
Skill settings in the operator record affect how the application routes work to the operator. Skill settings also affect how the application gets the most appropriate work when using the Get Next Work feature. You must determine the skills that are appropriate for your application and operators.
- Define the skills that are needed for the application.
- Determine which operator records or roles should be associated with those skills.
Defining the operator calendar
The application calendar affects date calculations within the application, such as the date between business days calculation, and the SLA goal and deadline date calculation. The calendar on the operator record is relevant only if you have users who are not working in the same time zone as the rest of the organization. Otherwise, the application uses the calendar on the organization record and you can skip this step.
- Determine the calendar instances that are needed for your application.
- Determine which operator roles need a distinct calendar.
- Determine the operator location.For more information, see Specifying calendar navigation options.
Defining the work groups
A work group determines which work queues you can access.
- In the header of Dev Studio, click .
- Review and modify the list if necessary.
For more information, see Teams.
Defining the workbaskets
A work queue is a queue of open assignments in the application.
- In the header of Dev Studio, click to display a list of work queues.
- Pega Government Platform provides a set of default work queues. Implementation teams must create their own work queues with their respective organization structure. References to the work queues must also be updated accordingly in the implementation layer.
Defining work parties
A work party represents a person, business, or organization that is involved in a case. It receives correspondence, such as email, and can be an active or passive participant based on its role. Pega Government Platform comes with default work parties, but you might need to configure them for site-specific requirements.
- In the Case types explorer, click the name of the case of which you want to modify the work parties.
- Click the Settings tab and select Parties.
- Click the work party name to open the settings for the work party.
- Make your modifications and click OK.
Implementing the security model and organization structure
After you review the existing groups and roles to determine additional groups and roles that you need, create them in Dev Studio when logged in as an administrator.
- For Access groups, click .
- For Access roles, click .
Extending an application built on Pega Government Platform
This section describes the high-level steps for creating an implementation layer on top of an application (such as Investigative Case Management) that is built on Pega Government Platform, then modifying or creating the required rules and structures to support that layer.
After the implementation layer has been created, perform the configurations that are described in the following steps. Ensure that you are logged in as a developer.
- Log in to Pega Government Platform as an administrator.
- In the header of your workspace, click the Switch Studio menu, and then click App Studio.
- In the navigation pane of App Studio, click .
- Click Setup application, and then click Done.
Setting up the application
When Application setup is run, it automatically runs the implementation layer steps that are required for the apps that are built on Pega Government Platform, and it performs the following actions.
- Overrides the lookup data pages in base applications work classes to implementation layer specific work classes and updates the source of lookup to the implementation work class.
- Overrides all node level data pages which are in the pattern inheritance of PegaPS-Data-Context class to the implementation layer and sets the access group to the implementation layer Admin Access Group. For example, if built-on is PegaGP, PegaPS-Data-Context-Application is the class. If built-on is ICM then it also considers PegaPS-Data-Context-ICM as well as per pattern inheritance.
- Updates the operators of base application with implementation specific access group and sets it to default.
- Updates the implementation Application Data class direct inheritance with the data class of the base application.
Alternatively, teams can perform the steps above manually, if only a subset of the steps is required.