In-Depth Interview & Real-Time Reference Guide (2025-26)
================================================================================
TABLE OF CONTENTS:
1. COMPONENT INTERFACE FUNDAMENTALS
2. CI STRUCTURE & OBJECTS
3. CI CREATION & CONFIGURATION
4. CI PROPERTIES & METHODS
5. COLLECTIONS & SCROLLING IN CI
6. DATA MANIPULATION & OPERATIONS
7. ERROR HANDLING & VALIDATION
8. PERFORMANCE OPTIMIZATION
9. INTEGRATION PATTERNS & REAL-WORLD SCENARIOS
10. TROUBLESHOOTING & DEBUGGING
11. SECURITY & BEST PRACTICES
12. ADVANCED TOPICS & PATTERNS
================================================================================
SECTION 1: COMPONENT INTERFACE FUNDAMENTALS
================================================================================
Q: What is a PeopleSoft Component Interface (CI)?
A: A Component Interface is a reusable application programming interface (API)
that exposes PeopleSoft business logic through a standardized object-oriented
interface. CIs are built on top of components and allow external systems to
interact with PeopleSoft data and processes without direct database access.
They encapsulate validation, default values, and business rules from the
underlying component.
Q: What is the purpose of using Component Interfaces?
A: CIs serve multiple purposes: (1) Enable integration with external systems via
web services or message queues; (2) Reduce coupling between PeopleSoft and
external applications; (3) Encapsulate business logic and enforce data
validation; (4) Provide a versioning mechanism for API changes; (5) Facilitate
reusability across multiple integration points; (6) Simplify maintenance by
centralizing logic.
Q: What is the relationship between a Component and a Component Interface?
A: A Component Interface is built on a single Component. The CI exposes the
component's structure (pages, records, fields) as properties and methods. The
component provides the user interface (pages, business rules, and validations);
the CI provides programmatic access to the same logic without the UI layer.
Q: What are the main delivery mechanisms for CIs?
A: CIs can be delivered via: (1) PeopleSoft Integration Broker (web services,
message queues); (2) Direct PeopleCode calls within PeopleSoft; (3) REST APIs
(PT 8.53+); (4) Java APIs (using the PeopleSoft Java SDK); (5) .NET APIs;
(6) File-based integration with connectors (e.g., PeopleSoft Data Mover).
Q: What is the difference between a CI and a web service?
A: A Component Interface is the PeopleSoft object that encapsulates business
logic. A Web Service is the delivery mechanism that exposes the CI to external
systems via HTTP/HTTPS protocols (SOAP or REST). A web service wraps a CI to
make it accessible across the network.
Q: Can a Component Interface be used without web services?
A: Yes. CIs can be invoked directly from PeopleCode within PeopleSoft using the
CreateComponent function. They can also be called via Java, .NET, or REST APIs
without traditional web services.
Q: What are the prerequisites for creating a Component Interface?
A: (1) A component must already exist in the system; (2) The component should
have pages with records and fields properly configured; (3) Business logic
(validation rules, defaults) should be implemented in the component's
PeopleCode; (4) Database records must support the data to be exposed;
(5) Security roles must grant access to the component.
Q: What is a CI version?
A: A CI version is a snapshot of the CI's structure and behavior at a point in
time. You can have multiple versions of the same CI (v1, v2, v3, etc.), each
with different properties, methods, or collections exposed. This allows you to
evolve the CI without breaking existing integrations.
Q: Can you modify a published CI version?
A: No. Published versions are read-only. To modify a CI, you must create a new
version. This ensures backward compatibility for systems consuming the
previous version.
Q: What is the purpose of CI versioning?
A: Versioning allows multiple systems to use different versions of the same CI
simultaneously. Old integrations can continue using v1 while new systems use
v2 with enhanced functionality. This prevents breaking changes.
Q: How does a Component Interface inherit business rules from a component?
A: When a CI is created, it copies the component's structure (pages, records,
fields) and its PeopleCode validations. Any changes to field-level or
record-level validation PeopleCode are inherited by the CI when it is
regenerated or a new version is created.
================================================================================
SECTION 2: CI STRUCTURE & OBJECTS
================================================================================
Q: What are the main structural elements of a Component Interface?
A: (1) Properties — field definitions mapped from the component; (2) Methods —
procedures that perform actions (Create, Fetch, Update, Delete); (3)
Collections — nested groups of records for scrolling; (4) Events — lifecycle
hooks that execute at specific points.
Q: What is a CI property?
A: A property is a field or value exposed by the CI that can be read or written.
Properties are derived from record fields in the underlying component. They
correspond to database columns and can have validation rules.
Q: What are standard CI methods?
A: Standard methods are: (1) Create() — adds a new row to a collection;
(2) Find() — retrieves existing rows; (3) Save() — persists changes to the
database; (4) Update() — modifies existing rows; (5) Delete() — removes rows;
(6) Fetch() — retrieves an entire row (retrieves read-only data by key).
Q: What is a Collection in a Component Interface?
A: A Collection represents a group of related records within the CI, typically
corresponding to a scroll area in the component. Collections are hierarchical
and can be nested (parent-child relationships). Each collection item is an
instance of a record group.
Q: What is the difference between a Property and a Collection in a CI?
A: A Property is a single field or value (scalar). A Collection is a group of
records that can contain multiple rows. Collections are accessed via indexing
(e.g., CI.Collection(1), CI.Collection(2)), while properties are accessed
directly (e.g., CI.Property1).
Q: What is a scroll area in a component?
A: A scroll area is a repeating section in a component page that contains
multiple rows of related data. In the CI, scroll areas are represented as
collections. Each row in the scroll corresponds to an item in the collection.
Q: How does a CI expose scroll levels?
A: Each scroll level in a component becomes a collection in the CI, with each
level forming a nested hierarchy. For example, a component with ORDER (level 0)
and ORDER_LINE (level 1) scrolls creates ORDER as a collection with
ORDER_LINE as a nested sub-collection.
Q: What is a CI event?
A: A CI event is a trigger point in the CI lifecycle that fires PeopleCode at a
specific moment. Common events include: OnCreate, OnFetch, OnSave, OnUpdate,
OnDelete, OnPopulate, and custom events.
Q: Can you add custom events to a CI?
A: Yes. You can create custom events in the CI definition that execute
application class methods or standard PeopleCode. These are triggered
programmatically when needed.
Q: What is the difference between read-only and read-write properties in a CI?
A: Read-write properties can be set and retrieved by the CI consumer. Read-only
properties can only be retrieved. Read-only properties are typically used for
system-generated values or calculated fields that should not be modified
externally.
Q: What is the CI root record?
A: The root record (or level 0 record) is the main record at the top of the CI
hierarchy. It typically contains header-level data (e.g., order number, order
date). All other records in the CI are nested beneath the root.
================================================================================
SECTION 3: CI CREATION & CONFIGURATION
================================================================================
Q: What are the steps to create a Component Interface?
A: (1) Open Component Interfaces in Application Designer; (2) Create a new CI or
copy an existing template; (3) Select a base component; (4) Verify the CI
structure (properties, collections, methods); (5) Configure properties (expose,
hide, set as key fields); (6) Create any custom methods; (7) Test the CI;
(8) Save and publish; (9) Create a version; (10) Deploy via web services or
direct calls.
Q: How do you select which fields to expose in a CI?
A: In the CI definition, you can individually check/uncheck fields. You can also
configure field-level properties: (1) Expose — make available to CI consumers;
(2) Required — field must be populated; (3) Key — field is used to identify
records; (4) Searchable — field can be used in WHERE clauses for Find/Fetch.
Q: What does "expose" mean for a CI property?
A: When a property is exposed, it becomes accessible to CI consumers
(external systems calling the CI). Unexposed properties are hidden and cannot
be accessed externally, but they still exist in the CI's internal logic.
Q: How do you configure key fields in a CI?
A: In the CI definition, select "Key" checkbox for fields that uniquely identify
a record. These fields are required when calling methods like Fetch or Update.
For example, ORDER_ID is typically a key field for an order CI.
Q: What is the purpose of marking fields as "Required" in a CI?
A: Required fields must be populated before the CI can Save or Update. If a
required field is empty, the CI raises an error. This enforces data quality at
the application interface level.
Q: Can you expose fields from multiple records in a single CI property level?
A: Typically no. A CI property level (collection item) corresponds to a single
record in the component. If you need fields from multiple records at the same
level, you should denormalize your component structure (not recommended) or
use multiple collections.
Q: How do you handle many-to-many relationships in a CI?
A: Many-to-many relationships are typically modeled as two separate collections
referencing the same data, or as a junction table exposed via nested
collections. For complex relationships, consider using multiple CIs or custom
application classes.
Q: What is a CI application class?
A: A CI can be backed by a custom application class (extending CI_BASE or
CI_DataArea) that contains custom business logic, validation, and methods
beyond the standard CI operations. This allows complex transformations and
business rules to be applied.
Q: Can you rename fields in a CI to differ from the underlying database?
A: Yes. In the CI property definition, you can set a "Publish Name" that differs
from the actual record field name. This allows you to present a different API
interface while maintaining the underlying data structure.
Q: What is CI inheritance?
A: CI Inheritance allows a CI to inherit properties, collections, and methods
from another CI. This is useful for creating specialized versions of a CI
(e.g., creating a read-only version of an order CI for reporting).
Q: How do you test a CI before publishing?
A: (1) Use the Component Interface Tester in Application Designer;
(2) Create a test instance with sample data; (3) Call Find, Fetch, Create,
Update methods; (4) Verify error handling; (5) Check property values;
(6) Validate collections and nested records.
Q: What does "publish" a CI mean?
A: Publishing a CI saves it and makes it available for use by web services,
PeopleCode, or external systems. A published CI can be versioned and deployed.
================================================================================
SECTION 4: CI PROPERTIES & METHODS
================================================================================
Q: What are the standard CRUD methods in a CI?
A: (1) Create() — creates a new instance in memory; (2) Find() — queries
existing records matching criteria; (3) Fetch() — retrieves a single record by
key; (4) Update() — modifies existing records; (5) Save() — persists changes
to the database; (6) Delete() — removes records.
Q: What is the difference between Fetch() and Find() in a CI?
A: Fetch() retrieves a single record by its key fields and returns a single
populated instance. Find() queries for multiple records matching a WHERE clause
and returns a collection. Fetch() is typically faster for retrieving one
specific record.
Q: How do you call a Fetch() method in a CI?
A:
Local object CI = CreateComponent("CI_NAME");
CI.OrderID = "12345";
CI.Fetch();
// CI now contains order data for OrderID 12345
Q: How do you populate a collection before calling Save()?
A: Create collection items and set their properties:
Local object CI = CreateComponent("CI_NAME");
CI.OrderID = "12345";
Local object LineItem = CI.LINE_ITEMS.CreateItem();
LineItem.LineNum = 1;
LineItem.ItemID = "ITEM001";
LineItem.Qty = 10;
CI.Save();
Q: What does the Save() method do in a CI?
A: Save() persists all changes (creates, updates, deletes) made to the CI
instance to the database. It executes all validation rules, triggers
PeopleCode events, and maintains referential integrity.
Q: Can you call Save() multiple times on the same CI instance?
A: No. Typically, Save() is called once after all modifications are complete.
Calling it multiple times can cause unexpected behavior or duplicate inserts.
To make multiple changes, create a new CI instance for each set of changes.
Q: How do you handle errors returned by CI methods?
A: Wrap CI method calls in try-catch blocks:
Try
CI.Save();
Catch Exception &e
Local object &ErrorCollection = &e.GetMessageCollection();
For &i = 1 To &ErrorCollection.Count
MessageBox(0, "", 0, 0, &ErrorCollection(&i).MessageText);
End-For;
End-Try;
Q: What is a CI custom method?
A: A custom method is a procedure defined in the CI (or its backing application
class) that performs a specific business operation beyond standard CRUD.
Example: CI.SubmitForApproval() or CI.CalculateTotal().
Q: How do you define a custom method in a CI?
A: In the CI definition, add a method with a name and specify whether it takes
parameters and what it returns. Implement the method in the CI's backing
PeopleCode or application class.
Q: Can CI methods accept input parameters?
A: Yes. When defining a custom method, you can specify input parameters:
CI.SubmitForApproval("MANAGER_ID", "COMMENTS");
The method receives these parameters and uses them in its logic.
Q: Can CI methods return values?
A: Yes. A method can return a value of any type (string, number, object, etc.).
This is useful for methods that calculate values or retrieve related data:
Local string &Status = CI.GetApprovalStatus();
Q: What is an "instance" in the context of CIs?
A: An instance is a runtime object created by calling CreateComponent("CI_NAME").
Each instance is independent and can hold different data. Multiple instances
of the same CI can coexist simultaneously.
Q: Can you create multiple instances of the same CI?
A: Yes. You can create multiple instances to work with different data:
Local object &CI1 = CreateComponent("CI_ORDER");
Local object &CI2 = CreateComponent("CI_ORDER");
&CI1.OrderID = "100";
&CI2.OrderID = "200";
// CI1 and CI2 are independent
================================================================================
SECTION 5: COLLECTIONS & SCROLLING IN CI
================================================================================
Q: What is a collection in a Component Interface?
A: A collection is a group of related records within the CI, corresponding to a
scroll area in the component. Collections can contain zero, one, or many items.
Each item represents a row in the scroll.
Q: How do you access items in a CI collection?
A: Collections are indexed (1-based, not 0-based):
Local object &Item = CI.ORDER_LINES(1); // First item
Local object &Item2 = CI.ORDER_LINES(2); // Second item
Local number &Count = CI.ORDER_LINES.Count; // Total items
Q: How do you iterate through a collection?
A: Use a for-loop:
For &i = 1 To CI.ORDER_LINES.Count
Local object &Line = CI.ORDER_LINES(&i);
MessageBox(0, "", 0, 0, &Line.ItemID);
End-For;
Q: How do you add a new item to a collection?
A: Use the CreateItem() method:
Local object &NewLine = CI.ORDER_LINES.CreateItem();
&NewLine.LineNum = 1;
&NewLine.ItemID = "ITEM001";
&NewLine.Qty = 10;
// Item is now in the collection; it will be saved when CI.Save() is called
Q: Can you access a collection property after deleting an item?
A: After deleting an item (using DeleteItem), the collection indices shift.
Accessing by index may return a different item. Always re-query or use a safe
loop pattern when deleting:
For &i = CI.ORDER_LINES.Count Down To 1
If CI.ORDER_LINES(&i).ItemID = "DELETE_ME"
CI.ORDER_LINES(&i).DeleteItem();
End-If;
End-For;
Q: What is nested scrolling in a component?
A: Nested scrolling means having multiple levels of scroll areas, where a child
scroll depends on a parent scroll. In CI terms, this creates nested collections:
CI.ORDERS(1).ORDER_LINES(1).ORDER_LINE_DETAILS(1)
Q: How do you access nested collections in a CI?
A: Index into each level sequentially:
Local object &Detail = CI.ORDERS(1).ORDER_LINES(2).DETAILS(1);
&Detail.PropertyName = "value";
Q: What is the impact of large nested collections on CI performance?
A: Large nested collections consume significant memory. The CI loads all rows
from all collections into memory, which can cause out-of-memory errors for
large datasets. For bulk operations, consider processing in smaller batches
or using SQL directly.
Q: How do you delete an item from a collection?
A: Use DeleteItem():
CI.ORDER_LINES(1).DeleteItem();
// Item is deleted; the collection is re-indexed
// Changes are persisted when CI.Save() is called
Q: Can you insert items at a specific position in a collection?
A: No. Items are always appended to the end. To reorder, you would need to
recreate the collection in the desired order or use a custom method.
Q: What happens when you call Fetch() on a CI with collections?
A: Fetch() populates the root level and all nested collections with all rows
from the database. For large collections, this can be slow and memory-intensive.
Q: Can you fetch only a subset of collection rows?
A: No. Fetch() retrieves all rows. To fetch specific subsets, use Find() with
WHERE clauses or implement custom methods that query specific rows and
populate the CI partially.
Q: What is "lazy loading" in CIs?
A: Lazy loading is a performance optimization where collections are not
immediately populated when the CI is fetched. Instead, rows are loaded only
when accessed. This is not natively supported in PeopleSoft CIs; you must
implement it via custom application classes.
================================================================================
SECTION 6: DATA MANIPULATION & OPERATIONS
================================================================================
Q: How do you create a new order via a CI?
A:
Local object &CI = CreateComponent("CI_ORDER");
&CI.OrderID = "ORD001";
&CI.OrderDate = %Date;
&CI.CustomerID = "CUST123";
&CI.Save();
Q: How do you update an existing order via a CI?
A:
Local object &CI = CreateComponent("CI_ORDER");
&CI.OrderID = "ORD001";
&CI.Fetch();
&CI.OrderStatus = "SHIPPED";
&CI.ShipDate = %Date;
&CI.Save();
Q: How do you delete an order via a CI?
A:
Local object &CI = CreateComponent("CI_ORDER");
&CI.OrderID = "ORD001";
&CI.Fetch();
&CI.Delete();
// Order is deleted from the database
Q: How do you find all orders for a specific customer?
A:
Local object &CI = CreateComponent("CI_ORDER");
&CI.GetHistoryItems(CUST_ID, "CUSTID", "");
// Returns all orders for the customer
Q: What is GetHistoryItems in a CI?
A: GetHistoryItems() retrieves multiple rows matching a WHERE clause. It's useful
for finding related records without fetching by key. The method returns a
collection of instances.
Q: How do you use a WHERE clause in a CI Find operation?
A: Depending on the CI implementation, you might use:
&CI.GetHistoryItems(KEY1, "FIELDNAME", "ADDITIONAL_CONDITIONS");
or implement a custom Find method that accepts a WHERE clause string.
Q: Can you bulk insert multiple records via a CI?
A: You can create multiple instances and call Save on each, but this is
inefficient. For bulk inserts, consider: (1) Using SQL directly via
ExecSQL; (2) Using Data Mover; (3) Implementing a custom method in the CI
that accepts a collection of records.
Q: How do you handle transactions in CI operations?
A: Transactions are implicit. When you call Save(), all changes are committed
atomically. If an error occurs, changes are rolled back. To control
transaction boundaries, use the built-in transaction management or
custom PeopleCode around CI calls.
Q: Can you rollback changes after calling Save()?
A: No. Save() commits immediately. To prevent unwanted commits, use validation
and error handling before calling Save(). After Save() completes successfully,
changes cannot be rolled back via the CI.
Q: How do you validate data in a CI before calling Save()?
A: Implement validation in: (1) PeopleCode before calling Save(); (2) CI event
handlers (OnSave event); (3) Backing application class; (4) Field-level
validation rules in the component.
Q: What is the CI_BASE class?
A: CI_BASE is the abstract base class for all Component Interfaces. It contains
common properties and methods like Save(), Find(), Delete(), Fetch(). All CIs
inherit from CI_BASE (directly or indirectly).
Q: Can you extend a CI with custom PeopleCode?
A: Yes. You can add custom methods and event handlers to a CI's backing
application class, or override existing methods to add custom logic.
Q: How do you handle multi-level collections during Save()?
A: Save() saves all levels atomically. It first saves the root level, then
nested collections, maintaining referential integrity (parent key is inserted
before children). If any level fails, the entire operation is rolled back.
================================================================================
SECTION 7: ERROR HANDLING & VALIDATION
================================================================================
Q: What types of errors can a CI raise?
A: (1) Validation errors — field value violates business rules;
(2) Constraint errors — violates database constraints (unique key, foreign key);
(3) Authorization errors — user lacks permission; (4) Data errors — record not
found; (5) Logic errors — application class throws exception.
Q: How do you catch CI exceptions in PeopleCode?
A:
Try
&CI.Save();
Catch Exception &e
If &e.IsA(PeopleCodeException) Then
MessageBox(0, "", 0, 0, &e.Message);
End-If;
End-Try;
Q: What is a CI error message collection?
A: When a CI error occurs, a collection of error messages is returned. Each
message contains details about what failed. You can iterate through them:
Local object &Errors = &e.GetMessageCollection();
Q: How do you check if a CI Fetch found a record?
A: If Fetch() fails to find a record (no matching key), it raises an exception.
Always wrap Fetch in try-catch. Alternatively, some CIs support a boolean
return value indicating success/failure.
Q: What is a "required field" error in a CI?
A: Occurs when a field marked as required in the CI definition is empty when
Save() is called. Fix by populating the field before Save().
Q: How do you validate field values before Save()?
A:
If &CI.OrderID = "" Then
MessageBox(0, "", 0, 0, "OrderID is required");
Exit;
End-If;
&CI.Save();
Q: Can you customize error messages in a CI?
A: Yes. In the CI backing application class, override error handling to provide
custom messages. Alternatively, catch exceptions and generate custom messages.
Q: What is a CI validation method?
A: A validation method is a custom method that checks business logic and returns
true/false. Example:
If CI.GetValidationStatus() = False Then
// Handle validation failure
End-If;
Q: How do you handle CI errors in a web service?
A: In the web service backing PeopleCode, wrap CI calls in try-catch. Catch
exceptions and map them to meaningful SOAP faults or HTTP error responses that
the client can understand.
Q: What happens if a foreign key constraint is violated?
A: The CI raises an error with a constraint violation message. The Save() fails
and no data is persisted. Ensure all related records exist before saving.
================================================================================
SECTION 8: PERFORMANCE OPTIMIZATION
================================================================================
Q: What are common CI performance bottlenecks?
A: (1) Fetching large collections into memory; (2) Excessive database queries;
(3) N+1 query problem (fetching parent, then querying children in a loop);
(4) Loading unnecessary fields; (5) Lack of indexing on key fields;
(6) Poor CI design with deep nesting.
Q: How do you optimize CI Fetch() performance?
A: (1) Fetch only required fields (hide unnecessary fields in CI);
(2) Fetch only required collections (make collections non-exposed if not needed);
(3) Use Fetch for single records, Find for filtered results; (4) Add database
indexes on key fields and foreign keys; (5) Consider fetching in smaller
batches.
Q: What is the N+1 query problem in CIs?
A: Occurs when you fetch a parent record, then loop through children querying
related data for each child. Instead of one query, you run N+1 queries
(1 parent + N children). Fix by fetching all related data upfront or using
join-based queries.
Q: How do you batch CI operations efficiently?
A: Process records in chunks:
For &i = 1 To &RecordList.Count
If (&i Mod 100 = 0) Then
// Process every 100 records
End-If;
End-For;
Q: Should you use CI for bulk operations (e.g., updating 1000 records)?
A: No. CIs are designed for single-record or small-batch operations. For bulk
operations, use SQL directly (ExecSQL, SQL UPDATE statements) or Data Mover.
Q: How do you profile CI performance?
A: Use Application Designer's SQL tracer to see all queries executed. Measure
execution time using &StartTime = %TimeOut and &EndTime = %TimeOut. Log
performance metrics to a custom audit table.
Q: What is CI caching?
A: CI instances are not cached by default. Each CreateComponent() call creates a
new instance. To cache, store the instance in a static variable or custom
cache class.
Q: Should you cache CI instances?
A: Caching can improve performance but introduces complexity around invalidation.
Use for read-only CIs or caches with short TTLs. For writeable CIs, avoid
caching to prevent stale data.
Q: How do you optimize collection access?
A: (1) Minimize collection size — fetch only needed rows; (2) Use indexed access
— avoid linear scans; (3) Build a map for O(1) lookups:
Local map &ItemMap;
For &i = 1 To &CI.ORDER_LINES.Count
&ItemMap(&CI.ORDER_LINES(&i).ItemID) = &i;
End-For;
Q: What is the impact of lazy loading on CI performance?
A: Lazy loading reduces initial load time but can increase total time if many
items are eventually accessed. Implement via custom application classes for
large collections.
Q: How do you minimize database round-trips with CIs?
A: (1) Batch operations — perform multiple changes before Save();
(2) Fetch once, use many times; (3) Use Find instead of multiple Fetch calls;
(4) Avoid nested queries in loops.
Q: What is connection pooling in the context of CIs?
A: Connection pooling reuses database connections across CI operations, reducing
connection overhead. PeopleSoft manages this automatically. No tuning needed at
the CI level, but ensure database pool is sized appropriately.
================================================================================
SECTION 9: INTEGRATION PATTERNS & REAL-WORLD SCENARIOS
================================================================================
Q: How do you integrate a CI with a web service?
A: (1) Create the CI in Application Designer; (2) Create an inbound web service
wrapping the CI; (3) Define service operations (e.g., CreateOrder,
UpdateOrder); (4) Implement backing PeopleCode calling CI methods;
(5) Deploy and expose the service; (6) Document the WSDL/REST API.
Q: What is a typical web service CI integration flow?
A: Client → HTTP Request (SOAP/REST) → Web Service Handler → PeopleCode →
CreateComponent(CI) → CI Logic → Database → Response → Client
Q: How do you handle authentication in web services exposing CIs?
A: Use OAuth 2.0 or JWT tokens. Validate the token before executing CI
operations. Optionally, map the authenticated user's security to verify they
have permission to access the data.
Q: How do you handle pagination in CI-based APIs?
A: Implement pagination in the backing application class:
GetHistoryItemsWithPaging(StartRow, RowCount, &WhereClause)
Returns only requested rows instead of all matches.
Q: Can you expose a CI via REST API?
A: Yes (PT 8.53+). Configure REST handlers to call CIs. REST endpoints can be
auto-generated from CIs or manually mapped for fine-grained control.
Q: How do you version a CI in production?
A: Create a new version (e.g., CI_ORDER_V2) before making breaking changes.
Maintain both versions simultaneously. Clients can request a specific version.
Deprecate old versions on a schedule.
Q: How do you handle CI backward compatibility?
A: (1) Add new optional fields without removing old ones; (2) Support old field
names via aliases; (3) Create new versions for major changes;
(4) Document deprecated fields; (5) Communicate deprecation timelines to
clients.
Q: What is the ideal CI granularity (how many records per CI)?
A: Depends on use case. Typically, one CI per business entity (Order, Customer,
Employee). A CI can expose multiple records, but keep the interface focused
and not overly complex.
Q: How do you handle transactions across multiple CIs?
A: Each CI manages its own transaction. For coordinated transactions, wrap
multiple CI calls in a single PeopleCode routine and handle rollback if any
CI fails.
Q: Can you call a CI from another CI?
A: Yes. A CI's backing application class can instantiate and call other CIs.
This enables composing complex operations from simpler ones.
Q: How do you integrate CIs with message queues?
A: (1) Message arrives in queue; (2) Message handler parses XML/JSON;
(3) Creates CI instance; (4) Populates CI with message data; (5) Calls
CI.Save(); (6) Sends confirmation message.
Q: What is an inbound CI integration?
A: External system sends data to PeopleSoft via web service or file. PeopleSoft
receives it, populates a CI, and saves to database. Example: Vendor sends
invoices to PeopleSoft.
Q: What is an outbound CI integration?
A: PeopleSoft sends data to external system. PeopleSoft fetches data via CI and
publishes it to web service, file, or message queue. Example: PeopleSoft sends
approved orders to fulfillment system.
Q: How do you handle partial updates in a CI?
A: Fetch the record first, modify only the fields you want to change, then Save().
Unmodified fields retain their original values.
Q: How do you implement a "upsert" (insert or update) using a CI?
A:
Try
&CI.Fetch();
// Record exists; update it
&CI.Property = NewValue;
Catch
// Record doesn't exist; create it
&CI.Property = NewValue;
End-Try;
&CI.Save();
Q: Can you call a CI from an external application (Java, .NET)?
A: Yes. Use the PeopleSoft Java SDK or REST API to invoke CIs from external
systems. Configure authentication and appropriate permissions.
Q: How do you monitor CI usage and performance?
A: (1) Log all CI calls to audit table with timing; (2) Monitor database query
performance; (3) Track error rates; (4) Set up alerts for slow CI operations.
================================================================================
SECTION 10: TROUBLESHOOTING & DEBUGGING
================================================================================
Q: How do you debug a CI in Application Designer?
A: (1) Enable PeopleCode Debugger; (2) Set breakpoints in CI backing code;
(3) Use CI Tester to invoke methods; (4) Step through execution;
(5) Inspect variable values.
Q: What does "CI instance is locked" mean?
A: Indicates another user or process is modifying the same record. Wait for the
lock to be released or delete the lock (as admin) if it's stale. Avoid
concurrent modifications to the same record.
Q: How do you trace CI database queries?
A: Use PeopleSoft's SQL tracer in the Tools menu. It shows every SQL statement
executed, including those from CIs. Useful for identifying inefficient queries.
Q: What does "record not found" mean in a Fetch?
A: The CI couldn't find a record matching the key values. Verify the key values
are correct and the record exists in the database.
Q: How do you handle "Cannot find CI_NAME" errors?
A: (1) Verify the CI name is spelled correctly; (2) Check that the CI is
published; (3) Ensure the CI exists in the system; (4) Check that your user
has access to the CI (security role).
Q: What does "Field validation failed" mean?
A: A field value violates a validation rule. Review the CI's component definition
for field-level validation. Ensure the value conforms to expected format and
range.
Q: How do you diagnose CI performance issues?
A: (1) Enable SQL tracer; (2) Count queries executed; (3) Check execution time;
(4) Look for N+1 patterns; (5) Check database indexes; (6) Review collection
sizes; (7) Profile PeopleCode.
Q: What are common CI design mistakes?
A: (1) Exposing too many fields; (2) Deep nesting without pagination;
(3) Loading entire collections unnecessarily; (4) Poor error handling;
(5) Missing validation; (6) Tightly coupled CIs; (7) No versioning strategy.
Q: How do you detect stale data in CI operations?
A: Implement row-level versioning or timestamps. When fetching, compare version
to current version. If stale, reject the update or prompt user to re-fetch.
Q: What is optimistic locking in CIs?
A: Assumes conflicts are rare. When updating, include a version field. Database
check fails if version has changed since fetch, indicating another user updated
the record.
Q: What is pessimistic locking in CIs?
A: Locks the record when fetching, preventing other users from modifying it until
the lock is released. Less common in CIs due to concurrency impacts.
Q: How do you handle CI timeout errors?
A: (1) Reduce collection sizes; (2) Fetch only needed fields;
(3) Increase timeout threshold in system configuration; (4) Optimize CI
performance; (5) Consider database tuning.
Q: What does "insufficient permissions" mean for a CI?
A: User's security role lacks access to the underlying component or records. Work
with security administrator to grant appropriate permissions.
Q: How do you test a CI with invalid data?
A: Use CI Tester to intentionally pass invalid data. Verify that CI raises
appropriate errors. Test boundary conditions (empty strings, null, max values).
Q: How do you log CI operations for audit trails?
A: In CI event handlers or wrapping PeopleCode, insert records into an audit
table containing: timestamp, user ID, CI name, operation (Create/Update/Delete),
old/new values.
Q: What is a CI memory leak?
A: Occurs when CI instances are created but not properly released, consuming
memory. Avoid storing references to CI instances in static or class variables
without cleanup.
================================================================================
SECTION 11: SECURITY & BEST PRACTICES
================================================================================
Q: What are CI security considerations?
A: (1) Verify user authentication before exposing CI; (2) Enforce authorization
via security roles; (3) Validate all input (no SQL injection); (4) Sanitize
output; (5) Log all CI operations; (6) Use HTTPS for web services;
(7) Limit exposed fields to necessary ones.
Q: How do you prevent SQL injection in CIs?
A: Use parameterized queries. Never concatenate user input into SQL strings.
PeopleSoft's parameterized approach is:
&SQL = "SELECT * FROM TABLE WHERE ID = :1";
ExecSQL(&SQL, &UserID);
Q: Should you expose all fields in a CI?
A: No. Expose only fields required by consumers. Hide sensitive fields
(passwords, SSNs) and calculated fields not needed externally.
Q: How do you enforce field-level security in a CI?
A: Configure access permissions on fields in the component. Users lacking
permission won't see those fields even if exposed in the CI.
Q: Can you audit who accessed CI data?
A: Yes. Log all CI reads and writes to an audit table. Capture user ID, timestamp,
operation, and record keys. Query the audit table for compliance reports.
Q: How do you protect sensitive data in transit?
A: Use HTTPS/SSL for web services. Encrypt sensitive fields at rest in the
database (column-level encryption).
Q: What is a CI security best practice for external integrations?
A: (1) Use OAuth or JWT for authentication; (2) Implement rate limiting;
(3) Validate request signatures; (4) Use IP whitelisting if applicable;
(5) Monitor unusual access patterns.
Q: Can you mask sensitive data in CI output?
A: Yes. In the CI backing application class, override field values with masked
values before returning to external consumers. Example: Credit card last 4
digits only.
Q: How do you prevent unauthorized CI access?
A: (1) Require authentication before exposing CI; (2) Check user security role
has access to underlying component; (3) Implement data ownership checks
(user can only access own records).
Q: What is PII (Personally Identifiable Information) in CIs?
A: PII includes names, SSNs, dates of birth, email addresses, addresses. CIs
exposing PII must enforce strong security: encryption, access control, audit
logging.
Q: Should you version your CIs even if not using web services?
A: Yes. Versioning provides stability. Even if using direct PeopleCode calls,
versioning ensures you can modify CI structure without breaking existing code.
Q: How do you document a CI API?
A: Create documentation listing: (1) Properties and types; (2) Methods and
parameters; (3) Collections and nesting; (4) Error messages; (5) Sample code;
(6) Usage restrictions.
Q: What is a CI API contract?
A: An agreement between CI provider and consumer about what the CI exposes, what
parameters it accepts, what it returns, and what errors it can raise. Breaking
the contract requires a new version.
Q: How do you handle CI API deprecation?
A: (1) Announce deprecation timeline; (2) Document the replacement;
(3) Provide migration guide; (4) Support old version for defined period;
(5) Remove in future release.
================================================================================
SECTION 12: ADVANCED TOPICS & PATTERNS
================================================================================
Q: What is a CI application class?
A: A custom PeopleCode class that extends CI_BASE or another CI base class. It
contains custom methods, validation logic, and business rules beyond what the
component provides.
Q: How do you create a custom application class for a CI?
A: (1) Create a new application class in Application Designer;
(2) Extend CI_BASE; (3) Override methods like OnFetch, OnSave, OnDelete;
(4) Add custom methods; (5) In the CI definition, set the backing class.
Q: What is CI method overriding?
A: Replacing a standard CI method (e.g., Save) with a custom implementation.
Allows preprocessing (validation, logging) or postprocessing (external API
calls).
Q: Can you override OnSave in a CI?
A: Yes. Override it in the backing application class to execute custom logic
before the actual save:
method OnSave()
/* Custom validation */
&super.OnSave();
/* Custom postprocessing */
end-method;
Q: What is a CI event handler?
A: A PeopleCode method that executes at a specific CI lifecycle moment: OnCreate,
OnFetch, OnUpdate, OnDelete, OnSave. Use for custom logic (default values,
calculations, external calls).
Q: How do you implement custom validation in a CI?
A: (1) Add validation in OnSave event handler; (2) Return true if valid, false
if not; (3) Populate error message collection if validation fails.
Q: Can you asynchronously call a CI?
A: No. CI calls are synchronous. To achieve async behavior, queue a message that
triggers a process handler that calls the CI asynchronously.
Q: What is a CI factory pattern?
A: Encapsulate CI creation logic in a separate class that returns CI instances.
Useful for complex initialization or CI selection logic:
Local object &CI = ComponentFactory.GetCI("ORDER");
Q: How do you implement CI caching?
A: Store CI instances (or their data) in a static map or custom cache class. Use
cache invalidation strategy to refresh stale data.
Q: What is a CI composite pattern?
A: A CI that wraps multiple lower-level CIs. Useful for complex operations
requiring multiple entities. Example: OrderProcessor CI creates Order,
OrderLine, and Shipment CIs.
Q: Can you use CI in a scheduled job?
A: Yes. Scheduled jobs can instantiate and call CIs just like any PeopleCode.
Useful for batch processing (nightly updates, recurring tasks).
Q: How do you handle CI versioning in a web service?
A: Accept version parameter in SOAP header or REST query param. Route to
appropriate CI version. Support multiple versions simultaneously.
Q: What is a CI adapter pattern?
A: Adapt a CI to provide a different interface. Useful when external API differs
from internal CI structure. Adapter translates between formats.
Q: Can you combine multiple CIs in a single transaction?
A: Yes, but coordinate carefully. Each CI manages its own transaction. If one
fails, others aren't automatically rolled back. Implement compensating
transactions if needed.
Q: How do you test CI error conditions?
A: Mock error scenarios: (1) Database constraint violations; (2) Missing required
fields; (3) Invalid key values; (4) Authorization failures; (5) Timeout
conditions. Use try-catch to verify error handling.
Q: What is BDD (Behavior-Driven Development) for CIs?
A: Write test scenarios in Gherkin language describing CI behavior. Implement
PeopleCode tests that verify the behavior. Useful for complex CIs with many
business rules.
Q: How do you handle CI data migrations?
A: (1) Create data migration CI with transformation logic; (2) Fetch legacy data;
(3) Transform and populate new CI; (4) Validate results; (5) Handle failures
with retry logic.
Q: Can you use CI for real-time analytics?
A: CIs are transactional, not optimized for analytics. For analytical queries,
use SQL directly or dedicated BI tools. CIs can feed data to analytics but
shouldn't be the primary analytics mechanism.
Q: What is a CI for read-only reporting?
A: A specialized CI that exposes only read-only properties (no Save, Update,
Delete). Useful for building reporting interfaces without modification risk.
Q: How do you implement pagination in large CI collections?
A: Use custom methods accepting StartRow and MaxRows parameters. Fetch only the
requested subset from the database. Return metadata (total count, more rows?).
Q: What is a CI health check?
A: Implement a health check method that verifies CI functionality:
(1) Database connectivity; (2) Key data availability; (3) External service
availability; (4) CI instance creation success.
Q: Can you use CI for master data governance?
A: Yes. CIs can enforce data quality rules, validate against reference data, and
maintain audit trails. Combine with workflow for approvals.
Q: How do you implement CI-based APIs with GraphQL?
A: Use GraphQL gateway that translates GraphQL queries to CI calls. Maps GraphQL
fields to CI properties, resolves nested types to CI collections.
Q: What is an eventual consistency pattern for CIs?
A: When syncing multiple systems via CIs, accept that data may be temporarily
inconsistent. Implement retry logic and reconciliation to achieve eventual
consistency.
================================================================================
SQL QUERY EXAMPLES FOR CI TROUBLESHOOTING
================================================================================
Q: How do you find records that may have CI locking issues?
A:
SELECT RECNAME, PROCESSINSTANCE, TEMPTIME, USERID, TYPE
FROM PSLOCK
WHERE RECNAME IN (SELECT DISTINCT RECNAME FROM CI_DEFINITION)
ORDER BY TEMPTIME DESC;
Q: How do you identify CI usage patterns?
A:
SELECT CI_NAME, COUNT(*) as USAGE_COUNT,
MAX(DTTM_LOG) as LAST_USED
FROM CI_AUDIT_TABLE
GROUP BY CI_NAME
ORDER BY USAGE_COUNT DESC;
Q: How do you find all CIs and their backing components?
A:
SELECT CI_NAME, CI_COMPONENT_NAME, CI_VERSION,
EFF_STATUS, DESCR
FROM PS_CI_PROPERTY_TBL
WHERE EFF_STATUS = 'A'
GROUP BY CI_NAME, CI_COMPONENT_NAME, CI_VERSION
ORDER BY CI_NAME;
Q: How do you audit CI creates/updates/deletes?
A:
SELECT USER_ID, OPERATION, DTTM_CREATED, RECNAME, KEYVALUES
FROM CI_AUDIT_LOG
WHERE DTTM_CREATED >= TRUNC(SYSDATE) - 7
ORDER BY DTTM_CREATED DESC;
Q: How do you find slow CI operations?
A:
SELECT CI_NAME, OPERATION, AVG(EXECUTION_TIME_MS) as AVG_TIME,
MAX(EXECUTION_TIME_MS) as MAX_TIME
FROM CI_PERFORMANCE_LOG
WHERE DTTM_LOG >= TRUNC(SYSDATE)
GROUP BY CI_NAME, OPERATION
HAVING MAX(EXECUTION_TIME_MS) > 5000
ORDER BY MAX_TIME DESC;
================================================================================
BEST PRACTICES SUMMARY
================================================================================
1. DESIGN
- Keep CIs focused on a single entity/domain
- Avoid overly deep nesting (limit to 3 levels)
- Expose only necessary fields
- Implement versioning from the start
2. PERFORMANCE
- Fetch only required data
- Use Find() for multiple records, Fetch() for single
- Avoid N+1 query patterns
- Profile and optimize slow CIs
- Consider database indexing
3. SECURITY
- Validate all input
- Enforce authentication and authorization
- Log all operations
- Use HTTPS for web services
- Mask sensitive data
4. ERROR HANDLING
- Wrap all CI calls in try-catch
- Provide meaningful error messages
- Log errors with context
- Implement retry logic for transient failures
- Test error conditions
5. TESTING
- Test CRUD operations
- Test error scenarios
- Test with edge case data
- Test performance with large datasets
- Test integration scenarios
6. MAINTENANCE
- Document CI structure and usage
- Keep versions stable (backward compatible)
- Communicate deprecations in advance
- Monitor CI usage and performance
- Maintain audit trails
7. INTEGRATION
- Use standard protocols (SOAP, REST, JMS)
- Implement request/response validation
- Handle partial failures gracefully
- Implement idempotency where possible
- Provide clear API documentation
No comments:
Post a Comment