Structure of a Business Object

A business object has these elements:

Header

The identification data of a business object.

Components

Components can be used to structure a business object. However, the rule is that business objects are as flat as possible. The only exception that allows a structure is the occurrence of recurring elements, for example, order lines that occur repeatedly. Note that, if components are used, the tables, protected attributes and protected methods are defined inside the components.

Tables

Because the information that is accessible through the business object is often stored in tables, the business object must be linked to one or more tables. Besides tables that store business object information, a reference table can be used to store references from an external application to the business object. These references are stored to prevent that business object information is deleted, while it is still required by an external application.

Attributes

The attributes are the entry points for the business object data. The attributes are often linked to a table field, but they can also represent a calculated value, or have a value that is not related to any table field.

Methods

Methods perform operations on the business object attributes, such as reading, changing, or calculating an attribute value.

Relations

Several types of relations exist inside business objects, between business objects, and between business objects and tables. Relations are important for the structure of the a business objects and its information channels.

Public vs Protected An important difference exists between public and protected business objects, and the public and protected layer within a business object. Business objects are always either protected or public. If they are protected, they have only a protected layer. If they are public, they have both a protected layer and a public layer. The protected layer consists of protected attributes and protected methods, while the public layer consists of public attributes and public methods. The protected layer can only be used by LN itself. The public layer can be used by an external application. So, an external application can call a public method, but not a protected method. The protected layer can also contain links to tables and other business objects.

Header

The header of the business object specifies the identification data, the VRC in which the business object is stored, whether the business object is expired, a description, and the business object type.

The identification data consist of the following elements:

• The business object name, which must be meaningful in the business area. For example, BusinessPartner.
• Package/module codes. Because a business object is modeled for a package/module combination, these data are also present.
• A three-digit identification code used to identify the business object within the package/module combination.

The business object type is either protected, or public, or proxy.

Components

A business object has components if the business object has recurring elements. For example, the PurchaseOrder business object has one order header, and a number of order lines. This structure is defined by using a component for the order header that has a one-to-many relation to the component for the order line.

Because components are a kind of group boxes, their most important features are the name and the relations they have with one another. The components do not store other important business object information themselves, but they provide a framework in which other information storing elements are defined, specifically, the tables that are linked to the business object, the protected attributes and the protected methods.

Because components can only occur in the protected layer of a business object, only protected attributes and methods can be defined in a component. Public attributes and methods are always defined in the business object itself. The details of the relation between components are specified on attribute level.

Tables

Most of the business object data is stored in tables, and can be accessed through the business object attributes. Before the attributes can be linked to a table field, the table concerned must be linked to the business object.

If the business object has components, the tables must be defined per component. The reason for this rule is that only protected attributes can be linked to a table, and protected attributes are defined per component, if the business object has components.

You must define one root table, which is the table that contains the primary key of the business object or component. In addition, other tables that store important information can be specified. However, you must not specify each table whose fields are required, but only those tables that really belong to the business object.

The value of a field that occurs in another, not specified table, can be retrieved (or changed) by means of a link to another business object in which that table is specified, and to the attribute of that business object that provides access to the field in question.

If the business object is public, it can have a reference table, which is used to store references from external sources to the current business object. As long as a reference exists, that is, as long as the reference table stores a reference from an external source to an attribute of the current business object, it is not allowed to delete that attribute.

If a reference table is used, the business object requires several specific attributes and methods, which can all be generated automatically.

Attributes

Attributes are entry points to store information.

Attributes are defined for the business object or for a component, and they are either public or protected. If a business object has components, the protected attributes must be defined per component.

Attributes can derive their value from a table field, from a calculation based on one or more table fields, or from a non-table field related source. The source from which the attributes derive their value is specified in the Map Operator field. If an attribute is based on a calculation, this calculation must be programmed manually.

An attribute has a domain and a data type. The domain specifies the format of the value. If the attribute is linked to a table field, the domain will often be that of the table field. The data type is actually part of the specification of the domain.

Attributes can also have the following properties:

• Read-only The value of the attribute cannot be changed directly.
• Mandatory The attributes must have a value.
• Identifying The attribute is part of the key of the business object or component.
• Default available A default value is available for the attribute. Note however, that only public attributes can have this property.

Methods

Methods operate on the business object attributes.

Methods are defined per business object or per component, and they are either public or protected. If a business object has components, the protected methods must be defined per component.

Dependent on the type of behavior, a method is a standard method or a specific method:

• Standard methods implement a behavior that is generic for all business objects, like Creating, Deleting, or Changing a business object instance.
• Specific methods implement a specific behavior for a particular business object only (or for a small group of business objects).

Standard methods can be generated by LN itself, based on the available attributes. Specific methods must be programmed manually. For details, see the online help of the Standard/Specific field in the Public Methods (ttadv7112m000) session.

Relations

To model a business object properly, the relations between the various business object related entities are very important.

The relation types:

• Business object relations Business objects are linked together to enable you to link attributes of these business objects to one another. This way you can retrieve information from another business object. The link to other business objects is made in the protected layer of a business object.
• Component relations Components are linked together in a business object to specify the relation type they have to one another. On a detailed level, the components are linked together through relations that are specified on the attributes.
• Table relations To link table fields to the protected attributes of a business object or component, the tables must first be related to the business object or component of these attributes. On a detailed level, it is possible to specify a filter on the relation between a protected attribute and a table field. In that case, the relation is only valid if certain conditions are met, for example, if another table field has a specific value. For reference tables, the reference table must only be specified. Because the reference table is fully standardized, even a non-existing table can be specified, in which case the table will be generated automatically.

References

Because business objects are used for integrations with other applications, you are not free to delete whatever business object information you want. Deleting information that is required by an external application can cause problems for that application. To prevent such problems, you can define a reference table for your business object. A reference table stores references from an external application to the business object. You can only delete information for which no reference exist in the reference table. External applications can access the reference table by calling a set of standard methods, which operate on a set of attributes that are linked to the reference table. Refer to the Help on the Tables (ttadv7111m000) session for more information.