Function module without exceptions

[Former Member]

Hi All,

Some function modules do not have exceptions or return tables to capture errors occurred during processing,

instead they contain hard coded error messages.

Can anyone suggest me some FM or any other way to capture these error messages in an internal table?

Thanks.

TC

[Former Member]

I think errors will be in SY table. So you can check SY-MSGTY, MSGNO, MSGV1, MSGV2, MSGV3 and MSGV4.

Thanks,

Kumar

[Former Member]

Thanks for your inputs prvn, but it isnt helping. Most of the time the SY table contains msg as 'System check error. Start Transaction SICK!' i.e. msgno = 00 in SY message class. its not storing the hard coded error inside the FM (with no exceptions).

[Former Member]

I think I've seen one ro two SAP standard function modules with embedded error messages. These were specialized function modules related to screen processing. If you're talking about customer-created function modules, error messages should not be inserted...handle everything through exceptions and handle the non-zero return codes in the code that calls the FM.

[Former Member]

Accepted. But then i have a requirement to replace CK23 transaction with a custom function module. In this i am using standard FMs like CK_F_CK23_COSTINGS_SELECT and CK_RFC_MARKING_RELEASING_CK24 etc.

In both of the FMs there are no return tables or exceptions. And i need to have a return table where appropriate messages can be stored. How can this be done? please advise.

[Former Member]

You have my empathy. Replacing a standard SAP transaction code with custom code is never a good idea, IMHO. Is there no way that BADIs, exits, implicit enhancement points would allow the modifications required? Creating a replacement version of a large piece of SAP standard code is a dead end street. After upgrade, enhancement or support package, you may get to do it all over again.

If there are message calls in those standard FMs, since you're cloning and whacking and hacking SAP code, why not just add copy those and add exception processing to the copies, too?

[Former Member]

Ya i could have done that but again call transaction would have been a good idea than this one. correct?

But again in BDCMSGCOLL table the messages are not being stored which are embeded in the SAP. And the requirement specifically asks for capturing actual reasons (S/E).

[Former Member]

If you want to use CALL TRANSACTION, messages should be returned in BDCMSGCOLL. If not, find out why. Does it display a list of meesages at the end.

Exporting parameter p_user_param is itself a table. Is there anything there that helps.

Do a where used list of these FMs to see if there are any other FMs that need to be used with them.

Rob

[uwe_schieferstein]

Hello

Transaction CK23 does not exist on our ERP 6.0 systems yet the fm's you have mentioned are there.

Fm CK_F_CK23_COSTINGS_SELECT does not raise any error message directly but collects them (e.g. routine ERROR_520, INFO_704 -> both routines call fm CM_F_MESSAGE ).

Fm CK_RFC_MARKING_RELEASING_CK24 apparently returns error messages in TABLES parameter T_MSGPROT:

...
* Tabelle der Messages aus diesem Kontext (Task) ermitteln...
  IF T_MSGPROT IS REQUESTED.
    CALL FUNCTION 'CM_F_MESSAGES_GET'
         EXPORTING
              APLID      = 'CKPF'
         TABLES
              E_MSGPROT  = T_MSGPROT
         EXCEPTIONS
              NOT_ACTIVE = 01.
  ENDIF.

ENDFUNCTION.

Thus, I assume that all messages collected during transaction execution can be found in function group CMFE.

Regards

Uwe

[Former Member]

Thanks Uwe.. It worked.

[uwe_schieferstein]

Hello

I have to thank you, too, because now I have a little head start should I ever have to deal with CK23 related transactions in the future.

Regards

Uwe