Qualitätssteigerung durch Unicode

Feature | 3. Februar 2003 von admin 0

Unicode ist die “State of the Art”-Technik, um die Zeichen aller Schriften weltweit elektronisch zu speichern und zu verarbeiten. Der SAP Web Application Server (SAP Web AS) unterstützt ab Release 6.10 Unicode-fähige Anwendungen. Mit SAP R/3 Enterprise, mySAP Supply Chain Management (mySAP SCM), SAP Business Information Warehouse (SAP BW) 3.1 und mySAP Customer Relationship Management (mySAP CRM) sind nun die ersten Unicode-fähigen SAP-Anwendungen verfügbar.
Was aber müssen Kunden tun, wenn sie ihre Programme – selbst wenn sie sich für ein nicht-Unicode System entschieden haben – Unicode-fähig machen wollen? In erster Linie gilt es, alle Programmstellen anzupassen, die auf der expliziten oder impliziten Annahme beruhen, dass 1 Zeichen gleich 1 Byte ist. Diese Annahme ist häufig in der Stringverarbeitung zu finden sowie bei Zuweisungen von Strukturen und bei Offset-/Längen-Zugriffen auf Strukturen. Darüber hinaus ist zu beachten, dass beim Schreiben und Lesen von Dateien eine explizite Deklaration der Zielcodepage erfolgt. Diese Anpassungen lassen sich bereits in einem Nicht-Unicode-System vornehmen, da sowohl die Nicht-Unicode- als auch die Unicode-Anwendung mit der gleichen Code-Basis laufen und im Wesentlichen die gleiche Semantik besitzen.

Problemstellen aufdecken

Unicode-Prüfungen aktiv

Unicode-Prüfungen aktiv

Um den Entwickler bei der Suche nach nicht Unicode-fähigen Programmstellen optimal zu unterstützen, hat SAP ein neues Programmattribut – “Unicode-Prüfungen aktiv” – eingeführt. Es aktiviert die restriktiveren Unicode-Prüfungen, die alle unter Unicode problematischen Anweisungen als Syntax- oder Laufzeitfehler sichtbar machen.

UCCHECK-Ergebnisliste

UCCHECK-Ergebnisliste

Diese Unicode-Prüfungen ließen sich nun zwar Programm für Programm durchführen. Bequemer ist es allerdings mit der Transaktion UCCHECK. Sie zeigt für eine frei definierbare Programmmenge an, welche Syntaxfehler nach dem Aktivieren der Unicode-Prüfungen auftreten würden.

Ursachenforschung leicht gemacht

Die Anzahl der neuen Regeln im Unicode-Umfeld ist groß. Darüber hinaus sind diese Regeln – um eine größtmögliche Kompatibilität mit bestehenden Programmen zu gewährleisten – im Einzelfall sehr ausgefeilt und komplex. Ein Entwickler, der seine ABAP-Programme auf Syntaxfehler überprüfen will, muss allerdings keine einzige dieser Regeln auswendig lernen. Aufgrund der Integration in den Syntax-Check und die Laufzeitumgebung, sowie der guten Dokumentation in der F1-Hilfe und der direkten Navigation von der Fehlerstelle im Editor zur Schlüsselwortdokumentation ist er jederzeit in der Lage, rasch die Fehlerursache zu ermitteln.
Außer der F1-Hilfe zu den einzelnen Schlüsselwörtern bietet das System auch eine Übersicht zum Thema Unicode, die über die Transaktion UCCHECK -> “Doku zu ABAP und Unicode” oder direkt in der ABAP-Schlüsselwortdokumentation zu erreichen ist (Transaktion ABAPHELP -> Schlüsselwort “Unicode”).
Kunden die bereits ein SAP-System besitzen, das auf dem SAP Web Application Server 6.10 oder 6.20 aufsetzt, können anhand der Demoprogramme TECHED_UNICODE_EXERCISE/SOLUTION* beispielhaft die Umstellung von ABAP-Programmen auf Unicode nachvollziehen. Die Programme sind über Support Package verfügbar (siehe Hinweis 583546 für Details).

Verschleierte Datentypen als Fehlerquelle

