PeopleSoft Advanced Technical Interview Questions & Answers (10+ Years Experience)
SECTION 1: PeopleCode - Advanced
Q1. What is the difference between SavePreChange, SavePostChange, and Workflow PeopleCode events? When would you use each?
Answer: SavePreChange fires before the database is updated. It is used for final validations, default population, or calculations just before save. SavePostChange fires after the database rows are committed and is used for post-processing tasks like triggering Integration Broker messages or updating related records. Workflow event fires after SavePreChange but before SavePostChange - it is specifically reserved for workflow triggering logic (e.g., TriggerBusinessEvent). Think-time functions cannot be used in any of these three events.
Q2. Explain the difference between Exit(0) and Exit(1) in PeopleCode.
Answer: Exit(0) immediately terminates a PeopleCode program but does NOT roll back database changes already made. Exit(1) immediately terminates the program AND rolls back all database changes made during that program execution. Exit(1) is used when you detect a fatal error and need to ensure data integrity.
Q3. What are think-time functions in PeopleCode and in which events are they restricted?
Answer: Think-time functions are functions that suspend PeopleCode processing until the user takes an action or an external function completes - for example, WinMessage, Prompt, DoModal, RemoteCall, and DoSave. They are prohibited in SavePreChange, SavePostChange, Workflow, RowSelect, and any event where the system doesn't expect a pause. Using them in restricted events causes runtime errors.
Q4. What is the difference between a Dynamic View and a SQL View in PeopleSoft?
Answer: A SQL View is stored as an actual database view object and must be built in the database through Application Designer. A Dynamic View is NOT stored in the database; instead, it is generated dynamically at runtime using a SELECT statement written in the record definition. Dynamic Views are more flexible because PeopleCode can modify the SQL before it executes, making them suitable for context-dependent data retrieval. The trade-off is that Dynamic Views cannot be indexed.
Q5. How do you implement dynamic prompts in PeopleCode?
Answer: Dynamic prompts allow the underlying prompt table for a field to change based on user input. You implement this using the SetPromptTable function in a FieldChange or RowInit event. For example, if a user selects a country, the state/province field's prompt table can be switched dynamically. The AddDropDownItem method can also be used to override a field's prompt entirely and populate it with custom values, which suppresses the original prompt table.
Q6. What is the difference between SQLExec and CreateSQL in PeopleCode?
Answer: SQLExec is a simpler function used for single-row SQL operations (SELECT, INSERT, UPDATE, DELETE). It binds parameters inline and is straightforward for one-off queries. CreateSQL creates a SQL object that supports multiple-row fetching via a fetch loop (Fetch method), better for iterating over result sets. CreateSQL is preferred for multi-row operations and reusable SQL objects. Both support MetaSQL, which makes statements platform-independent using constructs like %Table, %Bind, and %DateIn.
SECTION 2: Application Engine - Advanced
Q7. Explain the architecture of an Application Engine program. What are Sections, Steps, and Actions?
Answer: An Application Engine (AE) program is organized hierarchically. A Section is the top-level container and acts like a subroutine or module - programs start with the MAIN section. Each Section contains Steps, which are sequential units of processing. Each Step contains one or more Actions. Actions are the actual work units and can be of types: SQL (runs SQL statements), PeopleCode (runs PeopleCode logic), Log Message (logs to the process log), Do Select (loops over a result set), Do When/Until/While (conditional/loop control), and Call Section (calls another section). This structure allows for modular, maintainable batch programs.
Q8. What are State Records in Application Engine and why are they important?
Answer: State Records are special records used by Application Engine to maintain the state of variables across sections and steps during program execution. They act as the program's global memory - any field on a State Record is accessible throughout the AE program without passing parameters. AE programs can have multiple State Records. They are temporary (Derived/Work type) records that exist only during the run. Best practice is to define a dedicated State Record for each AE program to avoid conflicts and ensure clean variable scoping.
Q9. How do you call an Application Engine program from PeopleCode, and in which events is this allowed?
Answer: You call an AE program from PeopleCode using the CallAppEngine function. This is only allowed in events that permit database updates, such as FieldChange, SavePreChange, SavePostChange, and record PeopleCode. It CANNOT be used inside an AE PeopleCode action (use CallSection instead). The function signature is CallAppEngine(programname, staterecord) where the State Record is passed to share context between the calling component and the AE program.
Q10. What is the difference between Restart and No Restart in Application Engine?
Answer: Restart capability allows a failed AE program to resume from the last successful commit point rather than starting over. This is enabled by checking the "Restart" flag on Steps. No Restart means if the program fails, it must be run from the beginning. For long-running batch programs (e.g., payroll), Restart is critical because reprocessing millions of rows from scratch would be expensive. Commit frequency (Commit After Every N rows) combined with Restart enables reliable, recoverable batch processing.
SECTION 3: Integration Broker - Advanced
Q11. Describe the full architecture of PeopleSoft Integration Broker. What are its two core components?
Answer: Integration Broker is PeopleSoft's middleware framework for system-to-system communication. Its two core components are: (1) Integration Gateway - the transport layer that handles the physical sending and receiving of messages over HTTP, HTTPS, JMS, or other connectors. It routes messages between the PeopleSoft system and external systems. (2) Integration Engine - the application server process that handles message processing logic, including routing, transformation (using XSLT), and subscription. Together they support both synchronous (request/response) and asynchronous (fire-and-forget) messaging using SOAP or REST-based service operations.
Q12. What is the difference between synchronous and asynchronous messaging in Integration Broker?
Answer: In synchronous messaging, the caller sends a request and waits for a response before proceeding - similar to a web service call. The requesting system is blocked until the response is received. In asynchronous messaging, the caller sends a message and continues processing without waiting; the receiving system processes the message independently. PeopleSoft uses a Pub/Sub (Publish/Subscribe) model for asynchronous messages. Asynchronous is better for high-volume, non-real-time scenarios like nightly data loads, while synchronous suits real-time lookups or validations.
Q13. How do you configure Integration Broker to expose a REST API from PeopleSoft?
Answer: First, enable Integration Broker in PIA under PeopleTools > Integration Broker > Configuration. Create a Service and define a REST-based Service Operation (GET, POST, PUT, DELETE). Define the URI template (resource path and query parameters). Create a Handler (PeopleCode class method that processes the request). Define a Routing to specify the target node. Set security on the service operation using permission lists. The REST service can then be consumed by external systems using the published URL pattern. Authentication is handled via OAuth tokens, Basic Auth, or SSO depending on configuration.
Q14. What are Routing Definitions in Integration Broker and why are they needed?
Answer: Routing Definitions specify the path a message takes between nodes (systems). They define the sending node, the receiving node, the transformation (if any), and the connector settings. Without a valid routing, the Integration Broker cannot dispatch a message. Routings can be Local-to-Local (within the same PeopleSoft database), Local-to-Remote (PeopleSoft to external), or Remote-to-Local (external to PeopleSoft). Since PeopleTools 8.48+, routings replaced the older Channel/Message Node approach, making configuration more granular and manageable.
SECTION 4: Component Interface - Advanced
Q15. Explain the Component Interface lifecycle in PeopleCode. What are the key steps?
Answer: The standard programmatic steps to use a Component Interface are: (1) Establish a user session using %Session. (2) Get the CI object using GetCompIntfc. (3) Set the Create Keys or Get Keys depending on whether you are creating a new instance or retrieving an existing one. (4) Call Create() or Get() to instantiate the component. (5) Populate required fields using CI properties. (6) Call Save() to commit. (7) Handle errors using the Session's ErrorPending or WarnPending flags. (8) Call %Session.Disconnect() to release the session. Component Interfaces enforce all component-level PeopleCode, edits, and business logic, making them a safe way to insert/update data programmatically.
Q16. When would you choose Component Interface over a direct SQL INSERT/UPDATE? What are the risks of bypassing the CI?
Answer: Component Interfaces should be chosen when the underlying component has significant PeopleCode logic, defaulting, validation, or workflow triggering that must be respected. For example, creating an employee in HCM through direct SQL would bypass auto-numbering, effective dating logic, workflow approval triggers, and audit entries - leading to data corruption or missing dependent records. Direct SQL is only acceptable for read-only reporting purposes or in very controlled data migrations where all logic is manually replicated and thoroughly tested.
SECTION 5: Security - Advanced
Q17. Explain the PeopleSoft security model. What is the difference between Roles, Permission Lists, and User Profiles?
Answer: PeopleSoft uses a layered security model. A User Profile is the individual user's identity containing their login, password, and assigned Roles. A Role is a logical grouping of one or more Permission Lists. A Permission List is the granular access object that controls what a user can do - it defines access to menus, components, pages, fields (including field-level hide/display/required), processes, and query access. Row-Level Security is a separate layer that restricts which data rows a user can see (e.g., restricting an HR manager to only employees in their department). Sign-on PeopleCode further extends security by executing logic at login time - for example, redirecting users or enforcing IP restrictions.
Q18. What is field-level security in PeopleSoft and how is it configured?
Answer: Field-level security restricts access to individual fields on a page based on the user's permission list. It can set a field to Display Only, Hide, or Required. This is configured in the Permission List under Component Permissions - you drill down to the page and then the field. For example, a salary field might be hidden for all roles except Compensation Managers. This is more granular than page-level security and ensures sensitive data is protected even within an accessible component.
SECTION 6: Performance Tuning & Architecture
Q19. How do you tune a slow-running Application Engine program?
Answer: Key tuning approaches include: (1) Review and optimize SQL in Do Select and SQL actions - ensure proper indexes exist on driving tables. (2) Reduce commit frequency only if needed (too frequent commits add overhead; too infrequent risks rollback issues). (3) Use Parallel Processing where AE supports it. (4) Minimize PeopleCode within AE loops - SQL-only steps are faster. (5) Use temporary tables (%Table with instance tables) for staging large data sets to avoid locking production tables. (6) Enable PeopleSoft Performance Monitor and review AE trace files to identify bottlenecks. (7) Avoid unnecessary re-queries - use State Records to pass data between steps rather than re-fetching.
Q20. What is MetaSQL and why is it preferred over platform-specific SQL in PeopleSoft?
Answer: MetaSQL is PeopleSoft's abstraction layer over native SQL, providing platform-independent SQL constructs. Examples include %DateIn, %DateOut, %Table, %TruncateTable, %SelectInit, %Bind, and %Execute. Because PeopleSoft runs on Oracle, SQL Server, DB2, and other databases, MetaSQL ensures the same PeopleCode/AE logic works across all platforms without modification. For example, %DateIn converts a date to the appropriate format for each database, whereas writing Oracle-specific TO_DATE would break on SQL Server.
Q21. What is the PeopleSoft Update Manager (PUM) and how does it differ from traditional patching?
Answer: PUM is Oracle's selective patching mechanism for PeopleSoft. Instead of applying all available patches (a traditional cumulative patch), PUM allows administrators to select specific fixes relevant to their environment through an online catalog (hosted on a PUM image). Change Assistant then applies only the selected patches. This dramatically reduces patch application time and the risk of introducing unnecessary changes. The PUM image is a standalone PeopleSoft database containing all available fixes, and organizations connect their Change Assistant to it for targeted updates.
SECTION 7: Reporting & Data Tools
Q22. What is the difference between PS/nVision, XML Publisher (BI Publisher), and PS Query? When would you use each?
Answer: PS Query is used for ad-hoc, browser-based reporting for business users - suitable for simple tabular reports with filtering. PS/nVision is Excel-based financial reporting with matrix-style layouts and ledger drilldown - ideal for financial statements and budget reports in FSCM. XML Publisher (now Oracle BI Publisher) is used for formatted, print-quality reports (PDFs, Word documents) with sophisticated templates - ideal for regulatory reports, checks, purchase orders, or any document needing pixel-perfect formatting. For senior developers, the choice depends on audience (end user vs. finance team), format requirements, and data complexity.
Q23. How does SQR (Structured Query Reporter) differ from Application Engine for batch processing?
Answer: SQR is a third-party scripting language PeopleSoft adopted for batch reporting and data processing. It runs outside the PeopleSoft application server as a standalone executable and has its own procedural syntax (Procedures, Paragraphs). It is excellent for formatted output (paginated reports with headers/footers). Application Engine is PeopleSoft's native batch framework, runs within the app server tier, supports PeopleCode and MetaSQL, is restartable, and integrates more tightly with PeopleSoft objects and State Records. For new development, Application Engine is the modern standard; SQR is maintained for legacy programs.
SECTION 8: Architecture & Upgrades
Q24. Describe the PeopleSoft Internet Architecture (PIA). What are its tiers?
Answer: PIA is PeopleSoft's three-tier web architecture: (1) Web Server Tier - hosts the PeopleSoft servlet (WebLogic or WebSphere) and delivers HTML/JavaScript to the browser. (2) Application Server Tier - runs on BEA Tuxedo middleware and hosts the Application Server processes (PSAPPSRV, PSQRYSRV, PSSAMSRV, etc.) that execute PeopleCode and business logic. (3) Database Server Tier - the RDBMS (Oracle, SQL Server, DB2) storing all data and objects. Tuxedo continues to serve as the middleware layer between the web tier and app tier even when WebLogic or WebSphere is used as the HTTP/servlet engine.
Q25. What is Event Mapping in PeopleSoft and how does it support customization without modifying delivered objects?
Answer: Event Mapping (introduced in PeopleTools 8.55) is a framework that allows developers to attach custom PeopleCode to delivered component events without directly modifying the delivered component. You create an Application Class with the required logic, then use the Event Mapping configuration to bind that class to specific events (e.g., PreBuild, PostBuild, FieldChange) on any delivered component. This preserves the ability to apply Oracle patches without merge conflicts, as the delivered object is untouched. Combined with Drop Zones (for UI extensions), Event Mapping is now the recommended approach for non-invasive customizations.
SECTION 9: Scenario-Based / Leadership Questions (10+ Years Focus)
Q26. You are leading a PeopleSoft HCM upgrade from PeopleTools 8.54 to 8.60. What is your approach?
Answer: The approach spans: (1) Impact analysis - run the Upgrade Comparison Report in Application Designer to identify customized objects that conflict with delivered changes. (2) Environment setup - configure a copy-of-production for upgrade testing. (3) Use Change Assistant to apply the upgrade steps sequentially, addressing customization merges. (4) Regression test all customized components, integrations, and batch programs. (5) Performance baseline comparison before and after. (6) SIT and UAT cycles with business stakeholders. (7) Cutover planning with rollback procedures. Key risks to manage include custom PeopleCode broken by delivered object restructuring, Integration Broker node configuration changes, and third-party connector compatibility.
Q27. How would you design a high-volume inbound integration to PeopleSoft that processes 500,000 employee records nightly?
Answer: For high volume, avoid the overhead of Component Interfaces (which process one component at a time with full PeopleCode execution). Instead: (1) Use an Application Engine program with staging tables - load raw data into staging via flat file or direct database feed. (2) Validate data in AE using SQL and PeopleCode only where business rules require it. (3) Use Direct Insert/Update SQL with MetaSQL for bulk operations where CI is not required. (4) For records requiring CI (e.g., Job Data in HCM), use multi-threaded AE with parallel instances to distribute the load. (5) Implement robust error logging to staging error tables with re-processable error records. (6) Schedule via Process Scheduler with appropriate server load balancing.
Q28. A production PeopleSoft Integration Broker service operation is failing intermittently. How do you diagnose it?
Answer: (1) Check the Service Operations Monitor (PeopleTools > Integration Broker > Service Operations Monitor > Asynchronous/Synchronous) for failed instances and review the error detail. (2) Review the Integration Gateway log (integrationGateway.log) on the web server for transport-level errors. (3) Check the Application Server log for engine-level processing errors. (4) Verify the Node configuration - confirm the target URL, connector properties, and authentication tokens are valid and not expired. (5) Check for routing mismatches or inactive routings. (6) Review transformation XSLT if the message structure changed in a recent patch. (7) Use the Ping Node utility to verify connectivity. Intermittent failures often point to timeout settings, SSL certificate expiry, or target system throttling.
Q29. How do you handle a situation where a delivered PeopleSoft patch overwrites a customized record or page?
Answer: This is managed through the standard customization merge process. Before applying any patch, use the Upgrade Compare Report in Application Designer to identify conflicts between the patch objects and customized objects. For impacted objects, use Application Designer's side-by-side compare to review differences. Merge custom logic into the updated delivered object - preferably using Event Mapping or Application Classes rather than inline PeopleCode on delivered records, which would reduce future merge work. After merging, run full regression on all affected components. This process underscores why it's best practice to minimize direct modification of delivered objects.
Q30. What strategies do you follow to minimize performance degradation in a PeopleSoft environment post go-live?
Answer: Key strategies include: (1) Monitor with PeopleSoft Performance Monitor (PPM) - track slow component loads and long-running SQL. (2) Use the SQL Trace utility (%TraceSQL) during development to identify expensive queries before they reach production. (3) Review Application Server and Web Server tuning parameters (PSAPPSRV min/max instances, cache settings). (4) Implement proper database indexing on high-frequency query tables. (5) Archive historical data from heavily queried tables (e.g., JOB, PERSONAL_DATA) using PeopleSoft Archive Manager. (6) Schedule resource-intensive batch jobs (AE, SQR) during off-peak windows. (7) Use Fluid UI where applicable - it is more performant on modern browsers than Classic UI. (8) Regularly review and re-compile PeopleCode caches after patches.
PeopleSoft Deep-Dive Technical Interview Q&A - 10+ Years Experience (Part 2)
SECTION 1: PeopleCode - Expert Level
Q1. Explain the complete PeopleCode event firing sequence when a user opens a component, modifies a field, and saves. Name every event in order.
Answer: The full sequence is as follows:
When the component loads: RowSelect fires for each row fetched from the database, then RowInit fires for every row in every scroll level (used for initialization, hiding fields, setting defaults). PreBuild fires before the component builds, and PostBuild fires after it is fully built - both are used for component-level initialization logic.
When a user changes a field value: FieldDefault fires if the field has no value, FieldFormula re-evaluates field formulas, FieldChange fires after the user tabs out of the field (this is the most commonly used event for cascading logic), and FieldEdit fires for validation of the new value.
When the user clicks Save: SaveEdit fires for all rows across all pages for component-level validation, SavePreChange fires just before the database is updated (used for last-minute writes, defaults), Workflow fires for TriggerBusinessEvent calls, and SavePostChange fires after the commit (used for triggers, messaging, calling AE).
RowDelete fires when a user deletes a row, and RowInsert fires when a user inserts a new grid row.
Understanding this sequence is critical for debugging unexpected behavior - for example, a developer incorrectly placing a database call in RowSelect (which causes excessive queries during page load) is a common senior-level design mistake.
Q2. What are Application Classes in PeopleSoft? How do they differ from traditional PeopleCode functions? When should you use them?
Answer: Application Classes are PeopleSoft's object-oriented programming construct, introduced to bring class-based design into PeopleCode. They are defined under Application Packages and support concepts like encapsulation, inheritance, method overriding, and interfaces. A class has properties (data), methods (functions), and can extend another class using the extends keyword or implement an interface with implements.
Traditional PeopleCode functions are procedural - they are standalone functions attached to records, pages, or components. They don't carry state, cannot be inherited, and become difficult to maintain at scale.
For a 10+ year developer, Application Classes should be the default approach for any reusable, complex business logic - especially for AWE User List definitions (which must be an Application Class), Integration Broker handlers, Event Mapping hooks, and Chatbot integrations. The code is more maintainable, testable, and upgrade-safe compared to inline PeopleCode scattered across records.
Q3. What is the Rowset object model in PeopleSoft? How do you navigate a multi-level scroll structure programmatically?
Answer: The Rowset is PeopleSoft's in-memory data structure that mirrors the component buffer. A Rowset contains Rows. Each Row contains Records (field containers) and can contain child Rowsets for lower scroll levels. This mirrors the visual structure of a component with parent and child grids.
To navigate: GetLevel0() returns the Level 0 Rowset (the component header). From there you call GetRow(n) to access a specific row, then GetRowset(Scroll.RECORD_NAME) to go one level deeper. For example:
Local Rowset &rs_hdr = GetLevel0();
Local Rowset &rs_lines = &rs_hdr.GetRow(1).GetRowset(Scroll.ORDER_LINE);
Local integer &i;
For &i = 1 To &rs_lines.ActiveRowCount
&rs_lines.GetRow(&i).ORDER_LINE.QTY.Value = 0;
End-For;
This is a critical skill for 10+ year developers who need to manipulate complex multi-scroll components programmatically, perform data transformations during save, or use Component Interfaces on nested structures.
Q4. What is the difference between a Standalone Rowset and a Component Buffer Rowset? When do you use each?
Answer: A Component Buffer Rowset is the live in-memory data tied to the current component being displayed - changes to it affect what the user sees and what gets saved. You access it via GetLevel0(), GetRowset(), etc.
A Standalone Rowset is a Rowset object created in PeopleCode using CreateRowset(Record.RECORD_NAME) that exists independently of the component buffer. It is used for reading external data, performing batch-like logic within PeopleCode, or building data structures to pass into Component Interfaces. Changes to a Standalone Rowset do NOT automatically update the database - you must explicitly handle persistence. Standalone Rowsets are commonly used in Application Engine programs and Application Class methods for data manipulation without a UI context.
Q5. Explain the difference between %This, %Super, and %ClassName in PeopleCode Application Classes.
Answer: %This is the self-reference keyword inside an Application Class method - equivalent to this in Java or C#. It refers to the current instance of the class. %Super refers to the parent class when inheritance is used - it allows calling overridden methods from the parent, similar to super() in Java. %ClassName is a compile-time constant that returns the fully qualified class name of the current class (e.g., MYPACKAGE:MySubPkg:MyClass). It is useful for logging, error messages, or factory patterns where you need to identify which class is executing. Senior developers use these in complex inheritance hierarchies, particularly in AWE handler classes and Integration Broker service handler implementations.
SECTION 2: Application Engine - Expert Level
Q6. What is Parallel Processing in Application Engine and how do you implement it?
Answer: Parallel Processing allows an AE program to split its work across multiple concurrent instances using Temporary Tables. PeopleSoft delivers a mechanism where you define a "base" temporary table and then configure instance numbers (e.g., INSTANCE_1, INSTANCE_2 up to N). Each parallel AE process is assigned a unique instance number and works only on its dedicated temporary table partition, avoiding locking conflicts.
Implementation steps: First, define a temporary table in Application Designer and set the number of instances (e.g., 3 to 10). Build the database objects. In the AE program, use the %Table MetaSQL function - it automatically resolves to the instance-specific table name at runtime. Then submit multiple AE processes (via a master AE or via Process Scheduler) each with a unique run instance, and use a consolidation step to merge results after all instances complete. This is used for very high-volume jobs like payroll or GL posting where single-threaded processing is too slow.
Q7. What is an AE Library and how does it differ from a regular AE program? What are Section Types?
Answer: An AE Library is an Application Engine program specifically marked as a library - it contains reusable Sections that can be called from other AE programs using the CallSection action. Library programs cannot be run standalone; they exist purely to provide reusable logic. This is the AE equivalent of a function library.
Section Types within a regular AE program are: Prepare (runs once when the AE first starts, used for setup), Main (the default starting section), and Critical Updates (sections that contain critical database updates - they commit after each step regardless of commit settings, ensuring their updates are always saved). Knowing Section Types is an expert-level detail that indicates hands-on AE architecture experience.
Q8. How does the %UpdateStats MetaSQL command work and when should you use it?
Answer: %UpdateStats is a MetaSQL command in an AE SQL Action that tells the database to update statistics on a table immediately after large data operations. After inserting or updating millions of rows in a staging or temporary table, the database optimizer's statistics become stale, which can cause extremely poor query plans for subsequent SQL steps. By calling %UpdateStats(TABLE_NAME), you refresh the optimizer statistics mid-program without waiting for a nightly maintenance job. This is a critical performance tuning technique in large AE programs - especially after populating work tables in the early steps of a payroll, billing, or data migration AE.
SECTION 3: Integration Broker - Expert Level
Q9. Explain the full lifecycle of an asynchronous outbound message in PeopleSoft Integration Broker - from publication to delivery.
Answer: The lifecycle has these stages:
Understanding this full pipeline is critical for debugging integration failures, which is a daily task at the senior level.
Q10. What is Message Transformation in Integration Broker and how is it implemented?
Answer: Message Transformation converts the structure or content of a message from the PeopleSoft format to the format expected by an external system (or vice versa for inbound). It is configured on the Routing Definition. There are two transformation approaches: XSLT (eXtensible Stylesheet Language Transformations) is the traditional method where an XSL stylesheet maps source XML elements to target XML elements. Application Class Transformation is the modern alternative - you write a PeopleCode Application Class that implements the ITransform interface and manipulates the message XML programmatically using the XmlDoc object. Application Class transformations are more maintainable and easier to debug than raw XSLT. For JSON messages (supported in PeopleTools 8.54+), Application Class transformations handle JSON-to-XML conversion using PeopleCode's JsonParser and JsonBuilder objects.
Q11. What are Service Operation Versions in Integration Broker and why do they matter?
Answer: Service Operation Versions allow the same service operation to have multiple versions (V1, V2, V3, etc.) simultaneously active. This is critical for maintaining backward compatibility - when an external system is consuming V1 of an operation and you need to change the message structure, you create V2 with the new structure while keeping V1 active. Both versions have separate routings and handlers. The calling system specifies which version it uses. This prevents a forced simultaneous upgrade of all integration partners when PeopleSoft makes a structural change. Version management is a key architecture consideration in enterprise environments with many third-party integrations - for example, a healthcare system integrating HCM with payroll, benefits, and time-tracking vendors simultaneously.
Q12. What is the purpose of the Publish/Subscribe channel in Integration Broker, and how does channel sequencing work?
Answer: Channels are logical groupings for asynchronous messages that control the order of processing. Messages in the same channel are processed sequentially in the order they were published, ensuring that dependent messages are delivered in sequence (e.g., an employee hire message must be processed before the salary assignment message for the same employee). Messages in different channels can be processed in parallel.
Channel sequencing is controlled by the Sequence Number on the message publication. When strict sequencing is required, you place all related messages in the same channel and the dispatcher respects the publication order. A common issue is "channel starvation" - when one high-volume channel blocks all other messages because a single message in it has an error (the channel is paused for error). Resolving this requires either fixing the errored message, moving unrelated messages to different channels, or administratively skipping the failed message. Senior developers must understand this to prevent integration bottlenecks in production.
SECTION 4: AWE (Approval Workflow Engine) - Expert Level
Q13. Explain the AWE architecture in detail. What are the four key configuration areas?
Answer: AWE (available since PeopleTools 8.48) is PeopleSoft's configurable approval framework. It has four conceptual areas: the What, How, When, and Who.
The What is the Transaction Registry - this is where a custom transaction is registered with AWE. It defines which application is using AWE, the Header Record (the business transaction record being approved), the Cross-Reference Record (linking the transaction to AWE tracking tables), and the Application Class that implements the EOAW_CORE:ApprovalEventHandler base class to handle approval events (Submit, Approve, Deny, Push Back, etc.).
The How is the Approval Process Definition - this defines the stages, paths, and steps of the approval hierarchy. A Stage can contain multiple parallel Paths. A Path has one or more sequential Steps. Each Step points to a User List (who must approve). Criteria control at each level whether a stage, path, or step is even entered based on transaction data.
The When is the Approval Process Configuration - this defines notification triggers (when emails/worklist entries are sent) and links the Process ID and Definition ID to the transaction.
The Who is the User List - it defines who the approvers are. User Lists can be defined as Role-based (all users with a PeopleSoft Role), Query-based (PS Query returning user IDs), SQL-based (custom SQL), or Application Class-based (most flexible - resolves approvers dynamically using custom logic such as manager hierarchy traversal).
Q14. What is the difference between a Static Approval Process and a Dynamic Approval Process in AWE?
Answer: In a Static Approval Process, the approval path is fixed - the same approvers are always used regardless of the transaction content. User Lists are typically Role-based. This is configured entirely via PeopleSoft pages and can be maintained by functional users.
In a Dynamic Approval Process, the approval path expands or contracts based on transaction criteria. For example, a purchase order under $10,000 might need only one approval level, while one over $100,000 triggers three escalating manager levels. The User List is typically Application Class-based or SQL-based to dynamically resolve approvers at runtime (e.g., traversing the supervisor chain from EMPLID up to a certain level). This configuration may require developer assistance for the Application Class or SQL User List but gives maximum flexibility for complex business rules.
Q15. What PeopleCode do you need to write to integrate a custom component with AWE?
Answer: To integrate a custom component with AWE you need to implement several pieces:
First, create an Application Class extending EOAW_CORE:ApprovalEventHandler. Override methods like OnSubmit, OnApprove, OnDeny, OnPushback, OnWithdraw, and OnFinalApproval to update your transaction's status field when each approval event occurs.
Second, on the component Submit button's FieldChange event, write code to: (a) create an instance of EOAW_CORE:TxnApprovalMonitor, (b) call SetupConfig to bind the Process ID and Definition ID, (c) call SubmitForApproval. For example:
Local EOAW_CORE:TxnApprovalMonitor &monitor;
&monitor = create EOAW_CORE:TxnApprovalMonitor(%This);
&monitor.SetupConfig("MY_PROCESS_ID", "MY_DEF_ID");
&monitor.SubmitForApproval();
Third, register the transaction in the AWE Transaction Registry pointing to your Header Record, Cross-Reference Record, and the Application Class you created. This combination delegates all workflow routing logic to the AWE framework while keeping your custom approval event handlers clean and maintainable.
SECTION 5: Fluid UI - Expert Level
Q16. What is PeopleSoft Fluid UI and how does it fundamentally differ from Classic UI at the technical level?
Answer: Fluid UI (introduced in PeopleTools 8.54) is PeopleSoft's responsive, mobile-aware user interface framework built on HTML5, CSS3, and JavaScript. Unlike Classic UI which rendered pages as static HTML tables, Fluid uses CSS Flexbox layout, making pages responsive across desktop, tablet, and mobile devices.
Technically, Fluid pages are still defined in Application Designer but use a different page type (Fluid) and a different layout model. Classic pages use the %Panel metaphor with fixed pixel positioning. Fluid pages use groupboxes with layout styles (horizontal, vertical, responsive) that map to CSS Flex containers. Fluid pages use the psc_ CSS class naming convention and are governed by the PeopleSoft-delivered Unified Navigation framework including the Navbar, tiles (also called grouplets), and Activity Guides. JavaScript customizations in Fluid use the PT_ JavaScript API rather than inline scripts. Fluid pages also support Drop Zones for customization without touching delivered page definitions.
Q17. What are Drop Zones in PeopleSoft Fluid and how do they support upgrade-safe customization?
Answer: Drop Zones are predefined "extension points" embedded in delivered Fluid (and Classic Plus, since PeopleTools 8.58) pages where customers can inject custom content - fields, subpages, buttons - without modifying the delivered page definition itself. Oracle engineers embed Drop Zone markers in delivered pages, and administrators map custom subpages to those Drop Zones through PeopleTools configuration (not code). When a patch updates the delivered page, the Drop Zone binding is preserved because the customization lives in the configuration layer, not in the page definition. Combined with Event Mapping (to add custom PeopleCode logic to delivered components without modifying them), Drop Zones represent the modern, upgrade-safe customization model for PeopleSoft and should be the first approach considered before any direct delivered-object modification.
Q18. What is an Activity Guide in PeopleSoft Fluid and when is it used technically?
Answer: An Activity Guide is a Fluid framework that presents a multi-step guided process to the user, displaying a navigation panel on the left (showing step completion status) and the component content on the right. Common use cases are onboarding checklists, life event changes in benefits, and multi-step data entry wizards.
Technically, an Activity Guide is configured through PeopleTools (since PeopleTools 8.58, under PeopleTools > Activity Guide) by creating an Activity Guide Template that lists the steps (each step pointing to a Component/Page), defining the step order and completion conditions, and assigning it to a Context (which determines what data drives the instance). The framework provides built-in navigation (Next, Previous, Mark Complete) and tracks step completion in the database. Developers add PeopleCode only when custom step validation or dynamic step enabling/disabling is needed via the Activity Guide Composer framework.
SECTION 6: Search Framework & Elasticsearch - Expert Level
Q19. What is the PeopleSoft Search Framework and how does Elasticsearch integrate with it?
Answer: The PeopleSoft Search Framework (introduced with PeopleTools 8.52 using SES, then migrated to Elasticsearch from PeopleTools 8.55) provides enterprise-wide full-text search across PeopleSoft application data. It replaces the older keyword search with a fast, scalable search engine.
Technically, Search Framework defines Search Definitions (analogous to data sources - based on PS Queries, Connected Queries, or File Attachments), Search Categories (which group multiple Search Definitions and define facets for filtering), and Deploy configurations (which push index definitions to Elasticsearch). PeopleSoft deploys a dedicated Elasticsearch cluster (bundled via DPK since PeopleTools 8.57), and the Integration Broker creates REST-based web services to push data from PeopleSoft to Elasticsearch indices during scheduled or real-time indexing.
From PeopleTools 8.57 onward, each Search Definition maps to a separate Elasticsearch index (previously they were collated into one). This allows independent indexing schedules and more targeted reindexing. Kibana (bundled alongside Elasticsearch) provides monitoring dashboards for index health and search performance.
Q20. What is the Pivot Grid framework in PeopleSoft and how is it technically built?
Answer: Pivot Grid is PeopleSoft's embedded analytics framework, delivering interactive charts and pivot tables (cross-tab reports) directly within Fluid pages - no external BI tool required. It is powered by PS Queries and displays data as bar charts, line charts, pie charts, or pivot tables with drill-down to underlying transaction pages.
To build a Pivot Grid: Create a PS Query (or Connected Query for complex data), then create a Pivot Grid Definition in PeopleTools (Reporting Tools > Pivot Grid) pointing to that query. Define which fields are rows, columns, and facts (measure values). Configure chart type, filters, and user-configurable prompts. The Pivot Grid can be embedded in a Fluid page as a related content service or added as a Tile on the homepage. Since PeopleTools 8.57, Personalized Analytic Notifications allow users to set threshold alerts - when a measure value crosses a configured threshold, the system sends push or email notifications. This makes Pivot Grids suitable for proactive exception monitoring, not just reporting.
SECTION 7: HCM / FSCM Module-Specific Deep Dives
Q21. In PeopleSoft HCM, explain Effective Dating. Why is it architecturally significant and what problems does it solve?
Answer: Effective Dating is a design pattern used throughout PeopleSoft HCM (and FSCM) where each row in a table has an EFFDT (Effective Date) field and an EFFSEQ (Effective Sequence) field as part of the key. Instead of overwriting historical records, the system inserts a new row with a future or current effective date. Queries retrieve the "current" record by selecting the row with the maximum EFFDT that is less than or equal to today.
This solves several critical business problems: it maintains a full historical audit trail (you can see every version of an employee's job data), supports future-dating (you can enter a salary change effective next month while the current salary remains active), and enables retroactive processing (payroll can recalculate based on a retro-dated salary change). Architecturally, all developers must understand the WHERE EFFDT = (SELECT MAX(EFFDT) FROM table WHERE EFFDT <= %DateIn(...)) pattern and the role of EFFSEQ when multiple changes happen on the same effective date. Ignoring effective dating in custom SQL is one of the most common and dangerous errors in PeopleSoft development.
Q22. Explain SetID and TableSet sharing in PeopleSoft FSCM. What problem does it solve?
Answer: In FSCM modules (General Ledger, Accounts Payable, Purchasing, etc.), many configuration tables (like Vendors, Departments, Account Codes) need to be shared across multiple Business Units without duplicating data. SetID is the key that groups shareable configuration records. A Business Unit is mapped to one or more SetIDs via TableSet Sharing (configured in Set Control).
For example, Business Unit BU001 and BU002 might share the same Vendor SetID so that the same vendor master records are available to both. But they might have different Department SetIDs if their organizational structures differ. This avoids maintaining duplicate vendor records in each Business Unit. The technical implication is that all FSCM queries on shared tables must include the SetID in the WHERE clause, and prompt fields on pages use SETCNTLREC (Set Control Record) to dynamically resolve which SetID applies based on the current Business Unit. Developers unfamiliar with SetID routinely write incorrect queries that return cross-BU data or miss data entirely.
Q23. What is the General Ledger Combo Edit in PeopleSoft FSCM and how does it work technically?
Answer: Combo Edit (also called ChartField Combination Editing) validates that combinations of ChartField values (Account, Department, Fund, Program, Class, etc.) are valid per configurable business rules before a journal or accounting entry is saved. For example, a rule might enforce that Department 1000 can only be combined with Fund A or Fund B, not Fund C.
Technically, Combo Edit rules are configured in the General Ledger setup pages and stored in rule tables. The validation engine is invoked by Application Engine programs during journal processing and online during component save for transactions that generate accounting entries (vouchers, expense reports, etc.). An AE-based Combo Edit engine reads the rules and evaluates each ChartField combination, returning errors for invalid combinations. Custom rules can be added via the configuration pages. Senior FSCM developers frequently encounter ChartField combination errors during data migration and must understand the rule storage and AE engine to diagnose them.
SECTION 8: PeopleSoft on Cloud / Modern Architecture
Q24. What is the Deployment Package (DPK) in PeopleSoft and why is it important for modern deployments?
Answer: The Deployment Package (DPK) is Oracle's automated installation and configuration framework for PeopleSoft environments, introduced with PeopleTools 8.55. DPKs are Python-based (replacing the older Puppet-based approach from PT8.57 onward) fully automated installation scripts that deploy the entire PeopleSoft middleware stack - WebLogic, Tuxedo, JDK, the Application Server, Process Scheduler, Web Server, and optionally Elasticsearch - in a consistent, repeatable manner.
DPKs come in three flavors: PeopleTools DPK (middleware layer), PUM/Application DPK (database layer - the full PeopleSoft application image), and Infrastructure DPK (CPU patches for Oracle WebLogic, Tuxedo, and JDK). For organizations running PeopleSoft on Oracle Cloud Infrastructure (OCI) or on-premises virtual machines, DPKs dramatically reduce environment build time from days to hours. They also produce identical configurations across all environments (Dev, Test, Prod), eliminating environment drift - a major source of "works in dev, breaks in prod" issues.
Q25. What are the key considerations when migrating PeopleSoft from on-premises to Oracle Cloud Infrastructure (OCI)?
Answer: Key technical considerations include:
Network architecture - PeopleSoft's three-tier PIA architecture must be preserved on OCI, with the Web, App, and DB tiers running on separate compute or DB instances. OCI's Virtual Cloud Network (VCN) replaces the on-premises network, and security lists/NSGs replace firewall rules.
Storage - The database (Oracle DB) should be migrated to OCI's Exadata or Base Database Service for optimal performance. Application server binaries and PS Home directories go on Block Volumes.
DPK-based provisioning - OCI deployments should use DPKs for environment builds rather than manual installs, enabling Infrastructure-as-Code-style repeatability.
Licensing - PeopleSoft on OCI is included in the customer's existing license under the Bring Your Own License (BYOL) model for certain database tiers.
Elasticsearch - PeopleSoft's bundled Elasticsearch DPK must be deployed on a dedicated compute instance on OCI with appropriate heap sizing for the data volume.
Performance - OCI's low-latency networking between app and DB tiers can actually improve performance compared to on-premises if properly sized. However, WAN latency for end users must be mitigated using OCI CDN or FastConnect.
Change Assistant/PUM - Post-migration, Change Assistant must be reconfigured to point to the PUM image database on OCI and the target environments.
SECTION 9: Data Migration & Tools Deep Dive
Q26. Compare Data Mover, Component Interface, and Application Engine for data migration. Which would you choose for what scenario?
Answer: Data Mover is a command-line tool that imports/exports PeopleSoft database objects and data using a proprietary scripting language (DMS scripts). It is primarily used for environment management tasks - moving database contents between environments, mass data loads during initial implementation via IMPORT commands, or encrypting/decrypting passwords. It bypasses all PeopleCode and business rules, making it fast but risky for production data.
Component Interface is used when you need to enforce all PeopleSoft business rules, PeopleCode logic, workflow triggers, and data integrity constraints during migration. It processes one component at a time - correct but slow for large volumes. Use it for moderate-volume migrations (tens of thousands of records) where rule enforcement is non-negotiable.
Application Engine with direct SQL is the fastest approach for bulk operations - millions of rows. It bypasses component-level PeopleCode but allows you to implement business rules in SQL logic within the AE. This requires careful design to replicate critical logic (effective dating, setID resolution, auto-numbering) that the component would normally handle. Use this for very large data volumes in consultation with functional teams to confirm which business rules must be enforced.
The best enterprise data migration strategy often combines all three: Data Mover for initial environment setup, AE for bulk staging table loads, and CI for final transactional record creation.
Q27. What is Connected Query in PeopleSoft and how does it differ from a standard PS Query?
Answer: A standard PS Query is a single query built on one or more joined records - all records in the query are joined in a single SQL statement. This works for flat, relationally simple data but struggles with parent-child hierarchical data (e.g., one employee with multiple jobs, each with multiple compensation packages) because you cannot return truly hierarchical XML from a flat SQL join.
Connected Query links two or more standard PS Queries in a parent-child hierarchy. The parent query provides the driving key values, and the child query is executed once per parent row using bind variables from the parent. The result is a true XML hierarchy rather than a flat result set. Connected Queries are the required input for BI Publisher reports that need hierarchical XML (e.g., a PO report with line items and distribution lines), for Search Framework Search Definitions that index related data across multiple records, and for Pivot Grid configurations where measures span multiple levels. For a 10+ year developer, knowing when a Connected Query is technically necessary versus when a joined PS Query suffices is an important design judgment call.
SECTION 10: Tuxedo & Application Server Architecture
Q28. What is Tuxedo in PeopleSoft and what are the key server processes that run within it?
Answer: BEA Tuxedo (now Oracle Tuxedo) is the Transaction Processing Monitor (TP Monitor) that serves as the middleware layer between the Web Server and the Database in PeopleSoft's three-tier architecture. It manages a pool of server processes and routes requests from web users to the appropriate handler.
Key Tuxedo server processes include: PSAPPSRV (Application Server - handles component processor requests, executes PeopleCode), PSQRYSRV (Query Server - handles PS Query execution), PSSAMSRV (Sync Access Manager - handles synchronous Integration Broker messaging), PSANALYTICSRV (handles Pivot Grid and analytics queries), PSPUBDSP (Publication Dispatcher - picks up asynchronous messages for Integration Broker), PSSUBDSP (Subscription Dispatcher - processes inbound asynchronous messages), and PSDAEMON (runs AE programs scheduled at sub-daily frequency, such as every 15 minutes).
Tuning Tuxedo means correctly sizing the MIN and MAX instances of PSAPPSRV (too few causes request queuing; too many causes excessive database connections), setting appropriate LOAD and SRVGRP values for load balancing, and monitoring the Tuxedo queues (BBL - Bulletin Board Liaison process) for bottlenecks. This is a critical area for senior administrators and architects.
Q29. What is PeopleSoft Cache and what types of cache exist? How do you manage cache issues in production?
Answer: PeopleSoft caches PeopleTools object definitions (records, pages, PeopleCode, etc.) at multiple levels to avoid re-reading them from the database on every request:
Application Server Cache is stored on the Application Server filesystem (in the CACHE directory under PS_CFG_HOME). This is the most critical cache - it stores compiled PeopleCode, field definitions, record definitions, and component definitions. After applying patches or promoting objects, the Application Server cache must be cleared (by setting "Clear Cache at Startup" in PSADMIN or manually deleting cache files) to ensure the new versions are loaded.
Web Server Cache is maintained by the PIA servlet on the web server, caching menu definitions, portal pages, and static content.
Database Cache (PeopleTools tables like PSPCMPROG, PSRECDEFN, etc.) stores the canonical object definitions. After object migrations via Change Assistant or Application Designer, running the "BuildCache" process or restarting the App Server with cache clearing ensures consistency.
Cache-related production issues typically manifest as stale behavior - where users see old page layouts or PeopleCode logic doesn't reflect recent changes. The resolution is always a coordinated cache clear and application server restart during a maintenance window.
Q30. A PeopleSoft page is loading very slowly - taking 15+ seconds for a small number of rows. Walk through your complete diagnostic approach.
Answer: A systematic approach:
First, enable SQL Trace for the component (PeopleCode %TraceSQL or via the Trace menu in 2-tier Application Designer) to capture all SQL statements executed during page load. Review for: N+1 query patterns (SQL executing once per row in a loop rather than once for all rows), queries without WHERE clause index hits, and SQL executing in RowInit or RowSelect that could be batched.
Second, check whether the component has PeopleCode in RowSelect or RowInit that makes additional database calls per row. These fire for every fetched row and can multiply into hundreds of queries for moderate data sets.
Third, use PeopleSoft Performance Monitor (Enterprise > Performance Monitor) to review component load metrics and identify which sub-component (SQL, PeopleCode, network) consumes the most time.
Fourth, check Application Server tuning - if the PSAPPSRV pool is exhausted, requests queue up and the 15-second delay may be purely wait time for an available server process, not actual execution time.
Fifth, check for row-level security joins - complex security views joined to search records can make search queries extremely slow when the security view has no usable index paths.
Sixth, check if this is a Fluid page loading a complex grid - Fluid grids with many columns and thousands of rows may need pagination configuration or server-side filtering to reduce the initial data set.
Resolution varies but common fixes include adding database indexes, restructuring PeopleCode to move batch queries outside of row loops, reducing the component buffer size by adding search restrictions, or adding a SETMAXROWS call in RowSelect to limit fetched rows.
PeopleSoft: "Difference Between" - Complete Deep-Dive Guide
1. SOAP vs REST API (in PeopleSoft Integration Broker)
Aspect
SOAP
REST
Protocol
XML-based messaging protocol
Architectural style using HTTP methods
Format
Always XML (WSDL-defined)
XML or JSON
Transport
HTTP, HTTPS, JMS
HTTP, HTTPS
Contract
Strict - WSDL defines structure
Flexible - URI + HTTP verb defines intent
Complexity
Heavy - requires envelope, header, body
Lightweight - just payload + URL
PeopleSoft Support
Since early PeopleTools
REST supported from PeopleTools 8.51+
Operation Type
Service Operations (Sync/Async)
REST Service Operations (GET/POST/PUT/DELETE)
Security
WS-Security, SSL
OAuth, Basic Auth, SSL
Error Handling
SOAP Fault element in response
HTTP status codes (200, 400, 500, etc.)
Use Case
Legacy integrations, financial systems requiring strict contracts
Modern integrations, mobile apps, microservices
Real Example in PeopleSoft:
SOAP - when PeopleSoft HCM publishes employee data to a legacy SAP payroll system using a WSDL-defined web service, the message travels as a full XML envelope with header authentication and a structured body. The external system must conform exactly to the WSDL schema.
REST - when a mobile Fluid self-service app calls PeopleSoft to retrieve leave balances via a GET request to /PSIGW/RESTListeningConnector/HRMS/LeaveBalance.v1/{emplid}, the response comes back as lightweight JSON. This is faster, easier to consume, and mobile-friendly.
Key Takeaway: SOAP is used in older or enterprise-grade integrations requiring formal contracts and transactional guarantees. REST is the modern standard for new integrations, especially mobile and cloud-to-cloud scenarios. PeopleSoft supports both through Integration Broker service operations.
2. SavePreChange vs SavePostChange
SavePreChange
SavePostChange
When it fires
BEFORE the database is updated
AFTER the database rows are committed
Database state
Data is in memory only, not yet written
Data is fully written and committed to DB
Primary use
Final validation, last-minute defaults, calculated field writes
Triggering Integration Broker messages, calling AE, updating related tables
Can you roll back?
Yes - an Error() call stops the save
No - data is already committed
Think-time functions
NOT allowed
DoSave() allowed?
SQLExec (UPDATE/INSERT)
Allowed - but risky without care
Allowed - common for post-save side effects
Workflow
Fires AFTER SavePreChange
N/A
Order in sequence
4th event in save cycle
6th event in save cycle (after Workflow)
Real Example:
SavePreChange - You are building a Purchase Order component. Before the PO is saved to the database, you want to auto-generate a PO Number using a sequence table. You write a SQLExec to fetch and increment the sequence, assign it to the PO_ID field, and it gets written to the database as part of the save. If any error is detected here, you call Error() and the entire save is aborted - nothing is committed.
SavePostChange - After the PO is committed, you want to publish a message to an external procurement system to notify it a new PO exists. You call %IntBroker.Publish(&msg) here. Since the data is already in the database, the external system can safely query PeopleSoft for the PO details using the published keys.
Critical Rule: Never place Integration Broker Publish calls in SavePreChange - if the message is sent but the save then fails (due to a subsequent error), the external system receives a notification for data that never actually made it to the database, causing a data mismatch.
3. DoSave vs DoSaveNow
DoSave
DoSaveNow
Type
Think-time function
What it does
Saves the current component (triggers full save cycle)
Saves the current component immediately, without running through the normal save cycle queue
Validation
Runs SaveEdit, SavePreChange, Workflow, SavePostChange
Skips SaveEdit - goes directly to the database write
Where allowed
FieldEdit, FieldChange, ItemSelected
Think-time restriction
Cannot use in SavePreChange, SavePostChange, RowSelect, Workflow
Same restriction
Risk
Lower - full validation cycle runs
Higher - bypasses validation; use with extreme care
Use case
Programmatic save triggered by a button or field change
Forced immediate save when you need the data persisted before continuing, and you are certain the data is already valid
DoSave - A user clicks a custom "Submit for Approval" button on a Leave Request page. In the FieldChange event of that button, you call DoSave() to save all the leave request data before triggering the AWE workflow submission. The full save cycle runs - SaveEdit validates data, SavePreChange sets the status to "Submitted", SavePostChange triggers the workflow message.
DoSaveNow - In a rare scenario where you have a multi-step process and you need to ensure a row is committed to the database before calling an external service within the same PeopleCode program, and you are confident all data is already validated, you call DoSaveNow(). This is uncommon and considered a last resort because skipping SaveEdit risks saving invalid data.
Key Takeaway: Always prefer DoSave() over DoSaveNow(). Use DoSaveNow() only when you have a specific, documented technical reason and you have already programmatically validated all data.
4. FieldEdit vs FieldChange
FieldEdit
FieldChange
When the user leaves a field (before the new value is accepted)
After the new value has been accepted by the system
Purpose
Validation - accept or reject the new value
React to the new value - cascade updates, set other fields
Error() behavior
Prevents the field from accepting the new value; user must correct it
The value is already accepted; Error() stops the component from saving but the field retains the bad value
Warning() behavior
Warns but allows the value to be accepted
Warns but processing continues
SetDefault() allowed
Yes
Database access
Allowed but discouraged (think-time issues)
Commonly used for lookups and cascading field logic
Can you change the field's own value?
Yes - using %Field.Value =
Yes - but the value is already set; use to adjust other fields
Typical use case
Validating that an entered date is not in the past; checking that an ID exists
Populating department name when department ID is changed; restricting downstream prompts
FieldEdit - On a Job Data page, when a user enters a new Salary Amount, the FieldEdit event validates that the amount does not exceed the grade maximum from the salary grade table. If it does, Error("Salary exceeds grade maximum") is thrown and the field reverts to its previous value - the user cannot proceed until they enter a valid salary.
FieldChange - When the user selects a new Department ID on an expense report, the FieldChange event fires. You use SQLExec to fetch the Department Name and Manager's EMPLID from the Department table and populate those fields on the page automatically. The Department ID is already accepted - you're reacting to it, not validating it.
5. SaveEdit vs FieldEdit
SaveEdit
Scope
Entire component - all rows, all pages
Single field on a single row
At save time, for every row in the component
When the user tabs out of the specific field
Order
Fires during the save cycle
Fires during data entry, before save
Prevents the entire component from saving
Prevents the specific field from accepting the new value
Cross-field, cross-row validations that require the complete component data to be assembled
Single-field immediate validation
Performance impact
Can be slow if it runs complex SQL for every row on a large grid
Fires only when the user touches that specific field
Example
Validating that total budget allocations across all lines equal exactly 100%
Validating that a date field is not in the past the moment the user enters it
FieldEdit - As soon as a user types an invalid Employee ID in a lookup field and tabs out, FieldEdit validates against the PERSONAL_DATA table. If not found, the field turns red immediately and the user is told to correct it before moving on.
SaveEdit - When saving a Timesheet component with multiple rows, SaveEdit checks that the total hours across all rows for the week do not exceed 40 (or a configurable threshold). This cannot be done in FieldEdit because you need all rows to be entered before you can sum them.
6. RowInit vs PostBuild
RowInit
PostBuild
Fires for every row fetched in every scroll level
Fires once when the component finishes building
During page load, once per fetched row
After all RowSelect and RowInit events have completed
Number of executions
Once per row - can fire hundreds of times for large grids
Exactly once per component load
Row-level initialization - hide/display fields per row, set row-specific defaults
Component-level initialization - set page-level flags, populate derived fields, hide entire sections
Performance risk
HIGH - avoid database calls in RowInit; use it only for field-level operations on already-loaded data
Lower - fires once; acceptable for a limited number of lookups
RowInit - In a grid showing employee job history rows, RowInit fires for each row. You check whether the row's Action Code is "TER" (Termination) and if so, set certain fields to Display Only for that row. This is done per row because each row may have a different Action Code.
PostBuild - When the component loads, you want to hide the entire "Compensation Details" group box if the user's role does not include the Compensation Manager permission list. This check happens once in PostBuild, not per row.
7. PreBuild vs PostBuild
PreBuild
BEFORE the component builds and data is fetched
AFTER the component is fully built and all data is loaded
Component data available?
No - records are empty; no fetched data available yet
Yes - all data is in the component buffer
Set search defaults, override search record, set component-level flags before fetch
Initialize display logic based on fetched data, set field visibility based on loaded values
Access to component data
Limited - only non-database fields and %Page variables
Full access to all component buffer data
PreBuild - Before the component fetches data, you set a search key default using the current user's department from %UserData so the search is pre-filtered. You can also set %Component.SearchRecord to dynamically change which record drives the search.
PostBuild - After the employee record is fully loaded, you check whether the employee's status is "Inactive" and hide the "Add Job" button (a push button field) accordingly. You cannot do this in PreBuild because the employee status is not yet loaded.
8. Synchronous vs Asynchronous Messaging (Integration Broker)
Synchronous
Asynchronous
Wait behavior
Caller waits for response before continuing
Caller sends and immediately continues - no waiting
Response
Required - calling system expects a reply
Optional - fire and forget, or eventual acknowledgment
Failure behavior
If target is down, caller gets an immediate error
Message queued; retried automatically when target is available
Performance impact on caller
High - caller is blocked during processing
Low - caller is not blocked
Real-time lookups (validate a vendor ID in an external system), immediate confirmations
Batch updates, nightly data feeds, high-volume event notifications
PeopleSoft implementation
Synchronous Service Operation; uses %IntBroker.SyncRequest()
Asynchronous Service Operation; uses %IntBroker.Publish()
Message persistence
Not stored in queue tables
Stored in PSAPMSGPUBHDR/PSAPMSGPUBCON until delivered
Retry capability
No automatic retry - must be handled in calling code
Automatic retry with configurable intervals
Synchronous - When a user enters a Supplier ID on an AP Voucher in PeopleSoft FSCM, a synchronous call validates the supplier against a third-party vendor management system in real time. The page waits for the response and either accepts or rejects the supplier ID immediately.
Asynchronous - When an employee's job data is saved in PeopleSoft HCM, a message is published asynchronously to the payroll system. The HR clerk's save completes immediately without waiting. The payroll system picks up the message minutes later and updates its records. If the payroll system is temporarily down, the message stays queued and is delivered automatically when it comes back up.
9. SQL View vs Dynamic View vs Query View
SQL View
Dynamic View
Query View
Stored in database?
YES - built as a real DB view
NO - generated at runtime
NO - based on PS Query; generated at runtime
Performance
Fastest - database can index and optimize
Moderate - re-executed each time
Slowest - PS Query parsing adds overhead
PeopleCode control
Cannot be changed at runtime
SQL can be dynamically modified via PeopleCode
Cannot be modified at runtime
When to use
Static, frequently used joins that benefit from DB-level optimization
Context-dependent data retrieval where the SQL needs to change at runtime
Quick reporting views for business users; Query Manager access
Build required
YES - must be built in Application Designer
NO
Indexable
YES - can use DB indexes
SQL View - DEPT_VW joins PS_DEPT_TBL with PS_SETID_TBL to produce a flat view of active departments. It is built once in the database and PeopleSoft queries it like a regular table.
Dynamic View - A prompt view on a "Project" field that dynamically filters projects based on the currently selected Business Unit. The SQL in the record definition uses a bind variable that PeopleCode populates at runtime: SELECT PROJECT_ID FROM PS_PROJECT WHERE BUSINESS_UNIT = :1. You cannot do this with a SQL View because the Business Unit is not known until runtime.
Query View - A manager wants to see all employees in their department. A PS Query is built and exposed as a Query View, which business users can access through Query Viewer without any developer involvement.
10. Application Engine vs SQR
Application Engine
SQR
Language
PeopleCode + MetaSQL + SQL
Proprietary SQR scripting language
Execution environment
Runs within PeopleSoft App Server tier
Standalone executable outside App Server
Integration with PeopleTools
Native - full access to PeopleCode objects, classes, CI, MetaSQL
Limited - accesses DB directly via ODBC/native drivers
Restart capability
YES - built-in with commit checkpoints
NO - must handle manually
Parallel processing
YES - via temporary table instances
Limited
Output
No formatted report output natively
Excellent formatted report output (PDF, HTML, CSV, text)
State Records
YES - native concept
MetaSQL support
YES - platform-independent SQL
Partial - some MetaSQL via #include
Better for data processing
Better for formatted reporting
Modern status
Preferred for new batch development
Legacy - maintained for existing programs
Best for
Data processing, batch updates, integrations, ETL
Formatted reports with headers, footers, subtotals, page breaks
Application Engine - The nightly payroll calculation job processes 50,000 employee records, calculates gross-to-net pay using PeopleCode business logic, writes results to payroll output tables, and uses restart capability so that if the job fails at record 35,000, it resumes from that point rather than starting over.
SQR - The W-2 year-end report generates a formatted PDF with employee name/address header, earnings breakdown in tabular format, tax withholding totals, and page breaks per employee. This formatted output is where SQR still excels over Application Engine.
11. Component Interface vs Direct SQL (for data load)
Component Interface
Direct SQL
Enforces PeopleCode logic
YES - all FieldDefault, FieldEdit, SaveEdit, SavePreChange, SavePostChange
NO - bypasses all PeopleCode
Speed
Slow - one component transaction at a time
Very fast - bulk SQL operations
Effective dating
Automatically handled by component
Must be manually coded
Audit tables
Automatically populated
Workflow triggers
YES - SavePostChange triggers fire
NO - must be manually triggered
Risk of data corruption
Low - business rules enforced
High - easy to create orphaned or invalid data
Moderate volumes where data integrity is critical
Very large volumes in controlled migrations with known-good data
Auto-numbering (e.g., EMPLID)
Handled automatically
Must be manually replicated
12. Roles vs Permission Lists vs User Profiles
User Profile
Role
Permission List
Definition
An individual user's identity in PeopleSoft
A named grouping of Permission Lists
The actual access object defining what a user can do
Level
Top level - the person
Middle level - the grouping
Bottom level - the access rights
Contains
Assigned Roles, password, preferences, email
One or more Permission Lists
Menu/component access, page access, field access, process groups, query access
Cardinality
One per user
Many roles per user
Many PLs per role
Managed by
System Admin
Security Admin
Security Admin/Developer
User "JSMITH" has Role "HR Manager"
Role "HR Manager" has PLs "HCHR1000" and "HCHR2000"
PL "HCHR1000" grants access to Job Data component in display-only mode
13. Primary Record vs Search Record vs Add Search Record
Primary Record
Search Record
Add Search Record
Holds the main data of the component
Used to fetch/search for the component keys (in Update/Display mode)
Used in Add mode when the search for new keys differs from the search for existing records
When it's used
Always - the component's data source
When user searches for an existing record
When user clicks Add a New Value
Typical type
SQL Table
SQL View or Table
All transactional fields
Key fields only, often with descriptions for display
Key fields needed to create a new record (often fewer fields than Search Record)
Real Example: On the Job Data component, the Primary Record is PS_JOB. The Search Record is JOB_SRCH_VW - a view that joins PERSONAL_DATA for the employee's name to display alongside the EMPLID in the search results. The Add Search Record is PERSON_SRCH_VW - which only exposes fields relevant to finding a person to add a new job for, without showing existing job data.
14. Error() vs Warning() vs MessageBox() in PeopleCode
Error()
Warning()
MessageBox()
Stops processing?
YES - immediately halts and rolls back in certain events
NO - processing continues after user acknowledges
NO - informational only; processing continues
User can override?
YES - user clicks OK and continues
YES - returns the button clicked (OK, Cancel, Yes, No)
In FieldEdit
Rejects field value
Warns but accepts field value
Displays message; processing continues
In SaveEdit
Prevents save
Prevents save but shows warning; user can choose to override (depends on config)
Informational
In SavePreChange
Prevents database write; triggers rollback
Allows save to continue
Allowed but think-time concern
Hard business rule violations (missing required data, invalid combinations)
Advisory notices (amount is high but acceptable)
Interactive dialogs where user input determines next action
Think-time classification
Not think-time
IS a think-time function - restricted in SavePreChange, SavePostChange, RowSelect, Workflow
Error() - "Employee ID does not exist in the system." - Used in FieldEdit of the EMPLID field. User cannot proceed until a valid EMPLID is entered.
Warning() - "Expense amount exceeds the policy limit of $500. Are you sure?" - Used in SaveEdit. The employee can acknowledge and save anyway, but the system flags it for manager review.
MessageBox() - A custom button triggers a complex multi-step process. A MessageBox presents "Do you want to include terminated employees? Yes / No". The return value determines which branch of the processing logic executes.
15. Exit(0) vs Exit(1) in PeopleCode
Exit(0)
Exit(1)
Terminates program?
YES
Rolls back database changes?
NO - changes made before Exit(0) are retained
YES - all changes in the current transaction are rolled back
Graceful early exit when no further processing is needed but data changes so far are valid
Fatal error recovery - abort and undo all changes
Exit(0) - In a FieldChange event that populates a department description, if the department field is blank, you call Exit(0) to stop processing without error - there's nothing to look up and no change has been made.
Exit(1) - In SavePreChange, you detect that a critical audit record could not be written (e.g., the audit table is full). You call Exit(1) to roll back the entire transaction, preventing partial saves where business data is written but the audit trail is missing.
16. Effective Date (EFFDT) vs Effective Sequence (EFFSEQ)
EFFDT (Effective Date)
EFFSEQ (Effective Sequence)
Data type
Date
Number
Identifies WHEN a record version became effective
Differentiates multiple changes on the SAME effective date
Part of key?
YES (when present)
Query filter
WHERE EFFDT = (SELECT MAX(EFFDT) WHERE EFFDT <= %DateIn(:today))
WHERE EFFSEQ = (SELECT MAX(EFFSEQ) WHERE EFFDT = :effdt)
Example scenario
An employee gets a promotion effective Jan 1. New row with EFFDT = 01/01/2026 is inserted.
The same employee gets a salary change and a title change both effective Jan 1. Two rows with EFFDT = 01/01/2026 but EFFSEQ = 0 and EFFSEQ = 1.
Combined query
Always query both to get the truly current record
Must include EFFSEQ in the MAX subquery when it is part of the key
17. SetID vs Business Unit
SetID
Business Unit
Groups shared configuration/reference data
Represents an operational entity (company, plant, department) for transactional data
Type of data
Reference / Setup data (Vendors, Accounts, Departments)
Transactional data (Journals, Purchase Orders, Timesheets)
Reuse model
One SetID can serve many Business Units
Each Business Unit is distinct
Configured via
Set Control Table
Business Unit setup pages
Vendors SetID "SHARE" is used by BU "USA01" and BU "USA02" - both share the same vendor master
BU "USA01" and "USA02" each have their own journal entries and PO transactions
FSCM relevance
Foundational to all FSCM modules
18. PeopleSoft Query vs Connected Query vs PS/nVision
PS Query
Connected Query
PS/nVision
Structure
Single SQL statement with joins
Parent-child linked queries producing hierarchical XML
Excel-based matrix report with ledger drill-down
Flat tabular result set
Hierarchical XML or nested result sets
Excel spreadsheet with formatted financial layouts
User type
Business users, power users
Developers (for BI Publisher, Search Framework)
Finance users
Runtime tool
Query Viewer / Query Manager
BI Publisher, Search Framework
nVision Report Designer
Multi-level data
Difficult - joins flatten hierarchical data
Native - designed for parent-child relationships
Native matrix (rows/columns intersection)
Ad-hoc data extraction, simple reporting
BI Publisher reports needing hierarchical XML
Financial statements, budget reports, trial balances
In-Depth Interview & Real-Time Reference Guide (2025-26) =================================================== TABLE OF CONTENTS: 1. FLUI...
No comments:
Post a Comment