Chapter

10. WOW Features

10.1 Derived Fields

Perhaps one of the most commonly used features in WOW, derived fields provide the ability to create a “virtual” field. This field is defined by a field descriptor, just a like a normal field, yet it does not actually exist in a physical file. It is simply a container field that can be used to return any value needed. It can be handled and manipulated just a like an actual database field.

A derived field is represented in SQL by a “column name alias.” For instance, the following SQL statement contains a derived field with the column name alias D_DETAILS:

SELECT 'Details' AS D_DETAILS, FIRSTNME, LASTNAME FROM PJDATA.EMPLOYEE

This statement returns three columns, in the following order: D_DETAILS, First Name, and Last Name. The results of this particular statement can be seen in Figure 10-.1 below.

Figure 10-1 Results with the derived field D_DETAILS

Notice the first part of the column name alias ( 'Details' ) represents the the initial value that is displayed in the derived field. A string, which requires single quotes, was used in this example but you could also instead use numbers, functions, other field names, etc. The second part ( AS D_DETAILS ) assigns an alias (column name) to the value defined in the first half.

10.1.1 Creating a Derived Field Descriptor:

Once you have the derived field defined in your SQL, you can format and manipulate it by creating its derived field descriptor. This will allow you to assign it default values, assocations, field classes, and so on. A derived field descriptor differs from a normal field descriptor in really only one way: its Field Descriptor Type is set to ‘Derived’. This allows WOW to handle it appropriately. Also, a field descriptor for a derived field will not automatically generate by clicking the ‘Create FDs’ button in the Field Descriptor Manager.

Thus, you must manually create derived field descriptors. The easiest way to do this is to simply copy another field that is of the desired data type. For instance, if your derived field was a calculation that returned a decimal number, you would copy an existing field desciptor for a field of type DECIMAL or NUMERIC. To continue our example from the previous section, here are the steps to creating a derived field descriptor for D_DETAILS:

Step 1: Create a Field Descriptor

Since the only value that D_DETAILS will hold is the string ‘Details’, a good field desciptor to copy (rather than creating one from scratch) would be a simple CHAR field. Now, navigate to the Database Settings section of this new field descriptor and change the values to reflect those shown in Figure 10-2. In particular, the Library and Table Names are the same as specified in the SQL statement listed above. Also, SQL Type and SQP Type Name specify the CHAR field type and the Column Size is 7 since we only need 7 characters (ie. Details).

Figure 10-2 Database Settings for the D_DETAILS field desciptor.

Step 2: Set the Field Descriptor’s Settings

Besides the Database Settings given in Step 1, there are two other Field Descriptor settings that are key to success. The first is the Field Name field under the Basic Settings section. In this example, the Field name is D_DETAILS as shown in Figure 10-3. The second is the Field Descriptor Type under the Advanced Settings section. This must be set to ‘Derived’ as shown in Figure 10-4.

Figure 10-3 Specifying the Field Name of the derived field.

Figure 10-4 Specifying the Field Descriptor Type as Derived.

Step 3: Update and Run Application

Click Uupdate and run the application. If everything has been done correctly, the column label will say ‘Details’ rather than ‘D_DETAILS’ (see Figure 10-5). This means the derived field has successfully been linked with the derived field descriptor and is picking up the External Name (see Figure 10-3).

Figure 10-5 The derived field D_DETAILS now has a linked field descriptor.

10.2 Parameters

