Send Email from BSP --> Character Settings

[Former Member]

Hi all.

I'm having a question about sending emails out of BSP-pages and the used character settings. Hope someone can help me here.

We are using a BSP-page to collect input information which is then put into email content and send to email recipients using the standard class "cl_bcs" which has already been described a couple of times here.

Everything works fine and we have been using this for nearly two years now.

Now we have started to use our application in Turkey and obviuosly having problems displaying the special turkish characters in the email output. And I haven't found anything to maybe set the character settings or something like that when creating the email document.

We use the following code to create the email document:

Document = cl_document_bcs=>create_document(

i_type = 'RAW'

i_text = l_mailtext

i_length = textlength

i_subject = new_Subject ).

Example:

User enters turkish characters:

İsim

Now this is how it is processed on WAS:

Ýsim

This is also how it is stored in the database for example. When showing this as output in BSP-page (setting the codepage to "windows-1254" the result is 'İsim' again,

which is fine.

Now wehn creating the email document I don't see a way to set a codepage or something similar. Result is that the email output is exactly the same as is WAS handles internally: Ýsim.

Hope this makes sense. Has anyone come across this before ? Does anyone know of a solution here ?

We are using WAS 6.20, NO Unicode !

Thanks a lot in advance

Stefan Hester

P.S: okay great, the turkish character is not being displayed properly in this post. Hope that this makes sende anyway...

[thomas_jung · Accepted solution]

When the BCS class generates the email it will use the code page that you have setup for your SMTP node in transaction SCOT. Even if you don't have a Unicode SAP system, you can set this code page to 4110 Unicode UTF-8. See OSS Notes 633265 and 664833.

[Former Member · Accepted solution]

Hi Thomas,

thanks for your answer. This helps a lot and I can feel that I'm pretty close, though something still is not working properly.

I have set the codepage to "4410 Unicode" in transaction SCOT and the email output indeed looks different, but only from a layout point of view, the turkish characters still are not displayed correctly.

The note '633265' sounds good to me:

"E-mails can be created in different code pages in the SAP System, but must be converted to a single uniform code page when sent. You must therefore select Unicode (UTF-8) as a sending code page. This works in both Unicode systems and MDMP systems. "

From this I understand that I have to use the "Unicode" charset in the output settings, since I'm dealing with more than 1 codepage (latin, turkish, east european, etc.)

I would now assume that the problem now somehow lies in the process of creating the document.

I have already tried with the 'i_language' parameter

of the "create_document" function, but this seems not to have any influence.

Is there any other way to set the charset/codepage when creating the document ?

Thanks

Stefan Hester

[thomas_jung · Accepted solution]

So do you have elements from different code pages in your email document body? If that is the case I assume that corruption is occuring before you even create the document. SAP must convert the document body text from a single code page into Unicode. This source code page comes from the logon language for the running process. If you have elements from a different code page then your logon language, I assume they are corrupted during this conversion. Perhaps I am off base here, but maybe a little more details on what languages are combined toghere in the document and what langauge the process is running under would be helpful.

[Former Member · Accepted solution]

Okay, I think this may be the reason:

"This source code page comes from the logon language for the running process".

We only use characters of one codepage in one BSP-page, so this will not be a problem.

But we use one SAP function user for handling all BSP-requests and this user logs on with language "English". This would explain why characters of other codepages "get lost" during conversion.

Right now we have only "English" and "German" as logon-languages for the system. So is there any way of manipulating the language SAP uses for conversion ?

[eddy_declercq · Accepted solution]

The logon language depends also on the browser and OS. Here is an example to make things clear.

We are using Win XP Dutch. MIE gives Dutch as language, Mozilla type browsers give English. One can control this by setting the application->BSP_LANGUAGE or via SICF

[thomas_jung · Accepted solution]

I'm not sure I am following all the details in this latest message. Are you making an RFC call to another system from your BSP? It sounds like this. You have English setup for your RFC destination, right. Now in our system we always leave the language setting in the RFC blank. This way whatever the current logon language is, will pass through to the called system. Then again we use trusted RFC and always have current user set. We also have all the same language setup on R/3 as well as our WebAS. Are you having a problem because you have different languages setup on a WebAS as opposed to R/3?

I have not had a chance to test this yet, but you might try converting your entire message to unicode yourself. You would then add this unicode binary string to the mail message as a binary attachment. Not sure if this will work however. The following code sample would do this. It is hardcoded for Latin-2 but could be adapated to anything.

 data: encoding                    type string.
  encoding = 'iso-8859-2'.
  data: codepage            type cpcodepage.

  call function 'SCP_CODEPAGE_BY_EXTERNAL_NAME'
    exporting
      external_name = encoding
    importing
      sap_codepage  = codepage
    exceptions
      not_found     = 1
      others        = 2.

  data: codepage2            type cpcodepage.
  encoding = 'utf-8'.
  call function 'SCP_CODEPAGE_BY_EXTERNAL_NAME'
    exporting
      external_name = encoding
    importing
      sap_codepage  = codepage2
    exceptions
      not_found     = 1
      others        = 2.

  data: xdocument_length    type i.

  xdocument_length = xstrlen( me->pl_xstring ).
  call function 'SCP_TRANSLATE_CHARS'
    exporting
      inbuff           = me->pl_xstring
      inbufflg         = xdocument_length
      incode           = codepage
      outcode          = codepage2
      substc_space     = 'X'
      substc           = '00035'
    importing
      outbuff          = me->pl_string
    exceptions
      invalid_codepage = 1
      internal_error   = 2
      cannot_convert   = 3
      fields_bad_type  = 4
      others           = 5.

[Former Member · Accepted solution]

Okay, maybe my last post was a little bit confusing. In our case the function called is on the same machine and we use the language provided by the browser for internal processing and layout output, etc.

Now I have found out this:

We use the "create_document"-method for creating the email body:

Document = cl_document_bcs=>create_document(

i_type = 'RAW'

i_language = x_spras

i_text = l_mailtext

i_length = textlength

i_subject = new_Subject ).

The language is one of the input parameters and is taken from the browser's language, so in case of Turkish it will be 'T'.

After debugging and digging a little bit deeper going to

- 'SBCOMS_SR_FROM_DOCUMENT_CREATE'

- 'PERFORM CHECK_ATTRIBUTES_HEADER(SAPFSSO3)'

- 'perform check_object_langu'

I got to this language check:

catch system-exceptions localization_errors = 1.

set locale language langu.

endcatch.

And this is where the "set locale" for Turkish FAILS and in the next step default language (English) is being used. Obviuosly I have a problem with missing languages installed on the system. Now my colleagues tell me it's a problem to install "turkish" along with other west-european languages... does anyone have experience on this (using transaction SLMT, etc.) ?

Apart from this I will try your proposal to use conversion to Unicode and see if it works.

[thomas_jung · Accepted solution]

This is where I thought that this discussion might lead us. You have a normal SAP installation. Therefore you can only add and process languages that fall into a single codepage (sounds like Latin-1). There are really only two technologies that allow you to work with more than one codepage in SAP - MDMP and Unicode. Both are considerable undertakings to setup. There are several documents and weblogs on both (and their impact on BSP) here on SDN. If you are going to work with multiple languages (across multiple code pages), I would strongly suggest Unicode as the way to go. My company is in the process of converting from MDMP to Unicode, but it is no small undertaking.

The other option you might look at is transliteration. Looks like Turkey is Latin-9, so I don't know if this is an option. We did transliteration with Latin-2 (Polish). Transliteration replaces national characters with their closest ASCII7 counterpart. Not a great solution, but it might be better than data corruption. The following is some sample code:

data: i_codepage type cpcodepage.
  call function 'SCP_CODEPAGE_FOR_LANGUAGE'
       exporting
            language    = source_lang
       importing
            codepage    = i_codepage
       exceptions
            no_codepage = 1
            others      = 2.
  if sy-subrc <> 0.
    message e139(zes_general)
            with source_lang
            raising no_codepage.
*   No Codepage Maintained for Source language &.
  endif.

  call function 'SCP_REPLACE_STRANGE_CHARS'
    exporting
      intext                  = i_maktx
*   INTER_CP                = '0000'
      in_cp                   = i_codepage
*   REPLACEMENT             = 46
    importing
      outtext                 = maktx
*   OUTUSED                 =
*   OUTOVERFLOW             =
   exceptions
     invalid_codepage        = 1
     codepage_mismatch       = 2
     internal_error          = 3
     cannot_convert          = 4
     fields_not_type_c       = 5
     others                  = 6.
  if sy-subrc <> 0.
    message e140(zes_general)
            with source_lang
            raising transliteration_error.
*   Error during Transliteration from source language &.
  endif.

[Former Member · Accepted solution]

okay, this is starting to make sense. Obviously we have a single-codepage-installation, I wasn't 100% sure about this. I have read about MDMP and Unicode before. We have already discussed converting to Unicode, but as you mention this is not a 1-day job

Anyhow this will the only way to handle this correctly...

Thanks a lot anyway, one step more to understanding WAS )