During the data mapping work, you will have identified the delta between the shipped data model and the required data model for your business needs. Using that delta, the next task will be to extend the shipped data entities.
|Primary role||Senior System Architect|
|Secondary role||Senior Decisioning Architect|
For performance and data integrity reasons, Customer Decision Hub uses a copy of your customer data rather than the raw original. To accomplish this, a separate data schema is used. This is the external marketing data schema – ExternalMKTData. At a minimum, there needs to be a customer table in this schema. To maximize performance, your customer table should be flattened with limited associative entities and foreign tables.
That table is joined to other internal tables and interaction history data for segmentation purposes. This means that the customer data must exist on the same database instance that hosts the interaction history tables to support the join we’re talking about.
To extend the existing customer table, create an implementation customer class that direct inherits the shipped customer class PegaMKT-Data-Customer and add your identified delta properties to it. Then define a database table rule with a table name. Generate a RAP of these and reimport them for Pega to create the required database table. For more details on this, see the Pega Cloud support document on Best practices for managing data on Pega Cloud availablehere. If you are an on-premise customer, you can still follow these instructions or you can work with your DBA and directly update your database.
At a minimum, your customer class needs to have properties for full name, email, mobile phone number, and a customer class key and table key. Typically, your customer class key and table key are the same and represent a unique customer identifier. You do not need to fully define out all the properties in your data entities in this task. This will be accomplished in Task-040503:Map the new data to the Pega classes.
Follow the same steps for creating classes and tables for associated data entities.
The following table maps database table fields to properties:
Text (single line)
Date & time
The following table describes the available options for relational databases on the Database Table form:
Identify a database instance that corresponds to the database containing the table or view.
Optional. Identify a database instance that contains a copy of this table, replicated through database software.
Complete this field only if a database administrator has created a mirrored replica of all or part of the PegaRULES database that is sufficient to support reporting needs, and established a replication process. To reduce the performance impact of report generation, you can specify that some or all reports obtain data from the reports database.
The sources for a report cannot span multiple databases. If a report definition presents data from multiple tables, all required tables must be in one database. This database can be either the PegaRULES database or a single reports database.
Optional. Identify the database catalog containing the schema that defines the table or view.
In special situations, a catalog name is needed to fully qualify the table.
Optional. Identify the name of the schema (within the catalog) that defines the table. The schema name is required in some cases, especially if multiple PegaRULES database schemas are hosted in one database instances.
Enter the name of the specific table that is to hold instances of the specified class or class group.
When allowed by the database account, enter only an unqualified table name. Preferably, the database account converts the unqualified table name to the fully qualified table name.
A few of the database table instances that are created when your system is installed identify database views rather than tables. Views are used only for reporting. By convention, the names of views in the initial PegaRULES database schema start with pwvb4_ or pcv4_.
If you create additional views in the PegaRULES database, you can link to them to a class using a database table instance. The view data then becomes available for reporting.
After you save this Data Table form, you can test connectivity to the database and table. This test does not alter the database. The test uses information on this form, the associated database data instance, and in some cases, information from the prconfig.xml file, dynamic system settings, or application server JDBC data sources.
Once the task is complete, you will have all the tables created physically in ExternalMKTData schema and the database table rules in Records > SysAdmin > Database Table. To ensure that everything is configured properly, you can validate the mapping between your customer class and the specified database table by clicking Test Connectivity button.