There are many cases where the statement you want to run cannot be completely specified at design time. This usually happens when the statement contains certain values that either needs to be directly input by the user at runtime, or that depend on the context in which the statement is being run. (The context includes things such as the user's sign on information and previous statements that the user has run.) WOW handles these cases by using parameters. A parameter is represented in code by one or more question marks, possibly followed by additional parameter control characters. For example, the following SQL statement contains 3 different parameters:

SELECT * FROM PLANETJ.CUSTOMER WHERE (BALANCE > ? AND ID = ???CUSNUM) OR ??1 < 0

The "?", "???CUSNUM" and "??1" all serve as placeholders for values that are not known at design time, but will be plugged in to the statement at runtime before it is executed. This section will describe the various parameter types that are available in WOW, and how to use them.

10.2.1 SQL Prompt Parameters

A single question mark in an SQL statement represents a SQL prompt parameter. When a statement containing one or more SQL prompt parameters is executed, the user is prompted to enter values for these parameters. For example when the statement

SELECT NAME, BALANCE FROM PLANETJ.CUSTOMER WHERE BALANCE < ? AND NAME LIKE ?

is run, the user is shown the following screen:

Figure 10-6 WOW prompting the user for values

After supplying values, the user can click the search button to run the statement with the values that were entered. Unlike most types of parameters which can be used in any type of operation, SQL prompt parameters can only be used in SQL Operations.

10.2.2 Field Descriptor Prompt Parameters

A field descriptor prompt parameter is similar to an SQL prompt parameter in that it is used to display an entry field for the user to supply a value for the parameter. The difference between the two is how WOW generates the entry field. For SQL prompt parameters, WOW determines which field descriptor to use for the entry field based on the SQL statement. For a field descriptor prompt parameter, WOW will use a specific field descriptor you specify to generate the entry field. (For more information on field descriptors, see the previous chapter).

Field descriptor prompt parameters are denoted by a single question mark followed by the id of the field descriptor to use. For example, the SQL statement

SELECT * FROM PLANETJ.CUSTOMER WHERE BALANCE > ?49

will use the field descriptor with an ID of 49 to generate the prompt shown to the user. Field descriptor prompt parameters can only be used in SQL statements.

10.2.3 Row Parameters

A row parameter takes information from a row of data and plugs it into a statement. A row parameter is indicated by two question marks followed by a database column name. For example, if a database record describing a single employee has been selected from the EMPLOYEES table, and now information about that employee's department needs to be selected from the DEPTARTMENT table, the SQL statement might look something like this:

SELECT * FROM PJDATA.DEPARTMENT WHERE ID = ??DEPT_ID

This statement assumes that ID is the key in the DEPARTMENT table, and that the "current row" (from the EMPLOYEE table) contains a column called DEPT_ID which is a foreign key to the DEPARTMENT table. When this statement is run, the value of the DEPT_ID field of the "current" row is used as the parameter value. Note that this parameter is automatically filled in by WOW; the user is not shown any type of prompt.

10.2.4 User Parameters

A user parameter is similar to a row parameter, except instead of taking information from the "current" row, the information is taken from a row of data associated with the current application user. A user parameter is identified by three question marks in a row followed by a database column name. So the following statement:

SELECT * FROM PLANETJ.CUSTOMER WHERE ID = ???CLIENT_ID

will select rows where the ID field is equal to the CLIENT_ID field associated with the current user. See chapter WOW Security Protocols, section SQL Operation for more details on how you can associate information with users of your application.

There is a special user parameter called USERID which is always associated with the id that was used to sign onto the application. This user parameter can be used with any type of application sign-on (except for an unsecured sign-on, which does not require the user to enter a user id or password). The SQL statement

SELECT * FROM PLANETJ.USER_INFO WHERE ID = ???USERID

would select every row from the USER_INFO table where the ID column has a value equal to the user ID of the current user. User ID’s are always converted to uppercase, so in the above example all values in the ID column should be uppercase as well.

10.2.5 Usage ID Parameters

In order to use a row or user parameter, you have to know the database column name of the field whose value you are interested in. In some cases this is not possible -- usually this happens when multiple tables contain the same logical piece of information in different fields. In this situation, you can identify the field to use by its usage ID instead of its column name. A usage ID is an integer you can associate with one or more field descriptors. A usage ID parameter will look for a field descriptor with the specified usage ID in the row (either the user row or the current row) and use the value in the field described by that field descriptor.

A user usage ID parameter is denoted by three question marks followed by a caret and the usage ID. The statement

SELECT * FROM PLANETJ.CUSTOMER WHERE ID = ???^18

would take the value associated with usage ID 18 in the user row as the parameter value.

A row usage ID parameter is denoted by two question marks followed by a caret and the usage ID.

SELECT * FROM PLANETJ.CUSTOMER WHERE ID = ??^46

would take the value associated with usage ID 46 in the current row as the parameter value. Usage ID’s are described in more detail in Appendix A.

10.2.6 Table Parameters

A table parameter is used when you want to allow the user to specify the table or tables to run an SQL statement against. For example, you might have multiple tables containing customer orders - every table would have the same structure but be specific to a single customer. You could then build a query which could apply to any of the tables - the user will pick the exact table to run the query against at runtime:

SELECT * FROM ?~PLANETJ.CUSTOMER WHERE ORDER_NUMBER = ?

A table parameter begins with a question mark followed a tilde (~) and includes the name of a table; in the above statement "?~PLANETJ.CUSTOMER" is the table parameter. At runtime, the statement will be executed against whatever table the user specifies, which may or may not be the PLANETJ.CUSTOMER table. However, the PLANETJ.CUSTOMER table will be used to identify the field descriptors which will be used to display the parameter prompts to the user. The prompt for the table parameter will be based off of the table descriptor for PLANETJ.CUSTOMER - this table descriptor can be used to specify a display name and a list of possible table values for the user to choose from. (See the previous chapter for information on table descriptors.) The prompt for the second parameter will be based off of the ORDER_NUMBER field descriptor in the PLANETJ.CUSTOMER table - even if this is not the table the user specifies for the actual statement execution.

10.2.7 Parameter Parameters

A Parameter parameter is a parameter which gets its value from another parameter in the same statement. Parameter parameters are used when multiple parameters in a statement must all have the same value. For example if you wanted to look up customer balances that are within $200 of a certain value, your query might look like this:

SELECT * FROM PLANETJ.CUSTOMER WHERE BALANCE +200 > ? AND BALANCE – 200 < ??1

The first question mark is a normal SQL prompt parameter - the user will be prompted for this value. The second pair of question marks is immediately followed by a number, indicating that it is a Parameter parameter. The user will not be prompted to supply a value for this parameter. Instead it will have the exact same value as the first parameter in the statement.

In general, a Parameter parameter is denoted by two question marks followed by a number. The number indicates which parameter in the statement should be used to supply the value. (In the above example, the number 1 indicates that the first parameter should be used to supply the value.)

10.2.8 Context Parameter Parameters

A Context Parameter parameter is a parameter that is similar to a parameter parameter, but rather than getting its value from another parameter in the same statement, it gets it’s value from a parameter in an associated statement. When Context Parameter parameters are used, parameters in an association need to have the same value as the parameters in the original SQL. For example, an original query might show a summary of a customer’s balance between a certain date range. The query would also contain an association (using a derived field descriptor) that gets transaction details for that customer. The association (2^nd SQL listed below) would thus need to use the same search date range:

SELECT CUSTOMER_NAME, SUM(AMOUNT), !!DETAILS FROM PLANETJ.CUSTOMER_TRANSACTIONS WHERE TRANSACTION_DATE BETWEEN ? AND ?

SELECT TRANSACTION_ID, AMOUNT FROM PLANETJ.CUSTOMER_TRANSACTIONS WHERE CUSTOMER_NAME = ??CUSTOMER_NAME AND TRANSACTION_DATE BETWEEN ??&1 AND ??&2

In the association (2^nd SQL), the first parameter is a Row parameter used to ensure the proper customer information is retrieved. The last two parameters are the context parameter parameters used to get the same date range to search on as the original query.

In general, a Context Parameter parameter is denoted by two question marks followed by an ampersand (‘&’) and a number. The number indicates which parameter in the original statement should be used to supply the value.

10.2.9 Runtime Parameters

Runtime parameters are parameters which are specified when the user first enters an application, and can then apply to all operations executed by that user. For example, let’s say you have sales offices in three different locations: Atlanta, Boston, and Cleveland. You want to develop a WOW application containing various operations which let people from each branch run different queries against sales made by their branch. You could include the branch name in each query using regular SQL parameters like this:

SELECT * FROM PJDATA.SALES WHERE BRANCH = ? AND AMOUNT > ?

SELECT * FROM PJDATA.SALES WHERE BRANCH = ? AND DATE = ?

SELECT * FROM PJDATA.SALES WHERE BRANCH = ? AND ACCOUNT = ?

The only problem with this scenario is it forces users to select their branch for every query that is run. If you rework these queries to use runtime parameters instead, then the branch can be specified once when the application starts up and used for all subsequent queries without further user input.

Two question marks followed by a colon “:” and an identifying name is the sequence used to indicate a runtime parameter. Using runtime parameters for the branches in the above queries gives:

SELECT * FROM PJDATA.SALES WHERE BRANCH = ??:BCH AND AMOUNT > ?

SELECT * FROM PJDATA.SALES WHERE BRANCH = ??:BCH AND DATE = ?

SELECT * FROM PJDATA.SALES WHERE BRANCH = ??:BCH AND ACCOUNT = ?

To specify a value for the BCH runtime parameter, the application should be started with a URL like this:

http://www.planetjavainc.com/wow/runApp?id=40&BCH=Atlanta

This starts up application 40 and indicates that “Atlanta” is the value for all runtime parameters named “BCH”. The ‘?’ denotes the start of parameters and ‘&’ is used to separate parameters. Users from different branches can use links specifying their branch when starting the application:

http://www.planetjavainc.com/wow/runApp?id=40&BCH=Boston

http://www.planetjavainc.com/wow/runApp?id=40&BCH=Cleveland

When they run the operations, they will not have to select which branch they are querying.

10.2.10Defaulting Parameter Values

Normally when user needs to fill in a parameter’s value, that parameter will default to a blank value. For example, if your query is

SELECT * FROM PJDATA.CUSTOMER WHERE BALANCE > ?

The prompt shown to the user would look something like this:

However, if you want your parameter to have a default value of 1000, you can specify this is your SQL statement. Using the code

SELECT * FROM PJDATA.CUSTOMER WHERE BALANCE > ?{1000}

tells WOW that it should use a default value of 1000 for the parameter. Running an operation with the above code results in this prompt (before the user enters any data in):

The user can type in any value he or she wants; 1000 is just a default value. If your field has possible values (discussed later in this chapter) and you want to use a default value, remember that you need to use the value you want as the default, not the display value.

In general, any parameter that is displayed to the user can be given a default value by appending the default value, enclosed in curly braces, onto the end of the parameter. (There should not be any spaces between the rest of the parameter and the opening curly brace.) Here are several more examples of SQL statements which assign default values to parameters:

CALL PLANETJ.MY_SPROC (?45, ?92{Red}, ?14{Orange})

DELETE FROM PLANETJ.EMPLOYEE WHERE LASTNAME = ?{Stewart} AND FIRSTNME = ?

SELECT * FROM ?~PLANETJ.MYTABLE{PLANETJ.THISTABLE}

10.3 Operation Property Groups

The Properties field allows you to configure your operations in various ways. The screen shot below shows where the Properties field is located in the “Creating Operations” screen:

Figure 10-7 A screenshot of the display field in the Create Operation screen. This shows the many different configurations you can have for each Operation.

Within the properties field are different property groups. These groups are used to change the look and feel of the tables and data selected by the SQL statement. For instance, a few of the different property groups available are DisplayColumns, DetailDisplay, and TableDisplay. The properties of each group will be listed between curly brackets {}. For each property, the name of the property is followed by a colon and then the value (or comma separated list of values), and finally by a semicolon. Below are samples of properties groups correctly formatted:

DisplayColumns{ results:*; details:*; }

DetailDisplay{colCnt:; copyURI:; editURI:; insertURI:; maxInputWidth:; maxInputWidthSum:; printURI:;viewURI:;}

TableDisplay{ selectionType:none; refresh:true; chart:true; excel:false; msWord:true; pdf:true; xml:true; editFD:false; print:true; sorting:true; drawGrid:true; rowCopy:false; updateable:true; deleteAll:true; nextPrevious:true; }

OperationLabels{searchDisplay:3;}

Note that whitespaces (new lines, spaces, and tabs) are irrelevant to property group formatting.

10.3.1 AutoRun { }

This property group allows you to set the run schedule for an “Auto-Run – Batch Process” (an operation that is scheduled to run automatically when an application is started).

Property	Value	Description
startDate	TODAY \| MM/dd/yyyy	The date the batch auto run operation should start .
startTime	IMMEDIATELY \| hh:mm	The time the batch auto run operation should start.
frequency	integer	How often the batch auto run operation should execute (in seconds – e.g. 900 = 15 minutes, 86400 = 1 day). In the example below, the first run of the operation would occur on January 1, 2007 at 1 am, repeating every 7 days thereafter. AutoRun { startDate:1/1/2007; startTime:1:00 am; frequency:604800; } To see an AutoRun example, see the Logging Email section.

10.3.2 Browser { }

This property group allows you to control the browser behavior when the operation is run. One use for these properties would be when an operation displays a small pop-up window.

Property	Value	Description
url	URL	URL to load in the window.
target	window name \| _BLANK \| _SELF \| _PARENT \| _TOP	Target where to load the window. The value “_self” would ensure that the operation runs in the same window. For an example, see the Creating Associations section.
width	integer	Width for the browser window.
height	integer	Height for the browser window.
toolbar	TRUE \| FALSE	Show the toolbar.
location	TRUE \| FALSE	Show the location bar.
menubar	TRUE \| FALSE	Show the menu bar.
directories	TRUE \| FALSE	Show the directories (links / bookmarks).
scrollbars	TRUE \| FALSE	Show the menu bar.
resizeable	TRUE \| FALSE	Allow resizing of the browser window.
copyhistory	TRUE \| FALSE	Copy the browser history.

10.3.3 Chart { }

This property group allows you to specify properties used to create and generate a chart using JFreeChart. See the Creating Charts and Graphs chapter for more details.

10.3.4 Config { }

This property group allows you to specify a replacement library list for an operation. See the Replacement Libraries Support chapter for more details.

10.3.5 CSV { }

Specifies formatting information for CSV documents. (CSV documents include Microsoft Word and Microsoft Excel formats). When a user chooses to view data in a CSV document, this property group describes how that document should be formatted.

Property	Value	Description
columnHeadings	INTERNAL \| EXTERNAL	Indicates whether the internal database names or the external “user-friendly” names should be used for the column names in the CSV. The default is INTERNAL. Example: CSV{ columnHeadings:external;} This would cause the Excel download to use external labels for column headings.
outputRows	ALL \| SCREEN \| SELECTED	Indicates which rows should be exported. Possible values are ALL (all rows which satisfy the query), SCREEN (only rows on the current screen), and SELECTED (only rows which the user has selected). By default, all rows are exported.
displayColumns	field,field,…	Indicates which columns should be exported. You may type in a comma separated list of column names that should be exported. By default, all columns returned by the query are exported.

10.3.6 DetailDisplay { }

When a single entry (row) is displayed, this section contains information about how to display the details of a row to the user. (Row details are what the user sees when they insert a new row into the results, or when they select a row from the list of rows in the results, and choose to view, edit, or copy that row.) Most SQL Operations do not need to include these properties – they can simply use the WOW defaults. If you want to use a different JSP to display detailed results, set the appropriate DetailDisplay property. The features described below should only be used by advanced programmers who have experience with Java and JSP programming.

Property	Value	Description
addButtonsURI	file path	JSP to use for buttons during an insert.
button locations	TOP \| BOTTOM	Designates where the buttons are located on details screen. The default is to show buttons on both top and bottom.
buttonJustify	RIGHT \| LEFT	The buttons for the Detail screen are displayed at the top and bottom of the detail and have values such as Insert, Update, and Cancel. The default value is right.
colCnt	integer	Number of columns to display when showing Row details (default is 2).
colonAfterLabel	TRUE \| FALSE	Append colon after labels on the details screen. The default is false.
copyTargetWindow	window name \| _BLANK \| _SELF \| _PARENT \| _TOP	Describes how to use a new window for copying a row. For more details see the editTargetWindow property.
copyURI	file path	The JSP to use when displaying copied database rows.
delete	TRUE \| FALSE	Allow delete on details screen.
deleteText	text	Text to be used on the Delete button.
detailsTargetWindow	window name \| _BLANK \| _SELF \| _PARENT \| _TOP	Describes how to use a new window for viewing, editing, copying, or inserting a row. For more details see the editTargetWindow property above.
editButtonsURI		JSP to use for buttons during detail viewing.
editTargetWindow	window name \| _BLANK \| _SELF \| _PARENT \| _TOP	Information about the window to use when a row is edited. If this property is omitted, then the main browser window is used to edit a row’s details. When this property is specified, a new window will be used to edit a row’s details. The value of this property can either be a name for the new window, or a list of detailed information about the new window. For example, if the property is specified like this: editTargetWindow: claimEdit; Then when a row retrieved by this operation is edited, the editing will be done in a new window entitled “claimEdit”. In general, the exact name which the new window is given does not matter, however if there is already a window with that same name open, then that window is used instead of opening a new one. If the special name “_blank” is used then a new window is always opened: editTargetWindow: _blank; Alternatively instead of just specifying a name, a whole list of information about the new window can be specified: editTargetWindow: name=_blank,height=600,width=400, status=yes,menubar=no,scrollbars=no,resizable=no; The above example would cause the new window for editing to have a height of 600 pixels, a width of 400 pixels, a status bar, no scrollbar or menu bar, and not be resizable. Only the name value is required – the rest are optional and can be omitted if you want to use the defaults.
editURI	file path	The JSP to use when editing database rows.
grid	TRUE \| FALSE	Use grid to display details.
insert	TRUE \| FALSE	Allow insert on details screen.
insertAndCopy	TRUE \| FALSE	Show the insert and copy buttons.
insertAndNew	TRUE \| FALSE	Show the insert and new buttons
insertTargetWindow	window name \| _BLANK \| _SELF \| _PARENT \| _TOP	Describes how to use a new window for inserting a row. For more details see the editTargetWindow property above.
insertText	text	Text to be used on the Insert button.
insertURI	file path	The JSP to use when inserting new database rows.
label justify	TOP \| LEFT	Determines where the field's label is to be located, top (above) or to the left of the field's display. The default is to the left.
maxInputWidth	integer	The maximum input width allowed for table display (default is 36).
maxInputWidthSum	integer	The maximum sum of the input widths in the table display (default is 72).
nextAndPrevious	TRUE \| FALSE	Show the next and previous buttons
nextText	text	Text to be used on the Next button.
previousText	text	Text to be used on the Previous button.
printURI	file path	The JSP to use when printing database rows.
tableWidth	integer	The width (in pixels) to be used to display the details.
updateAndNextPrevious	TRUE \| FALSE	Show the update and next buttons.
updateText	text	Text to be used on the Update button.
viewButtonsURI	file path	JSP to use for buttons during detail viewing.
viewTargetWindow	window name \| _BLANK \| _SELF \| _PARENT \| _TOP	Describes how to use a new window for viewing a row. For more details see the editTargetWindow property above.
viewURI	file path	The JSP to use when viewing database rows.

10.3.7 DisplayColumns { }

There are two properties in the DisplayColumns group, results and details. In the above sample, both of the properties are set to display all data. This is indicated by the * asterisks. In all the properties of this property group, the values ‘all’ and ‘none’ may be used.

Property	Value	Description
details	ALL \| NONE \| * \| field,field,…	Used to specify what columns you want displayed in a details (single row) display. You can view details of any entry (row) by clicking on the corresponding View icon for the entry (row). Like the results property, the details property can also take specific column names. For Example: DisplayColumns{ results: ; details*:empno,firstnme,lastname,sex;} Now if you were to view an entry instead of showing all of the fields, it will only display the employee number, first name, last name, and gender fields.
detailsExclude	ALL \| NONE \| * \| field,field,…	Columns to exclude from the details view.
editableResults	ALL \| NONE \| * \| field,field,…	Used to specify what columns should be editable in the results view. Same functionality as the resultsEditable property. This must be used in conjunction with the updateable property in the TableDisplay property group: TableDisplay{ updateable: true; }
results	ALL \| NONE \| * \| field,field,…	Used to designate which columns (fields) are displayed in the table when a set of rows are displayed. To display only specific fields simply delete the asterisk and replace it with the column names or column number values you want to display. Each column name should be separated by commas. For Example: DisplayColumns{ results: empno,firstnme,lastname; details:;} The example above would only display the employee number, first name and last name fields of the table. Syntax is very important. The property groups are case sensitive. Each property group must start with a capital letter on each word with no spacing between them. The field names are not case sensitive though. Another technique to displaying certain fields in the table is by using numeric values instead of row names. DisplayColumns{ results: 3,1,2; details:;} In the example above, the row names were simply replaced by their corresponding number. For example the above DisplayColumns settings would display the third column, then the first column, and lastly the second column.
resultsEditable	ALL \| NONE \| * \| field,field,…	Used to specify what columns should be editable in the results view. Same functionality as the editableResults property. This must be used in conjunction with the updateable property in the TableDisplay property group: TableDisplay{ updateable: true; }
resultsExclude	ALL \| NONE \| * \| field,field,…	Columns to exclude from the results.

10.3.8 Distribution { }

This property group allows specification of the frequency, start date, end date, and timing for an automatic report. See the Creating and Distributing Automatic Reports section for more details.

10.3.9 Email { }

This property group allows you to specify properties that are used for emailing.

Property	Value	Description
from	integer	From ID
password	text	The SMTP/POP3 account password.
pop3	integer	The pop3 (incoming) mail server IP address to use.
to	integer	The To ID(s).
cc	integer	The CC ID(s).
bcc	integer	The BCC ID(s).
replyTo	text	The address replies should be sent to.
smtp	IP address	The smtp (outgoing) email server IP address to use.
subject	text	The email subject.
user	text	The SMTP/POP3 account user name.

10.3.10LayoutDisplay { }

This property group allows you to override the layout display properties for this operaton. See the Further Customization chapter for an example.

Property	Value	Description
toc width	integer	Width of leftside navigation.
css	file path	CSS file.
company text	text	Company name.
heading text	text	Heading text on page.
sub heading text	text	Sub-heading text on page.
help uri	file path	Help URI link.
title	text	Title text

10.3.11OperationLabels { }

This property group allows you to specify how to organize the search parameters and prompts.

Property	Value	Description
button