Maintaining the Advanced Configurator System

This chapter discusses how to:

Click to jump to parent topicManaging Model Versioning

Different versions of the same model and multiple instances of the same version can coexist. Models have a three-part version number plus a compile version number.

The compile version number contains the date and time. For example:

20040320-184840-135

This example version number indicates that the model was compiled at 6:48 p.m. on March 20, 2004.

The version number is separated into parts by hyphens. The parts are the major, minor, and subminor versions of the model. The modeler assigns the major and minor version numbers in the PeopleSoft Visual Modeler. The compiler assigns the subminor version number. It performs a cyclical redundancy check and advances the subminor version number if the model changes. An example is 0-1-3.

This example indicates that the modeler assigned a version number of 0-1, and that the compiler has detected three changes in the model since it was first compiled as version 0-1-0.

Note. The following description assumes that you accepted default settings when you installed the PeopleSoft Configurator server.

All models are compiled in subdirectories of the PeopleSoft Configurator models directory. Subdirectories exist for the model, each part of the version number, and the compile version number. For example:

<weblogic home>\wlserver_10.3.1\config\CalicoDomain\applications\CalicoApp\WEB-INF \models\myBestModel 0 1 0 20000306-063520-356

The compile version directory contains all the files that are created during linking and compiling. The parent directories have no files, although you can move the Explanations.properties file to them. Each time the model is compiled, the compiler creates a new compile directory and all the files in it. It creates a subminor directory only if the model changes.

The compiler creates the following files in the compile version directory:

Click to jump to parent topicLoading Models

You can specify which models the PeopleSoft Configurator server loads at startup by setting one or two parameters for the Configurator's startup servlet in the WebLogic Administrative console.

To specify the Configurator server settings:

  1. Open the WebLogic Administrative console in a browser using its domain address http://<server>:<port>/console.

  2. Navigate to CalicoDomain, Deployments, Web Application, CalicoApp.

  3. Click Edit Web Application Descriptor.

    A new browser window appears where the parameters can be set.

  4. In the new window, navigate to Web Descriptor, Web App Descriptor, Servlets, StartupServlet, Parameters.

    The default is a single parameter with name=load and value=default. The load parameter can have one of these values:

  5. Add the models parameter:

    1. Click Configure a new Parameter

    2. Set the name to models.

    3. Specify a value using one of the following approaches:

      Specify at least one model name and its version and compile version. If you specify only the model name, the application server loads the latest compile version of the latest version of the model that you specify.

      or

      Specify the model name and one of the following versions or combinations:

      major version

      major and minor version

      major,, minor, and sub-minor version

      major, minor, sub-minor, and compile version (which fully specifies the model)

      Example:

      Version specification

      Action taken

      load=all

      Loads all compile versions of all models in the models directory.

      load=default

      Loads the latest compile version of the latest version of all models in the models directory.

      load=specific,models= myModelOne:0-1-0:20000306-185244-355;myModelTwo; myModelThree:0-2

      Loads the specified compile version of myModelOne, the latest compile version of the latest version of myModelTwo, and the latest compile version of the latest subminor version of minor version 2 of major version 0 of myModelThree.

  6. Navigate to the top level of the tree in the left-hand pane (called Web Descriptor), and click on the Persist button.

  7. Restart the server.

Click to jump to parent topicManaging the Memory Usage of the Configurator Server

When a model is compiled on the Configurator server, it is translated from its XML representation into a set of object instances in the Java Virtual Machine (JVM). This set of object instances is then serialized to an RTP (runtime problem) disk file. When a client later requests the model, this file is used to reconstruct the needed object instances (hereafter referred to as a ModelSpec instance). Because reconstructing a ModelSpec from the RTP file significantly affects performance, ModelSpec instances are cached in memory.

To prevent the JVM from exhausting its available memory as new versions of models are added to the server, the administration servlet removes older ModelSpec instances from the cache. Administrators can control the cache size with the model.cache property in the Advisor.properties file:

model.cache.size=20

If not specified, the property's value is 10 versions by default.

To minimize the performance impact of a cache size setting that is too small, the cache comprises a primary and secondary cache. The cache size setting refers to the size of the primary cache alone. The secondary cache acts as a holding bin for the oldest ModelSpec instances, and they are subject to the regular deletion cycles of the JVM.

The primary cache contains the most recently used ModelSpec instances. As ModelSpec instances are requested from the cache, they are added to the primary cache if they are not already there. If the primary cache has reached its maximum size, then the least recently used ModelSpec instance in the primary cache is pushed to the secondary cache.

Click to jump to parent topicCompressing Configuration Data

PeopleSoft Configurator enables you to compress configuration xml data. Any compressed data is decompressed during a restore operation when the configuration is requested.

Two modes of data compression are available:

Use the maintenance compression mode to compress configuration data that has not been compressed during runtime saves.

