Event 

Definition

A BRF event has the following meanings simultaneously:

·        A BRF event forms a connection between the application that uses the BRF, and the BRF

·        A BRF event is the (logical) location to which any number of rules are assigned

·        A BRF event is often the carrier of the context.

Use

Events are the central entry point for use of the Business Rule Framework (BRF). You can implement an event (a BRF event) at a technical or business event in every application. If such a technical or business event is reached during the program flow in the relevant application, the (BRF) event is triggered along with processing of the associated rules.

You can define any number of rules for an event. You can use these rules to evaluate the current data and make any changes if necessary.

 "BRF event" is the term for a calling point from within the application to the BRF. This linkage is fixed, and the call is synchronous. For this reason, a BRF event should not be viewed like ABAP-OO or the "Observer Pattern" where an event only represents a loose linkage between two software components.

Integration

Implementation of Events in the Application

You must implement a BRF event in the coding as a method call

Registration of Events in the BRF

You must register a BRF event in BRF.

When doing so, you must ensure that

·        You have registered all the events called in the program in the BRF

·        You have only registered events that are actually called in the BRF.

Event Context

Very simple applications might be able to work without any context information. Generally, though, an event corresponds to a context, and an event object contains information on the context. This means that different events have different contexts.

In invoice verification, for example, two events with different contexts would be set up:

§         Check invoice header (the invoice number could form the context, for example)

§         Check invoice item (the combination of invoice number and item number could form the context, for example)

The BRF does not prescribe what a context is or how to implement it.

Here follows a description of two options for implementing a context:

·        You regard all the data of your application as the context. In other words, you actively make available to the BRF all the data that might be used in rules at some stage.

·        You define a very limited context that contains the minimum amount of data required. In the case of invoice verification at item level, this would be the invoice/item number. All other data on the item can only be derived indirectly via suitable data sources and the invoice/item number.

BRF events and their respective contexts (implementation and scope) are therefore defined by the developer of the application.

Adding Own Events

Partners/customers can only add other events to the application to the same extent as the application is capable of being enhanced by ABAP code. An application that does not offer any user exits (such as BAdIs) cannot be enhanced to include other events without the need for modifications.

Example

Examples of business and technical events at which you might want to implement an event:

·        After a change to address data

·        Before payments are transferred

·        After deletion of an archived document

·        After a status change

·        Before saving

·        Before booking a flight

·        When checking the invoice header

·        When checking an invoice item

The events, and thus the BRF events, are usually very application-specific.

 

See also:

For more detailed information (specially for developers), see Event: Details.