cancel
Showing results for 
Search instead for 
Did you mean: 

Portal and SAP Backend system languages are different

MarcelRabe
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi all,

not sure if this is a Content Development problem, or an Implementation issue.

Anyway, in our scenario we have users that logon to the portal in many different languages, outside de ISO8859P1 codepage. Not a problem for the portal since it's unicode. However, the backend SAP systems are not, and they have only 1 codepage installed: ISO8859P1.

I noticed that when a user logs on in a language that is not installed on the backend system (regardless of the codepage) the single sign on fails miserably with a message that the language is not installed. I guess this is because either JCo or the Logon Ticket sents the portal language as part of the logon.

To my best of knowledge, the logon ticket does not contain this information, nor does the system landscape configuration, so it must come from the portal or browser.

Now for the question: Is there any way to set the SAP logon language fixed for every user to a backend system (we must use SAP Logon Tickets), regardless of their portal language?

Much obliged

marcel

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Marcel,

sorry I overlooked the JCo in your initial post. There are three ways to programmatically connect to an R/3 as far as I know:

1. Create a single JCO Connection via JCO.createClient(...). Here you have to specify username, pw, and so on. Among the params is the backend system language. You could even create an own connection pool by the method

JCO.addClientPool(java.lang.String key, int max_connections, java.lang.String client,
 java.lang.String user, java.lang.String passwd, java.lang.String lang, 
java.lang.String ashost, java.lang.String sysnr)

Remember what the Javadoc says about SSO in this scenario:

For SSO specify the user to be $MYSAPSSO2$ and pass the base64 encoded ticket as as the passwd parameter

2. jcoclientservice: since this uses the params from the system landscape object (the relevant methods for retrieving a JCO client from the pool expect only the system alias) and there seems to be no parameter in this object for the language this would not work for you.

3. JCA (IConnectorGatewayService): same as 2.

Another issue: if one is using an R/3 as the UME datasource one can specify an optional parameter in the sapum.properties ume.r3.connection.master.lang=EN. Maybe this sets the default language for all R/3 backend systems even if you don't use R/3 as user datasource? Does anyone know more about it?

Hope it helps.

PD

MarcelRabe
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,

Thank you, i'll pass this on to the developers to try. In regard to your question below. We use 'Database Only' as the datasource and have the setting ume.r3.connection.master.lang=EN but that apparently doesn't matter. The browser language and the portal language seem to determine the language parameter for the JCo (and ITS and so on).

Marcel

Former Member
0 Kudos

Hi Marcel,

then could you please be a bit more specific: are you using JCO, the JCOClientService or what exactely is the method to connect to the backend system?

MarcelRabe
Product and Topic Expert
Product and Topic Expert
0 Kudos

Yes of course. I realized too late the I left out a little too much.

The iviews are developed in Java with the NDS, using JCo 2.0 to connect to the SAP backend systems. SAP Logon Tickets are used for SSO. For new iviews JCa is considered, especially if it can help us solve the problem.

thank you

marcel

Former Member
0 Kudos

Hi Marcel,

if you create an iView based on the appintegrator com.sap.portal.appintegrator.sap.Transaction, you can specify the attribute "logon language". If this attribute is empty, it uses the portal language for login into the SAP system. So you might want to set your favorite language here.

Best regards

MarcelRabe
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,

thank you, but the iviews we are using are custom developed and not sap transactions. Any other ideas?