You are on page 1of 21

Application

Engine
What is an Application Engine
• Application Engine is the PeopleTool that you
use to develop batch or online programs that
perform high volume, background processing
against your data.
• Designed to help you develop, test, and run
background SQL
• processing programs.
Advantages of an Application
Engine
• Seamless integration.
• Easy to code. The Application Designer
allows one to create/modify the program in
the Definition View and see a graphical
representation of the program execution in
the Program Flow View.
• All the logic sits in the PeopleSoft
database hence is secure
• Less chance of data corruption as no flat
files (e.g sqr, Cobol,and nvision) are
involved
• No need to install any third party or
external dll’s (e.g sqr, Cobol, and nvision)
• One can make use of Component
Interfaces along with File Layouts to
import data from other third party systems
and do necessary validations on the data
to populate the PeopleSoft database.
Application Engine
Components
• Sections
• Steps
• Actions
• State Records
• Temp Tables
Sections
• Consists of one or more steps
• Sections of one program could be called
from same / different
programs
• Every AE has a MAIN Section except for
Application Libraries (will be
discussed later).
• Sections can be called only through CALL
SECTION action type
Steps
• Used to break and organize logical units of
a program within a Section.
• A step may contain one or more actions
Actions
• Four types of Actions:-
– SQL,
– PeopleCode,
– Logging and
– Program Flow
• Does the actual data manipulation based
on logic coded for the AE.
SQL Actions
• Used to do Updates, Inserts, Selects ,and
Deletes on your data
• The best place to run all your SQL
statements.
• An AE should contain more of SQL than
any other Action Type for doing data
manipulation.
• One should exploit set-processing (will be
discussed later) in the SQL Action
Actions
Four types of Actions:-
• SQL,
• PeopleCode,
• Logging and
• Program Flow
Peoplecode Action
• Can be used to run the logic of a Program
using PeopleCode.
• Used for doing complex logical processing
based on multiple
data from multiple sources.
• Use of PeopleCode should be at a bare
minimum.
• Mainly used with Component Interfaces
and File Layouts
Logging Action
• Used for sending out descriptive messages
when the AE is
running
• Useful in large AE’s for traceability
• Works in tandem with the message
catalog.
• Log messages can be viewed using the
Process Details link
Program Flow Actions
• All Actions starting with Do are Program
Flow Actions.
• There is always one or more other actions
if a step contains a Do Action.
• All Do Actions accepts only SQL queries
• The different Do Actions are:-
– Do When
– Do While
– Do Select
Do Actions
• Do When
• Do While
• Do Select
• Do Until
Do When Action
• If an SQL present in the Do When returns
one or more rows the subsequent Action(s)
would be executed only once.
• The number of fields or type of fields
returned by the Do When Action are
immaterial.
Do While Action
• If an SQL present in the Do While returns
one or more rows, the subsequent Action(s)
would be executed in a loop as long as the
SQL returns values for every new loop run.
• The number of fields or type of fields
returned by the Do While Action are
immaterial.
Do Select Action
• If an SQL present in the Do Select returns
one or more rows, the subsequent Action(s)
would be executed in a loop as long as the
SQL returns values for every loop run.
• The values returned by the Do Select are
generally inserted into the state record for
row by row processing
Do Until Action
• If an SQL present in the Do Until returns
one or more rows, all previous Action(s) in
the step would be executed in a loop as long
as the SQL returns values for every new
loop run.
• The number of fields or type of fields
returned by the Do Until Action are
immaterial.
• Do Until makes sure that the previous
Action(s) in the step execute at least once.
State Records
• Used to store bind values
• Used for passing values across
programs/sections/steps
• Useful for row-by-row processing
• Used mainly for passing run control
parameters from the run control page to the
Program
Temp Tables
• Used for storing intermediate data on
which specific logic needs to be run.
• More efficient as the number of rows on
which data manipulation needs to happen is
reduced.
• Each concurrent instance of the Application
Engine would get its own temp table record
hence avoiding locking/conflicts of base
tables at the database level.
• Can be used to leverage Set Processing

You might also like