SAP poliglota w standardzie?

Wielonarodowe koncerny to codzienność naszej gospodarki, a polskie firmy sprzedają i otwierają oddziały w innych krajach. Z rozwiązań SAP można korzystać w różnych językach, zapisywanych w różnych alfabetach i ich wariantach.

Obsługa systemu w ojczystym języku czy generowanie faktur w języku klienta to niewątpliwe zalety, w końcu użytkownik SAP-a nie ma przecież obowiązku znać mowy Goethego czy Szekspira, zaś klient ma prawo oczekiwać komunikacji w formie najbardziej dla niego komfortowej.

Nawet gdy mówimy o językach zapisywanych tym samym alfabetem – na przykład łacińskim – w każdym języku spotykamy się ze specyficznymi znakami, jak w polskim choćby „ć”, „ź” czy „ą”. Zaimplementowany w systemie standard kodowania znaków oraz wersja SAP decydują o tym, czy użytkownicy z innych krajów będą mieli kłopot z odczytem dokumentów zawierających takie znaki.

Obecnie powszechnie wykorzystywane są wersje systemów SAP 4.6C i wyższe, dlatego skupimy się tylko na nich. W przypadku kiedy wykorzystujemy standard UNICODE, praktycznie nie mamy ograniczeń w implementacji wielu języków jednocześnie, ale co w innym przypadku?

Standardowo w systemie SAP są tzw. strony kodowe. W ramach jednej strony kodowej mamy pewien zestaw języków. W momencie instalacji systemów mamy standardowo zainstalowane języki angielski i niemiecki oraz ustawioną stronę kodową o numerze 1100 – która odpowiada standardowi ISO8859-1 i zawiera języki duński, niderlandzki, angielski, fiński, francuski, niemiecki, włoski, islandzki, norweski, portugalski, hiszpański i szwedzki.

UNICODE to międzynarodowy standard kodowania znaków. W zamierzeniach ma on obejmować wszystkie pisma używane na świecie. Standaryzacją tego kodowania zajmuje się Konsorcjum Unikodowe, założone, by rozwijać i promować używanie UNICODE. W jego skład wchodzą ważne firmy komputerowe, producenci oprogramowania, instytuty naukowe, agencje międzynarodowe oraz grupy zainteresowanych użytkowników. Konsorcjum współpracuje z organizacją ISO (standard 10646). Pierwsza wersja UNICODE 1.0.0 powstała w 1991 r. Najnowszą jest wersja 5.1.0.

W przypadku wykorzystania pojedynczej strony kodowej i konieczności implementacji języka polskiego jesteśmy zmuszeni przełączyć system na stronę kodową 1401 – która odpowiada standardowi ISO8859-2 i zawiera języki: chorwacki, czeski, angielski, niemiecki, węgierski, polski, rumuński, słowacki i słoweński.

A co, jeśli chcemy wykorzystać jeszcze francuski (standard ISO8859-1) i rosyjski (standard ISO8859-5)? Potrzebujemy już trzech stron kodowych, a obsługa systemu staje się bardzo skomplikowana.

Rozwiązaniem może być konwersja na kodowanie znaków w systemie UNICODE. Nota 73606 w SAP Service Marketplace szczegółowo opisuje języki wspierane przez SAP (Supported Languages and Code Pages).

Język komputerów

Komputery „rozumieją” tylko 0 i 1 („jest napięcie albo go nie ma”). Pojedyncze zero lub jedynkę nazywamy bitem. Z tego powodu każdy znak, który drukujemy, wyświetlamy i przechowujemy w bazie danych, musi być zakodowany tylko tymi dwoma cyframi. Matematycznie nazywamy to kodowaniem binarnym.

W standardzie kodowania ASCII każdy znak kodowany jest ośmioma bitami. Daje to 256 znaków do zakodowania. Jeżeli chcemy, by system obsługiwał więcej niż jeden język (np. w firmach międzynarodowych), okazuje się, że tych znaków jest po prostu za mało.

