Understanding Building Component Interfaces for the Excel to Component Interface Utility
To use the Excel to Component Interface utility effectively, you must have a complete understanding of the component that you are using and the component interface that is built around it. In addition, you should know what data needs to be entered and which fields on the component need to be exposed as component interface properties. Fields that are not relevant for data input should not be exposed on the component interface. This reduces processing time when you are loading data, as well as saving time when you are building the template because no need to delete unnecessary properties on the template will exist.
Some component interface structures will need to be modified before they can be used to load data through the utility. Components that have logic to insert multiple rows in child collections, and then require more values to be set on those collections, will need modification to the component to work with the Excel to Component Interface utility. Change the component so that the logic to insert and partially populate these rows does not happen by default through the component interface.
%CompIntfc and %CompIntfcName can be used so that this logic does not fire either from any component interface or from the component interface that you created for use with the Excel to Component Interface utility.
Additionally, components that have no keys at level 0, but rely on logic at level 0 to load the level 1 collection, cannot be loaded by using the Excel to Component Interface utility.
Component interfaces that rely on CommitWork to save the data cannot be used in the Excel to Component Interface utility.
Prompt and translate table values are validated when data is saved and submitted to the database through the Excel to Component Interface utility. This is different from the behavior on the page when prompts and translates are validated interactively. Some components may use prompts that are dynamically populated. For those situations, you must know what the valid values for the prompt will be.
Note: Remember that any changes made to the structure of a component interface will also need to be reflected in the template. Always ensure that the component interface and the template in the Excel to Component Interface utility are in sync. Structural changes made in only the component interface will cause an error in the Excel to Component Interface utility when data is submitted to the database.
Before using the Excel to Component Interface utility run the component interface through the component interface tester in three-tier mode. Testing the component interface enables you to troubleshoot any problems before running the component interface through the utility. If the component interface does not work in the tester, it will not work in the Excel to Component Interface utility either. The component interface tester is located on the Tools menu in PeopleSoft Application Designer.
The performance of a component interface depends entirely upon the underlying component. If the component has a complex user interface with many pages and scrolls, the component interface generally will have a slower processing time. The best performance times are found with small and medium-complexity component interfaces.
Certain PeopleCode functions and events that are specific to the user interface do not execute through the component interface. You will need to modify PeopleCode for the component, pages, and records when you build the component interface for the component.
PeopleCode events and functions that relate exclusively to the page interface and online processing cannot be used by component interfaces. These include:
Search dialog processing.
Menu PeopleCode and pop-up menus.
Transfers between components, including modal transfers.
Dynamic tree controls.
ActiveX controls.
DoSave and DoSaveNow.
Functions that are ignored in a component interface call.
When you create a new component interface in PeopleSoft Application Designer, the system can create default properties for all the fields exposed on the component interface that meet certain criteria.
When you are creating a new component interface, the following requirements must be met to qualify as a default property.
The fields should be of the following types:
Character
Long character
Number
Signed number
Date
Time
Datetime
The field should be one of the following page control types and must be exposed on the page:
Edit box
Drop-down list box
Check box
Radio button