Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

RAISE EVENT usage in real world

MichiFr
Participant

Hi,

I wonder what is the advantage of the statement RAISE EVENT in contrast to a normal call to a class method.

Given the following example coding:

METHOD pai_0100.
  CASE ok_code.
    WHEN 'START'.
      RAISE EVENT read_sflight_data_event EXPORTING i_carrid = i_carrid.
  ENDCASE.
ENDMETHOD.

This will raise the event read_sflight_data_event. This event calls the method read_sflight_data set as handler in the class constructor:

METHOD constructor.
  SET HANDLER me->read_sflight_data FOR me.
ENDMETHOD.

Reading data from database...

METHOD read_sflight_data.
  IF NOT i_carrid IS INITIAL.
    SELECT * FROM sflight INTO TABLE gt_sflight
      WHERE carrid = i_carrid.
  ELSE.
    SELECT * FROM sflight INTO TABLE gt_sflight.
  ENDIF.
ENDMETHOD.

Of course I could have written, too:

METHOD pai_0100.
  CASE ok_code.
    WHEN 'START'.
      me->read_sflight_data( i_carrid = i_carrid ).
  ENDCASE.
ENDMETHOD.

Which results in exactly the same result of course, however what is the advantage of events in real world? When is it useful to raise an event instead of calling the event handler directly?

Thanks for shedding some lights on this topic.

1 ACCEPTED SOLUTION

nomssi
Active Contributor
0 Kudos

Hi,

events implement the [publish and subscribe|http://sourcemaking.com/design_patterns/observer] pattern, which main advantage is is low coupling.

You can e.g. add another handler without changing the existing code.

best regards,

J. N. N.

4 REPLIES 4

MarcinPciak
Active Contributor

I agree that in this case it doesn't add any value to the logic. EVENTs are however really useful when used to communicate objects of different classes. Imagine situation where you have two objects: control tower and a plane . The control tower monitors the weather conditions and passes the information to the captain of the plane who decides whether to land or not.

We can communicate these two objects in two ways:

- either plane exposes its method alert_on_weather_condition_change by making it public to the world which control tower uses to pass him the information abouth changing conditions

- or sets a handler to tower's event weather_condition_changed and responds to it once it is raised by tower

The advantage of the second over the first is that the method is public so can be called by anyone who wants to use it. The alert then becomes unathorized. It can be anyone like lighthouse who gives the alert to the pilot. So he receives the information but doens't know anything about the caller (so is not sure whether it is a real danger to the plane or not).

In the second case he cleary stated that he want to react only on the tower's messages (SET HANDLER FOR tower), not someone else. So he is certain about the message authenticity and can react respectively.

So even the communication b/w object can go by calling of one another's public methods, the events provide proven and more reliable information flow.

Hope it is clear now.

Regards

Marcin

nomssi
Active Contributor
0 Kudos

Hi,

events implement the [publish and subscribe|http://sourcemaking.com/design_patterns/observer] pattern, which main advantage is is low coupling.

You can e.g. add another handler without changing the existing code.

best regards,

J. N. N.

Former Member
0 Kudos

You don't have to look far to get real world SAP examples for event handling:

<ul style="list-style:circle!important">

<li>Workflow (e.g. trigger an event upon creation/change of a document)</li>

<li>ALV (e.g. react to user input like a double click)</li>

<li>Job control (e.g. fire a job upon a specific event)</li>

</ul>

When you look at the examples it's obvious that the event producer doesn't necessarily know anything about any possible future event consumers: You can ignore events, have one or multiple listeners and the listeners are usually separate from the coding unit that raised the event. Note that it depends on the event handling framework how events are processed (e.g. asynchronous versus synchronous, sequential versus parallel). For class based events the event handler processing is synchronous and sequential; for multiple event handlers their execution sequence is based on their registration order (see [raise event|http://help.sap.com/abapdocu_70/en/ABAPRAISE_EVENT.htm]).

In a simple example like the one you gave I'd say the event handling approach is possibly questionable (at least as long as all the event listeners are within the same class and there is clearly no need for other objects to listen to this event). Anyhow, the example is probably designed to show the gist of event handling, but sometimes examples from SAP look overly complicated because they seem to prefer the [SoC|http://en.wikipedia.org/wiki/Separation_of_concerns] design principle over [KISS|http://en.wikipedia.org/wiki/KISS_principle] (couldn't resist this little rant).

Cheers, harald

MichiFr
Participant
0 Kudos

Thanks for all your replies!