Business objects are classified into categories. For more information, see here.

Each business object belongs to a deployment unit, which is a piece of software that can be operated on a separate physical system, isolated from other pieces of software. For more information, see here.

By analyzing the business scenario you want to model, you determine which processes and objects should be modeled as separate business objects. Information that describes the business object in more detail is modeled as elements within the business object.

To ensure the right naming according to the business semantics, the business object name is constructed / chosen according to ISO 11179 naming standards.

• The names are in British English

• Abbreviations and acronyms are allowed only when used normally within business terms

The internal structure of a business object (BO) is described by nodes, which are connected by relationships. The creation of a node is primarily based on the business understanding of the BO.

For a simple BO, you may decide not to create any nodes, in which case all elements belong to the root node of the BO, which is created implicitly.

A separate node represents a logical / semantic group of elements that can be treated as a group even if the elements could be assigned directly to the higher-level node.

• Elements in one node can be mandatory or optional.

• Elements with multiplicity larger than 1 require a separate node.

• Nodes are related by a strict hierarchical relationship

  • Compositions with multiplicity

  • No n:m relationship

The creation of a node implicitly introduces a composition, that is, a relationship between the parent node and the child node. Compositions can be used to access features of the child node from the parent node (for example, in action implementations). For each composition, a reverse association to the parent node is created implicitly.

A Purchase Order is a buyer’s request to a seller to provide or deliver certain quantities of products at one or several dates.

We can model the purchase order with the following nodes:

• Item – we can have one or more items, so this node is given a multiplicity of [1,n]

• Buyer – the buyer of the goods or services

• Seller – the seller of the goods or services

• Delivery Terms

An object or object node can “play” different roles. You have to decide which roles are important from a business point of view and should be represented explicitly by sub-types.

Analyze all objects and object nodes to determine whether some roles can be merged – this is an indication for the existence of sub-types. Merging the roles leads to generalized objects or components.

In our Purchase Order we can see that Buyer and Seller are two types of the more general component “Party”. There could also be other parties involved in this transaction, such as a Bill To party.

Internal association (also referred to as intra-BO association) enables navigation between nodes that is not provided directly by structural relationships.

Association for Navigation:

• Enables you to create a “navigation shortcut” to facilitate / optimize navigation

• Can be used where the target object node is determined by algorithm (“calculated / derived” relationships):

  • Navigation to multiple instances (“range”) – target multiplicity: [0,n] or [1,n]

  • Navigation to a single instance – target multiplicity: [0,1] or [1,1]

In our purchase order we can use association for navigation to simulate specialization by role.

Once you have defined the business objects and nodes you can assign elements of a particular data type to the nodes.

To homogenize the use of data types, SAP defines global data types that represent business-related content in conformance with widely used Web and business standards, such as DateTime, Amount, Currency, Text, String, and Boolean.

All business objects and service interfaces share the same pool of global data types. For more information, see Data Types.

External association (also referred to cross-BO association) is used to build relationships between business objects. These relationships are classified as aggregations and associations and are described from a business point of view.

Attributes with a name related to another object are replaced by the ID of the referenced object. The attributes are then removed from the current structure and included in the referenced object. This integration produces a local view of the object model.

The Purchase Order business object model contains:

• Party

• Product

• Location

In the element structure these associations are represented by the corresponding reference component.

Business object nodes offer services (operations) that can be accessed using interfaces. Operations and their implementation are generated from the business object definition.

Business logic is added in script coding, which may call operations from other business object nodes.

Core Services

The core services of Create, Retrieve, Update, and Delete ("CRUD") are automatically handled by the studio.

Save

The Save service checks the consistency of the business object and saves to the database. This is automatically handled by the studio.

Create with Parameters

This service creates a business object or business object node instance based on specific input parameters. For example:

• CreateWithReference (for example, create sales order from sales quote)

• CreatePaymentCard (for example, for a sales order)

• Copy

Status actions check the data of the business object and transfer the business object to another status, or refuse the requested status change. For example:

• Release

• Approve

• Complete

The status of a business object can determine which actions are allowed.

A query is a service that returns a list of business object instances based on query parameters. Queries support sorting, paging, and the use of "search engine" indexes.

• Simple queries for all elements in a business object node (QueryByElements) are automatically handled by the studio

• Complex queries can also be created that allow joining over business object nodes and business logic (for example, complex time dependencies)