Application Engine

Understanding Application Engine

2© Hexaware Technologies. All rights reserved.

Topics Covered

• What is an Application Engine ?• Why use Application Engines• Program Components• Types of Actions• Action Execution Rules • State Records• Restartable Application Engines • Commonly used AE Meta SQLs• Performance Improvement Techniques• Tracing Options


What is an Application Engine ?

• Application Engine is a development tool that allows you to develop programs that execute SQL against your data in a procedural and dynamic structure.

• The key word in the previous statement is "SQL”. Despite Application Engine's richer functionality, its primary purpose is still to run SQL against your data. In other words, Application Engine is not intended to execute programs that include only PeopleCode Actions.


Why use Application Engine ?

• Encapsulation - Unlike applications developed using COBOL or SQR, Application Engine programs reside completely within your database. With Application Engine, you do not have to compile your programs, there are no statements to store, and there is no need to

directly interact with the operating environment you use. • Upgrade Support - Since Application Engine program

definitions are defined in and stored as Application Designer objects, they join the growing ranks of PeopleTools components that you can easily upgrade using Application Designer.

• Reuse Business Logic - Application Engine programs can now invoke PeopleCode. This means that from Application Engine you can call common PeopleCode functions that you use throughout your PeopleSoft system. Conversely, PeopleCode can now invoke an

Application Engine program.


Why use App-Engine .. (contd.)

• Built-In Restart Logic - Within each Application Engine program, you must define how frequently your program will issue a COMMIT. After doing so, each COMMIT becomes a "checkpoint" that Application Engine uses to locate where within a program to restart after an abend.

This type of built-in logic does not exist in COBOL or SQR. You

need to code any restart logic for your programs yourself. • Meta-SQL Support - Application Engine supports

PeopleSoft meta-SQL. This language is designed to replace RDBMS-specific SQL syntax with a standard syntax, called meta-strings.

• Platform Flexibility - You have the ability to call different versions of a Section for different platforms. You can specify a Section to be one of the following:– (base). Think of this as the common denominator or global version.

– Any supported RDBMS platform, as in DB2/UNIX, Oracle, Informix, and so on.


Program Components

• Program - An Application Engine program identifies the set of processes to execute a given task. A program must contain at least one Section. The execution of the program always starts with the Section defined as "MAIN."

• Sections - A Section is a set of ordered Steps that gets executed as part of a program. You can call Sections (and other programs) from Steps within other Sections.

• Steps - A Step is the smallest unit of work that can be committed within a program. When a Section gets called, its Steps execute sequentially. Every program begins by executing the first Step of the required Section called MAIN and ends after the last Step in the last Section completes successfully.

• Actions - An Action is the object where the actual program logic is ‘coded’. It is common to have multiple Actions associated with a single Step.


• Program Flow Actions - A Program Flow Action contains a SQL SELECT statement designed to return results on which

subsequent Actions depend. There are the four types of Program Flow Actions:

• Do While. • Do When.• Do Select.• Do Until.

• SQL Action - Contains a single SQL statement that performs either a SELECT, INSERT, UPDATE or DELETE.

Types of Actions


• Peoplecode Action - This action is where we can write all the Peoplecode required. This action provides access to the PeopleSoft Internet Architecture's integration technologies such as Application Messaging, Business Interlinks, Component Interfaces, and XML File Processing.

• Call Section - This is an Action that calls another Section. The "called" Section can be in the same program as the calling Section, or it can be in an external program.

• Log Message - A Log Message Action can be used to write a message to the MESSAGE_LOG based on a particular condition in your

program. Could help in debugging or in providing multi-language

capability.

Types of Actions (contd.)


Action Execution Rules

• The actions SQL and Call Section cannot be part of the same Step.

• Cannot have the same Action type twice in a single step.• Due to the above reasons, the maximum number of actions

within a step can be 7 with the following execution sequence


State Records

• The Application Engine State Record is the method by which you allocate variables for your Application Engine program, and it is also the method by which Section, Steps, and Actions pass values to subsequent program steps. You can think of State Records in Application Engine as global variables without scope limiting rules.

• You can have any number of State Records associated with a particular Application Engine program. However, only one record can be the default State Record. You can specify both work (derived) and "physical" (SQL table) record to be used as State Records. The only difference is that derived State Records cannot have their values saved to the database at commit time, and so the values would be lost during a restart.

• An Application Engine State Record must have PROCESS_INSTANCE defined as the first field and the only key field. And, so that the system recognizes the record as a State Record, all State Record names must end with the _AET identifier.


