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 isl then assigned automatically to the same application as the object from which you started.
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 
Workbench 
Create Application 
.
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
The storage type must be defined when you create an application. Once the new application has been created, this setting cannot be changed anymore.
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
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.
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.
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. This class must be registered at the application to which it belongs. To accomplish this, fill in the name of the class in the Application Exit Class field.
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:
Setting |
Comment |
|---|---|
Restart Rule Set Enabled |
Processing rule sets can be done in two different modes:
With this setting switched on, rule set processing in deferred mode is supported. |
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.
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 Message Log). For more information, see Create Application Log. |
Persist Log |
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. |
Versioning Mode |
Controls whether newly created objects are put under version control by default or not. |
Language Settings |
Controls whether texts and documentation of newly created objects shall be maintained dependent on language, version, both, or none of all. |