Creating Terms

Defining a term involves specifying:

• 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 and whether they are 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 you are 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 drop-down list box 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 that 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 drop-down list box; 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 execution of 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 with the same trigger point force the data library engine to retrieve the data from the cache, provided that 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 invocation of the implementation every time.

• Association of a term with subject areas.

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

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, and customers within a segment.

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, and 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 group is computed based 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 each segment group.