Neben der Anmahnung der technischen Trennung von Zeichen- und Byteverarbeitung resultiert der größte Teil der von den neuen Programmprüfungen aufgespürten Fehler aus Programmstellen, in denen die wahren Datentypen verschleiert wurden. Dies war in der alten ABAP-Syntax recht einfach möglich und ist beispielsweise immer dann der Fall, wenn strukturierte Daten mittels eines impliziten Casts in einem großen zeichenartigen Feld als “Container” gespeichert werden. Dabei besteht die Gefahr, dass binäre Daten, die in dem Container verborgen sind, bei einer Stringverarbeitung (etwa TOUPPER CASE-Konvertierungen) oder bei einer Codepage-Konvertierung während der Außenkommunikation zerstört werden. Das Verschleiern der Feldgrenzen bewirkt zudem, dass bei der Außenkommunikation das implizite Layout selbst bei rein zeichenartigen Strukturen verloren geht, wenn bei der Codepage-Konvertierung eine datenabhängige Änderung der Länge eintritt. Dies ist bei der Kommunikation zwischen Unicode- und Nicht-Unicode-Systemen bei asiatischen Zeichen der Fall. Schwierigkeiten machen solche Typverschleierungen auch dann, wenn die Datenbank mit Codepage-Wechsel umgesetzt wird, zum Beispiel bei der Konvertierung von EBCDIC zu ASCII oder von ASCII zu Unicode.

Neue Unicode-Prüfungen verbessern die Softwarequalität

Fehlerhafte Programmierung

Fehlerhafte Programmierung

Die Analyse der angemahnten Programmstellen macht schnell den Vorteil der neuen Prüfungen deutlich. Denn eine beträchtliche Anzahl der Stellen ist zwar nach der alten Syntax korrekt, semantisch aber falsch. Mit den Prüfungen lassen sich also viele echte Fehler aufspüren und fragwürdige Konstruktionen finden.
Dabei ist zu beobachten, dass bei ABAP-Programmen aus älteren SAP-Releases mehr Fehler auftreten, als bei Neueren. Dies liegt hauptsächlich daran, dass sich die Programmiersprache im Laufe der Zeit weiterentwickelt hat und – etwa beim Typkonzept – wesentlich verbessert wurde. Zudem sind viele neue Sprachkonstrukte dazugekommen, die es erlauben, auf einer höheren Abstraktionsebene sicherere und robustere Programme zu schreiben als früher.
Da sich mit den restriktiven Unicode-Prüfungen durch Fehlerdiagnose die Software-Qualität verbessern lässt, ist es auch für Kunden, die nicht unmittelbar an Unicode interessiert sind, sinnvoll, ihre Programme diesen Tests zu unterziehen. Die Probe aufs Exempel kann jeder Anwender machen, der sich an seinem SAP Web AS basierten System anmeldet, UCCHECK auf seinen eigenen Programmen aufruft und sich die Meldungen einmal genauer anschaut – er wird sicher die eine oder andere wertvolle Überraschung erleben.

Typisierung nachholen

Die restriktiveren Unicode-Prüfungen gelten auch zur Laufzeit. Da es in ABAP möglich ist, mit untypisierten Variablen zu arbeiten, ist dort keine Unterstützung durch den statischen Syntax-Check möglich. Programmstellen, die statisch nicht überprüfbar sind, lassen sich aber in UCCHECK anzeigen. Es empfiehlt sich – wo möglich – die Typisierung nachzuholen und dabei – wenn nötig – mit den neuen generischen ABAP-Typen wie CSEQUENCE oder CLIKE zu arbeiten.
In der Praxis ist es allerdings oft nicht möglich, alle Variablen zu typisieren. Zudem gibt es Konstrukte, die sich erst zur Laufzeit in einem Unicode-System überprüfen lassen. So ist beispielsweise in ABAP-Listen – die vielerorts bereits durch den ABAP List Viewer (ALV) abgelöst wurden – die Annahme, dass ein Zeichen auch eine Spalte breit ist, nicht mehr korrekt. Aus diesem Grund ist es notwendig, nach der Unicode-Prüfung zusätzlich Laufzeittests durchzuführen. Diese Tests sollten umfassend sein, denn bei den restriktiveren Syntax- und Laufzeitprüfungen sind im Gegensatz zu der sonst üblichen Entwicklung von Zusatzfunktionalität alle Programme betroffen. Es reicht daher nicht aus, sich nur auf einige wenige Anwendungsszenarien zu konzentrieren. Ab Release 6.10 steht der eigens entwickelte ABAP Coverage Analyzer (Transaktion SCOV) zur Verfügung, der die Testabdeckung misst und damit diese umfassenden Laufzeittests unterstützt. Sein Einsatz wird daher bei einer Unicode-Umstellung empfohlen.

Umstellen der Programme ist Teil eines Gesamtprojekts

Wird ein System als Ganzes in ein Unicode-System umgewandelt, dann ist die Umstellung der ABAB-Programme lediglich ein Teil des Gesamtprojekts. Weitere Aufgaben sind es dann, die Datenbank und eventuell selbst geschriebene RFC-Programme umzusetzen. Diese Aufgaben werden in einem zweiten Artikel angesprochen.
Weiterführende Informationen zur Unicode-Umstellung von ABAP-Programmen, Leitfäden und Übersichten sind im SAPNet unter dem Alias Unicode@SAP in der “Media Library” zu finden.

Christian Hansen

Christian Hansen

Leave a Reply