Should I Re-use An Existing Component Interface (CI) Definition Or Create A New One?

A common question comes up when creating new code against a Component Interface (CI).

Should I re-use an existing Component Interface Object or create a new one?

It depends on your integration scenario. Specifically, if you have an internal PeopleCode program or an external interface like a Java application or a web service interacting with the CI.

Remember that a Component Interface is a wrapper to a PeopleSoft component. This CI provides a programmatic interface to the component in the form of an API. The API can be used to update, insert and read data in the underlying component which will trigger the underlying business logic. A CI definition can be built with limited fields or all fields in the underlying component. You may want to limit some external application to only seeing 3 fields out of 50 on a component. For example, let’s say you have a Visual Basic (VB) Program invoking a CI to look up some Job Data using a CI based on the JOB_DATA component. This VB program may only need access to the person’s department and location data. So you may choose to create a new CI definition instead of using the delivered CI_JOB_DATA object that does not have any salary information on it. This is basically a form of data security. If you create a new limited CI definition then the VB program could never “go rogue” and insert promotions and salary increase or leak employee compensation data.

So here are some guidelines based on if the integration is internal or external to PeopleSoft.

Internal PeopleSoft PeopleCode Integration

If you are writing PeopleCode in Application Engine or some on-line component then you should just re-use any existing CI definition if one exists for that component. Why?

• If the component changes as a result of a bundle or code change, there is the potential that the CI will become invalid. You should only have to update one CI instead of several to fix the invalidation.
• Having one CI definition for a component equates to less security updates because every user invoking the CI needs a permission list with the proper security.
• PeopleCode already has full access to any data in the system so creating a “limited” CI serves no data security purpose because PeopleCode has direct access to the database tables.
• With one CI, it is easier to research the ramifications of changing the underlying component structure.
  • For example, if you move a field from a header to a child record, it is less work to figure out all the PeopleCode that is referencing that header field via a component Interface.

External Program invoking a CI

If you have an external program like VB or Java invoking a CI either by directly connecting to the application server or via a web service then you may want to consider creating a new CI definition. Creating a new CI for this purpose will:

• Gives you more fine grained control over exactly what data is exposed to the 3rd party.
  • If the third party should not be reading salary information then create a CI definition and remove all salary related fields from the “left hand side” of the CI definition.
• Gives you the ability to change the CI property and Collection names to something that makes more sense to the third party.
  • For example, the default property name for the department id is: DEPTID. However, the third party may really want it named PSFT_HR_DEPARTMENT_ID. You should not rename properties on delivered CI definitions.