Testing

[Former Member]

<b>what is unicode testing</b>

[sreeramkumar_madisetty]

Hi

Unicode Testing : Test the code that whether the developed code is Unicode compatible or not?

This called Unicode testing.

Regards,

kumar

[p291102]

Hi,

== Unicode

In general Unicode is an evil that should be eliminated from the universe for the greater good of man kind....

but seeing that we are stuck with it, I have attempted to marry saprfc, librcu* and ruby together, as best I can.

Ruby at best has support for UTF-8, which at every stage needs to be translated into UTF-16 for SAP's unicode implementation.

You need to consider this carefully for what ever you try and do - you MUST work in UTF-8!!!

TO get this working you must compile saprfc against librcu* and libsapu16*. - get these from the usual instructions found at http://service.sap.com/connectors.

Additionally - you will most likely be on Linux, and therefore require a program from SAP called u16lit.pl. This must be retrieved from OSS note 763741, and placed in the root directory of the unpacked source distribution of saprfc eg. if you get saprfc-0.20.tar.gz => unpack and place in the directory saprfc-0.20 - this is where the compilation process will look for this program (from extconf.rb).

build with:

ruby setup.rb clean

ruby setup.rb config --with-rfcsdk-dir=/path/to/rfcsdk --with-unicode=yes

ruby setup.rb setup

the good ideas is to use the released method by SAP to do upgrade/conversion at the same time. this will save you time.

check OSS note

Note 928729 - Combined Upgrade & Unicode Conversion FAQ

Thanks,

Shankar

[Former Member]

Hi,

From SAP 4.7 Version onwards this has come.

This is intended mainaly to address the Langugae specific problems for different countries.

So when you go for upgrades from lower versions to Higher versions (>=4.7) of SAP you have to check for this Unicode related errors.

Regards,

Anji

[p291102]

Hi,

Looking at the trace it seems to strangely truncate the name of the function that is being called => RFCPING. This is a dummy function that you can see in SE37, used purely to test connectivity.

I've had a look at the RFCSDK documentation again, and there is specific talk about compiling for a UNICODE environment => eg. you must use librfccm.so, and -DSAPwithUNICODE is supposed to be added to CFLAGS. Also, there is considerable evidence that there are a lot of C helper functions that are supposed to be used to ensure that UNICODE data is preserved when being moved arround - this probably needs to be done to any RFC adapter.

The problem I have is that I do not have access to a UNICODE system so I cant do any build testing to sort this out.

So - if anyone out there has a system that they can give me access to - then I'll do the work.

Thanks,

Shankar

[Former Member]

hi sateesh

In the past, SAP developers used various codes to encode characters of different alphabets, for example, ASCII, EBCDI, or double-byte code pages.

1.ASCII (American Standard Code for Information Interchange) encodes each character using 1 byte = 8 bit. This makes it possible to represent a maximum of 28 = 256 characters to which the combinations [00000000, 11111111] are assigned. Common code pages are, for example, ISO88591 for West European or ISO88595 for Cyrillic fonts.

2.EBCDIC (Extended Binary Coded Decimal Interchange) also uses 1 byte to encode each character, which again makes it possible to represent 256 characters. EBCDIC 0697/0500 is an old IBM format that is used on AS/400 machines for West European fonts, for example.

3.Double-byte code pages require 1 or 2 bytes for each character. This allows you to form 216 = 65536 combinations where usually only 10,000 - 15,000 characters are used. Double-byte code pages are, for example, SJIS for Japanese and BIG5 for traditional Chinese.

Using these character sets, you can account for each language relevant to the SAP System. However, problems occur if you want to merge texts from different incompatible character sets in a central system. Equally, exchanging data between systems with incompatible character sets can result in unprecedented situations.

One solution to this problem is to use a code comprising all characters used on earth. This code is called Unicode (ISO/IEC 10646) and consists of at least 16 bit = 2 bytes, alternatively of 32 bit = 4 bytes per character. Although the conversion effort for the SAP kernel and applications is considerable, the migration to Unicode provides great benefits in the long run:

a. The Internet (www) and consequently also mySAP.com are entirely based on Unicode, which thus is a basic requirement for international competitiveness.

b.Unicode allows all SAP users to install a central system that covers all business processes worldwide.

c. Companies using different distributed systems frequently want to aggregate their worldwide corporate data. Without Unicode, they would be able to do this only to a limited degree.

d.With Unicode, you can use multiple languages simultaneously at a single frontend computer.

e.Unicode is required for cross-application data exchange without loss of data due to incompatible character sets. One way to present documents in the World Wide Web (www) is XML, for example.

Reward points if useful

regards

lavanya

[Former Member]

Hi,

From Release 6.10, ABAP supports multi-byte coding for characters in Unicode. Prior to Release 6.10, ABAP used only character sets that were based on single-byte codes – such as ASCII and EBCDIC – or double-byte codes, such as SJIS and BIG5.

This switch to Unicode affects all statements where an explicit or implicit assumption is made about the internal length of a character. If you use these statements in a program that is designed to exploit the Unicode capabilities of the runtime environment, they must be checked and changed if necessary. Once a Unicode-enabled program has been changed accordingly, it behaves in the same way in both Unicode and non-Unicode systems. You can develop programs in a non-Unicode system (NUS) and then import them into a Unicode system (US).

reward points if useful...