Maintaining data integrity

On the Locking tab of a data class rule, select Allow locking to allow instances to be locked. The Locking tab is displayed only when the data class is declared concrete as opposed to abstract. By default, the class key that is defined in the General tab is used as a key.

A potential data integrity issue can arise if you are querying two different tables in a database for the same entity. If you are retrieving data from similar columns that exist in both tables, the values in those columns may be different.

To avoid these potential conflicts, keep in mind the single source of truth principle. This is the practice of structuring information models and associated schemata such that every data element is stored exactly once.

Within a case hierarchy, you may want to always use data propagation from a parent case to each child case. However, if the data propagated from the cover is subject to change, then accessing the data from pyWorkCover directly is better. You can use a data page if you need to access data from a cover’s cover.

The following image illustrates the propagation of information from the WorkPage to a Claim case (W = WorkPage and C = Claim). W1 is the original WorkPage, W2 is W1’s cover, and C is W2’s cover.

The use of recursion in the example is avoidable by defining a ClaimID property at Org-App-Work and ensuring that the value of ClaimID is propagated to each child case. A subcase’s pxCoverInsKey never changes. Not setting the ClaimID property initially and propagating it leads to information loss, which requires effort to recover. Any property that is not subject to change can similarly be propagated, especially for reporting and security enforcement purposes.

Referencing pages outside a case has the additional benefit of reducing the case’s BLOB size. A smaller BLOB reduces the amount of clipboard memory consumed. The clipboard can passivate memory if it is not accessed within a certain period of time.

Instead of maintaining large amounts of data within the BLOB as either embedded pages or page lists, consider storing that information in CustomerData schema tables that do not contain a BLOB column.

Accounting for temporal data is another way to help ensure data integrity. Temporal data is valid within a specific time. One approach to accommodating temporal data is to create data classes using a base class containing Version and IsValid properties. The base class can also contain properties suited for lists such as ListType and SortOrder.

Alternatively, you can accommodate temporal data using a custom rule. Custom rules can be the best approach for maintaining a list that contains a list. For example, assume you create a survey that contains a list of questions. Each question has a list of responses. You could define a Rule-Survey rule class and the following data model.

• QuestionList – A field group list of class Data-SurveyQuestion
• ResponseList – A field group list of class Data-SurveyResponse

Each Data-SurveyQuestion owns the ResponseList.

Using data pages to perform SnapShot Pattern lazy loading can compromise data integrity if the data page lookup parameters do not account for temporal data. The child case can load information newer than the information that the parent case communicates to a customer.

You can use data propagation to child cases, but this approach can cause redundant data storage. To avoid this issue, you can have child cases refer to their cover case for the information (the questions and possible responses) sent to the customer. Only the cover needs the SnapShot Pattern. The child case needs to record just the customer’s responses to each question.