List of Functions and Keywords

In the following, the functions and keywords are listed in alphabetical order:
● Action (Business Object)
● Annotation (Business Object)
● Association (Business Object)
● Business Object (Business Object)
● Default Values (Business Object)
● Dependent Object (Business Object)
● Deployment Unit (Business Object)
● Element (Business Object)
● Import (Business Object)
● Message (Business Object)
● Node (Business Object)
● Raises (Business Object)
● Valuation (Business Object)

List of Annotations

In the following, the annotations are listed in alphabetical order:

● Access Control Context (Business Object)
● Alternative Key (Business Object)
● Change History (Business Object)
● Cross Deployment Unit (Business Object)
● Extension (Business Object)
● Label (Business Object)
● Multiple Texts (Business Object)
● Relevant For Access Control (Business Object)
● Separately Lockable (Business Object)
● Tooltip (Business Object)
● Transient (Business Object)
● With Administrative Data (Business Object)

Action (Business Object)

Syntax: action <name> [<Raises>]? ;

Description: Use the action keyword to define an action for a node. Actions carry out the
business logic and are implemented in .absl files.
Example Definition of an action:
action Cancel;
Action definition with raises statement :
action CountHappyDays raises BonusRule.ReferenceInvalid, DateMissing;
Alternative Key (Business Object)

Syntax: [AlternativeKey] element <element name> : <data type>;

Description: If you want to identify a node uniquely with an identifier that can be read by
human beings, you use the AlternativeKey annotation. You can use this identifier in an
association to refer to a business object node. In addition, this identifier is stored as an
additional key field in the database and thus accelerates enterprise searches and queries.
It is not possible to have more than one alternative key of the same type in a business object
node. Custom business objects contain an implicit alternative key of type UUID for each
node, enabling the node to be used as an association target.
Example: [AlternativeKey] element EmployeeID : ID;

Annotation (Business Object)

Syntax: [<annotation>[(<parameter>)]?]
Description: Annotations are used to add a category or property to an object specified by
the subsequent keyword. The names of the annotations are predefined and can be displayed
by the code completion. Technically, you can combine as many annotations as you want. But
not all combinations are possible and not all of them make sense. For more information, see
the list of possible combinations below.
Examples: [AlternativeKey] element EmpoyeeID : ID;
Example with annotation and parameter :
[DeploymentUnit(CustomerRelationshipManagement)]
Businessobject BonusRule{ ... };
Example with two annotations:
[DependentObject(TextCollection)][MultipleTexts] node TextCollection;

Association (Business Object)

Syntax: [ <annotation> ]? association <name> [ <multiplicity> ]? to <composition

path to target node> [using <alternative key>]?;
Description: An association is a relationship between two business object nodes. The
definition of an association includes a name, the multiplicity, a target node and, optionally, a
target element. The target node can be either part of the same business object or part of a
different business object. You can also refer to a target node or element in a different
namespace. Associations are based on a foreign key relationship. The using clause specifies
the key element of the target business object node for the relationship. As a prerequisite,
the key element must be an alternative key and foreign key usage must be allowed for it. The
using clause is optional. For business objects defined in the same project, the target node’s
hidden SAP_UUID element is used. For other business objects, the UUID of the target node
is used. The multiplicity of an association can be either [0,1] or [1,1] . If no multiplicity is
specified, [1,1] is used by default. Only compositions can have a multiplicity with an upper
boundary of “n”. However, you can easily simulate the [1,n] multiplicity by combining a [1,n]
node composition with a [1,1] intra or cross-businessobject association. For more
information about compositions.As a rule, the target node of an association must be located
in the same deployment unit as the current
business object or in the Foundation deployment unit. The path to the target node is
expressed as follows: <namespace>:<business object>.<node>. The path from the root node
of the business object to the target node must not be part of the expression. You can omit
<namespace>, if you have imported the required namespace by using an Import statement
or if the business object is part of your solution. If you leave out <node>, the target node of
the association is the root node of the business object. The following example shows the
possible path expressions of an association in a complex business object:

import Common.DataTypes as CommonDTs;

businessobject BusinessObject1 {
element Name : LANGUAGEINDEPENDENT_MEDIUM_Name;
node Level1 {
element Name : LANGUAGEINDEPENDENT_MEDIUM_Name;
node Level2 {
element Name : LANGUAGEINDEPENDENT_MEDIUM_Name;
node Level3 {
element Name : LANGUAGEINDEPENDENT_MEDIUM_Name;
}
}
}
association A_ToLevel3 to BusinessObject1.Level3;
association B_ToLevel3 to Level3;
}
If the target node is the root node, do not use the target node path in the association
definition. If the target business object is the current business object, do not use the target
business object in the association definition. However, this does not apply if the source and
the target node is the root node of the current business object. You can mark associations as
relevant for access control by adding the annotation RelevantForAccessControl.
Examples:
● Association target within the current business object Item is the name of the composition
from the current node to the Item node.

