Designing Pages for Optimal Performance

This chapter discusses how to improve online performance

Improving Online Performance

To improve the online performance of internet applications, you must optimize the transmissions to the server. Optimizing transmissions improves overall processing speed and reduces a user’s data entry time.

Transactions that are designed using deferred mode reduce traffic to the application server but do not operate interactively.

This section provides an overview of processing modes and discusses how to:

• Refresh pages.

• Trigger server processing.

• Use PeopleCode in deferred mode.

• Use page controls in deferred mode.

• Use error and warning messages.

Understanding Processing Modes

PeopleSoft applications can run in two different processing modes: interactive and deferred.

Interactive Mode

In interactive mode (formerly called standard), when the user exits a field that has a field-level event (for example, FieldChange, FieldEdit, or RowInit PeopleCode; prompt validation; related display; and so on):

1. A transmission to the application server occurs immediately so that it runs the field-level event.

2. The system refreshes the information.

Deferred Mode

In deferred mode, the application enables you to temporarily delay many of the conditions that need server processing until you encounter an event or condition that requires immediate processing or until you request processing manually. For example, when a user exits a field that has a field-level event (like FieldChange or FieldEdit PeopleCode, prompt validation, related display, and so on), that event is not processed until the next transmission to the application server. When the next transmission to the server occurs, PeopleTools determines which fields have changed since the last transmission. Then, logic on the application server runs the appropriate system edits and PeopleCode events (in field layout order).

You can select deferred mode processing at the field, page, and component levels. For a field in the component to run in deferred mode, you must select deferred mode at each of those levels. For a page to run in deferred mode, you must select deferred mode at the page and component levels. Deferred processing is the default mode at the field, page, and component levels.

Related Content and Processing Mode

When designing related content, you should carefully review and understand the interaction between the processing mode of any fields, pages, or components to which you associate related content services. This type of careful review will reduce the likelihood that unexpected or contextually irrelevant data appears when the processing mode is incorrect.

You should use deferred processing judiciously when interacting with related content services.

Refreshing Pages

Click the Refresh button on a page to force processing on the application server to determine which fields have changed since the last transmission and to run processing logic that is associated with those changes.

Users can also refresh by pressing the alt-0 hot key, which keeps the cursor in the same field when the system displays the page. You can refresh at any time during data entry to enable an expert user to:

• Update related display field values for data that is already entered.

• Recalculate totals and balances.

• Provide defaults that are based on data that was entered previously on the page.

• Validate the data that has been entered on the page so far.

• Invoke any hide, unhide, gray, or ungray PeopleCode that is associated with specific fields.

Note. The Refresh button does not refresh the page from the database. It does cause a server trip so that any deferred PeopleCode changes can be processed. If no deferred changes were made or the deferred changes do not cause any errors or other changes on the page, then clicking Refresh has no effect. The user might think that nothing happened. Fields on derived work records are not updated if the user clicks the Refresh button.

Triggering Server Processing

The following table shows the events that cause the PeopleTools runtime environment to process logic on the application server when operating in deferred or interactive processing mode:

Using PeopleCode in Deferred Mode

When designing transactions to run in deferred mode, you:

• Code field edits in FieldEdit PeopleCode; you do not need to move field edits to SaveEdit PeopleCode.

• Code field change logic in FieldChange PeopleCode.

• Set all fields, including those that have FieldEdit or FieldChange PeopleCode, to deferred processing.

• Do not use gray and hide fields on the same page to achieve a form of progressive disclosure on the page.

  Specifically, do not include hide or unhide and gray or ungray FieldEdit and FieldChange PeopleCode for definitions on the same page unless the page is triggered by a separate push button. Instead, use either page Activate PeopleCode or FieldChange PeopleCode for definitions that are on another page in the component. The appearance of the page should be static as the user enters values and moves between fields on the page.

  You should hide or unhide definitions or set them to display-only in page Activate PeopleCode before the initial appearance of the page based on setup data, configuration options, or personalization settings. Set fields to display-only in PeopleCode by setting the DisplayOnly property in the Field class to True.

• Show all fields as a static form and perform cross-validation edits to prevent invalid data combinations from being written to the database.

• For cross-validation edits, always assume that the controlling field (for example, a radio button, check box, drop down list box, and so on) is correct when editing for invalid combinations.

  Use SaveEdit to code cross-validation edits. If the transaction requires that the edits be performed before the user can select another folder tab, then code the edits in a function that is called from the page Activate PeopleCode for every other visible page in the component. If the transaction is a sequential process, add the cross-validation edits to the Next and Previous buttons that a user uses to navigate through the process. Code cross-validation edits at the record level if the cross-validation edits apply to all components, and at the component level if they apply to only one component.

Publishing Messages in PeopleCode

Use the SavePostChange event, either from record-field or component PeopleCode, to publish messages online. PeopleTools has special logic in SavePostChange PeopleCode that defers publishing until just before the commit for the transaction. This PeopleCode minimizes the time that the system locks single-threaded PeopleSoft Integration Broker tables.

See Also

Deferred Processing Mode

Using Page Controls in Deferred Mode

Consider the following information when you design transaction pages to run in deferred mode.

Edit Tables

