Life Cycle of a Component Interface
At runtime, there are certain things you want to do with a Component Interface, such as getting an instance of it, populating it with data, and so on. The following is an overview of this process. These steps are expanded in other sections.
Execute the GetCompIntfc method on the PeopleSoft session object to get a Component Interface.
Set the key values for the Component Interface object. If the keys you specify don’t uniquely describe a component (partial keys), proceed to step 3. If the keys uniquely describe a component, skip to step 4.
Do one of the following:
Execute the Find standard method on the Component Interface. This returns a collection of Component Interfaces with their key values filled out. The user can then select the unique Component Interface they want.
Execute either the Get or Create standard method to instantiate the Component Interface (populate it with data.)
Get property values, set property values, or execute user-defined methods. Setting a property value will fire the standard PeopleSoft business rules for the field associated with the property (any PeopleCode program associated with FieldChange, RowInsert, and so on.)
Execute the Save standard method to fire the standard PeopleSoft save business rules (any PeopleCode programs associated with SavePreChange, WorkFlow, and so on.) and commit any changes to the database.
At any point, the standard method Cancel can be executed to reset the Component Interface to its state in step 1.
The keys for a Component Interface are based on the key fields of the underlying component. There can be different types of keys for a Component Interface.
CREATEKEYS: A list of the primary key fields of the search record specified to be used in Add mode for the component. This list is automatically generated.
GETKEYS: A list of the primary (required) key fields on the search record. This list is automatically generated.
FINDKEYS: A list of primary and alternate key fields on the primary search record for the component.
If the Component Interface has CREATEKEYS, these are the keys you must set before you execute the Create() method to create a new instance of the data. If the Component Interface doesn’t have CREATEKEYS, use the GETKEYS to specify a new instance of the data.
Use either the GETKEYS or FINDKEYS to specify an existing instance of the data.
To set key values, use the field names listed under GETKEYS, CREATEKEYS or FINDKEYS like properties on the Component Interface object. The following example sets the CREATEKEYS values to create a new instance of the data.
&MYCI = GetCompIntfc(CompIntfc.EXPRESS_ISSUE); &MYCI.BUSINESS_UNIT = "H01B"; &MYCI.INTERNAL_FLG = "Y"; &MYCI.ORDER_NO = "NEXT’; &MYCI.Create();
Every Component Interface comes with a standard set of methods:
Use these methods during runtime to affect the data of the Component Interface.
The application developer can, at design time, disable any of these methods for the Component Interface.
In addition, an application developer can write their own methods. These methods are written as Functions using Component Interface PeopleCode. For example, suppose you wanted to be able to copy an instance of Component Interface data. You might write your own Clone method.
Note: User-defined method names must not be named GetPropertyName. The C header for Component Interfaces creates functions with that name so you can access each property. If you create your own GetPropertyName functions, you receive errors at runtime. User-defined methods can take only simple types of arguments (such as number, character, and so on) because user-defined methods can be called from C/C++ as well as from PeopleCode. PeopleCode can use more complex types (like rowset, array, record, and so on), but these types of arguments are unknown to C/C++.
Every Component Interface comes with a standard set of properties. These properties can be divided as follows:
Properties that affect how the Component Interface is executed
The following properties affect how a component interface is executed:
These properties must be set before the Component Interface is populated with data. That is, you must set these properties before you use the Get or Create methods.
EditHistoryItems and GetHistoryItems work together to determine how data is accessed:
If EditHistoryItems is False (the default) and GetHistoryItems is True, you access the data in the Component Interface in a similar manner as if you were accessing a component in update/display All mode. This means all history rows are returned, however, you can edit rows only with a date set in the future.
If EditHistoryItems is True and GetHistoryItems is True, you access the data in the Component Interface in a similar manner as if you were accessing a component in correction mode. This means all history rows are returned, and you can edit them.
If GetHistoryItems is False, you access the data in the Component Interface in a similar manner as if you were accessing a component in update mode. The EditHistoryItems has no effect when GetHistoryItems is False.
InteractiveMode causes the Component Interface to emulate an online component. For example, if you set a value for a field in a Component Interface and you have set InteractiveMode to True, then any FieldChange PeopleCode programs associated with that field fire as soon as you set that value.
Properties that return information about the structure of the Component Interface
The following properties return information about the structure of the Component Interface:
Every user-defined property in a Component Interface definition can be used like a property on the object instantiated from that Component Interface at runtime.
For example, the following Component Interface definition has RETURN_DT defined as one of its properties.
At runtime, you can use PeopleCode to assign a value to that property (field), or to access the value of that field.
&MYCI.RETURN_DT = "05/05/2000"; /* OR */ &DATE = &MYCI.RETURN_DT;