association MainItem to Item;

Item is the name of the composition from the current node to the Item node. SubItem is the
name of the composition from the Item node to the SubItem node.
association ToSubItem to Item.SubItem;
● Association to different business object

association ToServReq to
AP.CRM.Global:ServiceRequest.ServiceRequestOverview using ID;
association ToBP to AP.FO.BusinessPartner.Global:BusinessPartner
using UUID;
● Using keys and root node as a target node The default key of target root node is used.

association Rule[0,1] to BonusRule;

The key of target root node is specified.

association Material to Product using ProductID;

● Target with fully qualified business object name

association Customer [0,1] to AP.FO.BusinessPartner.Global:Customer

using ID;

● Target with fully qualified business object name using an alias

import AP.FO.BusinessPartner.Global as bp;

association Customer[0,1] to bp:Customer using ID;

● Association marked as relevant for access control

import AP.FO.BusinessPartner.Global as bp;

[RelevantForAccessControl] association ToBP to bp:BusinessPartner;

Business Object (Business Object)

Syntax: businessobject <name> [ <Raises> ]? { [<Message>? <Node>] };

Description: Use the businessobject keyword to specify the name and the nodes of a
business object. A business object consists of a root node, which can contain child nodes.
Even if not specified, the multiplicity of the root node is [1,1]. The .bo file that contains the
business object definition must have the same name as the business object itself. Each file
contains the definition of a single business object.
Example: Business object, message and root node element. The root node raises a specified
message:

businessobject BonusRule raises ReferenceInvalid {

message ReferenceInvalid text "Reference is invalid";
element ItemID : ID;
}

Cross Deployment Unit (Business Object)

Syntax: [CrossDeploymentUnit] association <name> to <path to target node>

[using <composition path to target node>]?
Description: You can use the CrossDeploymentUnit annotation to define an association from
a node of a business object in one deployment unit to a node of a business object in another
deployment unit. Optionally, you can specify the alternative key of the target node with the
using keyword. 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.
Examples: [CrossDeploymentUnit] association ToBusinessPartner to BusinessPartner;
[CrossDeploymentUnit] association ToSalesOrder to SalesOrder using ID;

Default Values (Business Object)

Syntax Basic data types:

element <element name> : <data type name> = <default value>;

Structured data types:

element <element name> : <data type name> = {<component1> = <defaultvalue>, ...,

<componentX> = <default value>};

You cannot use aggregated data types.

Description: Default values are initial values that are used to fill fields automatically when a
new instance is created. The studio supports only static default values such as Boolean
values, status information, numeric values, and free text. There is no syntax check for
default values included in quotation marks. Translation of default values is not supported.
Examples Basic data types:

element Text1 : {content = "14", languageCode = "EN"};

element Text2 : LANGUAGEINDEPENDENT_MEDIUM_Description = "Test Text";
element Date : Date = "2012–11–01";
element Time : Time = "23:59:59";
element Integer : IntegerValue = 12345;
element Code : ActionCode = "01";

Structured data type:

element Amount : Amount = {content = 13.45, currencyCode = "EUR"};

Dependent Object (Business Object)

Syntax: [DependentObject(<dependent object name>)] [MultipleTexts]? node <name>;

Description: A dependent object is a reusable part of a business object that - from a business
point of view – cannot stand alone, but can only be used in the context of the business
object. You can include the TextCollection and AttachmentFolder dependent objects in a
business object definition. For the TextCollection dependent object you can use the
following:

● MultipleTexts annotation to support different text types

● LanguageIndependent annotation to support language independent text

In order to define the dependent object inclusion node, you have to specify a name. You can
either use the dependent object name itself, for example, TextCollection, or add a specific
meaning to the dependent object name, for example,
ProcurementSpecificationTextCollection. If you include a dependent object in a business
object definition several times, you should provide different names for each of the
dependent object inclusion nodes.
You can, for example, use the following syntax:

<subordinate node name> + <dependent object name>, such as ItemAttachmentFolder.

You can add the same dependent object only once to a business object node. If you choose
to add the reuse UI, you need to provide a Type Code to determine the kind of
TextCollection or AttachmentFolder you intend to use. The lists of codes which are
supported are as shown below:

