Understanding Contexts
This section discusses:
Context lookup.
Contexts and AAF.
Term selection for contexts.
Context and business process associations.
Context Lookup
PeopleSoft CRM delvers these types of contexts:
Context for policies.
These contexts are used by the decision engine for evaluating policies.
To lookup policies that are associated with certain contexts, use the Manage Policies page. Select
Context for terms in automatic workflow notification.
These contexts are used for resolving terms present in a template for sending automatic workflow notification from the stated component.
To lookup contexts that are associated with automatic workflow notifications, use the Context Relationships page. Select
Context for terms in manual notification or correspondence request.
These contexts are used for resolving terms present in a template for sending manual notification or correspondence request from the stated component.
To lookup contexts that are associated with automatic workflow notification, use the Validate Terms and Templates page. Select
On the Validate Terms and Templates page, click the lookup button for the Context Name field.
Contexts and AAF
Contexts are considered foundation objects for AAF. Contexts provide the necessary input data (as specified in context definition) that is needed for resolving the terms by AAF. These terms, for example, can be present in policies, or in correspondence templates.
Contexts are a key component of how the AAF works. The purpose of the context is to describe the computing environment from which the decision engine or the data library engine is invoked and to play a role in selecting the appropriate term implementation to be used at runtime for resolving a term. Please refer to the topics on managing contexts in the PeopleSoft Active Analytics Framework documentation to get more information about contexts.
PeopleSoft CRM transactions use AAF for different purposes, such as requesting decision engine for evaluating policies, requesting data library engine for resolving terms in actions that trigger automatic workflow notification, manual notification, and correspondence requests.
In some cases, a single context may not be sufficient to provide the necessary content for delivering all the mentioned functionality for a transaction because some of the features, such as resolving terms that are present in templates that are found as part of correspondence requests, occur outside of the transaction. Therefore, more than one context may be present for a component. The appropriate component-specific context that is used depends upon the functionality that needs to be invoked.
Term Selection for Contexts
Features such as policy builder and condition builder ensure that the terms that are selected for building a policy are resolvable within the trigger point's context.
For AAF the system displays all the terms that are present in the subject area of the data library. Therefore, users need to ensure that a term can in fact be resolved within that context before selecting it.
For example, terms that are created for use in correspondence templates are categorized within subfolders under the Correspondence Template Terms subject area. Each subfolder contains application-specific terms that can be resolved using other components.
Context and Business Process Associations
PeopleSoft delivers contexts, business process names, and activity names as system data. Each delivered context has at least one delivered association with a business process name and activity name. Some have two or more. Most of the time during workflow notification, the system-delivered associations provide the values for the business process name and the activity name.
Administrator can create their own relationships using the Context Relationships setup page (select
). Use this page to define the relationship between business processes and activities that are valid for a particular context. When you are creating a policy, the user won’t have to add a business process or activity because the system automatically adds the fields behind the scenes based on the policy’s context ID.On the Notification and Workflow action page, the system hides the Business Process Name and Activity Name fields are populated behind the scenes and hidden from the user.
and fields from the user because they can be derived automatically from the context. The system populates these fields by default, based on the context of the policy. If the setup page contains a one-to-one mapping between these fields, then theIf you set up a one-to-many relationship, then the system displays these fields in a drop-down list box and lists the available values. On the Context Relationships setup page, you can select a default business project-activity relationship. The system uses this default relationship initially in the drop-down list, but users can also select values from the ones that are made available.