This presentation is part of the Declarative Pages Self-Study Course.

Transcript

Declarative pages enable developers to define a set of named clipboard pages for an application. They are created and refreshed on demand as they are needed by other rules.

The created pages are treated as reserved, so other rules (such as activities) cannot be used to update or remove them. However, conditions can be defined to trigger the refreshing of declarative page data.

Once the page has been populated, it is marked as read-only to maintain data integrity. The page can easily be shared by multiple requestors. It is for this reason that all of the properties on the page are not modifiable, and no new properties can be added to the page.

Declarative pages support the sharing of this data by the many users of an enterprise system. Examples of the data types to be shared are:

• Cached global system settings
• Lookup lists
• Product information
• Any other application wide information that should ideally be shared

A declarative page can be stored at the thread or node level.

Thread level pages allow developers to define pages similar to those generated by the existing Locate Page facility. In other words, the page is accessible to a given requestor’s process.

Node pages, on the other hand, are available to all requestors on a given node or application server. These pages can be used by developers to store common data in one place that is shared by multiple users of an application.

Note: Declared pages are available in PRPC version 5.3 or later. To implement global clipboard pages in PRPC versions lower than this, refer to the PDN Article PRKB-17593.

All declare pages are cached and remain on the clipboard until further notice; hence, improving performance.

Declare pages defined at the Node level also insure data integrity between multiple users since these pages are shared by all requestors on a given system node. Examples might include:

• Lookup lists
• Code tables
• Organizational information
• Translation tables
• System settings
• External data that changes infrequently
• Any commonly used enterprise information

For thread level pages the same benefits apply, with the exception of being able to share data between users. Thus, the idea of rule driven research or backward chaining is simpler to implement. Thread page examples might include:

• Cache information about the current user
• Credentials
• Personal information (such as address information)
• Customized user preferences
• Information about the process or activity executed

This is best explained by a simple example. In our auto insurance application, we use many risk modifiers to calculate an underwriting score. The underwriting rules (decision rules, declarative expressions, activities, etc.) responsible for doing the calculation simply reference properties in declared clipboard pages. At runtime, because the data is required, the pages and their properties are either referenced if they already exist, or they get created by the appropriate load activities.

The rules that define the generation of these pages are not defined as part of the underwriting process that uses them. Why is this beneficial? Because it separates the two components and if, in future we want to change the data source or the way it gets retrieved, or even reuse the data in other applications, it’s easier to maintain and is nicely encapsulated, apart from the processing application rules.