You are on page 1of 3

Limitations of Application Engine

1. The Maintenance of the SQL statements is entirely dependent on the


Developer.
2. Calling AESection object from an Application Engine PeopleCode Action
leads to Decreased Performance.
3. Application Engine does not commit a Step containing a DO Select with
the Select/Fetch option enabled until the entire Step completes
successfully.
4. A DO Select statement thats coded for Restartable can be converted to
Select/Fetch, but the opposite is not true.
5. Bulk Insert in the Action properties does not work with Informix.
6. Set processing does not necessarily behave the same on every database
Platform. Coincidentally, on some platforms, set processing can encounter
performance breakdowns. Some platforms do not optimize UPDATE
statements that include sub-Queries.
7. If you are using more that 10 Temporary tables the performance of the
Application Engine Program will be affected.
8. When you have manually released the temporary tables from their locked
state, you lose any option to restart the program run.
9. When developing for restart, the logic to handle the Restart should be well
defined, if not the performance gets reduced.
10. Reporting is difficult.
11. Peoplecode calls with in Do Loops leads to Decreased Performance. The
"startup and teardown" costs of the PeopleCode Interpreter will be
multiplied.
12. PeopleSoft recommends that you avoid using arrays & Global Variables in
your Application engine PeopleCode. In situations where you are tempted
to use an array, explore the use of temporary tables for storing

pertinent/affected data. Using temporary tables also lends itself to setbased processing for which Application Engine is most suited.
13. Application Engine programs can't access Page buffers.
14. Commit work function only applies to an Application Engine program
that's running in batch (not online). If the program is Invoked via
CallAppEngine, the CommitWork will be ignored. The same is true for
commit settings at the Section or Step level.
15. Commit work function can only be used in an Application Engine program
that has restart disabled. If you try to use this function in a program that
doesn't have restart disabled, you'll receive a runtime error.
16. The CommitWork function is only useful when you are doing row-at-atime SQL processing in a single PeopleCode Program and you need to
commit without exiting the program.
17. The SQL Editor doesn't validate all of the meta-SQL constructs, such as
%BIND and %SELECTS.
18. You can not use %SQL to reference SQL that resides within a Section in
an Application Library. Common SQL should be stored as a proper SQL
Object.
19. When you use the %EXECUTE function, it must be located at the
beginning of the statement and can be the only function or command
contained in the statement. The Action type must be "SQL".
20. When using %List in an insert/select or insert/values or %Select
statement, you must have matching pairs of %List (or %ListBind) in the
target and source field lists, using the same list type argument and record
name to ensure consistency.
21. No standards in referring the table or record name in meta-SQL.
e.g.
%Table(Recname) You have to pass the record name.
%TrucateTable(Tablename) You have to pass table name.
22. You cant use Trace options when you are calling an Application Engine
Program from Peoplecode.

23. More Usage of the Trace options will reduce the performance (Increase
cost) of Application Engine Program.
24. You cannot set a Watch on a "long text" field.

You might also like