Niezbędne jest więc przełączanie się pomiędzy stronami kodowymi, ale jak już wspomniano, niesie to pewne ograniczenia. Z tym ograniczeniem można sobie poradzić, używając kodowania znaków zgodnie ze standardem UNICODE.

Co z tym UNICODE?

UNICODE to kodowanie znaku z wykorzystaniem więcej niż 8 bitów. Istnieje kilka standardów UNICODE, np. UTF-8, CESU-8, UTF-16, UTF-32, UCS-2, UCS-4. Obecnie UNICODE uwzględnia ponad 98 000 znaków większości języków świata w różnych alfabetach. Standard UNICODE jest wspierany i rozwijany przez takie firmy jak SAP, Microsoft, HP, IBM, Sun, Oracle.

Serwer aplikacyjny SAP używa wersji UTF-16 (maksymalnie 16 bitów). Bazy danych w zależności od jej rodzaju używają kodowania UTF-8, CESU-8 lub UTF-16.

SAP R/3 4.6C – system wykorzystujący jedną stronę kodową, w przypadku języka polskiego musimy korzystać ze strony kodowej 1401, nie było możliwości instalacji w standardzie UNICODE, przy obsłudze wielu języków należało zaimplementować rozwiązanie MDMP, które ma pewne ograniczenia. np. logujemy się tylko jedną stroną kodową, a co za tym idzie, nie widzimy poprawnie znaków zapisanych w innej stronie kodowej.

SAP R/3 4.7 Enterprise – pierwszy system, w którym można było wykonać instalację w standardzie UNICODE, ale z racji nowego rozwiązania wiele systemów zostało zainstalowanych w wersji nie-UNICODE, czyli patrz SAP R/3 4.6C.

SAP ERP 5.0 lub 6.0 – powszechne instalacje w trybie UNICODE, niektóre rozwiązania, jak np. SAP XI/PI, wymuszały instalację UNICODE, jednak ciągle można zainstalować nie-UNICODE (można spotkać takie instalacje), wówczas niezbędna jest migracja do standardu UNICODE.

SAP bez UNICODE

Starsze wersje SAP wykorzystują kodowanie znaków ASCII z zastosowaniem omówionych wcześniej stron kodowych. Logując się w danym języku (np. po polsku), użytkownik odczytuje poprawnie tylko znaki zdefiniowane w stronie kodowej, w której znajduje się język polski. W nowszej wersji systemu, z kodowaniem UNICODE, użytkownik zalogowany po polsku poprawnie odczytuje również znaki zdefiniowane w innych językach czy alfabetach (np. rosyjskim czy greckim).

Nowe systemy SAP (od wersji SAP R/3 Enterprise) instalowane są z reguły w standardzie UNICODE. Co jednak zrobić ze starszymi wersjami systemu, które nie mają kodowania UNICODE?

W przypadku wersji R/3 4.6C, R/3 Enterprise i SAP ERP 2004 (ECC 5.0) mamy dwie możliwości:

  • wykonać upgrade systemu do wersji wyższych, wykonać migrację do UNICODE (jest możliwe dokonanie obu czynności w jednym kroku), skonfigurować dodatkowe języki (jest to rozwiązanie zalecane przez specjalistów z SAP i BCC – aktualnie All for One Poland);
  • zaimplementować rozwiązanie oparte na MDMP (nie jest to zalecane rozwiązanie, bo rozwiązanie MDMP nie będzie rozwijane).

Jest i inne rozwiązanie. Oczywiście możemy nie robić nic, jeśli nie planujemy w ekspansji na rynki zagraniczne ani upgrade’u systemu w najbliższej przyszłości. Jeśli wszystko działa, to po co to zmieniać. Jednak wcześniej czy później nie unikniemy migracji naszych systemów do wersji UNICODE. SAP docelowo i tak przestanie wspierać rozwiązania nie-UNICODE, i to już od wersji następnej po SAP ERP 2005.

