Overview: Profiling

 

+

Search Tips   |   Advanced Search

 

In this topic ...

  1. About Profile Sets
  2. About Profile Entries
  3. About Profiles
  4. Profiling Builder Call Inputs
  5. Previewing the Effects of Profile-Enablement
  6. Designer Profiling Tools
  7. How the Factory Associates Model Requests with Profiles
  8. Advanced Profiling Topics

 

Overview

Profiling refers to the process of defining the profiles and profile entry values from which any profiled builder call inputs get their values.

The profiling process consists of the following general tasks:

  1. Create a profile set.

  2. Add one or more profile entries to the profile set.

  3. Add one or more profiles to the profile set.

    As you add each profile, the Default profile entries also apply to the profile.

  4. Customize each profile by changing one or more default profile entry values for that profile.

  5. Profile the builder call inputs in the Builder Call Editor by selecting a profile entry from a specific profile set.

  6. Preview the effects of profiling on the model by applying various profile combinations.

Generally, the profiling process is iterative; we can perform any of these steps at any time and you will probably do them more than once, fine tuning the variability of your portlet or application as you go.

Note - Do not use the Navigator to rename a profile set - Since the Factory references profile sets by ID rather than by name, renaming a profile set in the Navigator will cause problems when a model is run because the profile set name and ID will not be consistent. Always use the Designer's profile management tools and views when working with or modifying a profile set.

 

About Profile Sets

A profile set defines the profile entries and the profiles that contain specific values for those entries. The Profile Manager editor is the primary tool you use to modify profile sets and profile entry values. (You also interact with profile sets when you profile a builder call input.) The profile sets are stored as XML files with a .pset extension in the WEB-INF/profiles directory.

When you create a profile set, the set is created with a default profile, named Default, which we cannot delete. All subsequent profiles will inherit either directly or indirectly from the Default profile. A new profile set will also have no profile entries.

 

Profile Set Structure

All profile sets share a similar structure, essentially containing a list of entries and profiles that specify values for those entries. A profile set includes the following major elements:

  • Entries Contains 0 or more <entry /> elements. Each entry element corresponds to one "unit" of variability in your Web application. Each entry element includes information about how it is displayed in the Profile Manager and the UI control to use to set its value.

  • Profiles Contains a set of <profile /> elements.

  • Profile Contains values for each entry element included in the profile set. When you profile a builder call input, you associate a builder call input with a profile entry value.

The following code sample defines a simple profile set:

<ProfileSet name="southwest">

 <Description>Profiles for Southwest users</Description> 

 <ProfileDef> 

    <Entries> 

       <Entry name="CustomerName"> 

         <UI type="TextInput"> 

            <Prompt>Customer Name</Prompt> 

         </UI> 

       </Entry> 

       <Entry name="ProductData"> 

         <UI type="Checkbox"> 

            <Prompt>Products</Prompt> 

            <ExtraData></ExtraData> 

         </UI> 

       </Entry> 

    </Entries> 

 </ProfileDef> 

 <Profiles> 

    <Profile name="Default" last_modified="1013788720766"> 

       <Values> 

          <Value name="CustomerName">Bobby Jo</Value> 

          <Value name="CustomerName_Text_Text">Bobby Jo</Value> 

          <Value name="ProductData"></Value> 

       </Values> 

       <Roles /> 

    </Profile> 

    <Profile name="Northeast" last_modified="1013788720766" parent="Default"> 

       <Values> 

          <Value name="CustomerName">Bobby Jo</Value> 

          <Value name="CustomerName_Text_Text">Jo Bob</Value> 

       </Values> 

       <Roles /> 

    </Profile> 

 </Profiles> 

</ProfileSet>

 

About Profile Entries

Upon creation, the profile set has a Default profile but no profile entries. Every entry that is added will have six definition fields:

  • Name

  • Prompt

  • UI Type (such as a radio box or select box)

  • Extra Data

  • Default Value

  • Execution Time.

For the types of data that we can supply for these fields, see Creating Profile Entries.

When you add a profile entry, the entry is actually shared by all existing and future profiles. Except for the Default Value field, the values of the definition fields will be the same for all profiles. The Default Value field is the only field whose data can be changed on a per-profile instance. In other words, the Default Value field is the only customizable field. To see the settings of all six fields of an entry, use the Entries tab of the Profile Manager.

You customize an entry value for a given profile either in the Manage Profiles editor of the Profile Manager or when you profile a builder call input. In either case, you are changing the Default Value field of that entry for that profile.