● TextCollection

○ 10001 Additional External Comment

○ 10002 Body Text
○ 10005 Rejection Reasons
○ 10006 Detailed Description
○ 10011 Internal Comment
○ 10025 Reason
○ 10026 Purchasing Note
○ 10027 Sales Note
○ 10029 Approval Note
○ 10047 Error Symptom
○ 10071 Work Description
● AttachmentFolder

○ 10001 Standard Attachment

○ 10006 Certificate
○ 10013 Image
○ 10047 Multimedia
○ 10049 Maps
○ 10051 Webpage
Example: [DependentObject(TextCollection)] node ItemTextCollection;

Example with two annotations:

[DependentObject(TextCollection)] [MultipleTexts] node TextCollection;

Deployment Unit (Business Object)

Syntax: Assignment to a different deployment unit:

[DeploymentUnit(<deployment unit name>)] businessobject <name> [ <Raises> ]? {

<message>? <node>] };

Cross-deployment-unit association:

[CrossDeploymentUnit] association <name> to <composition path to target node> [using

<alternative key>]?;

Description: A deployment unit is a piece of software that can be operated on a separate

physical system, isolated from other pieces of software. The SAP cloud solution is organized
in deployment units that group semantically related business objects, for example,
Customer Relationship Management. There is also a special Foundation deployment unit
that mainly contains master data objects, for example, Material, Employee, and Customer.
Each business object resides in a deployment unit. You can explore SAP business objects
that are released
with the public solution model (PSM) and the deployment units in the Repository Explorer
tool window. For more information, see Repository Explorer 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. You cannot create your own deployment units.
You can directly access business objects that reside in the Foundation deployment unit from
any deployment unit. However, business objects in the Foundation deployment unit cannot
access any business object residing in another deployment unit, not even by using
asynchronous communication. You can only use a query to read the data of this business
object. For all other deployment units the following applies: You cannot directly change the
data of a business object residing in another deployment unit. However, you can read the
data of such a business object by using a query, the Retrieve method or an association. To
change the data of a business object residing in another deployment unit, use asynchronous,
message-based communication. 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.
Example: Assigning a business object to a different deployment unit:
[DeploymentUnit(CustomerRelationshipManagement)] businessobject BonusRule { element
ID : ID;
}

Element (Business Object)

Syntax: [ <annotations> ]? element <name> : <data type name>;

Description: Use the element keyword to define an element of a business object node. The
element name must be unique within the node. The element type can be a simple data type,
for example, ID, or it can be a structured data type such as Amount. You can import data
types from different namespaces. However, you cannot define new data types. When
defining an identifier element, we recommend you use the ID data type instead of the
Identifier data type. The ID data type always has 60 characters, is not structured and does
not contain the Content element. The data type supports, for example, upper case
conversion and alpha conversion. Alpha conversion fills purely numeric user input like “4711”
with leading zeros from the left side to allow better sorting in character fields. For example,
if alpha conversion is not used, an alphabetic sorting would lead to results such as: “1”, “10”,
“100”, “1000”, “2”, “20”, “200”,
and so on. You can define additional properties of an element by using annotations. For
example, the annotation AlternativeKey defines the key element of a business object node.
Key elements uniquely identify a node and can be used to identify the target of an
association. An alternative key, SAP_UUID of type UUID, is generated implicitly for each
node. Therefore, you do not need to define an alternative key for each node. Enclose
annotations in square brackets.

Examples Element with simple type:

element Count : IntegerValue;

Element with complex type:

element Target : Amount;

Key element:

[AlternativeKey] element EmployeeID : ID;

Element with fully qualified type name:

element Recipient : AP.Common.GDT:Date;

Import (Business Object)

Syntax: import <namespace name>;

Description: Use the import keyword to import business objects and data types from
namespaces that are available in the repository. The namespace name is typically a Uniform
Resource Identifier (URI) in dot notation (see example below).
You can use imported business objects and data types in the definition of associations,
elements, and messages. You can reference the imported objects directly by their names
instead of using fully qualified names. If you use a namespace only for one or two sub-
entities, you can omit the import statement and use the qualified name <namespace
name>:<name> instead. If there are no conflicts for any entity in the business object within
all imported namespaces, you can omit the relevant namespace, as the system can identify it
automatically.
If you use more than one namespace in your business object definition, we recommend that
you define an alias for each imported namespace and qualify business objects or data types
from these namespaces by using the aliases. You do not need to import business objects and
data types from the namespace of the current project but you can access them directly by
their names. You can use code completion for importing the namespace as well as for
accessing imported objects, that is, when you select the target business object of an
association or the data type of a node element or message parameter.
Examples Import of a namespace:

