OCI HookUp URL

[Former Member]

Dear Exports,

We have set IMG for OCI call structure as following:

1 https://online.graf.co.il/secure/index.aspx? 0 URL

20 SENDERID 2 Fixed Value

25 SHAREDSECRET 2 Fixed Value

26 USERNAME 9951 2 Fixed Value

27 PASSWORD 9951 2 Fixed Value

40 HOOK_URL 4 Return URL

71 ~OkCode ADDI 2 Fixed Value

72 ~Target _top 2 Fixed Value

75 ~caller CTLG 2 Fixed Value

100 ~HTTP_CONTENT_CHARSE UTF-8 2 Fixed Value

The problem is that the HOOKUP URL contains &~HTTP_CONTENT_CHARSET=iso-8859-8-i

instead of UTF-8 as was defined in IMG above.

Please advise how we can correct it .

Best Regards,

Moshe Stein

[Former Member]

Moshe,

Try specifying UTF-8 in the field "Codepage of Service" in the Technical settings area of Web services details config and remove it from the Hook URL.

award points if helpful.

regards,

[Former Member]

Hi Onyedika ,

Please advise where are the settings for the field "Codepage of Service",

I have set the Standard Call structure in IMG , can you give us more information?

Regards,

Moshe

[Former Member]

It is the same page where you specified the description of the catalog, and if you want to use error log, http get, cross catalog search etc. The first screen you use when creating a new OCI entry with all the checkboxes.

regards,

[Former Member]

Hi Onyedika ,

Thanks for your prompt reply.

I have set in IMG the Codepage of Service to UTF-8

But Still have the problem with the Hebrew text that gets into the Shoping Cart.

It comes like "gibrish" #####

Also the HookUp URL still contains :

~HTTP_CONTENT_CHARSET=iso-8859-8-i

How we can change it to UTF-8 ?

Thanks,

Moshe

[masa_139]

Hi,

Here is my understanding. I don't know Hebrew characters but someone in your team knows about Hebrew and Unicode technical limitations.

Case A: SRM = UTF-8(Unicode) and Catalog = UTF-8(Unicode)

SRM sends parameter ~HTTP_CONTENT_CHARSET= UTF-8.

Catalog should sends back item data as UTF-8(Unicode).

SRM can receive UTF-8 data.

Case B: SRM = UTF-8(Unicode) and Catalog = iso-8859-8-i(Hebrew)

SRM sends parameter ~HTTP_CONTENT_CHARSET= UTF-8.

Catalog should sends back item data as UTF-8(Unicode) but catalog sends data as iso-8859-8-i(Hebrew).

If you set Codepage of Service = iso-8859-8-i, SRM maps character from iso-8859-8-i to UTF-8. Mapping is available.

Case C: SRM = iso-8859-8-i(Hebrew) and Catalog = UTF-8(Unicode)

SRM sends parameter ~HTTP_CONTENT_CHARSET=iso-8859-8-i. This is correct.

Catalog should sends back item data as iso-8859-8-i(Hebrew) but catalog sends data as UTF-8. (Catalog side issue)

If you set Codepage of Service = UTF-8, SRM try to map from UTF-8 to iso-8859-8-i, but no mapping is available.

Your issue is Non-Unicode system is trying to receive Unicode data.

Case 😧 SRM = iso-8859-8-i(Hebrew) and iso-8859-8-i(Hebrew)

SRM sends parameter ~HTTP_CONTENT_CHARSET=iso-8859-8-i.

Catalog should sends back item data as iso-8859-8-i(Hebrew).

SRM can receive iso-8859-8-i data.

Your case is C.

Solution is, changing the system to Case A or B or D.

Regards,

Masa

[Former Member]

Hello all,

We are encountering a similar problem while retrieving the content of the shopping basket from one of our provider.

After the POST request is made by the provider to our system, when debbuging I can see that some special characters are represented with the sign '#' (after the call the ITS_IMPORT_CONTEXT).

In our case using the parameter http_content_charset with various values, including UTF-8, did not change the result.

Inspecting the HTTP traffic has highlighted the following: the encoding received from the provider is related to UTF-8, but while we are expecting the hexadecimal values, we are receiving the "Unicode code points", which are not recognized by our SAP system. For more details look at the UTF-8 encoding table found here and compare the values under column "Unicode code point" with the one under column "UTF-8 (hex.)".

As an example, for the character 'é', we are receiving the value "%E9" (the code point) instead of receiving the the hexa value : "%C3%A9".

Do you have any idee if this can be corrected on our side or if the provider must addapt the way it's sending the POST parameters?

Many thanks in advance for you help.

Best regards,

Jerome.

!! A new thread has been created for this :

Edited by: Support TAS SC-TAS on Jul 4, 2011 10:14 AM

Edited by: Support TAS SC-TAS on Jul 5, 2011 10:52 AM

[masa_139]

Hi,

Application reads system charset and set the ~HTTP_CONTENT_CHARSET value automatically. I think the behavior is correct.

I guess your system is not Unicode system. Please let us know your runtime issue.

Regards,

Masa

[Former Member]

Hi Masa ,

Thanks for your reply.

Our system is not Unicode system .

We receive "Gibrish" on Item description text in Hebrew to our Sys.( English text is receiving properly)

Please advise if there is a note regarding this text problen for non Unicode system.

Best Regards,

Moshe

[masa_139]

Hi,

I think it is technical limitation.

Your SRM system should be Unicode or same codepage with Hebrew in case of Non-Unicode.

Regards,

Masa

[Former Member]

Hi Masa,

Please advise the solution on your statment:

" ...or same codepage with Hebrew in case of Non-Unicode."

Thanks,

Moshe

[masa_139]

Hi,

Please check following information.

1. SRM system code page. Go to transaction SNLS

2. Catalog side charset. Check encoding in the catalog UI.

Regards,

Masa

[Former Member]

Hi Masa,

SRM - SNLS folowing data:

Adj. DB according to country IL

System language (database) HE

Database codepage 1800

Current Codepage of Appl. Server 1800

Codepage of Front End 1804

[masa_139]

Hi,

Your SRM system looks Hebrew code page.

What is the catalog side encoding? It should be same codepage/encoding/charset.

If the catalog is Unicode, transfered text from catalog will be garbled.

Catalog should return text based on passed HTTP_CONTENT_CHARSET from SRM.

Regards,

Masa