The topics in this section describe how to activate functionality.

Activating 2G

The first step in the process is the activation of 2G. This configuration ensures that all new requirements are created using the new capabilities and that the engine follows the new rules.

1. In Dev Studio go to RecordsSysAdminDynamic System Settings.

2. Open the dynamic system setting PegaCLMFS Requirements/ActiveGeneration.

3. Change its value to 2.

4. 4. Click Save.

   If you are going to continue making changes under the current session, force the loading of the configuration by flushing the data-page D_ReqConfiguration.

Creating new requirements

The new generation of the functionality uses a separate set of requirement sets, requirements and documents.

At the time of activating the functionality in the production environment, there are two active set of rules:

Legacy requirements

The requirement sets, requirements and documents defined before the activation of 2G are used by the system to resolve the in-flight cases that might exist at the time of activation.

New requirements

The new set of rules are used by the new engine to create new requirement cases taking advantage of all the new capabilities provided by 2G.

If you are using the out-of-the-box requirements shipped with Pega Client Lifecycle Management for Financial Services, these two sets will be immediately available after the install of the 8.5version of the product. If, on the contrary, you are using your own defined requirements, you need to create that new set of rules.

The new functionality introduces a completely different paradigm, and trying to replicate the current arrangement of sets, requirements and documents in 2G without adopting that new paradigm can have significant implications in terms of performance and operations.

There are main differences to be considered at the time of creating the new set of rules for your organization:

Requirement-document cardinality

Requirements can now manage multiple documents. They can also manage different business scenarios and a satisfaction logic that can dynamically change as the data of the case changes. This new approach changes significantly the way in which the requirement sets and requirements should be used.

In previous versions, a requirement set used to represent a business requirement (for example, proof of identity). The requirement was the way to link it to a specific document. In the new version, the requirement can manage by itself a whole business requirement and that gives to the requirement set a completely different purpose: grouping together related business requirements.

Requirement set purpose

In previous version, all requirement sets were considered by the synchronization process. In 2G, the synchronization engine can be configured to look only at certain groups of requirements based on business rules. That grouping of requirement sets is implemented by what is called the purpose.

For example, you have two different groups of requirement sets, one group created for customer identification and another one for tax purposes. The customer identification sets do not need to be considered in an offboarding journey.

For example, we can tag a group of requirement sets created to collect documents for customer identification with a purpose Customer Identification Purpose (CIP). We can then configure the engine to consider the CIP purpose only under certain circumstances (for example, in all journeys except in offboarding). The purpose concept gives us the ability to segregate requirement sets and achieve this type of configuration.

For the actual creation of requirement sets, requirements and documents, you can use Dev Studio or the Requirements Portal. If you are going to use the latest one, you must configure it to generate the new rules under the appropriate rulesets. For more information, see Configuring ruleset for the portal, in chapter Requirements definition).

Configuring the engine

After the new requirements are defined, it is time to configure the synchronization engine. If you are using the requirements that comes out of the box with Pega Client Lifecycle Management for Financial Services, the synchronization engine are already configured for you. If you are using your own requirements, you must configure the engine to ensure they are considered during the synchronization.

The section Synchronization engine describes in details how the engine works and what should be configured. You should pay special attention to the following tasks:

Configuring the relevant purposes

Configure the engine to consider the new requirement sets that you might have created.

Building up the requirement set locators

Ensure that the engine knows which locators should be used for each specific purpose.

Adding more information to the context

Ensure that the engine has all the information that it needs to run the applicability rules of your new requirements.

Copying new requirements case type

The new functionality implemented in the requirement cases is driven by a new version of the requirement case type. The new version is a circumstanced version of the legacy case type and that it is not likely to be accessible from your implementation layer. To ensure that your application uses the right version of the case type, make a copy of the circumstanced version. For more information, see Copying requirements case type to the new class structure in chapter Building a new application.