SAP Business ByDesign – Business Object

The SAP cloud solutions are built using the concept of Business Objects to model the business environment. So that in this article, we’ll be discussing about the structure of business objects, what business objects are, how are they designed within SAP Business ByDesign, and what are some of the common pieces of them. SAP Byd Business object

SAP Byd Business object

Architecture of the SAP Cloud Solution

The cloud solutions are based on a 3-tier architecture:

1. User Interface
2. Business Logic
3. Persistence Layer (database, search index)

All business logic is implemented in business objects that model real-world objects and processes.

The business object model is the central anchor for script coding, the user interface (UI), forms, and business tasks.
[pullquote]   Changes to the business object may require corrections to scripts, UI screens, forms, and so on. Therefore, when developing a cloud solution, we recommend that you complete the business object design as far as possible before proceeding.[/pullquote]

What is a Business Object?

A business object is a self-contained, independent business concept that is well known in the business world. Typical business objects are Sales Order, Employee, and Product.

Key Points

1. An entity that represents something significant to business
2. Business Object Contains nodes, elements, associations, and actions
3. Framework provides CRUD services
4. Can be standard or partner-based
5. Defined using Business Object Description Language (BODL)

Structure of Business Objects

Nodes

The Business object is built up a number of nodes. Inherently, every object has some type of root node. This is really the header of the object: The main details are stored on here.

Key Points of Nodes

1. A business object is comprised of one or more nodes.
2. Nodes make up a tree-like structure.
3. Each object contains a “root” node and may contain sub-nodes.
4. Each node represents some business semantic.
5. Elements in one node can be mandatory or optional.
6. Elements with multiplicity larger than 1 require a separate node.
7. Nodes are related by a strict hierarchical relationship
   • Compositions with multiplicity
   • No n:m relationship

Example: Purchase Order

We have the purchase order root node and we have a number of sub-nodes:

1. Item – we can have one or more items, so this node is given a multiplicity of [1,n]
2. Buyer – the buyer of the goods or services
3. Seller – the seller of the goods or services
4. Delivery Terms

You can also see that the relationship, the cardinality of these nodes is in place. So we’ll have only one BuyerParty, SellerParty, or DeliveryTerms for the purchase order, but
we’ll have one or more items as part of the purchase order.
And so building up this type of structure will basically generate and create the business object that we want. You may have business objects that are very simple and only have a root node, you may have some that are a lot more complex and have many nodes. It depends on the use case.

Elements

1. Once you have defined the business objects and nodes you can assign elements of a particular data type to the nodes. Elements are the attributes of that specific node.
2. Elements are typed by global data types (GDTs) or core data types (CDTs)
3. All business objects and service interfaces share the same pool of global data types, published in SAP Developer Network (SDN). More information click here.
   

There is a large number of data types that are available in SAP Business ByDesign. In next article, we will see the detailed view of those data types.

Association

An association is a one-way relation between two different business objects.

Key Points

1. An association is a unidirectional relation between two nodes.
2. Each node can be part of the same business object, or different objects.
3. Association naming should be clear to as to what the association represents.

Example

• We have SALES_ORDER and in the root we have the Buyer_ID. We may have an association of the buyer to the actual business partner that exists in the system. So if I know that this person is a business partner in my system right now, and I want them to be the buyer of the sales order, I probably don’t want to copy the data from that buyer into my sales order object.
• It’s excessive, it’s duplication of data, I have to make sure that if it’s updated in the actual buyer business partner that I get that updated into my sales order.
• So to avoid this, we can actually use an association to basically say hey, I know where you are, I have a reference to you, to the business partner object that is this buyer, so if I need any data from you, specifically, I can always just go to your reference and get that data so I always have the most current and up-to-date data and I’m not duplicating anything.
• I may have some other details around the buyer that I want to keep in the sales order that are specific to the sales order, but not the business partner in general, but the associations can allow me to basically reference that data of the other object. We will use associations throughout our scenario: They are very helpful, very useful when you’re building your objects.

Deployment Unit

1. A deployment unit is a piece of software that can be operated on a separate physical system, isolated from other pieces of software.
2. The SAP cloud solution is organized in deployment units that group semantically related business objects, for example, Customer Relationship Management.
3. When a solution is created, the solution has to be assigned to a deployment unit. The business objects that are created subsequently in the solution are assigned to this default deployment unit. If you want to assign a business object to a different deployment unit, use the annotation DeploymentUnit at the beginning of the business object definition.

[pullquote]   You cannot create your own deployment units.[/pullquote]

Example

• Lead and Opportunity are within the CRM deployment unit. Now we can directly create and update data between each other without any additional work.
• If we want to go across deployment units, We have to use an Internal Communication. I can’t directly reference the object to maintain its code. we will be able to read some data from it, but if we want to maintain values in an object in another deployment unit, we will use cross-deployment-unit.
  [pullquote]   You cannot use a cross-deployment-unit association to access a business object in another deployment unit. You can only use a cross-deployment-unit association in an analytical data source to collect data from a business object residing in a different deployment unit.[/pullquote]

It’s a very common use case. It’s not that difficult; maybe just a little different to get used to as opposed to straight coding across, but it allows us to build anything we need to maintain data across different objects.

Foundation deployment

1. This is a special Foundation deployment unit that mainly contains master data objects, For example, Material, Employee, and Customer.
2. You can directly access business objects that reside in the Foundation deployment unit from any deployment unit.

For all other deployment units, the following applies

1. You cannot directly change the data of a business object residing in another deployment unit.
2. You can read the data of such a business object by using a Query, the Retrieve method or an Association.

Syntax

Assignment to a different deployment unit:

[DeploymentUnit()] businessobject
[ ]? { [? ] };
Cross-deployment-unit association:
[CrossDeploymentUnit] association to [using ]?;

Example

Assigning a business object to a different deployment unit:

[DeploymentUnit(CustomerRelationshipManagement)] businessobject
BonusRule {
element ID : ID;
}

We just seen the basic concept of the Business Object. In our next article, we will see the creation of Business Object in Software Development Kit(SDK) and different datatypes in it.

If you want to add any valuable points in this article, please leave your comment and don’t forget to subscribe.