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:
This is a quick summary of what the delivered methods do:
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.
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 allows for a partical key (wildcard) search for data in the underlying component.
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.
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:
I've expaneded the roles view to show what is contained in the roles scroll for the user. There are 3 roles (Roles … Roles) 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.