bapi return message

[Former Member]

hi,

1) i got the help from gurus that normally FM would use exceptions but not bapi FM. bapi FM uses bapiret2 internal table to know exception of the errors, warnings, success messages occurred when processing bapi.

may i know where to get (or keep) the message that return in RETURN in the calling program?

2) may i know those message variable below are messages maintained by customer or sap system message? where we store the message?

message-id sy-msgid type sy-msgty number sy-msgno with

sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

3) message in point 1 and point 2 are referring to same source? i mean messages for point 1 and point 2 getting from the same place?

thanks

[Former Member]

The messages in points 1 are returned in rows of an internal table (usually named BAPIRET2 but not necessarily, can have other names) and they have the similar structure in terms of msgid, msgno etc as in point 2.

For example if you look at BAPI_MATERIAL_SAVEDATA, its messages are returned in internal table RETURNMESSAGES, which has the below structure

TYPE
ID
NUMBER
MESSAGE
LOG_NO
LOG_MSG_NO
MESSAGE_V1
MESSAGE_V2
MESSAGE_V3
MESSAGE_V4
PARAMETER
ROW
FIELD
SYSTEM

[Former Member]

hi

bapiret1, bapiret2, bapireturn, bapimessages

are they the same? i read from post that advisable to use bapiret2 than using bapiret1 and bapireturn. what about this bapimessages?

rgds

[Former Member]

All of them will have similar structures (but not necessarily identical) but all of them will definitely contain msgid, msgno etc.

It doesn't make a difference as far as you need to just return messages. Moreover if none of those return structures satisfy your requirement (ie. you want some addition fields to return from your bapi), you can create your own dictionary structure and use it in your definition.

[Former Member]

hi,

where the message coming from? where to maintain if we need to maintain or sap provides?

thanks

[Clemenss]

Hi el,

in most cases the messages are those you would get from the corresponding transaction if processed online. BAPI_PO_CHANGE will process the same routines as transaction ME23N, BAPI_ORDER_CREATE1 is the equivalent of VA01 and so on.

For test purposes, you may display the return table as an ALV grid; just call FM REUSE_ALV_GRID_DISPLAY with structure_name 'BAPIRET2' (or what structure the return table is) and table RETURN.

For productive environment it will be good to put them into an application log. For IDocs it is possible to create a reference to the application log in IDoc status record. If processed in report, you can issue the message preceded with ICON_LED_GREEN, YELLOW or RED to make the message type visible.

One good reason for the RETURN table is that there is no limit for the number and type of messages including info, warning, success and error. An exception raised means just one type of (failed) end of processing.

The decision about handling depends on your specific requirements. To check if the processing was successful it is OK just to check if there was any message of types E, A or X:

loop at lt_return transporting no fields
  where msgty ca 'EAX'.
endloop.
if sy-subrc = 0.
* Failed!
  call function 'BAPI_TRANSACTION_ROLLBACK'.
else.
* Good
  call function 'BAPI_TRANSACTION_COMMIT'.
endif.

Regards,

Clemens