Setting Up the Data Library

This section gives an overview of the data library and discusses how to:

• Use the data library components.

• Create implementations.

• Create terms.

• Manage terms.

• Test term implementations.

Understanding the Data Library

The data library is a repository for information within the PeopleSoft Active Analytics Framework. Each element in the data library is exposed by way of a term, which is a pointer to a unit of data within the PeopleSoft system. This data may reside in a relational database, or it may be derived at runtime.

See Also

Understanding PeopleSoft Active Analytics Framework

Using Data Library Components

This section describes the components used to populate the data library.

Pages Used in This Chapter

Creating Implementations

An implementation refers to the mechanism through which the data is retrieved, derived or computed. The implementation knows either where the data physically resides or it knows the algorithm for deriving the value. All terms must be associated with an implementation unless the data to which the term refers is present in the component buffer.

An implementation can be associated with more than one term. Conversely, a term may require multiple implementations if it needs to be resolved from multiple contexts. Typically, application developers or IT personnel develop implementations.

Note. Terms that are resolved by accessing data available in the current operating component's buffer, do not need implementations to be developed. PeopleSoft Active Analytics Framework provides mechanisms to access data available in the component buffer.

PeopleSoft recommends that when multiple related terms will be accessed during a single business event, create a single implementation to return a rowset containing the data for several terms; then, specify which data element or field position in the rowset or record is to be used for the term.

Implementations are developed using:

• Application class.

  Use application class implementations when retrieval or derivation of data involves writing procedural code; or, as a resolution method when data must be retrieved from an external source such as another PeopleSoft database or legacy systems. The application class can return data to the data library in a variety of forms: rowset, record, date, datetime, string, number, date array, datetime array, string array, number array and array of any. Use PeopleSoft Application Designer to develop the application classes.

  Note. PeopleSoft does not recommend: 1) Using an application class to retrieve data from a component buffer; 2) Using an application class to retrieve the values for the binds directly by accessing the component buffer without registering them as implementation binds. Application classes must use APIs to retrieve the values for the implementation binds (input parameters).

• PS Query .

  Use Query Manager in PeopleSoft Application Designer to develop PS Query-based implementations. PS Query implementations are not appropriate for applications that get data from external databases or systems. The data library invokes the appropriate queries based on the information provided when you register the implementation. The data returned is available to the data library in the form of rowset.

• SQL object.

  Use this implementation when the SQL used needs to be platform independent and the data need not undergo complex transformations. SQL Object implementations are not appropriate for applications that get data from external databases or systems. The data library invokes the appropriate SQL object based on the information provided when you register the implementation. The data returned is available to the data library in the form of a record or an array of any objects. Use PeopleSoft Application Designer to create an SQL Object.

• Record.Field

  Create a Record.Field–based implementation when the data can be retrieved directly from a table without going through complex transformations. The data returned is available to the data library in the form of string, date, datetime, number, string array, date array, datetime array and number arrays.

Registering an Implementation

With the exception of component buffer implementations, all implementations must be registered in the PeopleSoft Active Analytics Framework. Before registering an implementation, you should have already defined PeopleSoft Application Designer objects if using application class, PS Query or SQL Object implementation methods.

Specify the following in the registration component:

• Functional name.

• Resolution method used for that implementation

• Values for the parameters needed for invoking the implementation. The list of parameters vary depending upon the resolution method.

• List of binds that are expected by this implementation.

Note. The binds specified for an application class implementation are referenced in the application class object for retrieving the values. Therefore, changing these implementation bind names can have adverse effect on the term resolution.

For IT users: The list of implementation binds specified are being used for two purposes: 1) To allow implementations to access these bind values. For any implementation, bind values are passed by position regardless of the resolution method used. Application class-based implementations alone have the additional capability to access the bind values by name. 2) To allow the data library engine to use these binds to uniquely tag the data in application cache. If IT users “take a short cut” by retrieving the necessary data by directly accessing the context (by not registering the data as implementation binds), the data library engine may, as a result, tag the data with incomplete key information. This could cause the same cached data to be incorrectly reused for resolving terms for which it is not valid.

