Application extension for different user populations

In a global enterprise application, you may have to extend the existing application to fulfill business expansion requirements. Some of the more common application extension requirements include:

• Extending an application for a new user population
• Splitting an existing user population

To extend the existing application for the new set of users, you can use one of the following methods:

• Extend the application within the existing database 
• Extend the application by deploying to a new database

Method 1: Extend the application within the existing database 

To support a new user population within an existing database, you run the New Application wizard to generate an application that extends the classes of the existing application’s case types. The wizard creates a new class group for the new user population; case data is stored in separate tables. 

For example, you may require a new user population to handle Online Streaming events in the current FSG application. Create a new application, Online Streaming Event, by extending the Booking application.

Assignment and attachment instances in the application cannot be separated into different tables based on application. You can leverage the following Organization properties to restrict access between these applications. 

Suppose the new user population is associated with the new division, and this new user population should not access any assignments created in the original division. The easiest solution is to implement a Read Access Policy in the Work- class that references the following Access Policy Condition. 

pyOwnerDivision = Application.pyOwningDivision

AND pyOwnerOrg = Application.pyOwningOrganization

Method 2: Extend the application by deploying to a new database

Ruleset specialization within new applications built on the existing application would suffice to support a new user population, provided they are hosted within a new database.

For example: Suppose there is a requirement for a new user population to handle Online Music events. Create a new application, Online Music Event, by extending the Booking application. Host that new Online Music events application within a new database.

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 the right approach. If the application uses background processing, there is duplicate processing. 

Two of the major deployment approaches are possible:

• Move a subset of the existing user population to a new database
• Create subsets of the existing user population within the original database

Move a subset of the existing user population to a new database

Suppose you create a new database to support a subdivided user population, and immediate user migration is not required. In that case, 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 the resolved cases from the original system immediately. It is a best practice to wait until the migration process is complete for the user or account. You 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).

Create subsets of the existing user population within the original database

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

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 from an executive at Pega before attempting a user population split for the same application within the same database.