Structure of Business Objects in SAP Business ByDesign
Business objects basically represent specific entities that are relevant to business. This could be something like a purchase order, a sales order; it could be an employee or an
account, generally a business partner. It could even be some type of activity. It's basically some entity that we want to represent within
the application itself.
Now business objects within SAP Business ByDesign contain what is called a number of
nodes, they contain actions, associations, different elements for each node, and this culmination of these items is basically what represents the object and the behavior that
that object has.
The framework that's in place provides all the typical
CRUD operations for us, to create, read, update, and delete. So we don't have to define these types of operations; the
framework automatically knows what to do with our business objects, and we can worry about the design of them and the specific behavior of that object.
There are many obviously standard objects that are delivered in SAP Business ByDesign. We have objects that we would create partner objects, sometimes called custom objects,
basically, something new that we have defined as developers within the SAP Cloud Applications
Studio.
To build our objects, we're going to use what's called BODL, the Business Object Definition
Language. This is the language that's in place to help us define the business objects and what these
different parts are, and it'll be slightly different than when we get date and time, whoever created it, who's responsible for that order. These types of details might be stored on the header level, or
the root of this object.
Now the object itself can have any structure of nodes you want. So there's always the root
node, but a root node will have sub-nodes, and those nodes could have sub-nodes of their own, etcetera, etcetera. And you can get as
complex as you want here.
For example in this purchase order, we have the purchase order root node and we have a
number of sub-nodes: Item, BuyerParty, SellerParty, and DeliveryTerms.
You can also see that the relationship, the cardinality of these nodes is in place as well.
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 and what the object is being used for.
Now every node itself will have elements. Elements are the attributes of that specific node.
Some type of data. So for a purchase order ID, you'll need an element on the root node that
represents purchase order ID.
It could be as simple as a name of ID, or it could be purchase order ID itself.
00:04:02 When you're naming yours, try to use names that are relevant to what that actual element is.
You wouldn't need to say, let's say, item ID; maybe you just say ID because you know it's on the item node, same as just ID on the
purchase order, but maybe you have an external ID that's coming in that you want to specifically say external
order ID, something like that.
Now every element though will have a name and an associated data type: What kind of data
can be stored in this specific element.
Now there's a large number of data types that are available to us in the application. You can
use the link in this slide to see what all is possible, or in the Repository Explorer, which we'll see in a little bit. But to give an example, on the sales
order root node we have an ID, and that has a type BusinessTransactionDocumentID. This is a very common data type for IDs
within SAP Business ByDesign, you'll see it used a lot in standard objects. Also, for example, OrderedDateTime: This uses the
Global_DateTime data type. That way it gives us a general place to store a date and a time code associated with it.
account, generally a business partner. It could even be some type of activity. It's basically some entity that we want to represent within
the application itself.
Now business objects within SAP Business ByDesign contain what is called a number of
nodes, they contain actions, associations, different elements for each node, and this culmination of these items is basically what represents the object and the behavior that
that object has.
The framework that's in place provides all the typical
CRUD operations for us, to create, read, update, and delete. So we don't have to define these types of operations; the
framework automatically knows what to do with our business objects, and we can worry about the design of them and the specific behavior of that object.
There are many obviously standard objects that are delivered in SAP Business ByDesign. We have objects that we would create partner objects, sometimes called custom objects,
basically, something new that we have defined as developers within the SAP Cloud Applications
Studio.
To build our objects, we're going to use what's called BODL, the Business Object Definition
Language. This is the language that's in place to help us define the business objects and what these
different parts are, and it'll be slightly different than when we get date and time, whoever created it, who's responsible for that order. These types of details might be stored on the header level, or
the root of this object.
Now the object itself can have any structure of nodes you want. So there's always the root
node, but a root node will have sub-nodes, and those nodes could have sub-nodes of their own, etcetera, etcetera. And you can get as
complex as you want here.
For example in this purchase order, we have the purchase order root node and we have a
number of sub-nodes: Item, BuyerParty, SellerParty, and DeliveryTerms.
You can also see that the relationship, the cardinality of these nodes is in place as well.
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 and what the object is being used for.
Now every node itself will have elements. Elements are the attributes of that specific node.
Some type of data. So for a purchase order ID, you'll need an element on the root node that
represents purchase order ID.
It could be as simple as a name of ID, or it could be purchase order ID itself.
00:04:02 When you're naming yours, try to use names that are relevant to what that actual element is.
You wouldn't need to say, let's say, item ID; maybe you just say ID because you know it's on the item node, same as just ID on the
purchase order, but maybe you have an external ID that's coming in that you want to specifically say external
order ID, something like that.
Now every element though will have a name and an associated data type: What kind of data
can be stored in this specific element.
Now there's a large number of data types that are available to us in the application. You can
use the link in this slide to see what all is possible, or in the Repository Explorer, which we'll see in a little bit. But to give an example, on the sales
order root node we have an ID, and that has a type BusinessTransactionDocumentID. This is a very common data type for IDs
within SAP Business ByDesign, you'll see it used a lot in standard objects. Also, for example, OrderedDateTime: This uses the
Global_DateTime data type. That way it gives us a general place to store a date and a time code associated with it.
0 comments:
Post a Comment