Structure of a Business Object

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.

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 business object type is either protected, or public, or proxy.

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 which 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.

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 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.

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.

Standard methods can be generated by LN itself, based on the available attributes. Specific methods must be programmed manually. Refer to Standard/Specific Method for details.

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

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.