I recently encountered a strange behavior of the event receiver: if an event is raised of a subtype of an object the receiver function module of the supertype is also called. The event trace showed the correct object (the subobject), but the receiver FM used the wrong one (the superobject).
Usually I would not recommend using event on a subobject at all since this is a common mistake done by not understanding the use of derived objects. but there are a few cases when it is possible to raise an event on a sub object, for example in my case the subobject was used for linking DMS documents of a different type and a link could be created for the object itself or for the subobject by using the same event; a more standard example would be all the SD objects BUS2032, BUS2031, etc. which are all base on the same superobject.
There a few notes describing a similar behavior (for example note 511681 for IS-U implementation for BUS2007 & BUS2080) all recommending the use of a check function module (which is a reasonable solution) and limiting the linkage to a specific object (not BUS2080), this however would not work in this case since the same event could be raised for the supertype object.
A more generic solution could be used by compering the (wrong) event transferred to the function module and the event in the event container – in the event container the correct object could be found.
So a check function module should look like:
DATA: lv_objtype TYPE swetypecou-objtype,
ls_event_container LIKE LINE OF event_container.
READ TABLE event_container
WITH KEY element = ‘_EVT_OBJTYPE’
lv_objtype = ls_event_container-value.
IF lv_objtype <> objtype.
MESSAGE text-001 TYPE ‘I’ RAISING sub_type.
Using message… raising… is better then using the regular exception since it will give you more readable event trace in transaction SWEL.