SaveEdit, SavePreChange, SavePostChange... Which Event Should I Use?

When a user presses the Save button on a PeopleSoft component, PeopleSoft triggers three PeopleCode events in sequence:

• SaveEdit
• SavePreChange
• SavePostChange

These events allow us to write specialized logic to:

1. Validate data before saving,
2. Update other fields within the component, and
3. Trigger additional business logic, such as synchronizing systems through integration or launching an approval process.

Each scenario uses a different event. Let's review scenario #1: data validation.

• A page has two fields: start date and end date. We must confirm that the start date precedes the end date.

Which event would you use?

• SaveEdit
• SavePreChange
• SavePostChange

Let's review the behavior of each event to help us determine the best fit. Specifically, we want an event that can stop Save Processing if validation fails. This will keep us from sending invalid content to the database.

• SaveEdit: Cancelable event.
• SavePreChange: Cancelable event.
• SavePostChange: Not cancelable because the data is already in the database.

This leaves two cancelable events: SaveEdit and SavePreChange. But what does PeopleBooks say?

"Important! Never use an Error or Warning statement in any save processing event other than SaveEdit. Perform all component data validation in SaveEdit." (emphasis added.)

Why? Why is it so important that we handle validation in SaveEdit and not SavePreChange?

Let's say we ignore PeopleBooks' advice, and we put data validation in SavePreChange rather than SaveEdit. How many SavePreChange events exist per component? The number is infinite. There is at least one per field associated with the component (Record/Field), as well as at least one per record in the component (Component/Record). We reach infinity when considering Event Mapping, because there is no limit on the number of Application Classes that may be associated with a component's SavePreChange possibilities.

Next, imagine that some of those SavePreChange events assume validation is complete and make changes to the component buffer. But if we put validation logic in one of those SavePreChange events, and that validation fails, what happens to all of those other SavePreChange component buffer updates? Nothing. There is no automatic reset. What if one of those handlers disabled the field that failed validation? How would the user correct the issue? This is why it is so important that we follow PeopleBooks' advice in this case and only validate in SaveEdit.

By the time the component processor reaches SavePreChange, all validation should be complete.

In summary, here is how you should use each Save event:

• SaveEdit: Cross-field validation. Do not update data or change field properties from this event.
• SavePreChange: Update data within the component buffer and apply field property changes, but do not perform validation.
• SavePostChange: Perform any non-component, post-database work: Integrations, Notifications, Workflow, non-component data updates, etc.

At JSMpros, we teach PeopleCode tips daily! Check out our live virtual events calendar and on-demand offerings to enroll in your next course. Interested in learning more about PeopleCode specifically? Then check out these two classes:

• PeopleCode
• PeopleCode Application Classes

Both are available live, live virtual, and on-demand. Contact us, and let's get you scheduled!