*
Concepts
*
Tasks
*
Reference

Object Model Customization

Using object extensions, you can create new attributes, enumerated lists, and relationships that you can add to views quickly and easily. Object extensions are custom fields that you can add to any class in APM to collect information specific to your business. Every organization has slightly different needs, and object extensions provide a method to customize the software for your unique data requirements.
To start working with object extensions, you need to select the class to customize. Selecting a class creates a prime class in the CustomerData system. You add your extensions to this class. Once you create object extensions, you need to add those fields to the user interface, either by customizing an existing view or by creating a new one.
You can create object extensions on two types of classes: prime classes or standalone classes. In addition, there are three types of extensions you can create: attributes, enumerated lists, and relationships. If you add other custom extensions from the object model, unexpected results might occur.
Note: When adding object extensions (classes, attributes, and so on), you must create your customizations as an English language user. If you do not create your customizations in English, you might have problems using the custom fields in APM reports. Once your customizations are complete, you can then translate them into other languages.
Before creating any customizations, you should also review the following topics:
•
Customizations and Upgrades
•
Planning Your Customization Requirements

Contents

Prime Classes
Standalone Classes
Join Path to Site
Attributes
Enumerated Lists
Relationships
Validation Rules
Custom States

Prime Classes

To customize an element of the software, you need to create a copy of an existing APM class. This customized version of the class, called the prime class, is then saved in the CustomerData system. The prime class is additive, so whatever you enter in this class will be added to all of the data included in the base class. You cannot delete any elements in the base class. If you do not wish to use a particular attribute or relationship, you can simply remove it from the user interface.
All classes and attributes represent tables and columns in the database. When you add attributes or add or modify views for the class, your custom data will appear in the prime class and columns will be added to the tables in the database. The attributes, relationships, and fields included in the base APM class will not appear in the prime class, and you cannot remove their tables or columns from the database.
TOP

Standalone Classes

Standalone classes are classes that don’t have a base copy in the APM system. The most common use of standalone classes is to create a value list. A value list usually includes an enumerated list of possible choices as well as relationships to one or more existing classes. You can add attributes, enumerated lists, and relationships to standalone classes just as you can to prime classes.
Standalone classes should always be classes of type Persistent, meaning that a table is created in the database for that class. By default, a standalone class will be of type Persistent. Three settings determine the class type: Base Class, Persistent in Table, and Primary Locking Object.
•
The Base Class selector specifies what existing class the new class inherits from and therefore places it at a specific spot in the overall inheritance hierarchy. Every business object must ultimately (that is, either directly or indirectly) inherit from either the Persistent or the Dependent abstract classes in APM. Every class is thus referred to as either Persistent or Dependent, depending on its ultimate base class. Your standalone class should have Persistent as the base class.
•
The Persistent in Table option defines a distinct table in the relational database when set (that is, when the class has schema). Only Persistent objects have schema. Furthermore, classes that are persisted cannot serve as base classes for other classes. They define a leaf in the inheritance hierarchy. Your standalone class should have the Persistent in table checkbox set to True.
•
The Primary Locking Object option defines the locking root of its containment hierarchy. Primary Locking Objects are independently lockable. Only Persistent classes are eligible to be Primary Locking Objects. If a class is not Primary, it is said to be Secondary. The Primary Locking Object designation drives implications into the user interface: Primary objects can be represented either by Primary Views or by Dialog Boxes, but Secondary objects can only be depicted in Dialog Boxes. Your standalone class should have the Primary Locking Object checkbox set to True.
TOP
For more information, see Adding a New Custom Class.

Join Path to Site

All custom classes have as a data member a join path to the top parent class (the Site class). This means that relationships specified in the join path must be mandatory (null behavior is set to Error). Setting this join path ensures that date and time data is converted to the appropriate time zone, the correct site is selected when site security profiles are enforced, and that the correct currency is always selected for currency conversions (EAM module only).
For more information, see Setting the Join Path to Site.

Attributes

An attribute is a piece of information that resides in a class. Attributes can also be referred to as properties or data members of the class. Using attributes, you can collect a variety of information about an object.
Some examples of class attributes are:
•
Asset Number (Asset class)
•
Date Completed (Work Order class)
•
Total Cost in Base Currency (Purchase Order class)
Attributes enable you to collect a wide variety of pieces of information. The type of information that you collect is based on the selected data type. Some examples of available data types are string fields (to enter text), file names (to display graphics), and date and time fields.
See Data Types and Adding an Attribute.
TOP

