Show TOC

Background documentationCreating Objects

 

In BRFplus, you create objects of all kinds to model the business rules that shall support your decision making in the use cases of your everyday business. You can create objects in different ways. Depending on the situation, different implications may apply.

 

General

All BRFplus object types provide a set of administrative data that consists of the same attributes. Most of these attributes are specific for each individual object, but some of them depend on the application object to which an object belongs. These dependent attributes are:

  • Strict dependency

    The following application attributes are inherited by all objects that you create in the context of an application and cannot be changed on object level:

    • Storage type

      With the storage type, you control whether an object is treated as a system object, a customizing object, or a master data object. You define the storage type of an application and all of its objects when you create the application. There is no way to change this setting afterwards, neither for the application itself nor for the objects that belong to the application.

    • Local vs. transportable objects

      For an application, you must define the package to which the application belongs. The transport behavior of the application and its objects is determined by the transport settings of the assigned package. Theoretically, you could change the transport behavior of the BRFplus objects by assigning a different package to an application. However, in most cases, such a change has far-reaching effects and is therefore not recommended.

  • Loose dependency

    The following application attributes are inherited by all objects that you create in the context of an application, but can be changed for each object individually:

    • Application log settings

    • Versioning behavior

    • Language and version dependency of object texts and documentation

Save, check, activate

Once you have maintained and saved the mandatory data for a newly created object, you can continue your work. It is not necessary to maintain all possible settings at once. However, keep in mind that many object types require detailed settings to make them ready for productive use. The system helps you to detect any missing or incomplete settings with the built-in check routines for each object type.

Example Example

You create a decision table expression with 10 condition columns and hundreds of rows for the different combinations of condition values. At first sight, the table seems to cover perfectly the business case that you have in mind. However, the check may remind you that the data objects you have used in the condition columns have been taken deliberately from the repository rather than from a function context that is needed for proper operation. Therefore, the decision table may be consistent and complete in itself but still cannot be activated as long as the table is not connected to a function providing all the data objects used.

End of the example.

You can check an object either explicitly with the Check button or implicitly with the Activate button. The system then runs all the check routines defined for the object type in question. If the checks detect any errors or inconsistencies, the system displays a message. Many of these check messages have a long text attached with detailed explanations of the problem and possible solutions.

Many object types in BRFplus contain references to other objects. If you try to activate an object containing such references, the system determines whether there are any inactive objects among the hierarchy of used objects. If so, the system offers to recursively drill down the object hierarchy and activate all inactive objects it may find. This is a prerequisite for the top level object to be activated successfully.

If any of the subordinate objects cannot be activated, the process stops with an error message. If this happens, we recommend that you thoroughly read the message explanation text to find out where exactly the problem occurred, since this is not always obvious.

Usage Consistency Check

In addition to those checks that are defined to detect any inconsistencies in the object definition, there is another check type available, namely Usage Consistency Check. With this check, you can let the system check whether an object that you are currently maintaining is used by any other objects, and if there are any problems with respect to these usage relationships, or with respect to the using objects. Of course, this check only makes sense for objects that are used by other objects and is therefore normally not relevant upon object creation time.

To perform this check, open the desired object in the work area of the BRFplus workbench and choose Start of the navigation path More Next navigation step Usage Consistency Check End of the navigation path.

Example Example

An element data object of type text has been defined with a maximum text length of 20 characters. This data object is used as the result data object of a decision table expression, where a number of different result strings has already been defined. If you reduce the maximum text length of the data object to only 10 characters, and if there are result values in the decision table exceeding this reduced maximum text length, the usage consistency check would make you aware of this potential problem.

End of the example.

Note Note

When the usage consistency check traverses the data model, it may also find objects that are using the current object, but reside in a different system client. For using objects of this kind, the system cannot perform any further checks. However, the system makes you aware of the fact that there are affected objects in other clients and leaves it up to the user to run the same check in these clients.

End of the note.
Manual Creation vs. Programmatic Creation
Creating objects manually

The usual way to create BRFplus objects is to create them one after another in the BRFplus workbench. You can accomplish this in any of the following ways:

  • Repository view

    In the Repository view, right-click any category node or object type node. In the context menu, choose Create. The system then presents the types of objects that you can create in the context of the node where you opened the menu.

    Note Note

    In the context menu of an application object, the Create menu offers subitems for creating BRFplus objects of all types, including application.

    End of the note.
  • Catalog view

    If you have a catalog defined, you can create new objects from the catalog's context menu. In this case, the newly created objects are at the same time assigned to the catalog node from where you started.

  • Favorites or Recently Used view

    In these two views, you can create new objects from the context menu of an application object. If there is no application object listed in these views, you cannot create new objects here.

