Understanding AAF

This section provides an overview of AAF.

This section discusses:

AAF structure.
Data library.
Action framework.
Policy builder.

This section discusses AAF from the CRM perspective. For more information about AAF components and how to set them up, refer to thePeopleSoft Active Analytics Framework documentation. This documentation also covers other components of the policy builder framework, such as the operator sets, business domains, and trigger types.

AAF Structure

AAF is a decision-making system that invokes actions based upon the evaluation of user-defined business rules. AAF provides a user-friendly environment in which functional users can build business rules using the simple if-then structure.

AAF provides components for setting up the analytic framework, which includes managing the data library, building policies, and managing trigger points and actions. These components provide a mechanism to define flexible business rules (which are called policies) that can be altered without modifying application code. Business analysts and other functional users define policies using an intuitive user interface.

Functional users can create policies that use data elements of various forms and shapes residing in different sources such as the transactional environment, data warehouses, legacy systems, and so on. The data elements are exposed to the business user as terms, which are defined in the AAF data library.

Image: AAF policy structure

This diagram illustrates the structure of policies, which get evaluated when their triggering events take place.

The major components of AAF consist of these components:

Data library.
Action framework.
Policy builder.

Data Library

Data library is a catalog of metadata about information of various shapes that is stored in different data resources. It consists of data elements called terms, which are pointers to disparate pieces of data residing in a data warehouse, an external database, or the operational environment such as PeopleSoft CRM. Terms are essentially metadata, which provide source and access information about the physical data. A term is associated with one or multiple implementations, which refer to the mechanism through which the data is retrieved, derived, or computed. The implementation is responsible for knowing either where the data is physically residing or the algorithm for deriving the value.

In AAF, functional users can reference terms when they build policies in the policy builder. In addition, the data library is used as a common data repository and extraction framework in various CRM applications and functionality. For example, correspondence management replaces the use of tokens with terms in correspondence templates.

Action Framework

The action framework provides an infrastructure for IT personnel to define actions that can be associated with policies in the policy builder, and facilitates the invocation of actions at runtime when the conditions of policies are evaluated as true.

An action type refers to a category of actions that can be associated with a policy. For example, display of alert messages and instantiation of business projects are all policies. The action type definition points to a class of similar actions. In some cases, the definition of a category of actions may not contain all the information that is needed by the decision engine in AAF to launch an action.

Therefore, when functional users specify an action when they are creating a policy, they need to provide additional configuration details to ensure the proper invocation of the action. For example, when users associate a business project action in a policy, they need to identify the actual business project in the configuration page that is developed for that action, which gets instantiated by the system.

In addition to creating and managing actions that are triggered in AAF as a result of a positive evaluation of policy conditions, other CRM applications leverage the framework to define actions that would be used by their own application logic, not through AAF. For example, the automated mail processor in the email response management system (ERMS) performs actions on them based on the email category and predefined rules. It uses the action framework to define these email-related actions (such as auto-route and auto-acknowledge), which get triggered by application class methods that are referenced in the application.

See Understanding Automated Mail Processing.

Policy Builder

The policy builder provides a user-friendly environment for functional users to construct policies in a natural business language. A policy consists of three parts—a trigger point, conditions, and actions:

A trigger point is the occurrence of an event that triggers the evaluation of conditions in policies that are associated with it.

Examples are When a customer is presented in a case and After a change request is saved. This is where functional users want the system to drive actions.
A condition is the if statement, which specifies under what circumstance some action would be performed.

Examples are If customer value is high and If the change request status is changed.
An action is the then statement, which is invoked if the associated conditions are evaluated to true.

Examples are Display alert message on screen and Log a change request history entry.

While the policy builder is primarily used in AAF to define and maintain polices, other CRM applications leverage the framework for building conditions and getting condition evaluation. For example, profile management enables users to define AAF conditions, which are evaluated at runtime to determine whether certain profile groups need to be displayed on a customer data model (CDM) component.