Zatem skoro przejście na kodowanie UNICODE jest nieuchronne, warto do takiej konwersji odpowiednio się przygotować i przeprowadzić ją według najbardziej polecanego schematu.

Wielojęzyczny SAP w Mennicy Polskiej
BCC już w 2002 r. wykonało dla Mennicy Polskiej SA implementację kilku języków zachodnio- i wschodnioeuropejskich, z wykorzystaniem trzech stron kodowych i konfiguracji MDMP. Sprawa była jeszcze bardziej skomplikowana przez to, że była to instalacja SAP w wersji 4.6C na AS/400 z kodowaniem EBCDIC, a była to jedyna konfiguracja sprzętowa, dla której konfiguracja MDMP nie działała. Pierwszym więc krokiem było wykonanie migracji bazy danych DB2 z kodowania EBCDIC do ASCII. Projekt się powiódł – w efekcie wystawienie czytelnej faktury w cyrylicy nie jest żadnym problemem.
Cezary Nita, Dyrektor Działu Informatyki, Mennica Polska

Wszyscy mówią UNICODE

Konwersja do UNICODE polega na wykonaniu następujących głównych zadań:

  1. Sprawdzenie we wszystkich tabelach aplikacyjnych, w jaki sposób zakodowane są teksty. Jeżeli tabela ma pole wskazujące na język, konwersja takiej tabeli jest automatyczna. Jeżeli tabela nie posiada takiego pola, należy dla wszystkich wpisów w tabeli wskazać, w jakim języku są te wpisy.
  2. Eksport bazy danych do plików.
  3. Import bazy danych z plików.
  4. Ewentualnie ręczne wskazanie języka, w którym wykonane są wpisy, jeżeli nie powiodła się automatyczna konwersja dla takiego wpisu.

Należy podkreślić, że głównym i najbardziej pracochłonnym zadaniem podczas konwersji jest określenie języka dla wszystkich tekstów w bazie danych przechowywanych w tabelach, które nie posiadają znacznika języka.

Od poprawnego wykonania tej czynności zależy sukces konwersji. Od tego również zależy czas trwania konwersji. Istotne jest, aby podczas konwersji na systemie testowym przeprowadzić określenie języka dla wszystkich wpisów, by zminimalizować ilość pracy na systemie produktywnym.

Istotnym elementem wielu implementacji systemu SAP są programy/raporty napisane w języku ABAP. Większość z nich powinna działać poprawnie po konwersji do UNICODE. Warunkiem jest to, by były napisane zgodnie ze składnią ABAP 6.10. Istnieją standardowe narzędzie do sprawdzenia, czy dany program będzie poprawnie działał po konwersji do UNICODE. Są to dwie transakcje UCCHECK do sprawdzenia, czy dany program jest napisane zgodnie ze składnią ABAP 6.10, oraz transakcja SCOV do monitorowania i testowania pozostałych programów.

Wymagania sprzętowe

Ważne jest, by przed migracją systemu SAP do UNICODE sprawdzić, czy obecny sprzęt ma wystarczające zasoby, by pracować wydajnie jako system UNICODE. Po konwersji systemu SAP z kodowania nie-UNICODE do UNICODE zwiększone zostanie zapotrzebowanie na moc obliczeniową serwerów. Dotyczy to głównie wykorzystania procesora i ilości potrzebnej pamięci RAM.

Jeżeli serwer posiada najnowsze procesory, wykorzystanie ich zwiększa się o ok. 10%. Przy starszych procesorach może się zwiększyć nawet o 30%. Ilość wykorzystywanej pamięci RAM po konwersji do UNICODE zwiększa się ok. 40-50%. Innym istotnym zasobem, który należy sprawdzić przed migracją, jest przestrzeń dyskowa potrzebna dla bazy danych.