Data Binding 
Data objects can be bound to elements in the ABAP Data Dictionary (DDIC) or to the global data types (GDT) in Enterprise Service Repository (ESR). In addition, you can also bind an elementary data object to an already existing BRFplus data object. This enables you to implicitly define a data object's settings, as opposed to explicitly assigning a data type to a data object, manually creating a value list for it etc.
In simple use cases where you just need a field that, for example, can hold a string for an intermediate result during rule processing, it is normally the easiest way to define the data object manually. However, when you have to handle complex data structures that are already defined in a different repository, then binding a BRFplus data object to such an already existing element is an effective way to accomplish this in a consistent and fast manner.
The advantages of using data binding are not restricted to complex structures. There are also use cases where binding a data object to a simple DDIC data element can save you a lot of work. For example, if you need to access a list of ISO country codes, you would just look up a data element in the DDIC that is used for the same purpose and has the country codes already assigned as a list of domain values. After binding the BRFplus data object to that data element, you are done: The data object has the same data type and field length as the bound data element, and all the domain values are made available to the data object.
Data binding can also help you keep your system consistent in cases where you have one or more fields that are reused at many places throughout your application. The following example shows what binding can do for you in such a scenario:
Example
The name of customer company Akron Heating Inc. shall be used in your BRFplus application at a number of different places. If you have to change the name from Akron Heating Inc. to Akron Heating Ltd., this change has to be done at all these places for reasons of consistency. By binding the data object, you can avoid such repetitive and error-prone tasks.
Create an element data object Company_Name of type text with a length of 30 characters.
On the Domain Values tab, choose Create Value.
The system displays a dialog for defining a constant expression for the name string.
Define a name for the constant and enter the company name Akron Heating Inc. into the Value field.
Click the Create button.
The system navigates back to the Company_Name data object and displays the newly defined company name in the Value List on the data object's Domain Values tab.
Create another element data object named Customer_Name.
Instead of explicitly defining a type for the new data object, choose Current object should be bound from the Binding Definition list.
From the Select Binding Type list, choose Bind to existing BRFplus element.
The system presents the Object Query dialog.
In the Object Query dialog, look up and select the previously defined Company_Name.
The system navigates back to the Customer_Name data object that is now bound to the Company_Name data object.
Click Create and Navigate to Object.
The system navigates to the newly created Customer_Name data object. On the data object's Domain Values tab, you can see the company name Akron Heating Inc. that is inherited from the definition of the bound data object.
You can now start populating your application with the Customer_Name data object wherever this entity is needed. Once you are done, change the associated text constant's value from Akron Heating Inc. to Akron Heating Ltd.. The new name is visible at all places where you have used the Customer_Name data object.
Features
Supported Binding Types
Depending on the type of the BRFplus data object that you want to bind to another element, you have different possibilities. This is explained in the following table:
Data Object Type |
Supported Binding Types |
Comment |
|---|---|---|
Element |
DDIC object GDT BRFplus element |
|
Table |
DDIC table type |
Table type structure with all contained fields is imported automatically into BRFplus |
Structure |
DDIC structure GDT structure |
DDIC structure with all contained fields is imported automatically into BRFplus |
Note
Binding BRFplus objects to GDTs is currently only supported for a limited scope of SAP-internal development projects. This feature is not supported for external applications.
Type Derivation
When you bind an elementary data object to a dictionary type, the system determines the dictionary type and adjusts the subtype of the BRFplus data object such that it matches best the bound dictionary type. While this sounds trivial for basic dictionary types like CHAR or INT1,
there are also some more sophisticated cases. For example, the BRFplus elementary type Boolean has no direct corresponding elementary type in the data dictionary. Here, data elements used for boolean purposes are set up by referencing a one–character domain of type CHAR with
two, sometimes three, fixed values. For a derivation of a BRFplus data object of type Boolean, the bound dictionary element must fulfill the following conditions:
Elementary type:
CHAR1Domain: Exactly two values defined: '
X' (True) and '' (False).These two conditions are fulfilled by the standard domain
BOOLE.As an alternative, BRFplus does also accept the standard data element
SYBATCHas a valid binding reference for a Boolean data object.
Another example of a type derivation that may be surprising at first sight is the handling of the widely used built-in type NUMC. Although this type accepts only digits from 0 to 9, it is still technically designed as a string of number literals. Therefore,
a NUMC field in the dictionary is always converted to an elementary data object of type text (not number) during data binding. As a consequence, within BRFplus, such fields cannot be used for mathematical operations like SUM or AVERAGE in a formula
or table operation expression.
Domain Value Lists
Most of the business-specific data elements in the dictionary have a domain object assigned. The domain is then used to define the data type of the referencing data element and a number of technical settings. In addition, a domain can provide a predefined list of values for the referencing data elements. Value lists can be defined in different ways:
Single Values: A list of single fixed values (for example, 1, 2, 3, 10, 20, 30, ...).
Intervals: A list of value ranges (for example, 'a'..'f', 'h'..'m', 'x'..'z', ...).
Value Table: A reference to a dictionary table where each table entry serves as a value for the referencing domain.
In addition to the domain values itself, the system lets the developer maintain a descriptive text for each value. An application can take advantage of this by using unique technical values stored in the value field while presenting the business-oriented descriptive text to the user.
When you bind a BRFplus data object to a data element in the dictionary, the system imports the domain values and presents them on the Domain Values tab in the BRFplus workbench. In addition, the system tries to import the descriptive texts associated with the values. Here, the system behavior differs with respect to the different ways of defining the texts:
Single Values:
The system imports the descriptive texts as defined in the domain definition.
Intervals:
For intervals, the system does not import any descriptive texts. This is because in this case, descriptions can only be associated with each defined interval as a whole, but not to the individual values within each interval.
Value Table:
The system analyzes the associated table in order to determine a field that is likely to be meant as the description field for the values. Among others, the following criteria are tested by the system to find out if a particular field is a candidate for descriptions:
Field type is Text.
Field length is 15 characters or more.
Field name contains 'DESC', 'DSCR', 'NAME', 'TEXT', or 'TXT' as a substring.
The first field that matches all of the above criteria is considered to be a value description field, and the system imports the field contents as value descriptions for the BRFplus data object. If none of the table fields matches the criteria, no value descriptions are associated with the data object's domain values.
Note
In the BRFplus workbench, only the first 500 domain values are displayed. This is to avoid performance problems in case of very large value lists. At runtime, however, you can of course access all the domain values that have been defined in the dictionary for the referenced data element.
Inheritance
Data objects inherit their attributes such as data type, allowed comparisons, or field length from the bound type. Value help for data objects is implemented by binding a data object to the data dictionary (DDIC) or a BRFplus data object with a defined list of domain values. Binding an elementary data object to the DDIC or to ESR enables you to reuse a list of values that has been defined in the distant repository.
Of course, a data object can only inherit attributes that are available in the bound data object. For example, a data object inherits the type of a bound DDIC object whereas the setting for allowed comparisons of the data object is not inherited and can still be defined for the inheriting data object directly. This is evident because a DDIC object does not support the concept of allowed or restricted comparison operations.
If you bind a data object to another BRFplus data object, be sure that the other data object has explicitly defined attributes rather than being bound to a third data object itself. This kind of cascading inheritance over more than one level is not supported and leads to an error message.
In contrast to this, however, it is possible to bind one BRFplus data object to another data object that is bound to a DDIC object. In this case, the attributes of the DDIC object are inherited by the involved BRFplus data objects on both levels.
Constraints
Binding data objects to GDT structures is only supported for systems that have been defined as AP (Application Platform) systems using the Switch Framework.