Application-extending for new user population

Extending a production application can occur for various reasons, planned or unplanned. Some of these reasons include:

• The enterprise has planned to sequentially roll out extensions to a foundation application due to budgetary and development resource limitations
• The enterprise has discovered the need to:
  • Extend the production application to a new set of users
  • Split the production application to a new set of users

In either situation, the resulting user populations access their own application derived from the original production application.

The previous scenarios fall into two major approaches:

• Extending the existing production application to support a new user population
• Splitting the existing production application to support subsets of the existing user population

Within each of the two major approaches are two deployment approaches: either to a new database or to the same database.

Whether extending or dividing an application, you can host the user populations on either a new database or the original database.

When you deploy the application to a new database, the data in both applications are isolated from each other. For instance, you can use the same table names in each database. Use ruleset specialization to differentiate the rules specific to each application's user population. This approach is similar to using foundation data model classes — embellishment is preferable to extension. You do not need to use class specialization.

When you deploy to the original database, use class specialization to differentiate the data. Class specialization creates new Data-Admin-DB-ClassGroup records and work pools. As a result, case data is written to tables that are different from the original tables.

Security enforcement between applications hosted on the same database is essential. Unlike case data, assignments and attachments cannot be stored to different database tables. You can avoid this issue by using Pega’s multitenant system. Discuss with the organization whether Pega’s multitenant system is a viable option.

Applications, cases, and assignments contain various organization properties. Use these properties as appropriate to restrict access between applications hosted in the same database.

Run the New Application wizard to achieve class specialization. In the Name your application screen, click the Advanced Configuration link. Under Organization settings, enter at least one new value in the Organization, Division, and Unit Name fields.

Suppose the new user population is associated to new division and there is a requirement to prevent an operator in the new division from accessing an assignment created by the original division. The easiest solution is to implement a Read Work- Access Policy that references the following Work- Access Policy Condition.

  pxOwnerDivision = Application.pyOwningDivision

AND pxOwnerOrganization = Application.pyOwningOrganization

Alternatively, you can also define an access deny rule.

When...

  pxOwnerDivision != Application.pyOwningDivision

OR pxOwnerOrganization != Application.pyOwningOrganization

If you extend an application to support a new user population, the extended application can be:

• An application previously defined as a foundation application
• An application that becomes a template, framework, blueprint, or model application on top of which new implementations are built

When deploying to a new database, ruleset specialization is sufficient to differentiate the existing application’s user population. Use the ruleset override procedure described in the Designing for Specialization module to specialize the existing application and to define the new application.

To support a new user population within an existing database, run the New Application wizard to generate an application that extends the classes of the existing application’s case types. Then use the ruleset override procedure described in the Designing for Specialization module to specialize the existing application.

In some situations, you may want to split an application's existing user population into subsets. The resulting subsets each access a user population-specific application built on the original application.

When active cases exist throughout a user population and there is a mandate to subdivide that user population into two distinct applications, reporting and security become problematic. Cloning the existing database is not a good approach. This can make controlling duplicate access, such as agents, difficult.

If you create a new database to support a subdivided user population, and immediate user migration is not required, you can gradually transition user/account data from the existing database to the new database. Ideally, transfer user/account data starting with classes that have the fewest dependencies. For example, attachment data does not reference other instances.

Copy resolved cases for a given user/account to the new database, but do not purge resolved cases from the original system immediately. Wait until the migration process is complete for that user/account. Use the Purge/Archive wizard to perform this task (DEV Studio > Configure > System > Operations > Purge/Archive). Optionally, modify case data organization properties to reflect the new user population.

A requirement to immediately move a subset of an existing user population to a new database is more complex due to the likelihood of open cases. Use the Package Work wizard to perform this task (DEV Studio > Configure > Application > Distribution > Package Work).

The most complex situation is when immediate user population separation is mandated within the same database. To support this requirement, a subset of the existing cases must be refactored to different class names.

Manipulating the case data model for an entire case hierarchy while a case is active is risky and complex. For this reason, seek advice and assistance before attempting a user population split for the same application within the same database.

Avoid refactoring every case type class name when splitting a user population within an existing database. Refactoring class names is a time-consuming process. Businesses prefer the most expedient and cost effective change management process. The most cost effective approach keeps the largest percentage of users in the existing work pool class and moves the smaller user population to a new work pool class.

Pega auto-generates Database table names. APP Studio generates names for rules such as When rules, Flow names, and Sections. Case type class names need not exactly reflect their user populations. An application's name, its organization properties, and associated static content are sufficient to distinguish one specialized application from another.

The notion of defining a framework, foundation, template, model, or blueprint layer that abstracts a business process is sound. In the past, these foundations classes used the FW (FrameWork) abbreviation in their class names. Naming case classes using the FW abbreviation sometimes occurs at the beginning of the development process. If during post-production an implementation application becomes a framework application, its class name does not contain the FW abbreviation. This abbreviation is optional, not a necessary, naming convention.