Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
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


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





 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
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
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.
are specialMeta - SQLelements for working with applicationengine state records.
puts data in the state record and
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
component - it is defined in the page object
. You can use log message actions in application engine programs towrite to the message log - essentially the
table behind the scenes.
Call Sections
Call sections can be dynamic. To use a dynamic call section:
Add the fields
to your state record
In a PeopleCode step, set the value of 
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
In a PeopleCode step, set the value of 
to the section of theapplication engine program you are calling
Set the dynamic flag check box on the call section stepFor a good delivered example, look at the Data Archive application engine program,
. The relevant parts are:
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
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
. 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
as their first field. Thisis also the only key field. Other commonly used fields are
. 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
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

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