Show TOC

Data Objects and TypesLocate this document in the navigation structure

Use

A data object describes data and serves as a data carrier in the context or the result of an expression or an action. Data objects can be further described by their type, namely element, structure, or table.

For an elementary data object, you can define the set of comparison operations that is supported by a particular data object. This is helpful when a data object is used in a comparison against a range expression. If the data object does not support the comparison type in question, the system can determine this mismatch already at design time and thus prevent you from running into problems at runtime.

An elementary data object must have one of the following subtypes:

Element Type

Text (Description)

Text

Character string (maximum length 255 characters)

Note

The maximum length of text data objects refers to the maximum string length that can be stored in the database. In contrast to this limitation for persistent strings, you can use much longer strings as long as they are only used for internal calculations during a BRFplus session. For example, you can concatenate a number of strings to one very large string in a BRFplus formula, then search this large string for a particular string pattern and finally return a formula result (for example, the number of occurrences of the pattern in the large string).

Number

Number with decimals

If a data object is bound to a DDIC data element of type NUMC, the BRFplus data object is automatically set to type text, not number. For more information, see the Type Derivation section in Data Binding.

Boolean

Boolean value

Amount

Number and currency

Note

The number of decimal places of an Amount element is always set to 10 and cannot be changed by the user. This is because this setting is only for formal reasons. At runtime, the actual number of decimals to be used is derived from the central currency tables in the backend, that is, the number of decimals is currency-dependent. Consequently, you can completely hide the formal setting in the BRFplus workbench with the help of the Personalization by choosing Start of the navigation path General Next navigation step Display Next navigation step Show Technical Attributes End of the navigation path.

Quantity

Number and unit of measure

In addition to the mandatory definition of the unit of measure at runtime, you can optionally specify the quantity dimension at design time (for example, length, mass, time). This additional specification has the following effects:

  • At runtime, the system checks if the unit of measure provided is valid for the specified dimension.

  • If data objects with a specified quantity dimension are used in calculations of a formula expression, the system performs additional formula consistency checks to detect semantic errors that could lead to an error at runtime.

Note

Even if there is a predefined number of decimals to be displayed for a particular unit of measure in the central dimension tables, the number of decimals defined by the user for the data object takes precedence over the system default. This is to ensure the transparency of decisions based on quantities. Otherwise, situations could occur where two values that are only slightly different are displayed with the same decimals after being rounded. In such a situation, a user could be confused why the system uses one value and not another one during rule evaluation. To prevent such ambiguities, and based on the fact that BRFplus is a generic tool that is not tailored to the needs of a specific business scenario, BRFplus always displays quantities with the user-defined number of decimals.

Timepoint

  • Local date

  • Local time

  • Local date and time

  • Universal time (UTC) timestamp

  • Local date and time with offset to universal time (UTC)

Note

The first three subtypes listed above are abstract values, i.e., there is no explicit time zone information stored along with values of that type. If you need precise and unambiguous date and time information in your application, you have to use the two UTC-based timepoint subtypes.

For a timepoint data object, it is not required to set the object's subtype at design time. You can leave this part of the object definition open so that the object can hold any valid kind of date and time data. This is useful in scenarios where the particular subtype of an incoming date and time value is not known. However, if you decide to leave the type setting undefined, you have to pay extra attention to objects using the timepoint element because the type-specific consistency checks cannot be applied to a timepoint element without a specified subtype.

Rather than explicitly defining the type of an elementary data object, you can also let an object inherit its type and properties from another object. The other object may either reside in the BRFplus repository or in another repository in the backend system. For more information, see Data Binding.

Structure

The structural relationships between the different types of data objects are shown in the following table:

Data Object Type

Consists of

Element

Predefined data types (see table above)

Structure

Element (0..n)

Structure (0..n)

Table (0..n)

Table

Element (0..1)

Structure (0..1)

According to the relationships shown in the table above, it is useful to know how the different data object types are built upon each other:

  • An element represents a predefined, elementary data type that can neither be reduced to smaller parts nor extended in any way.

  • A structure is a combination of an arbitrary number of elements, of structures, or a combination of both. Especially the fact that a structure can consist of other structures (which again may consist of structures) enables you to model data structures of almost any desired degree of hierarchical complexity.

    Note

    Although from an architectural point of view there is no theoretical limit to structure complexity, the following limitation must be observed for practical use: In case of deeply nested, multi-level structures, addressing a particular field via its name may result in a long sequence of concatenated strings needed to represent the fully qualified name of that field. If such a name consists of more than 255 characters, it can no longer be handled by the tool infrastructure of the ABAP backend system. If this limit is exceeded, code generation is no longer possible for such an object.

  • The fields in a table are defined by either assigning exactly one element or one structure to the table. In other words, the field structure of a table is not implicitly built up by adding one field after another to the table. Rather, the table can only adopt the fields of a structure data object that has been created before. If you choose, however, to assign an element rather than a structure data object to a table, this results in a one-column table (that is, a simple list).

More Information