Business Objects

A business object is defined by its properties, stored in a business object definition. These properties control how the object is identified and how it operates. When you create a business object, you define fundamental properties such as name and purpose. Then you can define more complex properties such as indexing and AnnotationA tag on a business object, business object group, business object relationship, or field identifying the item as a valid target. It is a property that identifies the purpose of the item so that other applications (for example, the FrontRange application, the FrontRange Administrator, integrated applications, FrontRange extensions, etc.) can identify or use that item.s, and modify existing properties by editing the business object. See Tabs for a description of these properties.

You can access business objects in three ways:

• To see the common business objects, such as change, problem, knowledge, release, incident, and service request, go to the Configuration Console and click Build > Business Objects. The Business Objects page appears. Click a business object to view its features.

Business Objects Main Page

• To see other business objects, besides the common business objects, in the Find box, type the name of a business object (for example, employee), then click Go. Select your business object from the list that appears.

• To view all of the business objects, click View All. The business object name is the name of the object stored in theHEAT database and the display name is how it appears in the HEAT application. Click a business object to view its parameters.

From this page you can also do the following:

• Create a Business Object: See Creating a Business Object.
• Manage Validation Objects: See Using Validation Business Objects.
• Manage Object Workflows: See Using Workflows.
• Manage Counters: See Using Counters.

A business object is stored in the HEAT database as a table. Within the table are fields for tracking information. Some of these fields are system fields that are generated when you create the business object. You can manually create fields to track industry-specific information. The actual business object definition is stored in a HEAT system table.

Business objects store sets of data called records. Each record is of the same type as the business object that stores it. For example, employee records are stored in the employee business object and notes records are stored in the notes business object. As a result, a record (such as Profile.Employee) is subject to the same rules as the business object (such as Journal.Notes) that houses it. For example, a record housed in a business object can be a parent or child in a relationship.

Records are member objects in a group.

HEAT includes several default business objects, designed for your business needs. As a system administrator, you can use these objects, edit them, delete them, or create your own. Some definitions are restricted to prevent the modification or removal of required items. You may be limited in how you can customize some business objects. Your role determines which business objects you can customize.

A business object relationship lets two business objects collaborate through the records housed in the objects. In a relationship, business objects can belong to other business objects or simply be associated with other objects.

Business Object Relationships

Each relationship contains a:

• Parent object: The center of a relationship with one or more child objects.
• Child object: The supplier of additional data to a parent object.
  

For example, an incident business object can have a relationship with a notes business object so that you can track notes pertaining to a specific incident. Incident becomes the parent to notes (Journal.Notes), the child object.

When you create a business object relationship between two business objects, you define the fundamental properties which tell the relationship how to operate.

Plan a relationship before you create it. Thoughtful design can alleviate complications.

Some business object relationships are restricted to prevent the modification or removal of items required by the system. The ability to create relationships is restricted by role. The default constraint (ParentLink field) can only be used in one relationship. Relationships using the ParentLink field allow the child object (for example, Journal.Notes) to be part of several parent objects (for example, incident and problem).

Relationship Syntax

A relationship string is used to specify a field, business object, or group of business objects. A relationship string is defined in the context of a specific base business object.