Understanding the Managed Object Classes

PeopleSoft enables users and application developers to generate PeopleTools definitions for managed objects and database objects by providing PeopleCode classes, methods, and properties. Existing field and record definitions cannot be updated through PeopleCode. Therefore, users and application developers must differentiate between the field and record definitions created through the Application Designer and the definitions generated through PeopleCode. Broadly, we’ll refer to the Application Designer definitions as design time definitions and the PeopleCode-generated definitions as runtime definitions.

Important! The classes, methods, properties, and built-in functions are intended for use during configuration time only, before active runtime usage is initiated. Using these classes, methods, properties, and built-in functions during active runtime is not supported. Changes to managed object definitions are not recognized on currently loaded component. In general, changes aren't recognized until the component is reloaded.

Consider the following before you begin using the Managed Object classes, methods, properties, and built-in functions:

Field and Record Definitions

Managed Object classes are FieldDefn, RecordDefn, RecordFieldDefn where FieldDefn objects are the standalone field definitions, and RecordFieldDefn objects are the fields on the records. FieldDefn and RecordDefn objects can be used anywhere in PeopleCode, that is, in an application class, Application Engine PeopleCode, record field PeopleCode, and so on. If you invoke any of the Save methods, you should ensure that it is invoked from an event that allows database updates, such as:

  • SavePreChange

  • WorkFlow

  • SavePostChange

  • FieldChange

  • Application Engine PeopleCode action

Objects of the Managed Object classes can be declared as component, global, or local variables.

Similar to Application Designer, the Managed Object field and record definition properties are validated when save is invoked to ensure that the properties are used correctly. If validation fails, the detailed error messages are available through the Messages property.

Runtime vs Design Time Definitions

You should not mix the runtime definitions (created through the Managed Object classes) with the design time (created in Application Designer) definitions. For example, you cannot add a runtime field definition to a design time record definition. In order to differentiate the definitions, a read-only property, RuntimeDefn, is added to both the field and record managed objects to indicate how the definition was created. Runtime Definition is displayed on the Field and Record editors in Application Designer.

The following Application Designer rules apply:

  • You cannot add runtime definitions to any design time definition (for example, fields on records, records on components, and so on) with the exception of Projects.

  • Runtime definitions are displayed as read-only.

  • During an import, runtime definitions cannot overwrite design time definitions.

The following Managed Object classes rules apply:

  • Design time definitions can be fetched using the Managed Object classes, but they cannot be saved using the Managed Object classes.

  • Design time fields can be added to runtime records.

Consider using a naming convention to distinguish runtime definitions from design time definitions.

Related Languages

The following restrictions apply with regard to related languages when you use the FieldDefn and RecordDefn classes:

  • Class methods for saving related language data of the definitions is not supported. That is, class methods only support saving base language data.

  • If a user is signed on in a non-base language, the data entered for related language types of fields will be saved to both the base language table and the related language table. For example, if the base language is English and a user is signed on in Spanish, and they enter a record description in Spanish, that description will be saved to both the base language table and related language table.

Records

The RecordDefn class only supports creating SQL views. If a user attempts to save any other type of record, the record is rejected.

Note: Similar to Application Designer record definitions, all record names used with the RecordDefn class should not be prefixed with PS_ although the view that is created is prefixed with PS_.

Consider the following ramifications, depending on the database platform, on SQL views:

  • Existing views will be dropped before rebuilding them. Dependent views may be dropped or invalidated, but these are not rebuilt automatically. Users and application developers should manage the views and rebuild the dependent views.

  • A separate method is provided to build views, that is, views are not built during the save method. It enables users to save their record definitions as frequently as they require and build a view when required.

  • The SQL for the view is validated when the view is saved or built. If the SQL is invalid, the view is not built. The RecordDefn class follows the conventions on creating and building views similar to Application Designer.

Message Catalog

The delivered component interface, MESSAGE_CATALOG_CI, can be used to create and delete message catalog entries, but the message catalog entries that can be manipulated are restricted to non-PeopleTools message sets.

Consider the following when you use MESSAGE_CATALOG_CI:

  • The structure of the Message Catalog component is such that the message catalog entries are a collection within a given message set.

  • Message sets cannot be deleted; only message catalog entries can be deleted.

  • The Message Catalog component interface supports the Component Interface Class methods: Cancel, Create, Find, Get, Save.

  • The Message Catalog component interface can manipulate non-PeopleTools message sets. PeopleTools message sets (1–999) are not allowed to be modified. If you attempt to save one of these, an error is displayed.

  • When creating a new message set, the underlying component automatically generates the first message catalog entry, which must be populated before the new message set can be saved.

  • When adding or updating a message catalog and the user is signed on in a non-base language, the base language tables and the related language tables are updated with the same text.