To specify data compression at runtime:

  1. Locate the Advisor.properties file in

    \\bea\wlserver_10.3.1\config\CalicoDomain\applications\CalicoApp\WEB-INF\config

  2. Set the property calico.na.db.compression equal to true if you want to enable data compression.

The calico.na.db.compression property enables and disables compression for the saved configurations of all solutions that are deployed on the web application server. Its default setting is true.

To compress configuration data on existing databases, run the following code from a command line. A utility compresses the saved configurations on the specified database.

java -classpath <CONFIGURATOR_JAR_PATH>;<CONFIGURATOR_CONFIG_PATH>; <DATABASE_DRIVER_PATHS> calico.cms.persistence.DBUtil -compress

where

<CONFIGURATOR_JAR_PATH> is the path to the Configurator jar file (advisor.jar).

<CONFIGURATOR_CONFIG_PATH> is the path to the Configurator properties files.

<DATABASE_DRIVER_PATHS> is the path to both of the database drivers.

Example:

java -classpath r:\MKTG_DEN_CRM\cfg\advisor.jar;r:\CRM_VOB\pscfg\3rdparty\jdbc
⇒ \classes12.zip;r:\MKTG_DEN_CRM\cfg\jdbc\mssqldriver.zip;E:\bea\wlserver_10.3.1 \config\CalicoDomain\applications\CalicoApp\WEB-INF
\config⇒ calico.cms.persistence.DBUtil -compress

Click to jump to parent topicUsing the Explanations.properties File

The Explanations.properties file contains messages about constraint violations. The compiler creates an Explanations.properties file in each compile version directory. This file contains key-value pairs that describe constraint violations, which are displayed in the test client and in the midtier application. Each explanation is keyed by its constraint name. For example:

LeatherSeatsSedanCompatibility=Leather seats are not available with this vehicle. WhiteMeatMustardCatsupCompatibility=White meat is not compatible with ​
mustard or⇒ ketchup. The condiment you selected is not available with ​
the meat you selected.⇒ ModemToMotherBoardDynDef=An external drive ​
(floppy or CD-ROM) is recommended.⇒ FramesToTintDynDef=Constraint ​
4.B.2 RadioMultipleCDCDChangerRequired=The multiple⇒ CD radio ​
requires a CD changer.

Click to jump to top of pageClick to jump to parent topicCopying the Explanations.properties File

You can move or copy the Explanations.properties file to the following directories:

Also, you can place an Explanations.properties file in the models directory. It applies to all compile versions of all models in the models directory. For example:

COMPLETENESS_CONSTRAINT=You must provide a selection for this choice. COMPATIBILITY_CONSTRAINT=The selections that you made are not compatible.

Click to jump to top of pageClick to jump to parent topicSearching for the Explanations.properties File

The Configurator test client that is used in the PeopleSoft Visual Modeler searches through directories for the Explanations.properties file in the following order:

  1. <MinorVersion>

  2. <MajorVersion>

  3. \models\ (the root directory for all <ModelName>s)

  4. <ModelName>

  5. <CompileVersion>

You can design your JavaServer Pages (JSP) midtier application to search in another order.

Click to jump to parent topicCompiling Models from the Command Line

If Configurator implementation requires regular or frequent model updates, you can save time and effort by using the command-line compile utility. This compile command calls the executable for the Visual Modeler, which opens briefly to compile the ,csw files that you supply in the command. It also generates a log file.

The command is the Visual Modeler executable, -compile, and the full or relative path of the model that you want to compile:

ClicViM -compile mymodel.csw

To compile multiple models, call each separately.

The models can be local or remotely located; however, the filepath must be to a machine on which the Visual Modeler is installed. If you want, you can store the compiled files to an internet protocol (IP) address.

Click to jump to parent topicAccessing and Using COPXML Servlet Statistics

The COPXML servlet tracks various processing times for interactive xml requests:

This is an example:

?@COPXMLServlet Statistics

@Hits 10 Total number of requests

@Overall Time(ms) 631 63 avg Total time to process request

@Start Time(ms) 380 38 avg Time spent parsing the request

@Init Time(ms) 90 9 avg Time spent initializing the cop with the correct model/version

@Execute Time(ms) 61 6 avg Time spent processing the request. (Creating choices and processing them through the engine)

@Extract Time(ms) 0 0 avg Not used

@Generate Time(ms) 100 10 avg Time spent generating the response XML

@Max Simultaneous 1 Maximum number of simultaneous requests

Note. All times are for processing interactive requests only. Times processing ConfigDetails, or ConfigCopy, requests are not included in the statistics with the exception of Start Time, which records the parsing of all requests. The first number in each row is the accumulated time since the server was started. The second number is the average per request.

To view the COPXML statistics, navigate to the copxml servlet in a browser window, using, for instance, http://localhost:7777/copxml

To reset the values without restarting the server, use the following post URL:

http://localhost:7777/copxml?reset=true