Enumerated Lists

An enumerated list consists of a set of constant values. Enumerated list attributes are based on either APM or custom enum types. The enum type defines which values are available in the enumerated list.
For example, if your object requires that a user enter a day of the week, you may want to create an enum type for days of the week. At run-time, the user is restricted to selecting one of the values that are defined in the enum type from either a dropdown list or a radio group. Once you create an enum type, you also need to create a new attribute enum type on your custom class. Placing the attribute on the user interface provides access to the enumerated list.
For more information, see Creating an Enumerated List.
TOP

Relationships

A relationship defines the way one class is linked to another class in the object model. When objects are created from classes, they relate to each other based on the relationships set up between the classes in the object model. For example, the Asset class has an “owns many” relationship to the Functional Failure class. This means that when asset objects are created, they can own one or more functional failure objects.
Relationships enable you to link to information in another class. You can create relationships of the following types:
•
References one
•
References many
•
Owns many
•
Hierarchy parent
•
Scopes
Each relationship also has an inverse. For example, the inverse of the References One relationship is called Referenced By.
See Relationship Types and Adding a Relationship.

Deletion Rules

When you create custom relationships, you can also set the deletion behavior of the related objects. For example, if you create a custom relationship from Asset to Employee, you could set the deletion behavior so that the employee reference is nulled out on the asset when the employee is deleted. For more information, see Creating Deletion Rules for Relationships.
TOP

Validation Rules

You can use custom validation rules that determine how lists are filtered and to enforce validation on attributes and relationships. For example, you could set up a validation rule to ensure that the hierarchy code for maintainable assets begins with a specific text string.
Rules can be defined using the object model and can take the form of complicated logical expressions. Rules can have conditions that must be met before the rule is applied (similar to an “If... Then” statement).
You can also create custom messages to be displayed when the conditions in the rule are not met. For example, you might create a message that says “The Hierarchy code for maintainable assets must begin with ‘MA’.”.
For more information, see Creating Custom Validation Rules for Attributes, Creating Custom Validation Rules for Relationships, and Creating Custom Messages.

Custom States

You can use custom states to determine how attributes and relationships (data members) and views are displayed in the user interface or to determine the availability of methods. For example, you could use custom states to make an attribute read-only (that is, not editable) under one condition but mandatory under another condition.
Possible state values for attributes and relationships include:
•
Warning: This option generates a warning message when the attribute or relationship violates the condition.
•
Mandatory: This option generates an error message when the attribute or relationship violates the condition.
•
Read-only: By default, attributes and relationships are editable, but you can make them read-only for your condition.
•
Visible - irrelevant: This option is only available for custom attributes and relationships. You cannot set base APM attributes or relationships to visible - irrelevant.
•
Invisible - irrelevant: This option is only available for custom attributes and relationships. You cannot set base APM attributes or relationships to visible - irrelevant.
•
Not visible: This option hides the attribute or relationship under the specified condition.
Note: If you select Read-only or Not visible as states on APM base attributes or relationships, these states are added to any existing states on those data members. For example, if an APM attribute is shipped with a state of Mandatory and you set a custom state of Not visible, the attribute will have both states. This could result in the situation where a field on an object is not filled in (because it is invisible); however, because the field is also mandatory, users will not be able to save the object. This will not result in data corruption; however, it means that you must test your custom states thoroughly before deploying your customizations.
Note: You cannot use custom states to reduce the compulsoriness of APM base attributes and relationships or to make them irrelevant. That is, you cannot downgrade an APM attribute that is normally mandatory to a warning. You will be able to save downgraded states on data members; however, they will not be applied by the system.
Possible state values for methods include:
•
Enabled
•
Toggled
•
Grayed out
•
Hidden
Possible state values for controls include:
•
Visible
•
Not visible
•
Irrelevant
•
Warning
•
Mandatory
•
Read-only
To determine when states are applied, you will create conditions (similar to validation rules). Conditions are defined using the object model.
For more information, see Creating Custom States.