To Model a Business Object

This document describes the business object concept and guides you through the process of modelling a business object.

The business object repository (BOR) is a virtual space in which business objects are stored. A business object is an object with a business oriented user interface, that serves as a single entry point to store all the business related data and perform operations on these data.

This document contains the following sections:

  • Integrations Explains why business objects are used.
  • Structure Describes the main elements and properties of a business object.
  • References Explains the use of reference tables.
  • Modeling Process Describes the steps you must take to model a business object.

Integrations

The business object is the primary enabler of integrations between LN and other applications. The business object is a layer between the LN application and an integration party. As a result, the integration party does not address the internal LN functionality directly, but through the entry points of the business object.

This construction has the following advantages:

  • The integration party is not confronted with the technical implementation of the LN functionality, nor with the complexities and limitations that apply on that level. For example, no matter how many tables are required to store the data, all tables are accessible through the business object, while, at the same time, the business object hides these tables, and simply presents the integration party with the entry points to read or store this data.
  • Because the internal LN functionality is not addressed directly, this functionality can be changed without affecting the integration, as long as backward compatibility is guaranteed. For example, the code of a table field can be changed, while the external representation of this field in the business object remains the same. BusinessPartnerAddress remains BusinessPartnerAddress. Of course, an update of the business object is required to link BusinessPartnerAddress to the new table code, but an integration party can still use that name.
  • The user interface of the business object is defined in compliance with international standards, such as OAGIS and RosettaNet. This terminology is understood in the business field and enables a quick recognition of data and functionality.
  • The adoption of XML as communication language between LN and an integration party provides a very flexible and application-independent way to structure the information that is communicated.
Structure

The remainder of this document explains the structure of a business object and the steps you must take to create and model a business object.

A business object has the following 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.

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

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. Refer to Standard/Specific Method for details.

Relations

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

The following relation types exist:

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

Modeling Process

To model one or more business objects, the following steps must be taken. The steps are displayed in a flow diagram. The sessions that are required to perform these steps are mentioned subsequently. Click the links to online Help of the sessions to read more information.

All these sessions are available through the sessions the occur previously in the flow, either by double-clicking a record in these sessions, by clicking one of the tabs in these sessions, or though the Vistas, Referencias o Acciones menu of these sessions.

The first flow provides the overall picture. This flow consists of several actions and sub flows, which are outlined in the sections that follow.

[...]

Fase 1. Create the Business Object

Use the following sessions to create a business object: Start the Objetos de negocio (ttadv7500m000) session, select the package and module in which you want to create the business object, and press New. Session Business Objects (ttadv7100s000) starts, where you can define the basic data of the business object.

Fase 2. Create the Protected Layer

This step is outlined in the following picture:

[...]

Use the following sessions. The sessions are listed in the order in which they occur in the flow, although some sessions may be used repeatedly, while others may not be used at all, according to the conditions specified in the flow.

  1. If the business object has recurring elements, you must define components in the Components (ttadv7117m000) session and the Business Object Components (ttadv7117s000) details session.

  2. Link the tables or forms to the business object:

    • If the business object persistency is based on DAL 2, then link the tables to the business object. If the business object has components, you must link the tables to the business object per component. Use the Tables (ttadv7111m000) session. Besides one or more tables that store the business data, you can define a reference table.
    • If the business object persistency is based on a Session/Form, then the session and, optionally, the corresponding synchronized dialog must be specified per component.
  3. If necessary, define the details of the relation between a business object or component and its tables. The details are defined by specifying conditions on the values of the fields of the tables in the Business Object Component Table Relations (ttadv7134m000) session.
  4. Create the protected attributes in the Protected Attributes (ttadv7104m000) session. If the business object has components, you must define the protected attributes per component. It is possible to generate a list of all possible protected attributes based on the fields of the linked tables.
  5. Create protected methods using the Protected Methods (ttadv7112m100) session. You can either create standard methods or specific methods. Standard methods can be generated automatically based on the definition of the protected attributes. The arguments of the methods are the protected attributes defined in the previous step.
  6. Create the arguments of the protected methods using the Business Object Method Arguments (ttadv7113m000) session. Note that the arguments of the methods are created automatically if you create or save a new method. So, the main purpose of this step is to correct the arguments, if necessary, that were created automatically. The arguments are saved as XSD files (XML Schema's).
  7. If you use components, and all components are defined, together with their tables, protected attributes and protected methods, you must specify the relation type between the components in the Business Object Component Relations (ttadv7133m000) session and the Business Object Component Relation Details (ttadv7132m000) session.
Fase 3. Create Business Object Relations

In the steps described in the previous section, the relation between a business objects and its tables, and the relation between the components of a business objects are already mentioned. A third type of relation exists between business objects. This relation is required to retrieve table field values from tables in another business object.

Use the following sessions to define the relations between business objects.

  1. Relationships between Business Objects (ttadv7520m000) and Relationships between Business Objects (ttadv7120s000) In these sessions you can define with which business objects a relation must exists, and what type of relation this is.
  2. Relationship Details (ttadv7119m000) In this session you can specify the details of the relation, which are defined on the components of the business objects.
Fase 4. Create the Public Layer

This step is outlined in the following picture. Remember that this step is only required if you create a public business object.

[...]

  1. Create public attributes in the Public Attributes (ttadv7114m000) session. You can either create them manually, or generate all possible public attributes. Attributes that are generated are either based on the protected attributes that are linked to a table field, or they are based on the protected attributes that are not linked to a table field. If you generate them, manual correction may be required, either with respect to the number of the generated attributes, or their properties and/or content.
  2. Create public methods in the Public Methods (ttadv7112m000) session. You can generate standard methods automatically. These methods are used for operations on the tables of the business object, such as read or change. These methods actually call the related protected method, which is not accessible directly by external applications. Specific methods must be created and programmed manually. Refer to Standard/Specific Method for details.
  3. Create the arguments of the public methods in the Business Object Method Arguments (ttadv7113m000) session. For public method arguments, the arguments are always a set of standard arguments: Request, Response and Result. However, the content of these standard arguments, which are specified as XSD files, can be edited. The XSD files can be generated automatically. Note that the arguments of the methods are created automatically if you create or save a new method. So, the main purpose of this step is to make the corrections that are often necessary to the generated arguments.

Related topics