Deferred Processing Mode

When a component runs in deferred processing mode, trips to the server are reduced. When deploying some pages in the browser, you may want the user to be able to input data with minimal interruption or trips to the server. Each trip to the server can slow down your application. By specifying a component as deferred processing mode, you can achieve better performance.

PeopleSoft applications use AJAX (Asynchronous JavaScript and XML) technology to limit server trips and perform partial page refreshes. AJAX uses asynchronous data transfer (HTTP requests) between the browser and the web server, allowing web pages to request small bits of information, rather than whole pages, from the server. AJAX technology makes Internet applications smaller, faster, and more user-friendly.

With a partial page refresh, the browser refreshes the entire page only when the user navigates to a new page. Any server trips triggered by PeopleCode functions, such as FieldChange and FieldEdit, or for related display fields do not redraw the entire page; the refresh updates only the changed fields. Because of AJAX technology, much of the communication with the server happens in the background. Users continue to work uninterrupted during this background processing.

AJAX and partial page refreshes allow you to more freely design interactive applications and deploy interactive fields. Nevertheless, the default configuration for components, pages, and fields remains deferred mode. Oracle still recommends that you leverage deferred processing mode to limit network traffic. Note that:

• Deferred processing set at the component level can be overridden at either the page field or page level.

• Conversely, interactive processing set at the component level cannot be overridden at either the page field or page level.

• Similarly, interactive processing set at the page level cannot be overridden at the page field level.

The characteristics of deferred processing mode are:

1. Field modification processing is deferred.

   No field modification processing is done in the browser. FieldEdit and FieldChange PeopleCode, as well as other edits, such as required field checks, formats, and so on, do not run until a specific user action occurs. Several actions cause field modification processing to execute, for example, clicking a button or link, navigating to another page in the component, and saving the page. The following actions do not cause field processing:

   • Clicking an external link.

   • Clicking a list (performing a search).

   • Clicking a process button.

     Deferred processing mode affects the appearance of pages in significant ways. For example, related processing is not done when the user presses Tab to move out of a field. Avoid related fields for components that use this mode.

2. Drop-down list box values are static while the page appears in the browser.

   Drop-down list box values are generated on the application server when generating the HTML for the page.

   If translate values are used to populate the drop-down list box, and the current record contains an effective date, that date is static while the page is displayed. This means the drop-down list box values may become out of date.

   If prompt table values are used to populate the drop-down list box, the high-order key field values for the prompt table are static while the page is displayed. This means the drop-down list box values may become out of date.

   Avoid interdependencies in drop-down lists used on pages executed in deferred mode, because the lists may quickly become out of date.

3. No field modification processing is done during prompt button processing.

   When the user clicks a prompt button, a trip is made to the application server (if values were not already downloaded) to select the search results from the database and to generate the HTML for the prompt dialog box. During this trip to the application server, field modification processing for the field being prompted is not performed, because this may cause an error message for another field on the page, and this error may confuse the user. When deferred changes are made to other fields, field modification processing for these fields is done before prompting. The field modification for the prompted field is done after returning from the prompt page. While the system displays the page, the high-order key field values for the prompt table should be static or not require field modification processing. Display-only drop-down list box, radio button, and check box fields do not require field modification processing. Field values that do not require field modification processing are temporarily written to the component buffer, without any field modification processing being performed on them, including FieldEdit and FieldChange PeopleCode. The system restores the original state of the page processor before returning to the browser.

4. Field modification processing executes in field layout order.

   The entire field modification processing sequence executes in field layout order for each field. If a field passes the system edits and FieldEdit PeopleCode, the field value is written to the component buffer. If an error occurs, field modification processing stops, and the system generates new HTML for the page, with the field in error highlighted and sent to the browser.

5. PeopleCode dependencies between fields on the page do not work as expected.

   Avoid PeopleCode dependencies between fields on pages displayed in deferred processing mode. Also, avoid FieldChange PeopleCode that changes the display.

   The following are examples of PeopleCode dependencies between fields on the page and the application server's action. In the following examples, field A comes before field B, which comes before field C.

   • Field A has FieldChange PeopleCode that hides field B or it makes unavailable for entry.

     The value in field B of the page that was submitted from the browser is discarded.

   • Field B has FieldChange PeopleCode that hides field A or makes it unavailable for entry.

     The change made by the user for field A, if any, remains in the component buffer.

   • Field A has FieldChange PeopleCode that changes the value in the component buffer for field B.

     If the value in field B of the page that was submitted from the browser passes the system edits and FieldEdit PeopleCode, it is written to the component buffer, overriding the change made by field A’s FieldChange PeopleCode.

   • Field B has FieldChange PeopleCode that changes the value in the component buffer for field A.

     The change made by field B’s FieldChange PeopleCode overrides the change made by the user to field A, if any.

   • Field A has FieldChange PeopleCode that unhides field B or makes it available for entry.

     Field B has the value that was already in the component buffer. If the user requests a different page or finishes, the user may not have the opportunity to enter a value into field B, and therefore the value may not be correct.

   • Field B has FieldChange PeopleCode that changes the value in the component buffer for field A, but field C has FieldChange PeopleCode that hides field B or makes it unavailable for entry.

     The change made by field B’s FieldChange PeopleCode, a field that is now hidden or unavailable for entry, overrides the change made by the user to field A, if any.

     Avoid such dependencies by moving FieldChange PeopleCode logic from individual fields to save processing for the component or FieldChange PeopleCode on a PeopleCode command button.

6. Not all buttons cause field modification processing to execute.

   External links, list (search), and process buttons do not cause field modification processing to execute.

7. You can use a PeopleCode command button to cause field modification processing to execute.

   An application can include a button for the sole purpose of causing field modification processing to execute. The result is a new page showing any display changes that resulted from field modification processing.

   In addition, if the user clicks the Refresh button, or presses Alt + 0, deferred processing is executed.

   Note: The Refresh button does not refresh the page from the database. It simply causes a server trip so any deferred PeopleCode changes get processed. If the page has no deferred changes or the deferred changes do not cause any errors or other changes on the page, it may appear to the user as if nothing happened.

8. A scroll button (link) causes field modification processing to execute.