We can also create a Java class that dynamically assigns data to profile values based on some runtime condition or business logic. Profile Value Selection handlers, as these Java classes are known, allow for even more flexibility in providing variability in your Web application.

 

About Profiles

Profiles define the values to supply to profiled builder call inputs based on the segment (J2EE Role, LDAP Group, etc.) to which the user belongs. When you create a profile, we can make one or more associations with a profile. We can change how the Factory servlet associates a profile with a request by using one of the alternate profile selection handlers (either an LDAP group-based or file-based determination). You can also create your own profile selection handler to implement some other way of associating a request with a profile.

You create profiles either in the Manage Profiles tab of the Profile Manager or when you profile a builder call input. Once you create a profile, we can specify values for the entries contained in the profile set to which the profile belongs.

 

Profiling Builder Call Inputs

Profiling a builder call input associates that input with the entry value specified in a profile. As a developer, when you run the model associated with one or more profiles, the builder call input gets whatever value is set for that profile.

For example, you could profile the Text input for a Text builder call, with the intent being to display a different greeting to each user based on the type of banking account they have. Other common builder call inputs that are profiled include:

  • Argument values in service call builder calls

  • Data Source values for select, repeated region, etc. builder calls

  • Values of variable builder calls (including XML variables)

  • Arguments to method builders

  • Actions in action list builders

  • Page Location values for control builders

  • Page to import values for imported page builders

  • Image values for image builders

One approach to profiling is to build your Web application without profiling any builder calls. Once built, we can determine what parts of the application require variability and profile the specific builder calls to implement that variability.

For a complete description of profiling a builder call input, see Profiling Builder Call Inputs.

 

Previewing the Effects of Profile-Enablement

After you have created your profile sets, customized the profile entries, and profiled one or more builder call inputs, we can test the effects of profiling on the generated Web application by using the Applied Profiles view.

The Applied Profiles view lets you apply any combination of profiles to the model. We can then run the Web application and clearly see how those specific profiles affect the various pages and user inputs.

 

Advanced Profile Topics

Profiles make use of various selection handlers to access data. In addition, profile data can be stored in an external repository such as a database. See Profile Selection and Storage Mechanisms for information about these advanced profiling topics.

 

Designer Profiling View and Dialogs

This table lists the various tools and views in Designer that you use to perform profile-related tasks.

Profile-Related Task Designer Dialog or Utility To Use
Profile Set Creation

Profile Input dialog
New Profile Set wizard

Profile Set Modification
(change name or description)
Entries tab of the Profile Manager
(description can be changed, but not the name)
Profile Set Deletion Profile Sets view
Profile Set Listing
(show all the sets)
Profile Sets view
Profile Creation

Manage Profiles editor of the Profile Manager
Profile Input dialog

Profile Modification
(change name, parent, or associated segments)
Manage Profiles editor of the Profile Manager
Profile Customization
(change an entry's Default Value field for a specific profile)

Manage Profiles editor of the Profile Manager
Profile Input dialog

Profile Deletion Manage Profiles editor of the Profile Manager
Entry Creation

Entries tab of the Profile Manager
Profile Input dialog

Entry Definition Modification
(change field definition data)

Entries tab of the Profile Manager
Profile Input dialog

Entry Deletion Entries tab of the Profile Manager
Preview the Effects of Profiles Applied Profiles view
Profile Selection Handler Setting Select Handler tab of the Profile Manager

 

How the Factory Associates Model Requests with Profiles

The Factory servlet applies a profile to a model for each profile set associated with the model by performing the following steps:

When a user requests (via a URL) a Factory Web application to run, the following process takes place:

  1. The Factory servlet associates the request, typically based on the user, with a profile.

  2. For each profile set associated with the model, the profile selection handler returns the profile name to use based on:

    • Segment
    • Other logic

  3. The Factory servlet checks to see if a generated instance of the Web application, with the appropriate profile(s) applied, already exists.

  4. If the Web application instance exists, the Factory servlet executes its main Action List or Method.

  5. If the appropriate Web application does not exist, the Factory servlet regenerates the model, applying the profiles returned by the profile selection handlers, and executes the Web application's main Action List or Method.

  6. The Factory servlet stores the regenerated version of the Web application for subsequent requests that use the same profile(s).

For more information about profile selection handlers, see Setting the Profile Selection Handler.

 

Related Topics ...

  • Profile Selection and Storage Mechanisms
  • Creating a Profile Set
  • Creating Profiles
  • Customizing Profiles
  • Creating Profile Entries
  • Setting the Profile Selection Handler
  • Profiling Builder Call Inputs