Understanding the Runtime System

This chapter discusses:

Click to jump to parent topicDeployment Framework

The PeopleSoft Advanced Configurator web deployment framework enables both rapid web-application development and good web performance.

The web application framework requires Java scripting and HTML coding skills; however, it separates the functionality into small components, or pages, that you can quickly compose and easily maintain.

The PeopleSoft Advanced Configurator engine is decoupled from the web application service, keeping the engine stateless and the entire state of each user’s configuration session maintained solely by the web application. This is done by embedding all the information needed to recreate each user’s session within hidden input fields on each page of the web application. This information is then sent back to the web server with every HTML form submission.

The Configurator engine is accessed through its public interfaces, which run on the application server. The following diagram shows the architecture of a midtier application managing the data flow between the Configurator engine service and the web user, in which the midtier proxies as the client:

User environment is decoupled from the processing

Create a Web client application for the Configurator by creating application JavaServer pages (JSP) that also run on the application server. Your JSP application pages call the Configurator interfaces and run other supporting Configurator JSP pages. JSP pages are web pages written using both Java scriptlets and HTML syntax.

See JSP and Page Templates.

You can design your web pages entirely using HTML, except for the form controls that access data from the configuration models that are processed by the Configurator Engine. Each decision point in the model maps to a selection point for the client, or web application, and can be implemented by a PeopleSoft-specific HTML form control. Simple Java scriptlets in the JSP pages are necessary to manually include the Configurator form control templates, which implement the HTML selection points.

Note. For even faster and easier application development, you can use the popular Dreamweaver web-authoring tool’s extensions to drag-and-drop Configurator’s form control templates into your application pages.

During the configuration session, the user steps through a series of HTML form-based JSP pages, submitting a set of picks, or configuration records, for each page. The following diagram illustrates how the user’s picks are sent to the Configurator engine, which processes the model’s constraints and redirects the configuration state back to the subsequent JSP page:

Data submission and return

Form Controls

HTML provides these user-selection input/output mechanisms for related choices (or picks), such as:

  • Option buttons, enabling the user to make a single selection from the displayed items; for example, the domain members of a decision point.

  • Check boxes, enabling the user to make more than one selection from the displayed items

  • Drop-down list boxes, enabling the user to make a single selection from a list of items.

  • Selection lists, enabling the user to make more than one selection from a list of items.

Form controls are rendered by all the code between the <FORM> and </FORM> HTML tags.

Form Control Item

A user-selectable choice on a form control that maps to a domain member in a decision point in the model.

JSP Pages (JavaServer Pages)

Scripted pages that consist of both HTML and simplified Java that is scripted along with the HTML. JSP pages are processed into pure HTML with runtime data included. A JSP page is a file or URL with a .jsp extension instead of an .html extension.

See http://java.sun.com/products/jsp/

Application JSP Pages

JSP pages that correspond to web pages that you create as a client application, which runs on a midtier environment, not in a browser. The JSP environment represents a client application connecting the web user to one or more server-side services.

Page template

An application JSP page that is processed to dynamically generate data to return to the web user along with the HTML web page. The data typically is provided by a specialized service; for example, the PeopleSoft Advanced Configurator Engine.

 

Form control template

A relatively small JSP page (provided) representing a form control that is included during the processing of an application JSP page.

Note. Configurator form control templates display selection points for a model on the users’ web pages and accept users’ picks.

Processor pages

JSP pages (provided) necessary to preprocess the user’s picks before sending them to the Configurator Engine.

Click to jump to parent topicAdvanced Configurator Web Components

The following interfaces enable you to create a dynamic web client application for the PeopleSoft Advanced Configurator Engine:

A dynamic Web client application is created by including Configurator JSP pages (among them, the Configurator control templates) in your application JSP pages, and setting template parameters and display properties for the form control template JSP pages.

The Configurator JSP pages make the necessary calls to the WCP and COP to generate an HTML page that has:

Click to jump to parent topicSequential Application JSP Pages

In building an application, assume that:

If the web client requests Page1.jsp, the special servlet for Page1.jsp creates an HTML page with radio buttons for coupe and pickup displayed as selectable—that is, neither selected nor eliminated. If the web client user chooses pickup and submits the HTML page, the servlet (the CLASS file of a JSP page) for Page2.jsp creates an HTML page with the radio buttons for cloth and vinyl displayed as selectable, and the radio button for leather displayed as computer-eliminated. If the web client user chooses a cloth interior and submits the second HTML page, a hidden INPUT tag submits the user’s previous pick of a pickup, while the radio button submits the user’s pick of a cloth interior.

