application engine note
TRANSCRIPT
Application Section Step ActionApplication Engine Program
Callable block of logic.
Logical grouping of actions.
Lines of code.
Composed of one or more sections
Composed of one or more steps.
Specified by:
Market.
Effective date.
Effective status.
Platform.
Composed of one or more actions.
Smallest amount of work that can be committed.
Used to:
Retrieve or manipulate data.
Control program flow.
First section MAIN
12- character name for application
Executed only when called, except for MAIN.
Executed from top to bottom within the section.
Must be unique within step.
Executed in specific order.
Adding Markets and Filters to Application Engine Program (continued)
Sections
These rules apply to when a section is executed:
If a section exists for the current market, execute it.
If a section exists for the current platform or RDBMS execute it.
If a section for exists for the current effective date, execute it.
If a there is no unique section, execute the default section.
Within the called section, steps are executed in order of sequence number
Within those steps, actions execute from top down
1
Testing Application Engine Programs
Application Engine Testing Tools
There are several common Application Engine testing tools available to you:
The Process Monitor.
The Application Engine Trace file.
The Application Engine interactive debugger.
The PeopleCode Debugger.
Using Process Monitor (Continued)
Other Links
Other links on the Process Monitor, Process, Process Detail page include:
View Locks
Batch Timings
View Log/Trace
Using Application Engine Traces
Trace Options
For processes running on Windows, trace options are set in the Configuration Manager.
These settings are only valid when the Application Engine program is run on the client from Application Designer or from the command line.
Using the Application Engine Debugger
To start the Application Engine Debugger:
1. Launch Configuration Manager.
2
2. Select the Profile tab.
3. Highlight the Default profile.
4. Click the Edit button.
5. Select the Process Scheduler tab.
6. In the Application Engine group box, select the Debug checkbox.
Commit Settings
When using Application Engine Restart, there are several program level commit settings that can be selected to make a program restartable:
Commit after each step in that section.
Require commits after a specific step.
Commit frequency within a step or n iterations for looping actions.
In this lesson you learned that:
You can test Application Engine programs using Process Monitor, the Application Engine trace file, the Application Engine debugger, and the PeopleCode debugger.
Process Monitor allows you to check Application Engine Program Status, access run time information and re-start programs initiated in the Process Scheduler.
You start an Application Engine trace from Configuration Manager, on the Trace tab.
The Application Engine Debug tool allows you to run a program in step mode, view the State Record as it changes and set breakpoints to permit you to determine exactly what your application is doing.
Restart allows you to both debug an application during development and restart a failed production run.
3
Do Select
Do Select:
Is the equivalent of a For loop in an Application Engine program.
Is driven by a %Select statement SQL.
Populates a state record with values to be used by other actions.
Controls execution of subsequent actions in a step.
Do Select Types
The three Do Select types are:
Select/Fetch
Reselect
Restartable
The Do Select types re differentiated by:
Cursor handling.
Checkpointing and commit handling.
Cursors
A cursor is a temporary workspace used by the RDBMS to exchange information with a program.
A cursor is created and opened whenever a SQL statement is sent to the RDBMS.
A cursor’s memory buffer can contain multiple rows, retrieved in turn individually by a Fetch.
Work done on rows in a cursor is conditional until a Commit is carried out.
4
Rollback discards work done in a cursor back to the last Commit.
An Application Engine may have many cursors open simultaneously, and many may be opened and closed during the course of program execution.
Select/Fetch Flow
This flow chart illustrates the flow for Select/Fetch:
Using Select and Fetch (continued)
Commit Processing
Programs with a Do Select type of Select/Fetch are not restartable from within the loop.
5
No checkpoints are performed within the loop.
Commits will be issued if the program is not restartable.
Select/Fetch commit processing follows these rules:
If restart is enabled (the default) all Commits carried out within Do Select loops are ignored. For example, Commits on steps in called sections.
A “COMMIT setting ignored” message is written to the trace file for any commits within a Do Select loop.
If Restart is disabled, Commits are not ignored
Using Reselect
This flow chart shows the Reselect flow if restart and commits are enabled:
6
Go to Slide
Using Restartable (continued)
Do Select Loop with Restart Enabled
This flow chart illustrates a Do Select loop with Restart enabled.
Using Restartable (continued)
Ensuring that Rows are not Processed Twice
You need to have some conditions that reduce the answer set returned by the Do Select to ensure that the program does not process rows again if restart is necessary.
Options include:
7
Delete processed rows.
Add a switch to the selected table.
Add an order by clause.
Using Restartable (continued)
AE_STEP_DONE
The AE_STEP_DONE column on PS_AERUNCONTROL table tracks step processing.
Set to ‘Y’ once the entire step, all loops, is complete.
Set to ‘N’ if the program terminates in the middle of a step.
Developing an Application Engine Program Using Do Select
Step 1: Design
Here are the steps to develop an Application Engine program:
1. Analyze and design the application.
Determine your data sources.
Application Designer - Find Object References.
Data Models.
Record Cross Reference Page.
Develop and process logic pseudo-code and program source.
Decide whether the program needs to be restartable.
Step 2: Develop and Build your Application
2. Develop and Build your Application.
8
2A. Create and Test your SQL Statements.
Write and test your SQL statements.
SQL Tool.
PeopleSoft Query.
Performance-tune your SQL statements.
Tuning is an iterative process.
Work with a database administrator (DBA) using Application Engine statistics and traces.
User Optimizers (rule-based or cost-based).
2B. Build Related Definitions.
State records (Application Designer).
Messages (Message Catalog).
Method for the user to run the program:
Process Definitions (Process Scheduler).
Push buttons (Application Designer).
Batch files (Text Editor).
2C. Build the Application Engine Program.
Create the program in the Application Designer.
3. Test and Validate the Program.
Design your tests.
Initialize your data (script for retesting).
9
Test and debug.
Validate success.
Test for restart capability, if applicable.
Build the Application Engine program.
Section Step Action Type
Statement
MAIN STEPM1 Do Select Type: Select/ Fetch
%SELECT(COURSE, EFF_STATUS, DESCR,LENGTH_DAYS, …)
SELECT A.COURSE, A.EFF_STATUS, A.DESCR…
* * Call Section
INSERT
INSERT STEPI1 SQL INSERT INTO PS_PSU_COURSE_TBL VALUES (%BIND(COURSE), %BIND(EFFDT), …
* STEPI2 Log Message
Message Set = 30,000 Message Number = 4 Param. = %BIND(COURSE), %BIND(EFFDT)
Select/Fetch opens the cursor and retrieves the first row that meets the SQL criteria performs the subsequent actions, the fetches the next row meeting the criteria. This process continues until there are no more rows meeting the criteria, at which time the cursor is closed and the program continues to the next step.
Reselect opens and closes the cursor on each iteration of the loop.
Restartable acts the same as the select and fetch, except that it will COMMIT inside the loop thus allowing a checkpoint.
10
SQL State Record.
The following table shows the interaction between the SQL test condition and the state record.
SQL Result%SELECT(TEMP_FLD) Meta-SQL to write ‘X’ to State RecordSELECT ‘X’ If ‘X’ is returned this equals TRUEFROM PS_INSTALLATION Fills the SQL Syntax requirement for a
FROM tableWHERE %BIND(COUNTER) > 10 Condition to be tested, value (%BIND)
from the state record.
Designing a Program Using Conditional Processing (continued)
Step 1: Application Design
In Step 1 you will:
Design a program that will increment a counter if the number of students enrolled in a course session exceeds the maximum enrollment for that session.
A message should be issued if the counter reaches a certain number.
Step 2A: Create and Test SQL Steps
In Step 2A you will:
Validate your Selects with what is in the table.
Validate your Count with what is in the table.
Enroll Table (Where Course=1001 and Session Nbr = 1)
Session Table (Where count(*) >= MAX_ENROLL)
Step 2B. Build Related Definitions
11
In Step 2B you will:
Create new fields.
Define state records
Create messages in the Message Catalog.
Step 2C. Write the application.
Create the WAITLIST Application Engine program.
Designing a Program Using Conditional Processing (continued)
Step 3. Test the Application
In step 3 you will:
Trace statement timings
Run from Application Designer
Save the trace to compare with others generated later.
Activate and test using the Debugger.
Application Engine Library
An Application Engine library:
Is a collection of shared Application Engine program sections
Contains sections defined as Public.
May not be defined to run standalone.
Does not require a MAIN Section.
12
Is not intended to store a specific SQL action within a section.
The steps of program construction are:
1. Application Design
2A. Create and Test SQL Steps
2B. Build Related Definitions
2C. Write Application
3. Test Application
Inserting PeopleCode into an Application Engine Program (continued)
The If-Then Statement
The parameter in the Exit function controls the path the Application Engine program will take.
“1” indicates that the On Return instruction will be executed.
“0” tells the program to ignore the On Return action.
For example:
If &Test = 10 Then
Exit(0); /* or can use Exit 0; */
Else
Exit(1); /* or can use Exit 1; */
End-If;
On Return
The On Return options are:
Abort The program issues an error and exits immediately.
13
Break The program exits and control returns to the calling step.
Skip StepThe program exits the current step, and continues with the next step.
Exit Code
The following diagram illustrates how the Exit code controls program flow.
Enabling Dynamic Calls (continued)
Enabling a Dynamic Call
To enable a dynamic call:
1. Add a PeopleCode action.
2. In the action, based on a condition test, store a program name and a section name in the state record. The two fields used with dynamic calls are:
AE_APPLIDfor the Application Engine program name.
AE_SECTION for the Application Engine section name.
14
The fields must be populated, typically using PeopleCode.
The fields must exist in the default state record.
3. Following the PeopleCode action, add a Call Section action with the Dynamic Call checkbox selected.
Temporary Tables
Set processing can make use of temporary tables to preselect data that can then be handled via a single SQL statement.
Temporary tables are designed to:
Hold transaction data for the current run or iteration of your program.
Contain only those rows of data affected by the business rule.
Present key information in a denormalized form.
Switch the keys for rows coming from the master tables if needed.
Modifying a Program to use Set Processing (continued)
CRS_FULL_TMP Data Model
The following diagram illustrates temporary table relations for the WAIT_SET temporary table, CRS_FULL_TMP.
15
Parallel Processing
Parallel processing is the simultaneous execution of multiple instances of a single program.
Uses of parallel processing include:
Concurrent execution of a program by multiple users.
Reduction of processing time by partitioning high volumes of data into batches to be processed by separate instances of a program.
Online and Batch Methods
When Application Engine programs are run in parallel, they are run in one of two methods:
Online (synchronously) – implemented through a code callappengine() function.
Batch (asynchronously) – implemented through a process definition initiated via the Process Scheduler.
Due to the differences in execution of these two methods the temporary tables used must be segregated.
16
This table summarizes PeopleSoft temporary table solutions:
Online BatchInvoked by CallAppEngine from PeopleCode.
Invoked through the process scheduler.
Run quickly, synchronously, and at random times.
Run for longer amounts of time, asynchronously, and at scheduled times.
Potential for simultaneous execution. Potential for simultaneous execution and can be designed for parallel execution for performance.
Uses the online temporary table pool. Uses the batch/dedicated temporary table pool.
Not restartable Restartable
Implementing Parallel Processing
Steps to Implement Parallel Processing
The steps to implement parallel processing are:
1. Define your temporary tables.
2. Set or check the temporary table online pool. This is a global setting and is usually established at installation time.
3. Assign temporary tables to be dedicated to each Application Engine program.
4. Set the number of dedicated temporary tables to form the number of temporary tables to be created for the process to be run in parallel.
5. Build or rebuild your temporary table record to create the appropriate number of temporary table instances assigned to the Application Engine parallel process.
6. Adjust your program meta-SQL (i.e. %TABLE) to resolve the data set to the appropriate application engine process being run in parallel..
Implementing Parallel Processing (continued)
17
Defining your Temporary Tables
1. Define your temporary tables
1. a. Create a new record.
PeopleSoft recommends that you make Process Instance a key field. The process instance is used to restart the process should it abnormally end.
2. b. Set the Record Type to Temporary Table.3. c. Save the record.
Temporary Table Online Pool
1. Set or check the temporary table online pool.
On the PeopleTools Options page, specify:
Temp Table Instances (Total)
Temp Table Instances (Online) – used by callappengine() function
Total temporary table instances that will be SQL created is:
The value in Temporary Table Instance (Total).
The sum ofinstance count values specified in all of the Application Engine Programs that use that temporary table.
A maximum of 99 temporary table instances can be created.
EPM Temporary Tables
18
This diagram illustrates which temporary tables are reserved.
Assigning Temporary Tables
1. Assign Temporary Tables to the Application Engine program.
Use the Temp Tables tab on the Program Properties dialog box to assign temporary tables.
Also on this tab assign Instance Count and specify Continue or Abort if non-shared tables cannot be assigned.
Setting the Temporary Table Batch Pool
1. Set the Temporary Table Batch pool
If the program will be run in batch, you will need to establish the number of temporary table instance that will be used for your program.
Use the Instance Count field on the Temp Tables tab of the Program Properties dialog box.
If the program will only be run in batch mode, select the Batch Only checkbox on the Program Properties: Advanced tab.
1. Build or rebuild your temporary table record.
19
This diagram shows how temporary tables are allocated based on Instance Count in the program properties:
Application Engine Temporary Table Use, Running in Parallel
This diagram shows an example with three Application Engine programs using a variety of temporary tables with different instance counts.
20
Application Engine Temporary Table Use, Running Serially
This diagram shows an example with three Application Engine programs using a variety of temporary tables with different instance counts:
Adjusting Meta-SQL
1. Adjust your program Meta-SQL to resolve the application engine program to the temporary table assigned to it’s process at run time.
Table references must be set up using %Table.
To add rows to temporary tables, you must provide the process instance number using either:
%ProcessInstance
%Bind(PROCESS_INSTANCE)
While assigned Temporary Tables are cleared at the start of processing, no automatic deletes happen during or at the end of the program. You may want to consider using an action containing SQL with %TruncateTable for additional deletes during or at the end of the run.
Using Meta-SQL with Parallel Processing (continued)
Single Temporary Table Assignment with %Table
With no batch or dedicated tables assigned, this statement:
21
Select PROCESS_INSTANCE,TEMP_COL1,TEMP_COL2
from %Table(MYAPPLTMP)
is resolved as shown in this diagram.
Multiple Temporary Table Assignment with %Table
Where multiple batch or dedicated tables are assigned, this statement:
Select PROCESS_INSTANCE,TEMP_COL1,TEMP_COL2
from %Table(MYAPPLTMP)
is resolved to an available instance of the temporary table, as shown in this diagram.
22
Batch Processes
Batch/dedicated table instance numbers are allocated on a record-by-record basis.
Numbers start with the lowest instance number until all numbers are in use.
If all instances are used and you indicated Continue for the If non-shared Tables cannot be assigned, additional programs use the base table with Process Instance as a key.
When a program ends normally or is cancelled in Process Monitor, assigned instances are automatically released.
Batch Processes
Batch/dedicated table instance numbers are allocated on a record-by-record basis.
Numbers start with the lowest instance number until all numbers are in use.
If all instances are used and you indicated Continue for the If non-shared Tables cannot be assigned, additional programs use the base table with Process Instance as a key.
When a program ends normally or is cancelled in Process Monitor, assigned instances are automatically released.
Batch Processes
Batch/dedicated table instance numbers are allocated on a record-by-record basis.
Numbers start with the lowest instance number until all numbers are in use.
If all instances are used and you indicated Continue for the If non-shared Tables cannot be assigned, additional programs use the base table with Process Instance as a key.
When a program ends normally or is cancelled in Process Monitor, assigned instances are automatically released.
This table gives a summary of differences between batch and online execution:
Online Execution Batch/Manual Execution
23
Started by CallAppEngine, executed as from PeopleCode.
Executes PSAE through Process Scheduler or the command line
Intended for programs that run quickly, synchronously, and at random times.
Intended for programs that run for longer periods of time, asynchronously, and at scheduled times.
Potential for simultaneous execution.
Can be designed for parallel execution for performance.
Uses the online temporary table pool.
Uses the Batch/Dedicated temporary table pool.
Executing an Application Engine Program Using a Push Button (continued)
Synchronous Execution
Use synchronous execution when:
Processing should be of short duration.
Processing requires some task to complete before further processing can occur.
Application Engine performs a SQL task more efficiently than some other methods.
A developer will be able to take advantage of existing Application Engine resources.
Setting up a Synchronous Call to Application Engine
To set up a synchronous call to Application Engine:
1. Create a record and field for the push button.
2. Add FieldChange PeopleCode containing CallAppEngine to call the program.
3. Add a push button to the page you wish to use to launch the process.
4. In the push button properties, select PeopleCode Command for the Destination.
5. Enter the record and field containing the PeopleCode into the push button properties.
24
Command Line Execution
Use Command Line execution of an Application Engine Program (PSAE.EXE) for:
Restarting a program.
Development/Testing.
Debugging.
Parameters
This table lists the minimum parameters that are required in addition to the path where PSAE.exe resides:
Description ParameterDatabase platform (e.g. Microsoft, Oracle, DB2, etc.)
-CT <dbtype>
Database name -CD <database name>Logon ID -CO <oprid>Password -CP <oprpswd>Run Control -R <run control id>Application Engine program -AI <application id>
Creating Application Engine Process Definitions
Purposes of Process Definitions
A process definition serves four primary purposes:
Identify the type of process to be run.
Identify the program name to be run.
Identify from where the program is to be run.
25
Identify who has security access to run the program.
Implementing an Application Engine Program with No User Inputs
Adding an Application Engine Process
To add an Application Engine process:
1. Design the Program.
2. Identify fields for user input.
3. Determine a Run Control record.
You may have to create one if input parameters are required.
4. Build the record.
5. Determine Run Control page.
Implementing an Application Engine Program with No User Inputs (continued)
Adding an Application Engine Process
The steps to add an Application Engine process are (continued):
1. Place page on a component.
2. Register the component, place on menu and apply security for the permission list.
3. Add a Process Definition.
4. Make Application Engine Program Modifications (if required) to read the input parameters.
5. Test
26
Implementing an Application Engine Program With User Inputs
Input Parameters
Many Application Engine programs require the user to input parameters.
Developing to include user input parameters requires:
A run control page with fields to enter the input parameters.
A run control record with fields to store the input parameters.
A state record with fields to store input parameters.
Modifications to the Application Engine program to retrieve the input parameters.
1 Design2 Identify fields for user input to be included on the run control record.3 Determine Run Control record 4 Build the record5 Determine Run Control page6 Place page on a component7 Register the component and set security with the registration wizard8 Add a Process Definition9 Add the necessary actions to your application engine program10 Test
Daemon Programs
A daemon program is an Application Engine program of daemon type that checks for an event.
When an event occurs, the daemon will trigger the process to handle the event.
Daemons allow processes to be driven based on events rather than a schedule.
Events can be internal or external to the PeopleSoft application database.
27
Daemon Groups
A collection of daemon programs for a Process Scheduler server definition is called a daemon group.
Unlike scheduled processes, the daemon group is re-initialized when a batch server restarts.
Grouped programs are run sequentially.
Each Process Scheduler server can have only one daemon group assigned to it.
28
Daemon Groups
PSDAEMON programs are run by assigning them to a daemon group and associating that group with a Process Scheduler server definition that is used by a Process Scheduler server.
This diagram shows how PSDAEMON is tied to a Process Scheduler server.
Go to Slide
< Prev | Home | Next >
Slide 226
Describing Traces
Three Traces
You will look at three traces:
29
Application Engine Trace.
SQL Trace.
PeopleCode Trace.
Describing Traces (continued)
PSAE.EXE Command-Line Parameters
This table summarizes PSAE.EXE command-line parameters for tracing.
Trace Name Trace Description Parameter Typical Trace Value
Application Engine Trace
Application Engine Trace File
-TRACE <tracevalue> 384
SQL Trace Tools SQL Trace -TOOLSTRACESQL <tracevalue>
31
PeopleCode Trace
Tools PeopleCode Trace
-TOOLSTRACEPC <tracevalue>
2048
Describing Traces (continued)
Trace Values
Here are 4 of the 8 trace values available to you for the -TRACE parameter:
Value Description1 Step Trace2 SQL Trace128 Timings Trace256 PeopleCode Detail
Timings
30
If you want Timings Trace Option (128) and PeopleCode Trace Option (256), add their values together to yield a trace value of 384.
Two-Tier Trace Settings
Use the Configuration Manager trace tab to select two-tier trace settings for:
Application Engine Trace.
SQL Trace.
PeopleCode Trace.
Passing Trace Values to PSAE.EXE (continued)
Process Scheduler Trace
If your program is being run through Process Scheduler, you can pass the additional trace parameters to the Process Definition, on the Override Options page.
Passing Trace Values to PSAE.EXE (continued)
Command Line Trace
To pass the additional tracing variables when executing your program from a command line, add on any additional parameters that you need with the trace value you want.
CallAppEngine Trace File Settings
Application Engine trace (-TRACE) settings are turned on in the Application Server configuration file using PSADMIN.
Trace settings made here affect all users and all online activity.
The SQL and PeopleCode traces may be activated for individual users via PIA trace options if available at logon.
31
The trace files will be sent to the Application Server’s log file directory.
Application Engine Trace File
The Application Engine trace file contains:
Columns for Compile, Execute, and Fetch counts and time.
A Total Time column.
A summary of PeopleCode actions.
Timing for PeopleCode built-in functions and methods.
A summary section.
TOOLSTRACESQL and -TOOLSTRACEPC
Use -TOOLSTRACESQL and -TOOLSTRACEPC only when:
The level of detail in the -TRACE parameter is not enough or
You required more specific details about the activities surrounding your program’s execution.
The PeopleTools Trace file will have the combined data collected for the PeopleCode trace and the SQL trace.
Interpreting the PeopleTools Trace (continued)
Column Definitions
32
This diagram shows the SQL trace information in the PeopleTools trace file:
SQL Statement Compilation and Execution And Fetch
This segment of the PeopleTools trace file shows SQL statement compilation and execution and fetch:
Interpreting the PeopleTools Trace (continued)
TOOLSTRACEPC Parameter
This segment of the PeopleTools trace file shows information generated by the –TOOLSTRACEPC parameter:
33
Advanced Trace Options
Two advanced trace options are:
DB Optimizer (file).
DB Optimizer (table).
In this lesson you learned that:
When improving performance on any system, it is important to take into account all areas of your system and understand the big picture.
The information gathered in a trace points to where to focus your tuning efforts.
At the Application Level, three trace parameters are key to gathering trace data:
-TRACE, -TOOLSTRACESQL, -TOOLSTRACEPC
The following trace settings are the most useful:
-TRACE 384, -TOOLSTRACESQL 31, -TOOLSTRACEPC 2048
-TRACE is your Application Engine Trace; -TOOLSTRACESQL and -TOOLSTRACEPC are PeopleTools traces.
34
Advanced trace options trace the performance of SQL statements on the database.
Five aspects we will discuss in this section are:
How traces can affect performance. Too many trace settings will skew the results.
How the ReUse option can reduce processing time.
How Commits and Checkpoints can affect performance.
Coding Bulk Insert SQL.
SQL vs. PeopleCode.
Identifying Application Level Tuning Opportunities (continued)
Tracing
Tracing can affect performance.
Gather the minimum trace information you need.
For batch timings, trace 384 (SQL and PeopleCode timings) is recommended.
It is highly recommended you do not have trace turned on in the production environment.
ReUse
ReUse Option:
Is generally most effective when looping.
Replaces %Bind variables with real bind variables.
Causes the program to reuse an execution plan.
When Not to Use ReUse
Do not use ReUse:
35
When limited by database platform functionality.
When SQL changes dynamically in the program.
Unnecessary Commits
Unnecessary commits can make a significant difference in your program’s run time.
Commits (and corresponding checkpoints) are set:
At the section level: Auto Commit After Step checkbox.
At the step level: Commit After dropdown and Frequency field.
Every commit with restart enabled causes an update to PS_AERUNCONTROL.
Bulk Insert
Bulk Insert takes advantage of your databases ability to place data in a memory buffer before the table insert.
To use this option your SQL must follow a specific structure to work properly.
Incorrect syntax for Bulk Insert:
INSERT INTO PS_SOME_TBL
VALUES (%BIND(FIELDX), %BIND(FIELDY), %BIND(FIELDZ))
Correct syntax for Bulk Insert:
INSERT INTO PS_SOME_TBL (FIELD1, FIELD2, FIELD3)
VALUES (%BIND(FIELDX), %BIND(FIELDY), %BIND(FIELDZ))
PeopleCode Actions
PeopleCode actions in Application Engine are meant to be limited to the following:
36
Testing for conditions (If-Then-Else).
Performing computations.
Building dynamic portions of SQL.
Sharing complex business rules between online and batch processing.
Accessing PeopleTools integration technologies.
In this lesson you learned that:
Many factors tied to your database affect performance. Manipulating these factors can affect the performance of other systems.
Application level performance tuning is by far the best place to start your Application Engine tuning.
The ReUse option is an excellent way to easily reduce the amount of work your program is doing to execute the SQL in your Application Engine program.
Executing SQL within a PeopleCode action is far less efficient than using the other Application Engine actions.
The Bulk Insert option can speed up your SQL Inserts within a loop.
Commits and checkpoints should be structured strategically.
37