import AP.FO.BusinessPartner.Global;

Importing a namespace and defining an alias:

import AP.Common.GDT as apc;

import ESF as esfnsp;

Using the defined aliases:

element duration : apc:Duration;

message ReferenceInvalid text "Reference & is invalid": apc:NumberValue;
association Customer to esfnsp:BusinessPartner;
Label (Business Object)

Syntax: [Label ("<label name>")] element <name> : <data type>;

Description: You can define a label for a business object field. If you then add the field to a
screen, the label is displayed on the screen instead of the field name. You can translate the
label text by exporting it to an XLFF file.
Example: [Label ("My label for field 1")] element ROOT_Field1 :
LANGUAGEINDEPENDENT_EXTENDED_Text;

Message (Business Object)

Syntax: message <message ID> text "<message text>" [: <data type 1>[, <data type2>[,
<data type 3>[, <data type 4>]?]?]?]? ;
Description: Use the message keyword to define a message between two business objects.
The definition of a message includes the message ID, the message text, and, optionally, data
types of up to four message parameters. The parameter names are defined by the system.
The limit for a message ID is 30 characters and for a message text is 73 characters. The
message ID must be unique within the business object; use uppercase for letters. You can
reference data types from different namespaces.
Example Message without parameters:

message DateMissing text "Due date of invoice is missing";

Message with two parameters:

message ReferenceInvalid text "Reference to sales order &1 invalid for &2" : IntegerValue,
ESF:AdressType;

Multiple Texts (Business Object)

Syntax: [DependentObject(<dependent object name>)] [MultipleTexts]? node <name>;

Description: You can use the MultipleTexts annotation together with the TextCollection
dependent object to support different text types. If the TextCollection dependent object is
assigned to the current node, the MultipleTexts annotation defines if more than one text is
allowed.
Example: [DependentObject(TextCollection)] [MultipleTexts] node TextCollection;

Node (Business Object)

Syntax: node <name> [ <multiplicity> ]? [ <Raises> ]? {[ <Element>, <Action>, <Association>,

<Node> ]* };
Description: Use the node keyword to define a business object node and its features, that is,
elements, actions, node associations, child nodes, and raised messages. The name of the
node must be unique within the business object. For the business object, the root node of
the node hierarchy is automatically created. The multiplicity of the root node is [1,1]. Each
direct or indirect child node implicitly contains a ToRoot association. A node must contain at
least one explicitly defined element (not including SAP_UUID, which is implicitly generated
for each node). Elements, actions, associations, and child nodes must have unique names
within
the node. The definition of a child node implicitly introduces a composition, that is, a
relationship between a parent node and a child node. The multiplicity of the child node
defines the upper and lower bound of that composition, that is, how many instances of the
child node can be part of the parent node. The multiplicity of a node can be [0,1], [1,1], [0,n],
or [1,n]. If no multiplicity is defined, the multiplicity [0,1] is used by default. You can use the
composition to access features of the child node from the parent node (for example, in
action implementations). For each composition, the reverse ToParent association is created
implicitly.
SelectAll and ByElements queries are created automatically for each node. It is not possible
to define new queries in the business object.
Example Business object and raises statement for the root node, message definition and
root node element as well as subnode with a raises statement followed by a subnode
element:

businessobject WorkingPlan raises DateMissing {

message DateMissing text "Date is missing";
element ItemID : ID;
node Item [0,n] raises BonusRule.InvalidReference {
element ItemID : ID;
}
}

Raises (Business Object)

Syntax: raises <message ID> [, <message ID>[,...]?]? ;

Description: At least one message ID must follow the raises statement. Following the
message ID, you can enter as many messages as needed. If the message is not part of the
same business object, you must also specify the message group. The name of the message
group is identical to the corresponding name of the business object.
Example :
● Raises statement that raises a message from the same business object:
businessobject BonusRuleOne raises DateMissing {
message DateMissing text "Date is missing";
element ItemID : ID;
}
● Raises statement that raises messages from the same business object and messages with
different message groups
businessobject BonusRuleTwo raises BonusRuleOne.DateMissing {
message ReferenceInvalid text "Reference is invalid";
element ItemID : ID;
node Item raises BonusRuleOne.DateMissing, ReferenceInvalid {
element ItemID : ID;
}
action Count raises ReferenceInvalid;
}

Relevant for Access Control (Business Object)

