PeopleSoft State Record

PeopleSoft State RecordsState 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 (a maximum of 200) 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.

App Engine Properties - State Record

App Engine Properties - State Record

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.

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, when ever the record name is not specified, the filed from the default state record would be accessed.

Within PeopleCode 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 PeopleCode or use %Select when used from within SQL actions.

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)

Passing Values to Another App Engine

To make this concept easy to understand, let’s assume that there are two App engines – AE1 and AE2. Also that, AE1 has a default state record SR1_AET and it App Engine calls a Section of AE2.

Now, if AE2 didn’t originally have a default state record, SR1_AET can be accessed from AE2 as if it was the default state record of AE2.

All other state records that are attached to AE1 are available to AE2 too. You can access the fields on these using the dot (.) notation from AE2.

Application Libraries

When developing application libraries, you would want them to have their own state records.

Why?

You would find out from this example.

Say, our previous App engine AE1 is calling a section in our Application Library ALIB.

Within ALIB, you can access all of AE1’s state records.
So you can write PeopleCode like SR1_AET.field1.value = “X”;

Now, if the other App engine, AE2, with state record SR2_AET, calls ALIB, the above code would fail as the library doesn’t have access the SR1_AET.

How can you overcome this?

Sharing State Records

You would attach a state record SR_ALIB_AET to ALIB and write all code in ALIB based on this record.

When AE1 wants to call ALIB, you would add SR_ALIB_AET as a state record to AE1 and pass values through it. Similarly, when AE2 wants to call ALIB, you would do the same thing to AE2.

This would ensure that your library can easily be called by any App engine.

Tags: , ,
Subscribe to Comments RSS Feed in this post
16 Responses
  1. I think that cover pretty much all about state records. Thank you for this quick reference for a new bee like me!

  2. @ Thomas – Glad that you found it useful. Looking forward to present more such articles.

  3. nice to join this site

  4. Very nice explaination.

  5. VER VERY GOOD SITE.BUT WE CANT UNDERSTAND NAVIGATION

    • Thanks for the feedback Rami.
      I’ve emailed you to understand what could be changed so that the site becomes more user friendly.

  6. This site really helps to refresh the things very quickly. Every topic delivers what is more important in it. A Good author should not deliver what he knows than other, he should deliver what others should know.. This site is good in it..
    Navigation is little issue here, but can find our topic with search option.

    • Hi Sukumar,

      Happy to know that you find the content useful.
      Re. the navigation issue you’ve faced, I’ve emailed you to understand more about it so that we can work on getting it fixed.
      Thanks!

  7. Thanks

  8. Please explain application engine using state record with full description. I Have understood state record but not understanding its use in application engine

  9. Nice Post

  10. > … our previous App engine AE1 is calling a section in our Application Library ALIB.

    What is an “Application Library”?

    • @Matt

      An Application Library is an Application Engine which doesn’t have a Main section.
      So it can only run when called by another App Engine.

Leave a Reply to Matt Skelton Cancel reply

Your email address will not be published. Required fields are marked *

*
*