Creating Terms

A term is a user-friendly name that refers to the data library content. It's essentially a piece of information that could exist in the PeopleSoft system or an external system, or it could be derived. For example, the data could be available in the component buffer; retrieved using a PS Query or an SQL object; or, computed using an application class.

Terms are the building blocks in policies. Functional users can build conditions for a policy using terms present in the data library. Terms must be registered in the PeopleSoft Active Analytics Framework before they can be used.

Registering a term is a multi-step process that includes:

• Developing an implementation.

• Registering the implementation.

• Defining the term.

• Associating the term to one or more subject areas.

• Testing and activating the term.

Understanding Term Properties

Defining a term involves specifying the following:

• Term name, code and type (constant or variable).

• Data type.

  The data library supports primitive data types of string, number, datetime, date , time; and PeopleSoft-specific data types of record and rowset.

• Number of rows to be returned, scalar or vector (returning an array). (Terms that are record or rowset data types have number of rows set to One).

  Note. Terms returning a vector (where value of number of rows is many) do not appear in the term list while building a condition for a policy.

• User binds.

  These are values that would be supplied either during the construction of a condition or at the time of associating the term with the application. Not all terms will have the binds; however, user binds may make a term more reusable.

• Optionally, details about how the data needs to be captured for user binds:whether a prompt or dropdown list needs to be shown and how to derive the values.

• Which implementation needs to be used for resolving the term.

• Whether the term can potentially be resolved from any context; or only from specific contexts

• How the data library needs to extract the data from the content returned by the implementation.

• Prompt details for the term.

  Specifying prompt details for a term is needed only when the term will be used to build a condition. The prompt details convey how the data needs to be captured on the right-hand side for a term participating in a condition.

• Configuration details for prompts.

  The details you provide are used during the construction of a condition. When a term is selected as an element in a condition, the right-hand side widget will be constructed based on the configuration details specified for the prompts. You can configure the following prompt types :

  • Translate.

    Specify a translate field name in which its values appear to the end user on the right-hand side of a condition.

  • Dropdown.

    Specify a record name, data field name, and description field name. The record and data field names supply the valid data values to display in the dropdown list; the description field provides a user-friendly description of the data value.

  • Prompt.

    Specify a record name, data field name, and description field name. The record and data field names supply the valid data values to display in the prompt; the description field provide a user-friendly description of the data value.

  • Custom.

    Specify a custom application class, a data field name, and a description field name. Valid values are retrieved by executing the specified application class method and presented as a prompt.

• Scope of each term implementation.

  • When caching is activated for a term, data that is cached is uniquely identified by the implementation ID and all of the implementation bind values for that implementation.

  • When scope is specified as the trigger point, after the first invocation of a term, subsequent references to the same term in one or more policies associated to the same trigger point forces the data library engine to retrieve the data from the cache, provided all the values for the implementation binds match those of the ones belonging to the data present in the cache.

  • When scope is defined as a component, the longevity of the data is for a specific instance of the transaction.

  • When scope is defined as global, the cached data is available for the entire user session.

  • When scope is defined as Do Not Cache, data is retrieved by invoking the implementation every time.

• Association of a term to subject areas.

  Subject areas act as file cabinets. You must assign a term to at least one subject area, but you can associate it to more than one.

Note. PeopleSoft Active Analytics Framework does not format the data. It is the term user's or term implementer's responsibility to format it according to their needs. For example, the term Current Date is always resolved using the standard YYYYMMDD format.

Using Generic Implementations

A generic implementation can resolve terms within the requesting context. You define generic implementations for terms when they can be used in various contexts and when any new contexts may want to use that term.

Examples of generic implementations are:

