Logon Language, sy-langu, and RFC

[horst_keller]

In a recent discussion, sisley_dsi pointed me to something that was not clear in my mind and therefore not made clear in the documentation (although one might have deduced it one or the other way).

It is about how the logon language of an RFC session is set.

First some clarification of terms:

 

• The logon language is the language that is used as logon parameter when opening an user session on an AS ABAP. The logon language of an user session cannot be changed during the session. You can get it using  method GET_LOGON_LANGUAGE of class CL_ABAP_SYST.

• An  internal session, that is a session inside a user session, where an ABAP program is executed, has  a text environment that is governed by a language. The text environment influences things like textual sorting of  internal tables. The language of the text environment can be found in sy-langu and you can get it from method GET_LANGUAGE of class CL_ABAP_SYST. When an internal session is started, the language of the text environment is the logon language. But you can change the language of the text environment using SET LOCALE LANGUAGE. After this statement, the language of the text environment and with it sy-langu can be different from the logon language. The change of the language of the text environment is valid within the current internal session only. Calling another program starts a new internal session with the logon language again.

• An RFC session is a fully fledged user session that is opened when an RFM (remote function module) is called via the RFC interface. The logon parameters of the RFC session are either defined in SM59 for the RFC destination or passed implicitly. The latter is especially the case for predefined destination NONE and therefore also for CALL FUNCTION STARTING NEW TASK without specifying a destination.

How are the logon parameters of an RFC session set, that are not defined in the destination?

 

• The username of the RFC session is the username of the calling session (sy-uname)

• The client of the RFC session is the client of the calling session (sy-mandt)

• The logon language of the RFC session is the language of the text environment of the calling session (sy-langu)

With other words, the logon language of the RFC session is not necessarily the logon language of the calling session (sy-langu is not necessarily the logon language)! You can use SET LOCALE LANGUAGE in the calling session to influence the logon language of the RFC session.

SET LOCALE LANGUAGE 'E'.



CALL FUNCTION '...' DESTINATION 'NONE'.

The function module is running in a fully fledged user session with logon language 'E'. Everything that depends on the logon language, e.g. surface texts, text pools, formats, and of course the text environment again, is influenced by the language of the text environment of the caller.

E.g. if the RFM looks as follows:

FUNCTION ...



  CALL TRANSACTION 'SE38' WITH AUTHORITY-CHECK.



ENDFUNCTION.

The RFC opens SE38 in English, independent from the logon language of the caller. Note that placing SET LOCALE LANGUAGE directly in front of CALL TRANSACTION wouldn't do the trick, because the call opens a new internal session.

Of course you can use SET LOCALE LANGUAGE in the RFM again in order to set the text environment of the internal session there.

PS: Reminder, don't mix up SET LOCALE LANGUAGE with SET LANGUAGE. The latter does not set a language but loads the text pool of a given language.