Running Application Engine Programmes

1. Thru Peoplecode on one of the events
1. Synchronously using CallAppEngine.
Commits in the AE program are ignored.


2. Async/thru process scheduler : Using CreateProcessRequest.

Since the AE runs in its own session, commits in the AE are fired.

2. Thru Process Scheduler:
1. Submitting a request using a specials page created for the purpose.
2. Using the AE request Page. ( Used only for testing. ) However, you can indicate the MARKET. Helpful if you have a single application engine with sections catering to different markets.

3. In 2 Tier thru Application Designer. ( Cannot set values for staterecords. )

4. Command line:
1. When developing and testing.
2. For restarting.
3. Debugging

%ReturnCode

Return code of last AE step performed.
value is 0 for successful operation.

%Execute

Used to execute multiple statements in an sql action in Application engine.

for e.g.

%execute(/)
INSERT INTO mytbl1 values (1,2,3);
INSERT INTO mytbl1 values (1,2,4);
/

In above example, the separator is changed to "/" for the default separator of ";" in peoplecode.

How can values be passed between a Page and a AE called thru Application engine

While a state record can be initialized with values before calling the application engine program, the parameters passed by value and not reference.

This means that values of the state record set in the AE will not be available to the calling peoplecode on the page..
Use global variables instead.

Restartable Application engine and Global Variables in Peopleocode

In addition to state record, variables defined in Peoplecode as Global variables are also saved in the database.

Application Engine Commits

At my work, I realized that while application engines were being created, people did not know exactly how commits work in application engine.

I therefore set out to undertand application engine commits better. Here is what I have figured out so far:


If you create a new App. Engine program and do nothing for handling commits, the ae is automatically configured to commit after the application engine completes. This means that if the program aborts, everything is rolled back. It also means that there is additional burden on the database to keep track of uncommitted data.

However, there are settings at the section and step level that can be used to commit at specific points in time in the program.

An understanding of the commits is helpful.


1. At Section Level :
1. Turn on commit after step to get AE to commit after every step in that section.
2. Commit even n rows: Foe sections that contain do while, do until and do select, set the
commit frequency to commit after every n rows. The commit fired here is in addition to
commits fired in the loop.

Restriction: For Action of Do Select of type select/fetch where the restart is enabled, the
commits within the loop is ignored.

2. At Step
1. Default: based on the setting at the section.
2. After Step : To override the setting at section and commit after the step completes.
3. Later: To override the setting at section and not commit after step. ( when at section, you
have defined for commit after step. )

Additional Pay

Continuing my previous post, when does P/S give addional pay ?

1. EFFDT should be less than or equal to the PAY END DT on pay calendaer.
2. END DATE should fall after the Pay begin date. Note that this is different from general deduction where the deduction end date is compared against the pay end dt.

When to take general deduction

There are so many dates in peoplesoft that it is difficult to understand the relationship between all those dates.

For e.g. when does P/S take general deductions configured for en employee?

This depends on the following:

1. effective date of the general deduction record setup.
2. whether the general deduction has a deduction end dt ornot.
3. pay end dt of the pay calendar for which the employee isbeing paid.

Payrollprocess compares only the following dates

1. Pay end dt on the Pay calendar.
2. Effdt on the general deduction table.
3.deduction end date on the generaldeduction table is it is populated.

Itlooks for a gen deduction table maexeffdtd row less than or equal to the pay end dt.
If the row does not have a deduciton end dt or the deduction end dt falls after or on the pay end dt,it takes the general deduction.Deduction is not prorated.

Other dates like pay period begin date and check date do not matter.


However, it is worth mentioning that if an employee is terminated during a pay period ( a job row wiht effdt ( and action which terminates the employee ) between the pay begin date and pay end dt , then based on whether the dedcd has been setup to stop deduction when employee is terminated, the deduction is stopped or taken.