The definition of the documentary requirements is articulated through three main data entities: requirement sets, requirements and documents.
The maintenance of these three data entities can be performed from:
- Requirements Portal
- This portal allows users to maintain requirements set, requirements and documents in a user-friendly manner. It is available by default for the standard CLM administrative access groups and can be added to other access groups as required (look for RequirementsPortal portal).
- Dev Studio
- Developers can manage the documentary requirements from Dev Studio by accessing the three data entities, all available under .
Using the forms available from these two points, users should be able to configure most of their documentary requirements. However, there are some advanced capabilities that should be enabled taking additional steps. The following section lists these tasks.
Configuring ruleset and base class for the portal
The Requirements Portal helps users with the maintenance of requirement sets, requirements, and documents.
The requirement sets and requirements are implemented in the system as rules that need to be associated to a specific application, ruleset, ruleset version, and class. In runtime, these values are determined by the configuration loaded through D_ReqConfiguration.
Use the available extension point LoadConfiguration_Ext to set the right values.
Ruleset, where the new and updated rules are stored.
For example, UPlusRequirements.
Ruleset version, where new and updated rules are stored. To enable the creation or modification of rules, the ruleset version must be unlocked.
For example, 01-01-01.
Name of the application that the rulesets belong to.
For example, uPlus.
The requirements application by default uses the PegaReq-Data-ReqVerify- class.
If you want to use a different class, set its class name in this property.
Defining document extended attributes
The second stage in the processing of a requirement is data-capture. In that stage, the user performs two basic operations: confirms that the collected document is in good order and captures the data that might be required for that document according to its type.
The definition of the attributes required for each specific document type is done in two different places.
- Expiration or stale date
- During the definition of a document type, either from Requirements portal or from Dev Studio, users can specify the expiration and stale date of the document should be collected. When these options are selected, the data-capture stage automatically ensures that the data is captured as per configuration.
- Extended attributes
- Any other attribute required for a given document type needs to be configured by a developer by completing the steps below.
Create a new class under PegaReq-Data-DocLib to represent the document type. For example, if you need to create attributes for a Passport document type, create a class like PegaReq-Data-DocLib-DocPassport.
Define the attributes as properties under the new class or directly on PegaReq-Data-DocLib class, what will let you later reuse properties across different document types.
Create under the new class a section with name DocumentAttributesView. This section should contain the properties that you have created and will be embedded in the data-capture stage for documents of this type.
Create under the new class a data transform with name SetDocAttributeRelevance. Take the base version available at PegaReq-Data-DocLib as reference.
Modify SetDocAttributeRelevance to add one entry per required attribute to the DocumentPage.DocRelevanceAttributeList list. For example, if you need to capture for your Passport the nationality and the passport number, create in this data transform two entries in the DocRelevanceAttributeList.
6. Run the activity named SaveAttributestoDocument to register the configuration that has been created in the document definition. Provide the following two parameters:
- DocId - Document ID (for example, Passport)
- DocumentClass – Document Class (for example, PegaReq-Data-DocLib-DocPassport)
The activity will open the definition of the document identified by DocId and invoke SetDocAttributeRelevance to register the attributes there.
After these changes are done, the new section will appear in the data-capture stage for the documents of the selected type. The defined attributes will be captured through that section and automatically stored along with the document. The information will be stored in two different places:
- Document metadata table
- Attributes are stored for its later use in the BLOB of the entry for the document in the document metadata table.
- Attributes index
- The attributes are also made available through a declare-index on the document metadata table. The index populates a database table that can be used by financial institutions to find documents using their attributes.
While the persistence of attributes in the document metadata table is essential for a good behavior of the functionality, the attributes indexes are not currently in used. If your organization is not planning to implement any functionality based on this table, it can be disabled and, that way, reduce the overall database footprint. The following when rules can be used to disable it.
Rule name Rule type Usage
When Set the when rules to false to disable the declare-index and therefore avoid the generation of entries in the attributes index table
If, on the contrary, you want to use the attributes index but you would like to make changes in the way the index is generated, you can also make some adjustments.
Rule name Rule type Usage
Data transform Extension point for consuming applications to define app specific logic to extract Name value pairs from DocAttributePage and populate Attribute list, which is used for indexing attributes Previous topic Introduction to requirements Next topic Synchronization engine