Note. A JSP page that has both groups of radio buttons has the same effect when submitted: that is, if the user chooses a pickup, the hidden INPUT tag stores that choice and the radio button for leather is displayed as computer-eliminated.

Click to jump to parent topicDeployment for a Web Application Based on a Single Component Model

A component model is a single, standalone representation of a product or a component of a product that contains relationships based on its own objects rather than those of another model. A set of component models whose relationships are interdependent is called a compound model.

To deploy a solution:

  1. Create a directory for your application JSP pages in the following directory:

    \\bea\wlserver_10.3.1\config\CalicoDomain\applications\ CalicoApp\solutions

    Note. It is good practice to create your application directory name only of lower-case characters.

    The application JSP pages belong in an application folder; by default the application folders should be in the CalicoApp directory. The application server looks for application JSP pages according to the value resulting from a concatenation of the Name and Path attributes of the Application element in the config.xml file for the Configurator domain:

    (\bea\wlserver_10.3.1\config\CalicoDomain\config.xml) in the format Path + \ + Name

  2. Copy these two files in the same application folder:

    CalicoProcessForm.jsp

    CalicoUI.properties

  3. Modify \bea\wlserver_10.3.1\config\CalicoDomain\config.xml to the desired settings.

    See http://e-docs.bea.com/wls/docs81/index.html

    and

    PeopleSoft Enterprise CRM 9.1 Installation Guide

  4. Modify \bea\wlserver_10.3.1\config\CalicoDomain\applications\
    CalicoApp\Web-inf\config\verify.properties
    by setting the “messages” flag to FALSE.

  5. You are responsible for creating or modifying only the following files for an entire Configurator web application:

    1. You must implement your application JSP pages.

    2. You should modify the display configuration file, CalicoUI.properties.

    3. You can customize the application’s copy of CalicoProcessForm.jsp.

    4. You can copy one of the form control templates (rename the copy, but put it in the application directory), and then customize the copy.

Click to jump to top of pageClick to jump to parent topicOptimizing Performance

For better performance, you should disable session support by starting your JSP application pages (that do not access the implicit session object) with the following tag:

<%@ page session="false" %>

This will prevent the JSP compiler from generating code to create session objects. However, you will not be able to implement any supporting JavaBeans with session scope for these applications.

Click to jump to top of pageClick to jump to parent topicRestore Policy

A user’s request to recover a saved configuration presents a challenge in light of the requirement for that configuration to run on a compatible version of the model that it was created with. It is conceivable that the picks on the saved configuration correspond to selection points that were removed in an intervening model update.

Click to jump to parent topicDeployment for a Web Application Based on a Compound Model

To deploy a compound model-based solution:

  1. Deploy the compound model’s component models (the .cms files) to the server by compiling them on the Visual Modeler or deploying them using the Administration Tool.

  2. Similarly, deploy the compound model’s XML compound structure document to the server by compiling it on the Visual Modeler or deploying it using the Administration Tool.

  3. Create a directory for the compound model in the following directory:

    \\bea\wlserver_10.3.1\config\CalicoDomain\applications\CalicoApp\

  4. Following the procedure described in “Create a directory for your application JSP pages in the following directory”, deploy, in the compound model directory you just created, each component model as if it is a single, standalone model.

    When you are done, the directory structure should look similar to this example:

    \\bea\wlserver_10.3.1\config\CalicoDomain\applications\CalicoApp\ <Compound Model> \Model1 \pages CalicoProcessForm.jsp CalicoUI.properties \Model2\ \pages CalicoProcessForm.jsp CalicoUI.properties \Model3\ \pages CalicoProcessForm.jsp CalicoUI.properties

  5. Update the compound model properties file CalicoNA.properties with the appropriate values.

    See Compound Model Properties File.

  6. Place CalicoNA.properties in the compound model’s root:

    \\bea\wlserver_10.3.1\config\CalicoDomain\applications\CalicoApp\ <Compound Model> CalicoNA.properties <compound model schema>.xml ... \Model1 \pages ...