WebSphere business objects that represent PeopleSoft data can be flat or hierarchical. All the attributes of a flat business object are simple, that is, they represent a single value (such as a String or Integer).
In addition to its simple attributes, a hierarchical business object can have attributes that represent a single-cardinality child business object or an array of child business objects. In turn, each of these business objects can contain single-cardinality child business objects and arrays of business objects, and so on.
A single-cardinality relationship occurs when an attribute in a parent business object represents a single child business object. In this case, the child business object represents a PeopleSoft Collection that can contain only one Record. The type of the attribute is the same as that of the child business object.
A multiple-cardinality relationship occurs when an attribute in the parent business object represents an array of child business objects. In this case, the child business object represents a PeopleSoft Collection that can contain multiple Records. The type of the attribute is the same as the type of the array of child business objects.
The connector assumes that every hierarchical business object represents a single PeopleSoft Component Interface. Although a hierarchical business object may represent data in multiple PeopleSoft Records, the connector assumes that each child business object in the hierarchy represents a single Collection within the Component Interface. The connector uses PeopleSoft's Component architecture and processing (rather than the underlying database) to take advantage of the business logic defined at the Component level.
When you define a business object, the following situations are possible:
Because the connector requires a PeopleSoft Business Component and Component Interface for each business object that it processes, and because the WebSphere business integration system does not provide Business Components, Component Interfaces, or PeopleSoft-specific business objects, you must create these objects to use the connector.
After creating the required objects mentioned above, you can use Application Designer to create the class structure required for the connector to process its supported business objects. For more information, see "Generating APIs".
To assist you in creating these objects, this section includes:
Figure 6 illustrates a simple Component, EMER_CONTACT, which has two Pages and three Records. The illustrated page, PERSONAL_DATA_PANEL1, stores emergency contact information for each employee.
The above graphic illustrates the relationship between data displayed at each level of the personal data Page and the corresponding Record that stores it:
As the EMERGENCY_CNTCT and EMERGENCY_PHONE Records illustrate, each Record's key is a composite that includes its parent's key as well as its own unique identifier.
Not all Components represent data records in the same straightforward manner as the example. For instance, scroll levels do not always correspond to separate Records or child Records. Sometimes a Component uses derived or work Records; sometimes it embeds related display Records; sometimes it uses the same Record to represent data on several of its levels. In these situations, the design of the Component Interface is much more sophisticated than the example, and requires serious consideration of the processing needs.
When working with a complex Component, consider the following areas when designing:
When designing a Component's levels, consider the following:
For example, assume you have a Page that uses three keys from the same Record (such as SETID, DEPTID, and EFFDT). Assume further that this Page uses EFFDT at Scroll Level 1 to return historical data for the given SETID and DEPTID. When you create a Component Interface that contains this Page, it displays all three keys in Collection Level 0 because all key fields exist in the same Level-0 primary Record. If you want to use this Component Interface to return a set of rows with EFFDT as the key, manually remove EFFDT from the Level-0 Collection and add it to the Level-1 Collection. Doing so causes the Component Interface to behave the same way as it does online.
Hidden fields are not always loaded into the Component Processor. Exposing these fields might cause application service errors. It is not recommended that you expose anything to the connector that is not visually exposed on the Page.
Fields marked as Read-Only on the Component Interface are accessible to the connector, but only by the method that returns values. The connector cannot set values in these fields. Therefore, specify the get=FieldName parameter in the corresponding attribute's application specific text, but leave the set=FieldName parameter empty. Specifying the set parameter in such a case causes an error if the method is triggered by an update or create operation.
For more information, see "Application-specific information at the attribute level".
Figure 7 illustrates the example Component Interface (EMER_CONTACT_PROFILE) that contains the EMER_CONTACT Component.
Figure 7. Example
component interface
The three broad arrows in the left margin point to the tables (PERSONAL_DATA, EMERGENCY_CNTCT, and EMERGENCY_PHONE) that store data for the Component Interface. The two narrow arrows point to the key icons that indicate the key fields (EMPLID and CONTACT_NAME) of the EMERGENCY_CNTCT table.
PeopleSoft designed Component Interfaces to expose desired elements of a Component to third parties, making the business process logic (such as the PeopleCode, Field Edits, and PeopleSoft Security) transparent to external integration applications. Therefore, the connector relies on the application for any processing between the Component Interface and the database.
This dependency causes certain limitations, such as the lack of Search dialog processing. Consequently, the SearchInit, SearchSave, and RowSelect events are never triggered, and any PeopleCode associated with them does not run. This limitation also extends to any PeopleCode events that are exclusively related to GUI or online processing, including Menu PeopleCode and pop-up menus.
Therefore, before you create a Component Interface for the connector, verify that no important behavior will be lost, and that all predetermined data is in place before the connector accesses it. You can implement some of this skipped behavior as user-defined methods in the Component Interface or as Component-specific PeopleCode (such as the Pre-Build event). Failure to take these precautions can cause runtime errors.
To enable the connector to process the data represented by the EMER_CONTACT_PROFILE Component Interface, you must create PeopleSoft-specific business objects in the WebSphere business integration system.
Figure 8 illustrates a hierarchical PeopleSoft-specific business object that you can create in the WebSphere business integration system to represent the example Component Interface.
Figure 8. Example
business objects
The PSFT_EmergencyContact business object contains two simple attributes that represent the key field data: EmpId and ContactName. These attributes correspond to EMPLID and CONTACT_NAME in the EMERGENCY_CNTCT Record. PSFT_EmergencyContact also has an array attribute (EmergencyPhone[n]) that represents the array of PSFT_EmergencyPhone business objects.
The PSFT_EmergencyPhone business object contains three simple attributes that represent the key field data: EmpId, ContactName, and PhoneType. The first two attributes serve as keys, uniquely identifying the parent business object. The third attribute uniquely distinguishes the child from other business objects in the same array.