Application

A BRFplus application object is a container of different BRFplus objects. You can think of the BRFplus application as a reflection of a particular system functionality that you want to enhance by some business rules modeled with BRFplus. It is then recommended to collect all the BRFplus objects that contribute to a given system functionality in one BRFplus application.

Features

Object Hierarchy and Application Assignment

The application object type is located at the highest level in the classification hierarchy for objects. Nevertheless, you can define as many applications as you like. All objects must be assigned to an application. The system supports you to accomplish this by offering two ways of assigning an application to an object:

You can create new objects out of the context of a given application by choosing Create Object on the Contained Objects tab of the application. All objects created this way are automatically assigned to the application from which you started.
You can create new objects from the navigation panel of the BRFplus workbench. In this case, you have to create the new object with the help of the context menu of one of the already existing objects. The new object is then assigned automatically to the same application as the object from which you started.

Note Note

In case of a system that is completely empty with no BRFplus objects inside at all, you would start working in the BRFplus workbench by choosing Start of the navigation path Workbench Next navigation step Create Application End of the navigation path .

End of the note.

Storage Types

There are three types of application referred to as storage types:

System application (default)
Master data application
Customizing application

Depending on the storage type, the system behaves differently when it comes to system transports. System and customizing applications can be local while master data applications are always local. The storage type as well as the locality setting of an application is inherited by all objects that are assigned to that application. All three types of application can be assigned to a development package.

Note Note

The storage type must be defined when you create an application. Once the new application has been created, this setting cannot be changed anymore.

End of the note.

Versioning

Like all other types of objects, you can decide whether the system should keep the previous versions of an application in the system database after the application has been modified. In addition, you can also define a default versioning setting for objects that you newly create and add to the Contained Objects list of the application. The newly created objects inherit the versioning setting that has been defined by the application.

Note Note

The inherited versioning setting of an object is a default setting only and can be changed individually for each object at any time.

Keep in mind that the versioning default setting for objects assigned to the application does not affect the versioning behavior of the application itself. The versioning setting for an application object is controlled in the same way as for all other object types.

End of the note.

Further Settings

An application also offers attributes for the application component and the software component. The application component and software component have to be the same as defined for the development package. The application and software component are automatically derived from the development package if they are not set explicitly.

An application also helps you control reuse, changeability, and visibility with access levels.

Recommendation

For the definition of the development package, application component, and software component, we recommend that you choose the same values that are in effect for the software solution that you want to enhance by a new BRFplus application. This simplifies all activities related to the software infrastructure, especially transports.

End of the recommendation.

Restrictions and Interdependencies

The settings for development package, application component, and software component of an application (and the objects belonging to an application) are partially dependent on each other. The following restrictions apply:

The development package assigned to an application determines whether the application is either transportable or local.
The definition of an application as transportable or local is irreversible. Once the application has been saved for the first time, this setting cannot be changed anymore. If you try to reassign a local application to a transportable package or vice versa, the system rejects this and sends an error message.
For a local application, defining a software component is not needed. As opposed to that, for a transportable application it is essential to define the software component because the SAP transport system is based on this attribute.

Application Exit Class

If your application requires special processing routines (for example, for auxiliary calculations, validations, etc.), you can implement such additional functionality with methods of an ABAP class. These methods can then be used, for example, to extend the functionality of a formula expression in the form of additional formula functions. The exit class must be registered for the application to which it belongs. To accomplish this, fill in the name of the class in the Application Exit Class field.

For an application exit class, the following applies:

For a BRFplus application, you can define no more than one exit class.
An application exit class must implement the IF_FDT_APPLICATION_SETTINGS interface.
Once you have started to use the functionality provided by an exit class, we highly recommend not to change the exit class assignment from that point in time. If changes to the functionality are needed, try to implement this within the scope of the already assigned class.

Note
If, for whatever reason, you cannot avoid changing or deleting the exit class assignment of an application, you have to check manually where the implemented functionality has already been used. For each usage, you are responsible for either providing a workaround or canceling the using object. Be aware that these usages may be hard to find (for example, a formula expression using a function that used to be provided by the exit class to be changed).

End of the note.

Object Type-Specific Settings

While all of the aforementioned settings directly affect the application itself, there is another set of settings used to control the properties and behavior of particular object types that are created inside of the application's scope. The following application-wide settings can be made on the Miscellaneous tab:

Object Type-Specific Settings
Setting	Comment
Restart Rule Set Enabled	Processing rule sets can be done in two different modes: Standard mode: All rules in a rule set are executed one after another. Processing stops either after the last rule in the rule set has been processed or if an exit condition is met. Deferred mode: Like standard mode, but with the possibility to restart the rule set processing at the point where it had stopped due to an exit condition. With this setting switched on, rule set processing in deferred mode is supported.
Secondary Database Connection	Expressions of type Procedure Call (subtype Database Procedure) and Dynamic Database View can operate on database objects not only in the local database, but also in an alternative database belonging to a different system, or even in a stand-alone database that is not part of an SAP system. With this setting, you can choose a database from the database connections that have been defined in the local system. The system offers all entries that have been maintained in backend transaction DBCO. If a secondary database has been maintained for an application, the Procedure Call and Dynamic Database View expressions in that application automatically refer to the secondary database.

Default Settings for New Objects

All BRFplus objects have a number of administrative data fields in common. For some of these fields, it is very likely that for the majority of objects in an application, the respective settings are identical. Therefore, it is possible to define default values for these fields on application level so that newly created objects carry these default values. The values can of course be changed if need be.

Default Settings for Newly Created Objects
Setting	Comment
Application Log Object, Application Log Sub Object	Defines the application log objects used for recording the log entries that are created by objects belonging to the application (for example, actions of type Log Message). For more information, see Log Message Action.
Save Log Data	Controls whether the log data shall be permanently stored in the database or not. If not, log data is only kept in memory during runtime and is lost after the session.
Default Enforcement	Controls if and to what degree of compulsion the objects of the application have to follow the application-wide default setting concerning application log.
Allowed Message Types	Controls which message types you can use in an application when you define a Log Message action.
Versioning Mode	Controls whether newly created objects are put under version control by default or not. Note This setting affects objects of all types except for catalogs. Catalogs are always created with versioning off. End of the note.
Language Settings	Controls whether texts and documentation of newly created objects shall be maintained dependent on language, version, both, or none of all. Object names, however, are treated as technical names and are therefore not affected by these settings.

More Information

Storage Types

Versioning

Creating an Application

Setting Properties

Adding Objects

Setting an Access Level

Setting Versions