Glossary:Historical processing

Historical Processing, historical processing

Historical processing is a feature that enables an application (for the current requestor) to operate based on how rules were defined on a specific date. Such processing is useful to reconstruct past behavior or apply past policies.

Historical processing applies to an entire ruleset version, not a single rule.

A feature that enables an application (for the current requestor) to operate based on how rules were defined on a specific date. Such processing is useful to reconstruct past behavior or apply past policies. Historical processing applies to an entire ruleset version, not a single rule.

A feature that enables an application (for the current requestor) to operate based on how rules were defined on a specific date. Such processing is useful to reconstruct past behavior or apply past policies. Historical processing applies to an entire ruleset version, not a single rule.

A capability that you implement in your application. By defining features that are linked to rules and work items, you can improve the traceability of capabilities to their respective implementations.

The process and data associated with a Pega Platform user (guest or authenticated). A requestor is also the processing and data associated with a request to your system started by an outside system, such as a web application server or an Active Server Page on a web site.

The basic building blocks of an application, rules define the behavior of an application. There are many types of rules, each defining a different type of behavior. For example, rules define the display of a form, the fields that are used in your application, and the flows that define the process of completing work.

The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a user interface to capture an address, and reuse the same rule for the UI to capture both the mailing address and the billing address for the order.

You define rules in an application to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently, so that they can be implemented again in future projects.

The ruleset version characterizes the evolution and development of a rule instance, and the application it belongs with. The version number, in the format NN-NN-NN, defines the major version (first two digits), minor version (middle digits), and patch version (last digits). Rules in versions below the major version are not visible to rule resolution.

The basic building blocks of an application, rules define the behavior of an application. There are many types of rules, each defining a different type of behavior. For example, rules define the display of a form, the fields that are used in your application, and the flows that define the process of completing work.

The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a user interface to capture an address, and reuse the same rule for the UI to capture both the mailing address and the billing address for the order.

You define rules in an application to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently, so that they can be implemented again in future projects.