OO approach for bapi return

[Former Member]

HI ,

I am using the FM BALW_BAPIRETURN_GET2 and i want to know if there OO approach that emulate

this issue .

Regards

Joy

CALL FUNCTION 'BALW_BAPIRETURN_GET2'

EXPORTING

type = 'E'

cl = if_consnts=>gc_m_cl

number = 25

par1 = lv_msg

IMPORTING

return = ls_return.

[uwe_schieferstein]

Hello Joy

If you have class CL_RECA_MESSAGE_LIST available in your system then have a look at its many useful methods, e.g.

ADD 
ADD_SYMSG
ADD_FROM_BAPI
GET_LIST_AS_BAPIRET

Regards

Uwe

[Former Member]

HI Uwe,

Thanks ,

but i dont find this class in my system .

i check in SE24.

Any other idea?

Regards

joy

[Former Member]

Joy,

It really depends on what you're trying to achieve.

In older releases I used a class similar to CL_RECA_MESSAGE_LIST that I built myself, to collect messages for logging purposes. I wouldn't call that an "OO approach" per se, although it uses OO.

An important detail, however, that has nothing to do with OO: if you pass the message details (especially message class and number) to a method as literals, the where-used analysis on the message (from SE91) will not find this spot. So I found it useful to do more or less as follows:

DATA l_msgtext TYPE string.
MESSAGE ID if_consnts=>gc_m_cl TYPE 'E' NUMBER '25'
  WITH lv_msg
  INTO l_msgtext.

CALL FUNCTION 'BALW_BAPIRETURN_GET2'
  EXPORTING
    type   = sy-msgty
    cl     = sy-msgid
    number = sy-msgno
    par1   = sy-msgv1
  IMPORTING
    return = ls_return. 

If you do it like this, the where-used analysis will find the spot. And if you replace the function BALW_BAPIRETURN_GET2 with something of your liking or you leave it as-is, that's up to you.

Regards

Rainer