State Records (contd.)

• Sharing of State Records - The "scope" of the State Records will be global in that they are not only designed to service multiple Sections, they can also be used by multiple programs. When you call a Section in another program, any additional State Records defined for that program (as in State Records that are not already in use by the calling program) will be initialized, even if the program has been called previously during the run. But State Records that are common to both programs will retain their current values.

• Referencing State Records - To reference variables that exist within a State Record, use %BIND(fieldname). Unless a specific record name is specified preceding the fieldname, %BIND references the default State Record. To reference a State Record other than the default, you need to use %BIND(recordname.fieldname).

• In the case of a called program or Section, if the called program has its own default State Record defined, then Application Engine uses that default State Record to resolve the %BIND(fieldname). Otherwise, the called program will inherit the calling programs default State Record.


Disabling Restart

• You're committing after N iterations of a looping construct within a Step, and the SELECT statement driving the loop is composed in such a way that if the program abend and then started again, it would ignore transactions that were already processed in the previous program run. In this sense, the program handles the restart internally in that Application Engine treats each start of a program as a "fresh" start instead of restarting a previous instance.

For row-by-row processing.

You don't want the overhead involved with Application Engine performing a checkpoint during the program run.

There are certain conditions for which you may want to disable Restart


Restartable Application Engines

By default, Application Engine doesn't perform a COMMIT until an entire program successfully completes. It's up to program developers to set any individual Commits where appropriate.

At the Section level, you can choose to Commit after each Step in that Section.

At the Step level, you can require or defer COMMITs for individual Steps, or you can increase the COMMIT frequency within a Step to n iterations of a looping action within a Step, such as a Do Select or Do While.

PS_AERUNCONTROL- record where last commit point stored. Keyed by PROCESS_INSTANCE.


Commonly Used AE Meta-SQLs

• %Bind The Application Engine function, %Bind, is used to retrieve a field

value from a State Record. The %Bind function can be used anywhere in a SQL statement.

%BIND([recordname.]fieldname[,NOQUOTES][,NOWRAP][,STATIC])

• %Select A %SELECT is required at the beginning of any and all SELECT

statements. It identifies the State Record fields to hold the values returned by the corresponding SELECT statement.

%SELECT(statefield1[, statefield2]...[, statefieldN])

SELECT field1[, field2]...[, fieldN]


Commonly Used AE Meta-SQLs

• %SelectInit It is identical to %SELECT barring the following exception. If the

SELECT returns no rows, %SelectInit reinitializes the buffers. In the case of a %SELECT and no rows are returned, the State Record fields retain their previous values

• %SQL Use the %SQL function for common SQL fragments that you have

already defined and want to re-use, substituting additional values dynamically. SQLid is the name of a SQL definition created using either Application Designer or the StoreSQL function.

%SQL(SQLid [, paramlist])


Performance Improvement

One of the key performance features of Application Engine is the abilityto "re-use" SQL statements.

• ReUse (SQL Action Property)

Unless you select the ReUse property for you SQL Action, %BIND fields are substituted with literal values in the SQL statement. This means that the database has to recompile the statement every time it is executed.

However, selecting ReUse converts any %BIND fields into real bind variables (:1, :2, and so on), allowing Application Engine to compile the statement once, dedicate a cursor, and re-execute it with new data multiple times. This reduction in compile time can bring dramatic improvements to performance.

• Bulk Insert (SQL Action Property)

By buffering rows to be inserted, some databases can get a considerable performance boost. It should only be considered when the INSERT SQL is called multiple times in the absence of intervening COMMITs.


• IF, THEN Logic (using Peoplecode)

Instead of using Do When, we can use Peoplecode to simulate IF/THEN logic. Eg. If StateRec.Field1 = 'N’

Exit(1);

Else

Exit(0);

End-if;

• Set Processing

Set processing is a SQL technique used to process groups, or sets, of rows at one time rather than processing each row individually.

Eg : UPDATE EmployeeTable SET Salary = Salary + 0.25

WHERE SalaryType = 'HOURLY'

Performance Improvement


Trace Options

Application Engine Trace• TRACEAE = 255. Traces every SQL in the App Engine and

shows the buffer values.• TRACEAE = 128. Only shows the timing codes for each

statement. Useful for checking performance.

Peoplecode Trace• TRACEPC = 108. This option is useful when setting trace for all

Peoplecode in the Application Engine.

Using Process Scheduler

Append in Parameter List -TRACE 255 -TOOLSTRACEPC 108

Documents

Application Engine