This chapter discusses:
Deployment framework.
Advanced Configurator web components.
Sequential application JSP pages.
Deployment for a web application based on a single component model.
Deployment for a web application based on a compound model.
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.
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
HTML provides these user-selection input/output mechanisms for related choices (or picks), such as:
Form controls are rendered by all the code between the <FORM> and </FORM> HTML tags. |
|
A user-selectable choice on a form control that maps to a domain member in a decision point in the model. |
|
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. |
|
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. |
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. |
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. |
The following interfaces enable you to create a dynamic web client application for the PeopleSoft Advanced Configurator Engine:
Configurator form control templates: JSP pages that retrieve information from the Client Operations Processor (COP) about decision points and domain members, and dynamically generate HTML for user input and messages on pick violations.
CalicoUI.properties: A text file that sets display properties for the HTML generated by Configurator form control templates.
Configurator JSP processor pages: Enable you to use the Configurator controls templates from your application JSP pages.
Web Client Processor (WCP): Converts user picks from strings to objects, and passes them to the COP for processing.
Client Operations Processor (COP): Processes user picks to retrieve the current state of decision points and domain members from the 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:
Option buttons, check boxes, selection lists, and drop-down list boxes that display the current state of selection points and domain members.
Text lists that display messages about constraint violations.
A hidden INPUT tag that submits all previous user picks when the page is submitted.
Note. The Web client’s request for the first JSP page has no user picks, so the hidden INPUT tag has and submits none.
In building an application, assume that:
Page1.jsp contains the code for grouped radio buttons that let the Web client user choose either a coupe or a pickup automobile.
Page2.jsp contains the code for grouped radio buttons that let the Web client user choose one of these interiors: leather, cloth, or vinyl.
Neither page has default picks.
The configuration model for the two pages, Vehicles01, has this constraint: a pickup cannot have a leather interior.
When the user submits his/her picks on Page1.jsp, the next page, Page2.jsp is processed.
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.
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:
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
Copy these two files in the same application folder:
CalicoProcessForm.jsp
CalicoUI.properties
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
Modify \bea\wlserver_10.3.1\config\CalicoDomain\applications\
CalicoApp\Web-inf\config\verify.properties by setting the “messages” flag to FALSE.
You are responsible for creating or modifying only the following files for an entire Configurator web application:
You must implement your application JSP pages.
You should modify the display configuration file, CalicoUI.properties.
You can customize the application’s copy of CalicoProcessForm.jsp.
You can copy one of the form control templates (rename the copy, but put it in the application directory), and then customize the copy.
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.
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.
To deploy a compound model-based solution:
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.
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.
Create a directory for the compound model in the following directory:
\\bea\wlserver_10.3.1\config\CalicoDomain\applications\CalicoApp\
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
Update the compound model properties file CalicoNA.properties with the appropriate values.
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 ...