Dynamic Call-Section
The execution of a PeopleSoft Application Engine starts with the Main section and flows down to other
sections which are called from the main section.
For calling a section from within one, we use the call section action. To do this, in the call-section
action, we specify the name of the App engine and the section we wish to call. If the section is in the
same App engine, then, providing the name of the App engine is optional.
How to use Dynamic Call-Section in App engine?
Often, business logic requires us to call different sections based on occurrence of certain conditions in
different scenarios and that too from the same call-section. To enable this kind of logic, we will have to
make the call-section dynamic. This is how we can do it.
Dynamic Call-Section State Record
To enable dynamic call-section, we need to have a state record that can support it. The state record, in
this case, should have two extra fields – AE_APPLID and AE_SECTION. If you intent to make a dynamic
call to sections that are in the same App engine as the calling section, then the state record would be
good to go with just AE_SECTION.
PeopleCode for Dynamic Call-Section
Once you have the state record in place, it’s time to set the values for the extra fields – AE_APPLID and
AE_SECTION. This should be done before the dynamic call section. The simplest way to implement this
is to use a if-else as shown below:
if condition then
AE_APPLID = "AE_ABC_TEST";
AE_SECTION = "SEC_STATE";
else
AE_APPLID = "AE_ABC_TEST";
AE_SECTION = "SEC_CITY";
end-if;
Call-Section Action
This is the final step. Insert a Call-section action into the App engine. Check the Dynamic check-box
that states that the call-section is dynamic. On finding the dynamic check-box checked, the processor
looks for the values of AE_APPLID and AE_SECTION in the state record and calls the section mentioned
in AE_SECTION from the app engine that is mentioned in the AE_APPLID.
If the AE_APPLID is blank, the processor calls the section mentioned in AE_SECTION from the current
application engine.
Call Section: Dynamic Check box
How do you program AE program for the restarts?
Program Level
State Record
One of the state record needs to SQL Table, Since All Derived work record will be re-initializing on
commit.
Program Properties
On the Advanced tab in the program properties dialog box, make sure that disable restart is not
checked.
Configuration manager
In the configuration manager, sure that Disable restart is not selected on the process scheduler tab.
Section Level
Section type
1. The option for section type are prepare only and critical updates If the section is preparing data
i,e select data, Populating temporary tables, or updating temporary tables then the section
should be prepare only.
2. If the section is updating the permanent application tables in the database, you should select
critical update.
Step Level
Add an order by clause
Add a switch to the selected table
Delete processed rows.
The only restriction for batch runs occurs when you have restart enabled, and you
are inside a Do Select that is of the Select/Fetch type (instead of "Re-select" or "Restartable"). with
select/Fetch, all commits inside the loop are ignored, including the commit frequency if it's set.
What are different types Do Select?
1- Select/Fetch: -
Opens the cursor only at the first time and retrieve rows one at loop.
Commits inside the step (commits in the Called Section) are ignored if AE is Restart enabled.
2- Reselect: -
It opens the cursor and closes the cursor on each iteration of the loop.
It will reselect the same row of data.
Logic in Actions of the step should be such that it will be changing the status of the rows in the table
the do select is selecting.
Commits are not ignored and will be committed in a reselect loop when the restart is enabled.
3- Restart able: - similar to select/Fetch but it WILL COMMIT inside the loop thus allowing the
checkpoint to the PS_AERUNCONTROL table.
Explain Error handling or Exception handling in Application Engine ?
Step properties:-
On Error:-
Abort - Write message to message log and terminate.
Ignore - Write message to message log and continue.
uppress – No message will be written, but program will continue.
People code Action: - On return options can used to handle run time errors.
Abort: - Exits immediately – Not recommended.
Break:- Exits the current step and section and control returns to the calling step.
Skip Step:- The program exits the current step, and continues processing at the next step in the
section. If this is the last step in the section, the calling step resumes control of the processing.
SQL Action properties:-
No Rows:- When the Sql doesn’t return any rows, you can tell what application engine program
should do.
Abort: - Program terminates
Section Break: - Application Engine exits the current section immediately, and control returns to the
calling step.
Continue: - The program continues processing
Skip Step: - Application Engine exits the current step immediately and moves on to the next step.
When using skip step keep the following in mind:
1) Application Engine ignores the commit for the current step at runtime
2) If the current step contains only one Action, only use skip step at by-pass the commit.
How can you divide the data to be processed by different instance of
the program to perform parallel program?
Run control parameters passed to each instance of the AE program enable it to identify which input
rows “belong” to it, and each program instance inserts the rows from the source table into its assigned
temporary table instance using %Table.
What are the important steps for implementing the parallel
processing?
Define you Temporary Tables.
Set the Temporary Tables Online pool.
Assign Temporary Tables to your Application Engine program in it program.
Set Temporary Table Batch Pool – Instance count in the AE.
Build / Rebuild your Temporary Table record.
Code %Table Meta – SQL as reference to Temporary Tables in your Application Engine program, so that
Application Engine can table references to the assigned Temporary Table instance dynamically at
runtime.
How running AE program as Batch differs from running it online?
Application Engine programs are designed for two types of execution and each has its own pool of
Temporary Tables
Online:
Invoked by CallAppEngine from People code
Run quickly, synchronously, and at random times.
Potential for simultaneous executions
Uses the online Temporary Table pool.
Not restart able.
[Link] randomly assigns an instance number from the number range on your online temp tables.
If the instance number is in use [Link] puts the program in Queue until the assigned instance
becomes free.
Unlock on completion, on Crash free from Manage Abends.
Batch:
Invoked through the Process Scheduler.
Run for longer amounts of time, asynchronously, and at scheduled times.
Can be designed for parallel execution for performance.
Uses the Batch/Dedicated Temporary table.
Restartable.
It allocates instance number based on the availability on a record by record basis and [Link] begins
with the lowest instance [Link] the properties are set continue – Base table is used with Process
instance as key.
If Re-starable – Locked across Restarts until completes successfully.
If not Re-startable on Program completion.
How to test and debug an application engine program?
Application Engine Trace file-You can track the step execution of your application execution.
Application Engine Interactive Debugger – First click on the trace tab and turn off the statement
timings.
Select Profile -> Edit Profile-> Process Scheduler Tab -> Application section Select Debug check box.
(You can dynamically modify the state record run application engine step by step People Code
Debugger for the Application Engine.)
AE Trace files: - AE_<Program Name>_<Process Instance>.AET
Without the process instance: - AE_<Date/Timestamp>_<OS_PID>.AET
Advantages of Set Processing?
Improved Performance: - Our internal testing has revealed that, in an overwhelming majority of
cases, set processing performs significantly better than it is -by-row counterpart for “reasonable”
batch processing volumes.
Minimized SQL Overhead: - It tends to use fewer Application Engine SQL tatements that each
processed more data than the statements executed in row-by-row processing.
Easy Maintenance: - if need to make a fix or add an enhancement to SQL, it’s just a matter of
modifying the SQL or inserting the new “Chunk”.
Leveraging the RDBMS: - With Set – based processing, you take advantage of the SQL processing
engine on the database rather than placing the processing burden and overhead on the application
executable.
