Application engine
PeopleSoft Application Engine is a PeopleTool used to carry out background SQL processing. Application Engines are neatly structured into blocks and offer an alternative to writing COBOL or SQR programs for background SQL processing.
Application Engine Program Types
Application Engine has five types of programs. We can specify the type in the Program Properties dialog box for your program definition.
The types are:
1. Standard, which is a normal entry-point program.
2. Upgrade Only, which is used in PeopleSoft upgrade utilities.
3. Import Only, which is used by PeopleSoft import utilities.
4. Daemon Only, a type of program used as a daemon process.
5. Transform Only, a program type used to support Extensible Style sheet Language Transformations (XSLT).
The key elements of an application engine program are:
Peoplesoft Application Engine Structure
Sections
A PeopleSoft App Engine can have one or more sections. Every App Engine should have at least one section called main section where the execution always start. A section can have multiple steps that get executed one after another.
Steps
Steps in an Section gets executed sequentially. Steps are the smallest unit of work that can be committed within a program. Each Step can have one or more actions.
Actions
Actions, unlike steps have a particular execution order. An Application has 9 Actions out of which two (SQL and Call Section ) are mutually exclusive. These steps are discussed in detail in the Application Engine Action article.
1. Do When
2. Do While
3. Do Until
4. Do Select
5. People Code
6. SQL
7. Call Section
8. Log Message
9. XSLT – found only in Transform Only programs
State Records
State Records are PeopleSoft records that are used to pass values from one action to another. They can be considered as storage locations for an Application engine. Find more about State records here.
Parallel Processing in Application Engines
Application Engine seamlessly supports Parallel Processing which helps faster processing when the data involved is huge. This is achieved by the use of temporary tables and %Table meta-SQL. PeopleSoft highly recommends programmers to make use of this feature.
Running an Application Engine
An application engine can be executed from the following 4 places:
1. From within Application Designer using Run Request
2. From PeopleCode using CallAppEngine()
3. From Process Scheduler
4. Manually from command prompt
PeopleSoft State Record
State records are used in Application Engines as a storage location for data that needs to be passed across actions. An Application Engine can have more than one state records associated with it out of which only one can be marked as a default state record.
Type of Sate Records
A state record can be an SQL table or a temporary table based on the requirement. If you want the data in the state record to be preserved across commits then you need to use an SQL Table as your state record. If you use a temporary record as a state record, it’s contents are wiped out on commit. SQL Tables are also used in restart enabled app engines.
Accessing Values from State Records
you can access values from the state record seamlessly. If you are accessing values from the default state record, you can simply use the fieldname. When accessing values from other state records, you need to use the dot (.) notation (recordname.fieldname). In other words, whenever the record name is not specified, the filed from the default state record would be accessed.
Within People Code you can access a state record field using fieldname. Value. Within SQL actions you can access the state record fields using the %Bind(fieldname)
For assigning values to the fields within a state record, you can use the fieldname. Value notation from within People Code or use %Select when used from within SQL actions.
Key Structure
A physical State record should have Process Instance as the first field and the only key. A state record can hold only one row of data at any point. If you need access to multiple rows of data, use a temporary table.
Naming Convention
A state record name must end with _AET.
Example:
This example assumes that the state record has the following fields apart from the process instance: CONTRACT_NUM, CONTRACT_LINE_NUM, PRODUCT_ID.
The below code fetches and stores into the state record, PRODUCT_ID from CA_DETAIL table based on the CONTRACT_NUM and CONTRACT_LINE_NUM (from the state record) passed on using the %Bind meta.
%Select(PRODUCT_ID)
SELECT PRODUCT_ID
FROM PS_CA_DETAIL
WHERE CONTRACT_NUM = %Bind(CONTRACT_NUM)
AND CONTRACT_LINE_NUM = %Bind(CONTRACT_LINE_NUM)
PeopleSoft Subrecord
PeopleSoft Subrecords are collection fields that are grouped together into one entity so that they can be used as building blocks for multiple records. Subrecords doesn’t have an existence in the database by itself as they are not build.
The reason behind using a subrecord is the easiness it brings to building of records. Suppose you need to use a set of fields in multiple records; instead of manually adding each and every field to the record definition, a good approach would be to create a subrecord with these fields and then use it. You may then use insert the subrecord directly into any number of record definition for faster development.
Another powerful aspect of PeopleSoft subrecords is that they can be combined with subpages to form a deadly bolt-on combination that enables faster development. For example, that a subpage can be populated with page fields that are associated with a subrecord so that the subrecord is determined to be the “from” record. Then when that subpage is used as a subpage-type page field, you can specify the “to” record as one of the records that contains that subrecord. This enables you to associate a single set of page fields (through the subpage) with a variety of different records (each containing the subrecord).
Once defined, subrecords can be interted into a record with the same easiness with which you add a filed.
To view the definitions / fields within any subrecord that has been inserted into a record, press the Expand All subrecords button. While the subrecord id expanded, you may not be able to perform standard functions like sorting, insertion of fields etc. on the record. Also, the expanded subrecords are read-only, meaning, you may not be able to open the properties of the fields in the subrecord.
PeopleSoft suports nesting of subrecords to any level. This means that you can have a subrecord inside another subrecord and so on, to any depth. And off course, you can write PeopleCode in the subrecord filed. This will be triggered for all records that the subrecord is used in.
PeopleSoft Application Engine is a PeopleTool used to carry out background SQL processing. Application Engines are neatly structured into blocks and offer an alternative to writing COBOL or SQR programs for background SQL processing.
Application Engine Program Types
Application Engine has five types of programs. We can specify the type in the Program Properties dialog box for your program definition.
The types are:
1. Standard, which is a normal entry-point program.
2. Upgrade Only, which is used in PeopleSoft upgrade utilities.
3. Import Only, which is used by PeopleSoft import utilities.
4. Daemon Only, a type of program used as a daemon process.
5. Transform Only, a program type used to support Extensible Style sheet Language Transformations (XSLT).
The key elements of an application engine program are:
Peoplesoft Application Engine Structure
Sections
A PeopleSoft App Engine can have one or more sections. Every App Engine should have at least one section called main section where the execution always start. A section can have multiple steps that get executed one after another.
Steps
Steps in an Section gets executed sequentially. Steps are the smallest unit of work that can be committed within a program. Each Step can have one or more actions.
Actions
Actions, unlike steps have a particular execution order. An Application has 9 Actions out of which two (SQL and Call Section ) are mutually exclusive. These steps are discussed in detail in the Application Engine Action article.
1. Do When
2. Do While
3. Do Until
4. Do Select
5. People Code
6. SQL
7. Call Section
8. Log Message
9. XSLT – found only in Transform Only programs
State Records
State Records are PeopleSoft records that are used to pass values from one action to another. They can be considered as storage locations for an Application engine. Find more about State records here.
Parallel Processing in Application Engines
Application Engine seamlessly supports Parallel Processing which helps faster processing when the data involved is huge. This is achieved by the use of temporary tables and %Table meta-SQL. PeopleSoft highly recommends programmers to make use of this feature.
Running an Application Engine
An application engine can be executed from the following 4 places:
1. From within Application Designer using Run Request
2. From PeopleCode using CallAppEngine()
3. From Process Scheduler
4. Manually from command prompt
PeopleSoft State Record
Type of Sate Records
A state record can be an SQL table or a temporary table based on the requirement. If you want the data in the state record to be preserved across commits then you need to use an SQL Table as your state record. If you use a temporary record as a state record, it’s contents are wiped out on commit. SQL Tables are also used in restart enabled app engines.
Accessing Values from State Records
you can access values from the state record seamlessly. If you are accessing values from the default state record, you can simply use the fieldname. When accessing values from other state records, you need to use the dot (.) notation (recordname.fieldname). In other words, whenever the record name is not specified, the filed from the default state record would be accessed.
Within People Code you can access a state record field using fieldname. Value. Within SQL actions you can access the state record fields using the %Bind(fieldname)
For assigning values to the fields within a state record, you can use the fieldname. Value notation from within People Code or use %Select when used from within SQL actions.
Key Structure
A physical State record should have Process Instance as the first field and the only key. A state record can hold only one row of data at any point. If you need access to multiple rows of data, use a temporary table.
Naming Convention
A state record name must end with _AET.
Example:
This example assumes that the state record has the following fields apart from the process instance: CONTRACT_NUM, CONTRACT_LINE_NUM, PRODUCT_ID.
The below code fetches and stores into the state record, PRODUCT_ID from CA_DETAIL table based on the CONTRACT_NUM and CONTRACT_LINE_NUM (from the state record) passed on using the %Bind meta.
%Select(PRODUCT_ID)
SELECT PRODUCT_ID
FROM PS_CA_DETAIL
WHERE CONTRACT_NUM = %Bind(CONTRACT_NUM)
AND CONTRACT_LINE_NUM = %Bind(CONTRACT_LINE_NUM)
PeopleSoft Subrecord
The reason behind using a subrecord is the easiness it brings to building of records. Suppose you need to use a set of fields in multiple records; instead of manually adding each and every field to the record definition, a good approach would be to create a subrecord with these fields and then use it. You may then use insert the subrecord directly into any number of record definition for faster development.
Another powerful aspect of PeopleSoft subrecords is that they can be combined with subpages to form a deadly bolt-on combination that enables faster development. For example, that a subpage can be populated with page fields that are associated with a subrecord so that the subrecord is determined to be the “from” record. Then when that subpage is used as a subpage-type page field, you can specify the “to” record as one of the records that contains that subrecord. This enables you to associate a single set of page fields (through the subpage) with a variety of different records (each containing the subrecord).
Once defined, subrecords can be interted into a record with the same easiness with which you add a filed.
To view the definitions / fields within any subrecord that has been inserted into a record, press the Expand All subrecords button. While the subrecord id expanded, you may not be able to perform standard functions like sorting, insertion of fields etc. on the record. Also, the expanded subrecords are read-only, meaning, you may not be able to open the properties of the fields in the subrecord.
PeopleSoft suports nesting of subrecords to any level. This means that you can have a subrecord inside another subrecord and so on, to any depth. And off course, you can write PeopleCode in the subrecord filed. This will be triggered for all records that the subrecord is used in.
No comments:
Post a Comment