Component Interfaces

Component Interfaces are PeopleSoft's way of exposing the business logic developed into
Components for consumption by other areas of the system. Component interaces are part
of PeopleSoft's Integration Broker technology and an attempt to introduce SOA into the
product. They tend to work quite well but can be slow for large amounts of data
processing.
Please also refer to the component interface development FAQ for development help with
component interfaces.

Creating the Component Interface

PeopleSoft can automatically generate a component interface for you. This can save a bit
of time but it is important to note that it will not be completely correct. You will need to
tweak the create/get/find keys and should ensure that all the scroll 0 properties that you
require have been added.
Also very important is to give your fields and collection scrolls meaningful names - don't
leave them at their defaults which is the record / field names. This is very handy for when
you are coding. It makes referring to data collections so much simpler. A great example
to look at is the delivered USER_PROFILE component interface.
Before going any further, validate your component interface (Tools > Validate for
Consistency). Also double check all the relevant information is in the scroll, particularly,
ensure that the keys on each scroll match what is presented in the component definition.
There's a good reason Application Designer gives you the component and component
interface side-by-side view!
Component Interface Methods
All component interfaces come with a standard set of methods:
Cancel()
Create()
Find()
Get()
Save()
This is a quick summary of what the delivered methods do:
Cancel
Cancels the instance of the component interface object executing this method and rolls
back changes. This closes the component interface and returns its created state. Returns
True if component is succesfully cancelled, otherwise returns False.
Create

This creates (adds) a new set of keys to the component - essentially the same as pressing
add and entering the relevant keys through the component. The created keys are
associated with the component interface object. At this point the CI is instantiated with
the created data. Returns True if data is successfully created, otherwise returns False.
Find
Find allows for a partical key (wildcard) search for data in the underlying component.
Get
Gets the data from the underlying component interface matching on the get keys
specified. The component interface is object is instatiated with the resulting data from the
component. Returns True if data is successfully retrieved, otherwise returns False.
Save
Saves changes made to the component data through the component interface object. The
save method triggers standard PeopleCode Processing. All errors are logged to the
PSMessages collection. Use this collection to troubleshoot errors. Returns True if data is
successfully saved, otherwise returns False.
See PeopleCode Session Class for a better understanding of how to handle errors.
You can override these methods and also write your own. These are stored as methods in
component interface PeopleCode.
Component Interface Tester
PeopleSoft provide a nifty component interface tester with Application Designer. To use
it, open the component interface and select Tools -> Test Component Interface from the
menu. Remember to select the right-hand side (the component interface) of the display,
not the left hand side (component) display.
The first page that pops up in the component interface tester is more or less the
search/add page of the underlying component. I say more or less because component
interface may not necessarily use the same search keys as the component's search record.
Once you enter the search (get) key (or add a new value - create key), you are presented
with the data in the underlying component or the opportunity to enter new data into the
component. Note the checkboxes and what they mean according to PeopleBooks:
Interactive Mode. This access the component in interactive as opposed to [[[deferred
processing]] mode. Typically you would use the mode that suits the way you will be
interacting with the component, but will probably want to avoid interactive mode as it
will additional processing overhead.
Get History Items. This is the equivalent of update/display or correction mode where

effective dated data is involved.

Edit History Items. This is the equivalent of update/display or correction mode with the
ability to modify history data.
Get Dummy Rows. This is selected by default and will return a dummy row when when
the scroll level you are working with doees not contain any data. Dummy rows are a real
nuisance when developing PeopleCode with component interfaces so it is best to have
this unchecked.
Note for component search records that support it, you can use the Find key to find
partial matches.
For a detailed example of how to create a user and update their information using the
USER_PROFILE component interface, take a look at this article
Viewing Component data through Component Interface Tester
The component interface tester is a really great way to think about how you should write
code to work with a component interface because it can display the structure of a
component interface with populated data (much more useful than just looking at the
scroll levels in the component). The example below is for the USER_PROFILE delivered
component interface to the USERMAINT component. Notice the scroll levels:
EmailAddresses
IDTypes
Roles
I've expaneded the roles view to show what is contained in the roles scroll for the user.
There are 3 roles (Roles[1] … Roles[3]) and each is a different role assigned to the user.
Very handy. The scrolls in a component interface are referred to using the terminology a
data collection. A data collection is generic APIObject that acts as a container (or
collection) for other PeopleCode objects. Data collection objects are used to store the data
in a scroll level so that it can be programatically traversed.