One of the key tools that we use with most of our development projects is the Component Interface. Normally, a form is not fully leveraged unless we load the data into PeopleSoft at the end of the approval process. Component Interface is Oracle’s recommended tool to get that data into the system.
This article will give both Functional Analysts and Technical Developers thoughts toward navigating and mastering component interfaces. It will work from functional topics toward the more technical intricacies.
Introduction to Component Interfaces
The most important thing to understand about component interfaces is that they are an automation tool for the end-user interface. Analysts and Developers should treat them as if they are a robot sitting at a terminal entering information into a PeopleSoft browser page.
Practically, this means that In order for a analyst or a developer to understand what needs to happen in the CI, they must first understand how the page works online. Our rule at Gideon Taylor is that the analyst and the developer must both enter a transaction before any coding is done. Taking it a step further, remember that if the end user can’t do it online, the component interface shouldn’t do it either.
The goal of the component interface is to take advantage of all of the validation and business logic already programmed into the system. If the user can’t enter it, the CI program won’t be able to either. if the system is designed to replicate the data to several other tables, the CI program will trigger the same effect.
In Application Designer, the component interface is just what its name implies: it is a programmable interface to the component. In other words, it is a map of the records and fields in the component to properties that a program could access. When looking at the component interface window, the component structure shows on the left. The developer can drag a field from the structure and place it on the panel on the right where App Designer creates a “property” associated with that field.
In order to emphasize the interface responsibilities, the lingo for a CI changes. To help understand them, think of it as the component becoming an API for a program:
- Rowsetbecomes Collection
- Row becomes Item
- Field becomes Property
- Records are not a concept in a CI
The biggest part of a CI really isn’t in the Component Interface definition at all. The CI window is just a mapping. The real work is in the program that uses the CI. This is the important part that the analyst must communicate to the developer and where the developer will spend the most time.
Mapping the Way Through the Forest of Fields
One of the most misunderstood concepts is which fields to update. Many developers will simply allow the component interface to auto define all of the properties. Then, the developer will drag the CI from the project window onto a PeopleCode window. App Designer generates a huge program, and the developer works to populate every property in that huge program so it will save.
The problem with this approach is that the user never updates all of those fields online nor even sees many of them. Remember, the program is automating what an end user would do in the online page.
At Gideon Taylor, the analyst creates a functional specification for the CI. The document contains a table listing the field to change on the page, the field on the form containing the new value, and a sample value to use for testing. The table is broken into chunks and after each chunk is a screenshot of the online page with the fields highlighted.
As the developer codes, the developer should have the page open in the browser. For each field in that document, the developer needs to see which record/field is getting updated. Don’t assume it is the main record. If the user is updating a work record, the CI should also update the work record, not the main record. Remember, if the program does not trigger the same field updates as the user, the correct validation expected may not happen.
For “the rest of the story”, check out next week’s blog post: Comprehending Component Interfaces, Part 2 of 2.
