Creating a brand new Application in PEGA v8 😎

What is an application?

An application is a software program that can be used by end-users. Some of the examples are “BookMyShow” for booking movie tickets, “GPay” for money transfers, “Swiggy” for ordering foods and so-on.

Why do we create Application in PEGA?

Let’s consider an example of XYZ organization requesting for a Claims application in PEGA.

• The main aim of XYZ organization is to have a software where they can process their customer claim request. This can be achieved by creating a brand new application in PEGA.
• When a new application is created in PEGA, system generates a lot of in-built rules which can be directly reused or enhanced to satisfy XYZ organization requirements.

Let’s first start with how to create a new application in PEGA followed by the list of rules that PEGA readily provides when a new application is created.

How to create a brand new Application in PEGA?

We should have developer access in PEGA to create a new application. Starting from v8, we should have access to DEV studio to create an application.

Login into the system using DEV Studio and navigate to the below option

New application wizard will prompt us to select the type of application that we wish to build.

Applications can be created in either one of following ways:

• Custom application that can be created from scratch
• New application that can be created with pre-defined application templates “Request approval”, “Service request” and “Task tracker“
• New application that can be created on top of our application specific frameworks or enterprise application
• New application that can be created on top of industry standard frameworks provided by PEGA

Custom application that can be created from scratch

It will be a stand-alone application that will be built on top of PegaRULES application. System will not generate any case types or data types during application creation.

New application that can be created with pre-defined application templates

PEGA has identified few commonly used application types and have provided template like case types, data types which can be leveraged by the new application to be created.

Let’s assume a scenario of creating an application to handle service request. The proposed way of creating application for the above requirement would be using “Service request” application type in the new application wizard.

New application on top of Application Frameworks

Application can also be created on top of framework application that we have built earlier. A typical example could be our implementation application built on top of custom framework application.

New application on top of Industry Standard Frameworks

Industry standard framework applications are applications provided by PEGA that can be used as a framework. Typical example would be Sales Automation, Customer Service, Pega Marketing and so-on..

We can build an application on top of industry standard frameworks and system gives flexibility to extend appropriate case types and data types to the newly created application.

Let’s explore about creating custom application from scratch in this post.

Creating custom application from scratch

• Create an application by selecting application type as “Custom“.
• Wizard prompts us to enter a name for the new application. Make sure that we enter the most appropriate name for our application.

System gives us option to directly create application with system generated information or to review and update the same before proceeding with creation.

PEGA recommends to manually review the configuration details before creating an application.

By default system executes “pzPrepareAdvancedApplicationSettings” Data transform to populate application details.

Default application configuration

• Application Structure -> Implementation
• Application ID -> <<Application name entered in previous step>>
• Application version -> 01.01.01
• Organization Name -> System uses function “@Utilities.pxGetRandomName(“O”,”5″)” to generate random name for organization.
• Division Name -> Div
• Unit Name -> Unit
• Class Layer -> <<Organization Name>>+<<Application Name>>+”Work”

Updated application configuration for claims

• Application Structure -> Implementation
• Application ID -> Claims
• Application version -> 01.01.01
• Organization Name -> XYZ
• Division Name -> Div
• Unit Name -> Unit
• Class Layer -> XYZ-Claims-Work

Let’s explore each configuration in detail 😳

Application Structure

Application structure can either be framework or implementation. Let’s explore layers of PEGA in our future posts. When framework is selected, the generated class will have an additional layer in its structure (FW-).

Application version is used to manage the subsequent releases of an application. It can be a Major release / Minor release / Patch release. Initial version of an application can be 01.01.01 and it can be upgraded in subsequent releases. For example;

Organization settings

We will have a separate post to understand organization structure in detail. Basics of Organization/ Division/ Unit is explained below:

Organization: It’s the organization for which we build application. [In our case it’s XYZ]

Division: If our organization has further divisions, then each division can have a separate layer and the generated application will be division specific. This can be achieved by configuring division name and enabling “generate division layer” option.

Unit: If division has further sub-divisions (units), then each unit can have a separate layer and the generated application will be division+unit specific . This can be achieved by configuring unit name and enabling “generate unit layer” option.

Once updated, click on Create Application.

Now login into the created application & verify the list of rules that the system has generated.

Let’s explore each of the generated rule in detail.

Application Rule:

Since we had chosen custom application type while creating the new application, “Claims” application is built on top of PegaRULES.

Below list of rulesets are created by the application wizard. New rulesets can be added anytime as per the business need.

• Claims:01-01 -> Implementation ruleset of claims application. This ruleset can be used to develop implementation specific rules [Case Types, Flows, Reports, SLAs etc.]
• ClaimsInt:01-01 -> Implementation integration ruleset of claims application. This ruleset can be used to develop implementation specific integration rules [Connectors and Services that might not be required across enterprise].
• XYZ:01-01 -> Enterprise/Organization ruleset of XYZ Organization. This ruleset will be reused across applications which are built for XYZ organization.
• XYZInt:01-01 – > Enterprise/Organization specific integration ruleset of XYZ Organization. This ruleset will be reused across applications which are built for XYZ organization. For Eg: Security specific integrations will be common across organization which can be implemented in this ruleset.

Security Rules:

System generates below Access Groups and Access Roles during application creation.

• Claims:Administrator -> Admin access for application. Mostly developers will have this access.
• Claims:Authors -> Business Analyst/Citizen developers usually have this access. It’s equivalent to admin access with few restrictions in terms of accessibility. By default Pega Express portal will be launched for this Access Group.
• Claims:Managers -> Case Managers usually have this access. They have access to work on cases, view team members and their works, view reports and so-on.
• Claims:Users -> Case workers usually have this access. They have very limited access to system in terms of managing work.

Required access roles will be created for each access group and it will be directly inherited from dependent roles. Dependent role in PEGA v8 are roles that are pre-defined by PEGA.

Dependent roles have AROs/privileges which defines the authorization. It can be customized or extended with application specific access roles.

Class Rules:

The system generates the below class rules which can be extended for our business needs.

Implementation classes

XYZ-Claims-Work ->Implementation specific work class. This will be considered as Work pool/Class group of claims application & corresponding database table will be created by the system. All our case types/work classes will inherit from XYZ-Claims-Work.

XYZ-Claims-Data -> Implementation specific data class. All the data classes/data types that are specific to claims application will be extended from XYZ-Claims-Data, which is an abstract class.

XYZ-Claims-Int-> Implementation specific integration class. All the integration rules specific to claims application will inherit XYZ-Claims-Int class. This class will be used as parent class while configuring integration wizard.

Enterprise/Organization classes

Enterprise ruleset will not have work class.

XYZ-Data -> Enterprise data class. Data class created in this layer can be used across multiple applications built on top of XYZ Organization. Enterprise data class can be reused across division and unit layers if exist.

XYZ-Int-> Enterprise integration class. Integration rules created in this layer can be used across multiple applications built on XYZ Organization. Enterprise integration ruleset can be reused across division and unit layers if exist.

Finally, we are done with our claims application creation 😎😎😎

Once application is created, case types, data types can be configured based on the business need.

Hope now the basics of creating a custom application, understanding the back-end rules & extending it for our need is clear.

We are glad to publish the article requested by @Vamshi on “Creating application from scratch”. If you want us to publish any articles of your choice, please fill out this form & we will make sure it gets published.

Stay tuned for more posts on Enterprise Design !!!