Creating objects programmatically

You can of course also create objects programmatically through the interfaces (APIs) offered by BRFplus, with the CL_FDT_FACTORY class as a starting point. This is especially helpful if you have to create a large number of objects, for example, if you want to test the system performance with many thousands of objects before you actually start a development project of such a dimension. In that case you have to take care that those objects that are connected by a usage relationship must be activated from the bottom up. For more information, see the tutorials on the BRFplus pages in SAP Developers Network (SDN).

Single vs. Multiple Objects

As outlined above, the most common way to create single BRFplus objects is using the BRFplus workbench, and the most efficient way to handle large amounts of objects is via programming. However, there is a third alternative that may serve as a good compromise between these two approaches.

Experience shows that in a rules project, the highest number of objects is of type element data object. Here, the BRFplus workbench offers a mass creation tool with a table-like layout where you can enter the basic attribute values for any number of objects in a row. Once you are done, you choose OK and the system creates all the data objects at once. This is much faster than creating single objects. To start the mass creation tool, open a view in the BRFplus workbench where you can create objects and choose Start of the navigation path Create Next navigation step Data Object Next navigation step Elements (Mass Creation) End of the navigation path from the object tree context menu.

Note Note

Mass creation is available for element data objects only.

End of the note.
Reusability

In many situations, it is desirable to use the same BRFplus object at different places in an application or even in different applications. Reusing objects can reduce the complexity and improve the consistency of an application. BRFplus therefore encourages you to create reusable objects. This is accomplished by setting the Is reusable flag that is available in most object creation dialogs by default. With this setting, defining a name for the new object is mandatory, which in turn is the prerequisite for object reuse.

Making an object reusable has no drawbacks whatsoever. Therefore, in the BRFplus workbench, the Is reusable flag is not only set by default, it is even impossible to unset it in most cases. There are only rare cases where you can decide to create an object that is not reusable. The prerequisites for this are the following:

  • Only expressions can be defined as non-reusable.

  • This is only possible when you create an expression from the context of another object rather than from the object tree in the Repository view. For example, you can create an unnamed (and therefore non-reusable) expression in the context of a function by assigning a top expression with the help of the Create command from the Top Expression field's object menu.

Object Nesting and Unnamed Objects

Instead of creating objects from the object tree in the workbench navigation pane, there are some situations where you can directly embed a new object into another object. This is possible for the following tasks:

  • Assigning a new expression to a superordinate object (for example, assigning a top expression to a function, a range expression to the cell of a decision table, and so on)

  • Assigning a new rule to a ruleset

Creating objects by nesting them into a container object is comfortable because you do not have to leave the context where you are currently working in. Besides, this is the only way to create objects without having to define an object name. The consequences of working with unnamed objects are the following:

  • Unnamed objects can only be used by the container object for which they have been created.

  • Unnamed objects are neither listed in the repository object tree nor in the object query dialogs nor in the hit list of the advanced search.

  • As a consequence, unnamed objects are not reusable.

  • If the container object is deleted, its nested unnamed objects remain in the system. Since these objects are invisible, you cannot access and delete them like other objects. To remove unused unnamed objects from the system, choose Start of the navigation path Tools Next navigation step Application Administration End of the navigation path and execute the Delete unused objects operation.

Implicit Object Creation via Data Binding

You can create data objects of all kinds (element, structure, table) not only by manually defining all their attributes but also by defining a reference to an existing object in the data dictionary of the backend system. This kind of object creation is called data binding. When you use this option, the system determines the dependencies of the referenced dictionary object and automatically tries to reflect the dictionary object as good as possible on BRFplus side. Depending on the situation in the dictionary, this feature can help you save significant amounts of time. The system can do the following for you:

  • Element data objects

    When you bind an elementary data object to a data element in the dictionary, the system determines if the data element itself is bound to a domain. If so, the system automatically populates the BRFplus data object with all the domain values defined in the dictionary.

  • Structures and tables

    When you bind a structure or a table data object to a dictionary structure or table, the system automatically creates an element data object for each field in the structure or table. In addition, the system establishes a binding relationship to the corresponding dictionary data element. Again, for each element data object, the system imports the domain values that are defined in the dictionary for that field.