Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
Application Engine Basics

Application Engine Basics

Ratings: (0)|Views: 498 |Likes:
Published by harikishore14
Uploaded from Google Docs
Uploaded from Google Docs

More info:

Published by: harikishore14 on Apr 25, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

04/25/2011

pdf

text

original

 
 Application Engine
Application Engine programs are PeopleSoft's batch processing technology. They aredeveloped in application designer and consist of blocks of PeopleCode and SQL.Application engine programs can also use application classes, component interfaces,XML publisher reports, and call SQRs and COBOLs through PeopleCode.
 
Program StructureProgram PropertiesState RecordsLogging to the Message LogCall SectionsMigrating in a Project
Program Structure
Application engine programs are have very structured hierarchy (loosely based onCOBOL). They consist of a single application (application engine program) that canconsist of one or more sections. Each section can contain one or more steps, and eachstep can contain one or more actions. The actions in a step can include:
SQL actions
Do actions
PeopleCode actions
Call Section actions
Log Message actions
Program Properties
There are number of properties associated with an application engine program. Theseinclude:
General PeopleSoft object properties
State records
Temporary Tables
Advanced program propertiesThere several different
types
of application engine programs:
Standard, which is a normal entry-point program.
Upgrade Only, which is used in PeopleSoft upgrade utilities.
Import Only, which is used by PeopleSoft import utilities.
Daemon Only, a type of program used as a daemon process.
Transform Only, a program type used to support Extensible Stylesheet LanguageTransformations (XSLT).
State Records
A
state record
is a PeopleSoft record object that contains one or more fields used by the program to pass values between steps and actions. Essentially it is a work record for your application to store common variables that can then be used throughout the program. A
 
state record can either be a database table or a PeopleSoft work record. If you make astate record a database table it
must be keyed by process instance
. Otherwise the staterecord will not work properly.Because state records contain process instance, you can use the following SQL action toge tthe operator ID and run control ID of the person who triggerred the application engine program.
%Select(OPRID,RUN_CNTL_ID)SELECT OPRID ,RUN_CNTL_IDFROM PS_AE_REQUESTWHERE PROCESS_INSTANCE = %Bind(PROCESS_INSTANCE)
 Note
%Select
and
%Bind
are specialMeta - SQLelements for working with applicationengine state records.
%Select
puts data in the state record and
%Bind
gets data from thestate record. Think Select-In and Bind-Out.
Logging to the Message Log
The PeopleSoftProcess Scheduler provides access to the message log. The message logis part of the
PROCESSMONITOR
component - it is defined in the page object
PMN_BAT_MSGLOG
. You can use log message actions in application engine programs towrite to the message log - essentially the
PS_MESSAGE_LOG
table behind the scenes.
Call Sections
Call sections can be dynamic. To use a dynamic call section:
1.
Add the fields
AE_APPLID
and
AE_SECTION
to your state record
2.
In a PeopleCode step, set the value of 
AE_APPLID
to the application engine program name that you are calling. If it is a section in the same application engine program, you can leave this blank and it will default to the current runningapplication engine program
3.
In a PeopleCode step, set the value of 
AE_SECTION
to the section of theapplication engine program you are calling
4.
Set the dynamic flag check box on the call section stepFor a good delivered example, look at the Data Archive application engine program,
ARCH_PROCESS
. The relevant parts are:
ARCH_PROCESS.MAIN.Step001b
ARCH_PROCESS.MAIN.Step003b
The data archive process application engine can dynamically call application engine programs specified by the user in the data archive configuration template.
Migrating in a Project
One of the problems with application engines is getting all the relevant parts of theapplication engine into a project.I've found the following to be the best approach (repeat for each program):
Develop away until you have the application design in place. Don't worry about putting it all into a project at this point. The reason is that you will make mistakes
 
and remove/add/update sections, SQL, PeopleCode etc. Obviously you shouldhave a project that you are doing all this in, just don't worry about gettingeverything related to the application engine(s) into this project at this point.
When you're satisfied with the final design, do a validate project on your working project. This will clear out all invalid definitions that may have been placed in the project over the time you were working out the design. To do this in applicationdesigner, select Tools -> Validate Project.
In application designer select Insert -> Definitions into Project or press CTRL +F7. Select the Application Engine Programs definition type, find your applicationengine program and select all the related definitions. Press insert. Now check inthe upgrade tab to verify that the program, sections, PeopleCode, SQL, recordsand XSLT are all shown in the upgrade tab.
Make sure that the action flag is set to copy for all relevant definitions and that theupgrade flags are checked.
Migrate your app engine to another environment and confirm everything wascopied over and works.
Populating a State Record
This article goes through a basic example of how to populate data in an application staterecord. State records are used in Application Engine programs to keep track of usefulinformation through the life of a program. PeopleSoft uses the concept of a record (table)to store this information. I
believe
the scope of data in a state record is global to anapplication engine program (and other programs that share the state record), however thiscould be wrong.The naming convention of state records is to end with the suffix
_AET
. They can either bea derived/work record or a SQL table. The difference is one of persistence. Aderived/work state record will lose its value when the application engine is restarted or after database commits, while a table will not as state data is committed to the database.So if you are developing a restartable application engine program, the state record should be a table (and built in the database). Since Derived/work state records can also loseinformation between commits in your application engine, its safest to use a SQL table asthe default type for your state records.The following steps are involved in populating a state record in an application engine program:
Create the state record
All state records must have at least one field
PROCESS_INSTANCE
as their first field. Thisis also the only key field. Other commonly used fields are
OPRID
and
RUN_CNTL_ID
. Thislets you track who is running the application engine program and what run control IDthey are using. Other fields are a matter of your requirements; what information do youneed to track through the execution of your program?Remember the naming convention: state records end with the suffix
_AET
.
Assign the state record to your App Engine

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->