• Customer-specific measures such as customer value, the number of cases reported in a period of time or the number of telephone interactions with the customer.

• Customer profile information such as, first and last name, email address, customers within a segment.

Using Contextual Implementations

If the input data needed for invoking an implementation is too specific and cannot be supplied outside of the component, then the implementation must be associated with the component's context. For example, terms such as case status, order creation date, or case description, cannot be resolved from components other than those in which they are present.

Terms that have different implementations depending upon their contexts will have an implementation associated with a specific context. For example, the term Revenue for a customer/ segment / segment groupis computed differently depending on the context from which it originates. The implementation specific to the customer context calculates the revenue value from that customer. The implementation specific to a segment context calculates the revenue value generated from all the customers belonging to that segment, and so on for segment group.

Managing Terms

Before defining a term, you should have already:

• Created context definitions if you're using a contextual implementation.

• Registered any implementations if the term is not accessing the component buffer.

• Created prompt records in PeopleSoft Application Designer if prompt options need to be specified.

Access the Manage Terms page.

Term Name	Unique identifier of the term; label that will be displayed to the functional users. Though allowed, PeopleSoft recommends that special characters not be used in term names.
Term Type	Specify that a term is a variable or constant. Variable terms must have at least one implementation.
Term Code	Uniquely identifies a term when accessing a term programmatically. This is user-defined.
Number of Rows	Number of rows to be returned, one or many (scalar or vector). If this field is Many, the term cannot participate in policy conditions. Note. Applications directly integrating with the data library are responsible for converting the resolved output value of a term (which will be of data type any) to the appropriate data type.
Status	Valid values are Active , Inactive and In-Design. Only active terms are used in policy conditions and other applications.
Data Type	Return data type of the term. Possible values are string, number, date, datetime, time, record and rowset.
Run-Time Display	Specify user binds for this term, which will be needed when the resolved value of the term depends on user defined binds.
Prompt Users for Bind Values	Specify the bind name; (optional) specify prompt options.
Generic Implementation	Specify a generic implementation. Generic implementations are resolved by deriving the bind values from the runtime context. Terms having generic implementations can be resolved by multiple contexts. You specify a generic implementation by selecting an existing implementation from the prompt or creating a new one using the Create button. Click on the View applicable contexts hyperlink to view the list of contexts in which this term would be resolved.
Contextual Implementation	Select an implementation specific to a context. Contextual implementations are resolved by deriving the bind values from this specific context.
Input Mapping	Maps the implementation binds to context variables or to constant values. If the term has user binds, one or more implementation binds must be mapped to the user binds. For generic implementations, this mapping is critical for this term to be resolved by multiple contexts.
Output Mapping	Specify the extraction parameters for a term implementation—such that a subset of the value returned by the implementation is returned as the resolved value of the term.

Note. Use caution when making changes to the term definition after the term has been associated to one or more policies. Changes to term attributes such as data type, number of rows, implementation category, and implementation details; or, changing a non-configurable term to a configurable term and vice versa, could have significant impact on the policies which reference this term. It is possible that these changes could result in invalidating these policies. Before making any of these changes, view the policies using a term by clicking the hyperlink View Policies Using This Term.

Testing Term Implementations

Access the Test Term Implementation page.

Specify Implementation	Specify whether you want to test the generic or contextual implementation defined for the term. Contextual. If you select this you must specify a context name from the drop-down list. Displays the list of bind values required by this implementation in a grid. Generic. If you select this, the context from where the term is resolved must be specified. Check Flush Cache if you do not want the system to fetch the value for this implementation from the memory cache.
List values..	Enter sample values for the parameters expected by the implementation and click Run Test.
Test Results	Displays the resolved value of a term implementation being tested and the elapsed time to retrieve the value.

Note. Context variable implementations of a term cannot be tested. Also, terms that have application class implementations accessing data from a component buffer or directly from the context, cannot be tested in the Term Tester page. Testing these terms will result in an error message.