This section provides an overview of state recordsand discusses how to:
- Share state records.
- Choose a record type for staterecords.
Understanding State Records
- Forgot your password? To use our self-service password option, set it up by going to MenuMy system profileChange/Set up.
- Iv) State Records It is a PeopleSoft Record that must be created and maintained by the Application Engine developer. This record defines the fields a program uses to pass values from one action to another. It can be either a Physical record or a work record, any no of sate records can be assosiated with a program.
You assign variables for your Application Engineprogram through state records, while sections, steps, and actionspass values to subsequent program steps through state records.
To use more than one state record in an application engine, open program properties and on the 'State Records' tab add your State Records. You will need to set one of them as default. To save or get values from your 'none' default state record, you will need reference the record.
You can have up to 200 state records associatedwith a particular Application Engine program. However, only one recordcan be the default state record. You can specify both work (derived)and physical (SQL table) records to be used as state records. Theonly difference is that derived state records cannot have their valuessaved to the database at commit time, and so the values are lost duringa restart. Therefore, Application Engine erases the contents of derivedstate records at commit time if Restart is enabled for the currentprocess.
A Application Engine state record must have a processinstance defined as the first field and the only key field, and thestate record name must end with _AET.
Not all the database columns referenced in yourprogram must be in the state record, just the columns that must beselected into memory so those values can be referenced in a subsequentprogram action. You may also want to include additional fields tohold pieces of dynamic SQL, to use as temporary flags, and so on.
Application Engine supports long fields, unlikeCOBOL or Structured Query Reports (SQR). However, it allows only onelong field per state record. You set a maximum size for the fieldin Application Designer and make sure that the data space is compatiblewith the size of the field that you set.
Application Engine also supports image fields andlong text fields.
Image: Sample state record
This is an exampleof Sample state record.
During batch processing, Application Engine automaticallyperforms all state record updates. When a program starts, it insertsa row into the state record that corresponds to the process instanceassigned to that program run. Application Engine updates the recordwhenever a commit operation occurs. When restart is enabled and acommit occurs, all state records that have been updated in memoryare written to the database, except for derived state records, whichare initialized instead.
After the program completes successfully, ApplicationEngine deletes the corresponding row in the state record. There isonly one row in the state record for each process instance. Multipleprograms can use the same state record, and each program has its ownrow based on the unique process instance key.
To set values in the state record, you use the %SELECTconstruct in a SQL statement or write PeopleCode that references thestate field with the standard record.field notation. To referencefields in the state record, use the %BIND construct.
Sharing State Records
What Is State Record In Peoplesoft
State records can be used by multiple sections andby multiple programs. When you call a section in another program,any additional state records defined for that program (as in staterecords that are not already in use by the calling program) are initialized,even if the program has been called previously during the run. However,state records that are common to both programs retain their currentvalues.
To reference variables that exist within a staterecord, use the following:
Unless a specific record name is specified precedingthe fieldname, %BIND references the default state record. To referencea state record other than the default, use the following:
In the case of a called program or section, if thecalled program has its own default state record defined, then ApplicationEngine uses that default state record to resolve the %BIND(fieldname).Otherwise, the called program inherits the default state record ofthe calling program. In theory, the called program does not requirea state record if all the fields it needs for processing exist onthe calling program’s state record.
For those state records that are shared betweenprograms (during an external call section), any changes made by thecalled program remain when control returns to the calling program.Any subsequent actions in the calling program can access residualvalues left in the common state records by the called program. Thiscan be useful to return output values or status to the calling program,yet it can also cause unforeseen errors.
Generally, a called program should not share staterecords with the caller unless you need to pass parameters betweenthem. Most programs have their own set of state records unless a programcalls another program that requires specific input or output variables.In that case, you must include the state record of the called programinto the calling program’s state record list, and make sure to setthe input values before issuing the call section.
Choosing a Record Type for State Records
State Record Properties In Peoplesoft
As a general rule, to preserve state record fieldvalues across commits in your program, you should store those valuesin a state record with a record type of SQL Table. Only derived/work-typestate records store values that don’t need to be accessed across commits.Derived/work records are, however, an excellent choice for temporaryflags and dynamic SQL containers that are set and then referencedimmediately. Because these values aren’t needed later, you don’t wantto have to save them to the database at each commit. When you createyour state record in Application Designer, you should have an idearegarding how your state record will be used. With this information,you can select the appropriate record type to build.
With Application Engine programs, state recordsthat are derived/work records function the same as SQL Table records.However, there is one notable distinction: unless you have disabledRestart, derived work records have their field values reinitializedafter each commit. Therefore, unless you anticipate this behavior,you may encounter problems. One quick way to diagnose such a problemis to examine a trace. Typically, you see %BIND variables resolvedto values prior to a commit, and then after the commit, they haveno value.
This behavior is necessary to ensure consistencyin the event of an abnormal termination and restart. During the restart,Application Engine begins, or restarts, at the point of the last successfulcommit and restores the values of any state records with correspondingdatabase tables. Derived/work records aren’t associated with a physicaldatabase table, and consequently they can’t be restored in the eventof a restart.