topic Re: MESSAGE...INTO versus FORMAT_MESSAGE function module in Application Development and Automation Discussions

MESSAGE...INTO versus FORMAT_MESSAGE function module

Sandra_Rossi — Sun, 30 Aug 2009 18:06:34 GMT

I would be interested to know why many developers still use FORMAT_MESSAGE function module as there is the abap statement MESSAGE ... INTO ... since at least 2001. [Note 171952 - Funct. mod. FORMAT_MESSAGE evaluates &1 to &4 false|https://service.sap.com/sap/support/notes/171952] says it must not be used (because not released for customer).

Maybe because of language field, but I guess developers generally never check if it's of some interest, and usually the message language is the same as the connection's language.

I saw this function module was indicated today in the forum, for getting text from messages returned by a BAPI ().

Re: MESSAGE...INTO versus FORMAT_MESSAGE function module

Former Member — Sun, 30 Aug 2009 18:14:29 GMT

Hi,

I still use FORMAT_MESSAGE for getting message text. Dint know that it should not be used. May be its time to check and avoid using it.

Regards,

Vikranth

Re: MESSAGE...INTO versus FORMAT_MESSAGE function module

Former Member — Mon, 31 Aug 2009 04:47:12 GMT

Hi Sandra,

It's really great that you pointed out such a flaw in the code. I also came across similar scenarios where we were using an obsolete function module "GUID_CREATE' to generate globally unique identifiers. We have a new advance OO Method which handles the GUID Generation.

But, the good thing here is that once you run the code inspector check on the Development Object, it will immediatly figure out the Use Access error and will flag a priority 1 error. So, it will be always be brought to notice.

Is that scenario similar for you also? Did the ABAP Code Inspector check flagged a similar error? If not, possibly we can raise this so that all obsolete function module and also all Function Modules that are not released to customers can be identified whenever used by any developer in the code.

Thanks,

Samantak.

Re: MESSAGE...INTO versus FORMAT_MESSAGE function module

Sandra_Rossi — Mon, 31 Aug 2009 09:33:03 GMT

thank you Vikranth for the info.

Samantak, my comment was not especially about my team, but any developer (in the world). Your idea is nice, I didn't know that code inspector could check that. I looked at the "Search functions / Find unwanted language elements" check, we can put a warning for any statement we want (for example CALL FUNCTION 'FORMAT_MESSAGE', CALL FUNCTION * GUID * , etc.) It seems that SAP doesn't display warnings when we use "not released" function modules (FORMAT_MESSAGE, GUID_CREATE, for example). Note that the CL_SYSTEM_UUID class exists only since SAP NetWeaver 7.00 Enhancement Package 2 and SAP NetWeaver 7.10, see [note 935047 - Creating and using GUIDs (UUIDs)|https://service.sap.com/sap/support/notes/935047], and GUID_CREATE has to be used in releases before.

Edited by: Sandra Rossi on Aug 31, 2009 8:32 PM (formatting problem with * GUID * which appeared previously as bold)

Re: MESSAGE...INTO versus FORMAT_MESSAGE function module

SuhaSaha — Mon, 31 Aug 2009 10:10:51 GMT

Hello Sandra,

But please note that the error has been corrected as of release 4.6B. So why do you think that it is not safe to use the FM?

As for the FM being "not released" we use many FMs which are not released (e.g., ALSM_EXCEL_TO_INTERNAL_TABLE).

You must be aware that when an FM is not released for customers, SAP does not guarantee upward compatibility.

Hope i put my idea clearly.

BR,

Suhas

Re: MESSAGE...INTO versus FORMAT_MESSAGE function module

Sandra_Rossi — Mon, 31 Aug 2009 11:10:46 GMT

I agree, we use non released function modules at our own risk (which, for me, just means a risk of spending more time in maintenance) . So why don't we use official abap statement which is recommended.

Re: MESSAGE...INTO versus FORMAT_MESSAGE function module

Former Member — Mon, 31 Aug 2009 18:59:30 GMT

Hi Sandra,

Thanks for pointing that out, I sure did not check that was not released and would have issues in maintainence.

Thanks,

Himanshu