Set fields that have edit table validations to deferred. The user can click the Refresh button for immediate validation of the field; otherwise, the prompt validation is deferred until the next required transmission to the application server.

Prompt Tables

Use deferred processing for prompt table edits that use %EditTable to set the prompt keys based on the values of other fields on the page. Deferred processing still results in the appropriate behavior being run. For example, if the user clicks the prompt icon, the system:

1. Determines which fields have changed since the previous server transmission.

2. Runs the appropriate PeopleCode events.

3. Applies the values from the page to the buffer.

   This action results in setting the correct values before resolving the %EditTable function, provided that any controlling fields come before the prompt table edit based on the page layout order.

4. Runs the prompt table edit lookup logic for the corresponding field.

Drop-Down List Boxes

Do not use drop-down list boxes when the high-order key values are set on the same page. If you do, it requires the server to transmit the correct drop-down list box values based on the high-order key values. Therefore, set the high-order keys on another page, if possible, or use a prompt lookup instead.

For pages that have an effective-dated scroll area and a drop-down list box based on the PSXLATITEM translate table, the drop-down list box is not refreshed when the effective date is changed on the page. However, the drop-down list box does accurately reflect the new effective date the next time that the page is displayed. Evaluate whether this is a problem for the transaction, based on whether customers typically enter effective-dated XLAT rows for the field and on how often changes to the XLAT values are made. If this is an issue, either replace the drop-down list box with an edit box and a prompt, or use the refresh icon after the effective date field.

Drop-down list boxes are a good design choice because they present users with a small number of selections from which they must select one. They are typically more appropriate than prompts for transactions that are targeted at casual, untrained users. Prompts are more appropriate when a power user is entering the transaction from a paper form or document that contains the necessary codes.

Check Boxes and Radio Buttons

Remove any FieldChange PeopleCode associated with check boxes in a grid that are mutually exclusive (meaning only one row can be checked). Instead, implement cross-validation edits in SavePreChange PeopleCode. When you design cross-validation edits between a radio button or check box and any associated edit box fields, assume that the controlling field (in this case, the radio button or check box) is correct.

Related Displays

When you include related displays on your pages, make sure that they are set to deferred mode and that the standard Refresh button is enabled. Then, users can press the Refresh hot key to display related displays when they want to see them. Self-service transactions should not display the code and corresponding related display; they should use descriptive prompts.

Adding Multiple Rows

This feature enables the user to specify the number of blank rows to be added when clicking the Insert Row button.

The number of blank rows that the user specifies is included on the page when it is refreshed, so application server processing is no longer required to add individual rows.

Do not use this feature for effective-dated grids or scroll areas.

Multiple row inserts might not apply if the entire row is populated using PeopleCode, especially if the data is copied from previous rows. If a multiple row insert does apply, the default value of the ChangeOnInit property can be used. (The default value is True, which means that any PeopleCode updates done in the RowInit or RowInsert events set the IsChanged and IsNew properties to True.)

After a transaction is saved, empty rows are discarded before the page is displayed again to the user. An empty row means that the user did not access the data and that PeopleCode or record defaults might have been used to initialize the row for the initial display.

PeopleCode Save processing (that is, SaveEdit and SavePreChange PeopleCode) runs for all rows that are in the buffer (including the empty ones). Therefore, SaveEdit and SavePreChange PeopleCode should be coded so that it runs only if the field contains data or if the row properties IsNew and IsChanged are both true.

An alternative method is adding PeopleCode in the first save program in the component to explicitly delete any row based on the IsNew and IsChanged properties. If you choose this method, then rows should be deleted from the bottom of the data buffer to the top (last row first).

To implement multiple row insert:

1. Ensure that deferred processing is set.

   Open PeopleSoft Application Designer and ensure that deferred mode is set for the component, all pages in the component, and all fields on each page.

2. Access the Page Properties dialog box of the appropriate control.

3. Enable multiple row insert.

   For each grid or scroll area where appropriate, select the Allow Multi-row Insert check box under the Use tab in the grid or scroll area property sheet.

4. Add ChangeOnInit PeopleCode.

   Setting the ChangeOnInit property for a rowset to FALSE enables PeopleCode to modify data in the row set during RowInit and RowInsert events without flagging the rows as changed. This functionality ensures that only changes entered by the user cause the affected row to be saved.

   Note. Each rowset that is referenced by a grid or scroll area with multiple row insert enabled should have the ChangeOnInit property for the rowset, including child or lower-level rowsets, set to False. In addition, you must set this property before any RowInsert or RowInit PeopleCode for the affected row.

Using Error and Warning Messages

When components, pages, and fields are set to deferred mode, FieldEdit PeopleCode errors and warnings do not appear when a user exits a field; they appear after the next application server transmission. Therefore, users might not receive an error message until they enter all of the data and click the Save button.

For FieldEdit error messages running in deferred mode, the system changes the field to red and positions the cursor at the field in error when it displays the message, enabling the user to associate the error message with a specific field. However, for warning messages, the system does not display fields nor reposition the cursor. Consequently, create warning messages that clearly describe to which fields they apply. For example, if a page contains a "Date out of range" warning, users will be confused if multiple date fields appear on the page.