Logon Language, sy-langu, and RFC
In a recent discussion, Former Member 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.
I was watching that original discussion!!!! I had never really thought of that either...it was interesting. Glad you expanded upon it here in a blog rather than in a short questioner reply/comment that would likely get lost somewhere in the ether later.
Thanks Horst!
The key takeaways for me are:
– “logon language” and “text environment” are different things
(I think I latently knew that)
– “The logon language of the RFC session is the language of the text environment of the calling session (sy-langu)”
-> good to know!
best
Joachim
Hi Dr.Keller,
One of my colleague encountered this scenario. The scenario was, a RFM was developed for UK store users and worked perfectly fine. But, when we rolled out the same for FR users, the messages was still appearing in English.
The Frech users (FR) used the RFC with log-on language as FR. we tried this with SET LOCAL LANGUAGE, and noticed that, this statement worked only when the log-on language in SM59 is removed. otherwise, it by default takes the SM59 language set.
Do we have any other work around for this scenario ?
Thanks !
SET LOCALE sets the logon language only if it is no set in SM59. I see no workaround for that.
Dear All,
thanks for sharing, but I still am puzzled.
I want to call a standard report but with a different language (via submit ?). Is there another possibility?
Any hints are appreciated.
Best regards,
Gotthard Friedrich
I have a report where you can call a transaction with a different language in the same session, not sure if that helps you....
REPORT ZSPRAS.
PARAMETERS LANGUAGE LIKE tcp0c-langu OBLIGATORY.
PARAMETERS tcode LIKE sy-tcode.
START-OF-SELECTION.
IF tcode IS INITIAL.
tcode = 'SESSION_MANAGER'.
ENDIF.
SET LOCALE LANGUAGE LANGUAGE.
CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'LANGUAGE'
EXPORTING
tcode = tcode.
LEAVE PROGRAM.
Hello Thorsten Watzke,
My code is same as u mentioned above, the only change is that I cannot use 'STARTING NEW TASK' Since this does not work with NWBC it only works for GUI.
Now the issue without using 'STARTING NEW TASK' is that the language is updated for the 1st time as per SET LOCALE LANGUAGE LANGUAGE. But when I run the piece of code again it will not update the language, it will still have same language set during 1st run for the 2nd tcode.
https://answers.sap.com/questions/13193035/issue-with-set-locale-language.html
Can you suggest anything for this issue.
Thanks,
Vishal.
Thanks for sharing the info.
K.Kiran.
Hello Horst,
Thank you very much for the article.
It helped me enhance an already 15 year running application.
Kind regards.
Hello Horst,
Thank you very much for the article.
My question is: what can I do if I have one field out of 10 in Hebrew, and 9 fields out of 10 in English?
The Hebrew field I see as gibberish.
Thanks in advance
Hello Faina,
Horst
Hello Horst,
one additional question to this Topic. We call a RFC from our central ATC System in an own implemented Check where we fetch Description of Reports. This is an existing SAP Function Module which is RFC enabled.
In this Function Module there is at the End an SELECT against the TRDIRT with Reportname and Language. The Language will we selected with SY-LANGU (FM Name : SIW_RFC_READ_TRDIRT). Because the Description is maintained sometimes in German and sometimes in Englisch. we first try to call the RFC via English and then via German if nothing found in English.
The Problem is that we use before the RFC call the command SET LOCALE LANGUAGE ‘D’ and when we enter the other System you can see in the Debugger that SY_LANGU is switched again back to ‘E’ immeaditely.
We have checked the RFC Connection in SM59 and there is no Language Default stored there.
What is going wrong ?
Best regards
Mario
A useful tip regarding the RFC function call.
I wonder why there isn't any standard way to set the language permanently for the whole user session (and not just the internal session).
Calling SUBMIT via RFC isn't an ideal solution because it has its own disadvantages (a new user session with its own memory area, for example).
Hello Horst Keller,
I am facing similar issue with set logon language.
https://answers.sap.com/questions/13193035/issue-with-set-locale-language.html
The problem is I am unable to update the language second time can you please suggest some solution for this.
Thanks.
Vishal.