Syntax: [RelevantForAccessControl[(<parameter>)]?]
Description: To do this, you mark associations as relevant for access control by adding the
annotation RelevantForAccessControl. The following conditions must be met:
● For each business object, you can only use one association that is relevant for access
control.
● The source node of the association must be the root node.
● The target node of the association must be root node of the target business object.
● The target business object must have an association that is relevant for access control. The
target of this association must be the dependent object Access Control List.
● The target business object must support at least one access context. You can find this
information in the Repository Explorer by viewing the documentation of the relevant
business object and by searching for the Supported Access Context section. If this section is
not listed in the documentation, access context is not supported for this business object.

Example: [RelevantForAccessControl] association toBusinessPartner to BusinessPartner;

Tooltip (Business Object)

Syntax: [Tooltip ("<tooltip name>")] element <name> : <data type>;

Description: You can define a tooltip for a business object field. If you then add the field to a
screen, the label is displayed on the screen instead of the field name. You can translate the
tooltip text by exporting it to an XLFF file.
For more information Example [Tooltip ("My tooltip for field 1")] element ROOT_Field1 :
LANGUAGEINDEPENDENT_EXTENDED_Text;

Transient (Business Object)

Syntax: [Transient] element <name> : <data type>;

Description: You can use the Transient annotation to create transient fields. The data in such
a field is not persistent, this means, it is not saved in the database. A transient field is filled
after an AfterLoading event has been executed. The Transient annotation can be combined
with the following annotations:

● Label
● Tooltip

Example:
[Transient] element myTransientField : LANGUAGEINDEPENDENT_LONG_Name;
[Transient][Label("MyTransientField")] element myTransientField :
LANGUAGEINDEPENDENT_LONG_Name;

Valuation (Business Object)

Syntax: association <name> [<multiplicity>] to <target node> valuation (condition

[&& condition]*); <condition> ::= <element of target node> <operator> <element defined in
source node> | <code value> <operator> ::= == | < | > | >= | <=
Description: The valuation keyword enables you to create not only 0,1 and 1,1 associations
but also 0,n and 1,n associations. Thus, you can model hierarchical business object
structures, for example, a product catalog. You can add the valuation keyword to an
association in order to evaluate the elements of a target node. A valuation association must
have the multiplicity [0,1], [1,1], [0,n], or [1,n]. Usually, associations represent relations
between nodes of the same business object or between nodes of different business objects.
However, when you use the valuation keyword, the association must refer to a node within
the same business object. Depending on the node type, the valuation is executed as follows:

● If the association refers to a subnode of a business object, the valuation is executed on the
subnode instances that belong to the same business object instance as the source node
instance (association within a business object instance).
● If the association refers to the root node of a business object, the valuation is executed on
all
instances of this business object (association across all instances of a business object).

The valuation keyword is followed by one or several conditions, which are evaluated when
the
associations are resolved. You define a condition as follows:
1. You specify the target element.
This element must exist in the target node of the association.
2. You specify one of the following comparison operators:
● == (is equal to)
● < (is less than)
● > (is greater than)
● >= (is greater than or equal to)
● <= (is less than or equal to)
● ! (not equal)
If you want to compare two node elements, you can only use the == operator.
3. You define either an element defined in the source node or a code value.
You can use the AND operator (&&) to connect several conditions. Please note that in this
case the OR operator (|) and the NOT operator (!) are not supported.
In a condition, you can specify elements with non-structured data types only. However, you
can use the element path, for example, Amount.content, to use elements of structured data
types.
The valuation keyword cannot be used together with the using keyword and the
RelevantForAccessControl annotation.
Examples Valuation within a business object instance:

businessobject BusinessObject1 { [AlternativeKey] element ID:ID;

node ChildHierNode[0,n] {
element ID:ID;
element ParentID:ID;
association toChild [0,n] to ChildHierNode valuation (ParentID ==ID);
}
}
In the real world, BusinessObject1 may represent a catalog, containing sub-items that are
ordered in a hierarchy (all items belong to the same catalog) Valuation across all instances of
a business object:
businessobject BusinessObject1 {
[AlternativeKey] element ID:ID;
element ParentID:ID;
association toChild [0,n] to BusinessObject1 valuation (ParentID ==ID);
}
In the real world, BusinessObject1 may represent persons or objects (for example, buildings)
that build a hierarchy. Valuation with a code value:

businessobject BusinessObject1 {
[AlternativeKey] element ID:ID;
node CountryNode [0,n]{
element ID:ID;
element CountryCode:CountryCode;
}
association toGermany [0,1]to CountryNode valuation (CountryCode =="DE");
}