Skip to Content

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’

             INTO ls_event_container.

lv_objtype = ls_event_container-value.

IF lv_objtype <> objtype.

  MESSAGE text-001 TYPE ‘I’ RAISING sub_type.

ENDIF.

P.S

Using message… raising… is better then using the regular exception since it will give you more readable event trace in transaction SWEL.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Florin Wach

    Hi Ronen,

    I like this behaviour, although your right in spotting, that the BOR object type could change through the propagation of the event to the superior object instances.

    However, there is no such problem with ABAP OO events:

    – The event linkage for the superior Class is also processed, when there’s an event consumed by a supertype’s event linkage

    and

    the binding preservers the original class type here, so the Workflow is working with subtype.

    That’s a grand feature when you have a generic implementation for a Workflow Design pattern and use different subclasses to be routed through the same procedure.

    If you still need only to process “Original” object types from the linkage, the given coding is somewhat buggy and also uses the “old” interface, not the one with SIBFLPOR … so it works only under certain circumstances and is not release safe.

    Best wishes

    Florin

    (0) 
    1. Ronen Weisz Post author

      Hi,

      Although ABAP OO objects might be free of these problem, most of the ECC transactions are still linked to BOR objects, so you still have to use them.

      As far as using the “old” and not “release safe” interface, well, simple works and is still supported to the best of my understanding. and some customers are still in a very old version of the system (yes, they should upgrade, but they still need a solution in the system they have).

      You are of course welcome to write the solution based on the SIBFLPOR interface.

      Ronen

      (0) 

Leave a Reply