Rüdiger Plantiko

Interesse am Computer wecken und fördern

2012-02-03T20:27:00.028+01:00

Was ist es eigentlich, was mich an Computern, insbesondere der Programmierkunst interessierte und bis heute begeistert? Diese Frage stellte sich mir, als für meinen Sohn das Thema "Informatik an der Schule" aufkam. Was hat mich damals, als ich als Vierzehnjähriger in die Gedankenwelt der Informatik eintrat, besonders an ihr fasziniert? Was könnte auch heute für Schüler in diesem Alter wirklich interessant sein?

In den späten siebziger Jahren, lange vor dem Erfolg des PC, waren Computer noch nicht so omnipräsent wie sie es heute sind. Um sie kennenzulernen, musste man sich selbst zu ihnen hinbewegen. Ein heutiger Lehrer, der in mittleren Schulklassen die Informatik unterrichten soll, sitzt dagegen vor Schülern, die fast alle einen Facebook- und Twitter-Account haben, die in den Pausen nicht mehr gummitwisten oder Fussball spielen, sondern, wenn sie es dürfen, auf ihren Smartphones Filmchen anschauen und Mails, Kurznachrichten und Kommentare lesen und schreiben. Schüler, für die die Benutzung eines Computers ganz selbstverständlich ist.

Einige dieser Schüler dürften mit mir gemeinsam haben, dass sie die blosse Bedienung eines Computerprogramms uninteressant finden. Das sind die Schüler, denen ich mich nahe fühle. Sie wollen etwas herausfinden, grübeln, forschen, eine Idee wirklich werden lassen, eine nach Regeln ablaufende Ordnung in Gang setzen - nicht ein Programm bedienen.

Vielleicht haben oder hatten sie einmal eine Game-Phase, in der sie sich freiwillig in die Regeln einer künstlichen Welt hineinbegeben, die ein Programmierer sich für sie ausgedacht hat. Aber diese Phase wird aufhören, sobald sie die Unfreiheit erkennen, in der sie sich als Gamer befinden. Ein paar Knöpfchen zu drücken, ein paar ausprogrammierte, vorgedachte Tricks herauszufinden, die ein anderer ersonnen hat: Das stillt nicht auf Dauer die wissenschaftliche Neugier, den Erkenntnisdurst und den gerade in der Pubertät mächtig aufkommenden Wunsch, sich von Fremdbestimmung zu emanzipieren, sich von Grenzen zu befreien, die andere einem auferlegen. Nein - viel mehr Spass macht es doch, sich frei seines eigenen Verstandes zu bedienen und sich den Computer anzueignen – ihn nach eigenen, selbst erdachten Vorstellungen für das einzusetzen, was er gut kann: Systematisch Dinge abarbeiten oder durchsuchen, einen Status überwachen, Ereignisse melden, etwas berechnen, Geräte oder mechanische Vorgänge steuern.

Was mich damals in diese Richtung bewegte, war der Wunsch, die Arbeitsweise des Computers zu durchdringen und kennenzulernen. Natürlich waren damalige Rechner im Vergleich zu heutigen geradezu niedlich. Der Einplatinenrechner KIM-1 wäre mein erster Computer geworden, wenn meine Eltern ihn mir geschenkt hätten. Die Schaltkreise lagen offen. Er hatte einen sehr guten Mikroprozessor, den 6502[1], 1 KByte Arbeitsspeicher, eine Tastatur mit den Hexziffern 0 bis 9 und A bis F, und als Ausgabemedium reichten sechs Siebensegmentanzeigen: Vier für den aktuellen Speicherplatz und zwei für den Inhalt. Unter Bastlern waren auch seine Schnittstellen zur Aussenwelt sehr beliebt, an die man Fotozellen, Thermometer, Lautsprecher, Steuerungen für kleine Modelle mit Elektromotoren, Modelleisenbahnen und anderes anschliessen konnte.

Bis heute gibt es Fans und Nostalgiker, die für diesem Prozessortyp Assembler und Emulatoren schreiben. Die beeindruckende Seite visual6502.org kann sogar für jeden Taktzyklus des zu durchlaufenden Assemblerprogramms die Potentiale der einzelnen Leiterbahnen darstellen (die sich die Autoren der Seite in wochenlanger Detektivarbeit durch Microphotographie des Chips erschlossen haben)!

Ich war sehr neugierig auf Computer und wollte vor allem wissen, wie sie eigentlich funktionieren. Ich gehörte zu den Käufern der allerersten Nummer der Computerzeitschrift CHIP (Sept. 1978), weil mich der Titel ansprach: Der Computer, das unbekannte Wesen. Die Artikel gingen ziemlich tief ins Detail und eröffneten mir eine faszinierende Gedankenwelt. Durch die Beschäftigung mit den dort besprochenen Rechnern und Assemblerprogrammen wurde mir langsam die Funktionsweise eines Computers klar: Was ist der Datenbus, was ist der Adressbus, wie wird Speicher angesprochen und ausgelesen, welche (logischen) Bestandteile hat die CPU selbst, wie erfolgt die Kommunikation mit der Aussenwelt, d.h. den Peripheriegeräten? Dadurch, dass ich die Bestandteile des Computers näher kennenlernte, wuchs mein Interesse, den Computer zu betreiben - und das hiess für mich: zu programmieren.

Ohne dass ich zum damaligen Zeitpunkt etwas von Dingen wie "Turingmaschinen" wusste (den Begriff lernte ich erst sehr viel später kennen), stellte ich mir einen laufenden Computer vor, wie er sich Byte für Byte durch den Speicher durcharbeitet und versucht, die Inhalte, als Befehle zu interpretieren und auszuführen. Das ist ein bedeutendes gedankliches Modell, das auch in der mathematischen Grundlagenforschung eine Rolle spielt - man kann mit einer solchen Maschine als rein gedanklichem Modell schwierige theoretische Fragen wie das Entscheidungsproblem behandeln. Es ist der Kontaktpunkt, bei dem ein "auskristallisierter" Gedanke schliesslich Realität in Form einer Sequenz von einzelnen Schritten wird, die so klar sind, dass sie auch eine Maschine ausführen könnte.

Die Kernfrage eines Computerkurses könnte ganz schlicht sein:

Wie funktioniert ein Computer?

Natürlich wäre Assembler für einen durchschnittlichen Schüler, der normalerweise nicht so viel Interesse an diesem Thema hat, eine viel zu tiefgehende Angelegenheit. Aber wenn die Schüler nach Absolvieren des Kurses ein Grundverständnis davon haben, wie eigentlich ein Computer arbeitet, dann wäre doch schon viel erreicht! Mehr - viel mehr - als wenn sie nur gelernt hätten, ein bestimmtes heute gängiges Computerprogramm zu bedienen, also Tastenkombinationen oder Menüpunkte zu erlernen, die sich irgendein Programmierer ausgedacht hat. Die Bedienung von Büro-Software erlernt man nebenbei später im Beruf sowieso. Es wäre m.E. zu schade, die wertvolle Zeit eines Schulkurses über Computer damit zu verbringen.

Aber um die Idee einer Turingmaschine kennenzulernen, reicht schon ein einfaches Simulationsprogramm. Das folgende

Turing Scrapbook

ist ein solches Simulationsprogramm. Man könnte diese Webseite ins Deutsche übersetzen und leicht anpassen, dann könnte sie eventuell etwas für den Unterricht sein. Man kann mit "load" ein Programm in das Textfeld unten links laden und dieses mit "step" schrittweise ausführen. Aber vor allem: Man kann in das Textfenster auch ein eigenes "Programm" für die Turingmaschine eingeben und ausführen.

Vorstellbar wäre auch eine Mini-Prozessor-Simulation: Ein Prozessor könnte zwei Arbeitsregister haben, sowie Befehle, um Bytes vom Speicher in diese Register zu laden, etwas mit ihnen zu machen (z.B. die beiden Register zu addieren und das Ergebnis in das erste Register zu schreiben), die Registerinhalte in Speicheradressen zu schreiben und bedingte bzw. unbedingte Verzweigungen, die also den Befehlszeiger verändern. Gerade der 6502-Prozessor ist für solche Vorhaben ideal geeignet.

Sinnvoll in Hinblick auf die Grundfrage Wie funktioniert ein Computer? könnte dazu auch sein:

Bis zur Elektronik herunter zu verstehen, wieso man eigentlich mit zwei Transistoren einen Speicher bauen kann, der sich 1 bit merkt (Flipflop). Wie geht das eigentlich?

Man könnte einen einfachen Einplatinencomputer zusammenbauen, dabei seine Bestandteile diskutieren und kennenlernen und ihn schliesslich in irgendeinem Modell einsetzen. Das wäre etwas für eine Klasse, die besonders gern bastelt oder Modelle erstellt.

Mit dem Bit hat man das Kapitel Dualzahlen aufgeschlagen. Man könnte Rechnungen zur Basis 2 und 16 behandeln, dabei insbesondere die Hexadezimalziffern.

Vom Bit ausgehend, kann man das ganze Kapitel der Logik und insbesondere der Booleschen Algebra anreissen: Operationen mit Bits. UND, ODER, NICHT. Dass man etwa alle Operationen aus einer einzigen Operation herstellen kann, dem NAND (Nicht-Und). Die De-Morganschen-Theoreme. Wahrheitstafeln usw.

Wenn Interesse da ist, eine Programmiersprache zu erlernen, gibt es gute und weniger gute Wahlen. Eine gute Wahl wäre Logo (auch hier gibt es eine Webseite zum Üben: http://logo.twentygototen.org/ ). Denn Logo wurde genau für diesen Zweck - zum Kennenlernen: wie geht eigentlich Programmieren, wie fühlt es sich an? - konzipiert. Auch eine gute Wahl wäre Forth, da lernt man auch gleich etwas über die Datenstruktur des Stapels und wie diese nutzbringend eingesetzt werden kann. Eine schlechte Wahl wäre sicher Basic - in all seinen Varianten. Sprachen wie Java, C# oder C++ fallen vermutlich aus, da sie nicht schnell genug zu erlernen sind.

Ich bin kein Pädagoge. Daher weiss ich nicht, für welche Altersstufen welche der angerissenen Themen "richtig" sind. Ich bin mir aber sicher, dass die hier beschriebenen Wege vielen Schülern ein Interesse am Computer nahebringen dürften - viel eher als wenn man ihnen beibringt, Softwareprodukte wie Word und Excel zu bedienen. In letzterem Fall lernt man nicht wirklich etwas über Informatik, sondern macht nur einen Ausflug in das Hirn einiger Redmonder Programmierer.

Völlig abwegig finde ich auch das Argument "wirtschaftlicher Erfordernisse". Die Schule dient nicht wirtschaftlichen Interessen, sondern soll die geistige Entwicklung der Schüler begleiten und fördern. Es steht der von seinen persönlichen Interessen und Zielen motivierte Schüler im Vordergrund, den es bei diesen Interessen anzusprechen, zu fördern und dabei möglichst vielseitig auszubilden gilt. Dass davon auch die Wirtschaft profitiert, ist schön für sie, aber nur ein indirekter Effekt. Eine Einmischung steht ihr trotzdem nicht zu.

[1] Das Herz des KIM-1, der Mikroprozessor 6502 hatte neben dem Akkumulator nur zwei Register, glänzte dafür aber durch eine hohe Zahl von Adressierungsarten. Der Befehl LDA, um ein Byte in den Akkumulator zu laden, kennt z.B. nicht weniger als acht verschiedene Adressierungsarten (siehe http://www.obelisk.demon.co.uk/6502/reference.html#LDA).

Von der Regel zum semantischen Modell

2012-01-30T12:27:00.023+01:00

In diesem Blog will ich beschreiben, wie man mit wenig Aufwand einen Parser für eine selbstdefinierte domänenspezifische Sprache schreiben kann, der die vom Benutzer eingegebenen Regeln in passende ABAP-Datenstrukturen konvertiert. Ich verwende ein Beispiel, das ich hier schon öfter herangezogen habe: Die Verpackung von Lieferungen in Paletten.

Eine Palette kann den Inhalt einer oder mehrerer Lieferungen haben. Paletten können aber auch zu grösseren Verpackungseinheiten zusammengefasst werden, auch gemischt mit Lieferungen, und auch diese zusammengefasste Einheit ist wieder eine Palette. Vom Datenmodell ist eine Palette also ein Kompositum.

Wenn wir jeder Palette und jeder Lieferung eine Belegnummer geben und den Inhalt einer Palette darüberhinaus mit einer Positionsnummer durchnumerieren, können wir folgendes beispielhaftes Datenmodell in der Sprache ABAP formulieren:

types:

  ty_doc_number(10) type c,
  ty_item_number(6) type c,
  ty_pallet_item_type(2) type c,
  ty_doc_numbers type standard table of ty_doc_number 
    with non-unique default key,

  begin of ty_pallet_item,
      pallet_no   type ty_doc_number,
      item_no     type ty_item_number,
      type        type ty_pallet_item_type,
      content     type ty_doc_number,
    end of ty_pallet_item,
  ty_pallets type standard table of ty_pallet_item
    with key pallet_no item_no,

   begin of ty_model,
    pallet_numbers    type ty_doc_numbers,
    delivery_numbers  type ty_doc_numbers,
    pallets           type ty_pallets,
  end of ty_model.

Als mögliche Typen einer Position kommen nur "Palette" und "Lieferung" in Frage. Dafür prägen wir, wenn wir schon dabei sind, noch eine Konstante aus:

constants: begin of gc_pallet_item_type,
  pallet   type ty_pallet_item_type value 'PA',
  delivery type ty_pallet_item_type value 'DL',
end of gc_pallet_item_type.

Eine Instanz von ty_model ist demnach ein strukturiertes Datenobjekt, das aus drei Tabellen besteht: Je eine Tabelle enthält die benötigten oder verwendeten Lieferungs- und Palettennummern, und die dritte Tabelle listet positionsweise den Inhalt jeder Palette auf.

Eine Instanz von ty_model repräsentiert somit eine Packregel. Sie gibt an, auf welche Weise ein Vorrat von n Lieferungen auf m Paletten zu verteilen bzw. in m Paletten zu organisieren ist.

Eine nach meiner Ansicht für den Benutzer angenehme Notation einer solchen Packregel würde die Paletten und Lieferungen mit Ordinalzahlen durchnumerieren und Paletteninhalte in Klammern spezifizieren. Ein einfacher Fall:

1. Palette (
  1. Lieferung
  2. Lieferung )

würde also vorschreiben, den Inhalt von zwei Lieferungen in einer Palette zu verpacken.

Ein wenig komplexer wäre schon der hierarchische Fall:

1. Palette (
  1. Lieferung
  2. Palette )
2. Palette (
  2. Lieferung
  3. Lieferung )

Hier kommt die 2. Palette in zwei Notationen vor: Einmal als blosse Referenz - indem angegeben ist, dass sie zum Inhalt der 1. Palette gehört - und ein weiteres Mal, um ihren Inhalt zu spezifizieren. Es soll aber auch erlaubt sein, die zweite Notation geschachtelt zu verwenden, etwa so:

1. Palette (
  1. Lieferung
  2. Palette (
    2. Lieferung
    3. Lieferung
    )
  )

Das ist dieselbe Verpackungsvorschrift wie die vorherige - nur anders notiert.

Zeilenvorschub soll keine andere Rolle haben als anderer Leerraum auch. Ausserdem wäre es noch schön, wenn man abgekürzte Wörter wie "Lief" und "Pal" verwenden kann, um sich Schreibarbeit zu ersparen:

1. Pal ( 1. Lief 2. Lief )

Schliesslich soll es möglich sein, nacheinander mehrere Packregeln aufzuführen.

Wie kann man nun mit möglichst wenig Aufwand einen Übersetzer schreiben, der eine solche, frei erfundene Notation in das obige ABAP-Datenmodell transformiert?

In oMeta würde man nur die folgenden acht Zeilen benötigen, um einen Parser für die oben beschriebene Syntax zu definieren:

ometa HandlingUnitDefinition <: Parser {
  expr        = fullPallet+ end,      
  fullPallet  = pallet "(" content ")",
  pallet      = ordnum ( "Palette"  | "Pal" | "SSCC" ),
  content     = (spaces contentPart)+, 
  contentPart = fullPallet | delivery | pallet,
  delivery    = ordnum ( "Lieferung" | "Lief" | "LF"  ),
  ordnum      = spaces digit+ "."
  }

Auf die Details der Syntax von oMeta will ich hier nicht eingehen – ich habe die wesentlichen Züge dieser Sprache bereits in meinem Blog Eine objektorientierte Metasprache beschrieben. Hier soll es um die Integration von oMeta in ABAP gehen - und darum, um welche semantischen Aktionen man diese Definition noch erweitern muss, um eine Abbildung in ABAP-Daten zu erhalten.

Da es (noch! siehe [2]) den in ABAP eingebauten JavaScript-Interpreter CL_JAVA_SCRIPT gibt, ist es auch möglich, die oMeta/JS-Implementierung in ABAP zu verwenden. Als Basis dafür habe ich den Subroutinen-Pool Z_OMETA_BASE geschrieben. Ich habe extra die Form des Subroutine-Pools gewählt, der leicht mit Copy & Paste in ein (fast) beliebiges SAP-System übernommen werden kann.

Aus dem Programm Z_SEMANTIC_MODEL_EXAMPLE, das diese Übersetzung in ABAP leistet, schauen wir uns einmal die zentrale Routine rule_to_model an, die eine als String nach obigen Regeln eingegebene Verpackungsregel in eine Instanz von ty_model konvertiert:

* --- Apply parser to input, populating the semantic model
form rule_to_model using iv_rule type string
                   changing es_model type ty_model
                            ev_parse_errors type flag.

  data: lv_error_code type i,
        lv_result type string.

  clear es_model.

* Bind the semantic model
  perform bind(z_ometa_base)
    using 'pallets.model' es_model.

* Execute the parser
  perform match(z_ometa_base)
    using 'HandlingUnitDefinition' 'expr' iv_rule
    changing lv_result lv_error_code.

  if lv_error_code <> 0.
    ev_parse_errors = abap_true.
    message 'The rule entered is syntactically incorrect' type 'I'.
  else.
    ev_parse_errors = abap_false.
    perform normalize_model changing es_model.
  endif.

endform.                    "rule_to_model

Das aktuelle ABAP-Datenobjekt, das gefüllt werden soll, muss dem Interpreter bekannt gemacht werden. Durch Aufruf der bind()-Methode wird in JavaScript ein Proxy-Objekt erzeugt, auf das man mit JavaScript zugreifen kann. Ist dies gemacht, erfolgt der Aufbau der Daten durch Aufruf der Regel expr (zuvor generierten) Parsers HandlingUnitDefinition.

Mit der obigen Grammatik HandlinUnitDefinition allein wird das natürlich nicht funktionieren. Denn sie beschreibt ja nur die Syntax. Sie muss noch um die nötige Semantik angereichert werden. Das macht man in oMeta mit den sogenannten semantischen Aktionen. Wenn eine Regel passt, kann man, von einem -> gefolgt, Angaben im Quellcode der Hostsprache des Parsers (hier JavaScript) machen, die in diesem Fall auszuführen sind. Das Ergebnis der Evaluation einer solchen semantischen Aktion kann darüberhinaus in Form von Symbolen in anderen Regeln abgegriffen und in deren semantischen Aktionen weiterverwendet werden.

Hier sind nun mit den Regeln für delivery, pallet und fullPallet bestimmte JavaScript-Funktionen addDelivery(), addPallet() und buildPallet() verknüpft, in denen die gelesenen Daten direkt an die gebundenen ABAP-Variablen übertragen werden.

    ometa HandlingUnitDefinition <: Parser {
      expr      = fullPallet+ end,      
      fullPallet  = pallet:s "(" content:c ")"
              -> { buildPallet( s, c ) },
      pallet  = ordnum:n ( "Palette"  | "Pal" | "SSCC" )
              -> {addPallet(n)},
      content = (spaces contentPart)+, 
      contentPart = fullPallet | delivery | pallet,
      delivery  = ordnum:n ( "Lieferung" | "Lief" | "LF"  )
              -> {addDelivery(n)},
      ordnum  = spaces digit+:ds "." -> parseInt(ds.join(''))
      }

Die Zugriffsnotation für gebundene ABAP-Variablen ist in der ABAP-Hilfe dokumentiert. In dieser Notation müssen die Funktionen addDelivery(), addPallet() und buildPallet() folgendermassen implementiert werden.

function addDelivery(n) {
  return addDocNumber(pallets.model.delivery_numbers,"DL"+n);
  }
function addPallet(n) {
  return addDocNumber(pallets.model.pallet_numbers,"PA"+n);
  }
function buildPallet( id, content ) {
  var p = pallets.model.pallets;
  var wa, i;
  for (i=0;i<content.length;i++) {
    p.appendLine();
    wa = p[p.length-1];
    wa.pallet_no = id;
    wa.item_no = i+1;
    wa.type = content[i].substring(0,2);
    wa.content = content[i];
    }
 return id;
 }
function addDocNumber(table,id) {
  table.appendLine(); 
  table[table.length-1] = id;
  return id;
  }

Das ist alles. Probieren Sie es in Ihrem SAP-System aus: Sie können den Report Z_SEMANTIC_MODEL_EXAMPLE und den von diesem vorausgesetzten Unterprogrammpool Z_OMETA_BASE herunterladen und ersteren dann ausführen. Es erscheint ein Popup, in dem Sie eine stringförmige Verpackungsregel nach obiger Syntax eingeben können:[1]

Wenn die Syntax eingehalten wurde, kann die Transformation ausgeführt werden. Das von ihr produzierte semantische Modell wird schliesslich mit dem Baustein RS_COMPLEX_OBJECT_EDIT angezeigt (der auch vom SAP-Standard als Benutzerschnittstelle zur Dateneingabe beim Funktionsbaustein-Einzeltest verwendet wird):

Dieses Modell kann nun mit ABAP-Mitteln weiterverarbeitet werden. Es könnte beispielsweise als Template zum Abfüllen realer Lieferungen in Paletten benutzt werden.

Ich erwähnte im Blog Domänenspezifische Programmierung in ABAP, dass ein ähnliches Tool in meiner Firma im Einsatz ist. Ich hatte allerdings den Parser damals mit Hilfe von regulären Ausdrücken ausprogrammiert. Der Sinn dieses Blogs ist zu zeigen, dass sich das Parsen und Transformieren von Ausdrücken in einer frei definierten Syntax erheblich verkürzt - wenn man eine geeignete Metasprache verwendet.

Das muss nicht oMeta und nicht JavaScript sein. Nur reizte mich der Titel von Alessandro Warth's Dissertation über oMeta - Experimenting with Programming Languages [3] - zu einer Machbarkeitsstudie.

[1] Soweit ich das gesehen habe, gibt es in der Basis genau einen Funktionsbaustein, der ein Popup zur Eingabe eines freien Textes sendet. Er heisst TERM_CONTROL_EDIT und stammt vermutlich noch aus der Zeit, als das TextEditControl entwickelt wurde (das "Enjoy"-Release).
[2] Leider wurde die Klasse CL_JAVA_SCRIPT von SAP für Release 7.02 zum Auslaufmodell erklärt. Die Dokumentation kündigt an, die Klasse zu einem späteren Release aus der Wartung zu nehmen. Leider fällt sogar das Wort von der ersatzlosen Streichung. Das wird es für Zugänge wie den hier beschriebenen schwer machen. In Java hat man mit dem JSR-223 schon lange erkannt, wie wichtig die Integration dynamischer Sprachen ist. Mit Java SE6 kam dann ein Framework, um beliebige dynamische Sprachen in Java zu integrieren, das zu SE7 sogar noch um einige neue Bytecode-Anweisungen wie invokeDynamic bereichert wurde. Das zeigt, welch hoher Stellenwert in der Java-Welt den dynamischen Sprachen beigemessen wird.
[3] Alessandro Warth, Experimenting with Programming Languages, PhD dissertation, 2009, http://www.vpri.org/pdf/tr2008003_experimenting.pdf

XML Parser zum letzten

2012-01-24T20:26:00.023+01:00

Da, wie bereits früher erwähnt, meine Blogs mit XML-Themen am meisten gelesen werden und da ich auch hierzu die meisten Fragen erhalte, soll dieser Artikel die grundlegende Bedienungsfragen des XML-Parsers in ABAP ein für allemal klären. In einem früheren Blog habe ich den ereignisbezogenen, "SAX"-artigen XML-Parser erklärt. Hier soll es um den DOM-Parser gehen, der für kleinere Dokumente häufig die richtige Wahl ist.[1]

Es ist "nur" knapp 14 Jahre her, dass die erste Version des XML-Formats vom World Wide Web Konsortium herausgebracht wurde. Das ist ziemlich viel Zeit, vor allem in der IT. XML wurde in den ersten Jahren euphorisch begrüsst und hat sich in der Softwarewelt schnell verbreitet. Seine universelle Verwendbarkeit als Container für beliebige strukturierte Daten und die Existenz von Parsern in allen möglichen Sprachen und Systemen, sowie die Lesbarkeit und sogar Änderbarkeit mit einem beliebigen Klartext-Editor machten es zum Format der Wahl für alle möglichen Anwendungsdaten.

Mittlerweile ist man soweit, auch die Schattenseiten von XML wieder klar zu sehen. Die vielen spitzen Klammern, die Notwendigkeit, geöffnete Elemente wieder zu schliessen, die Notation für Attribute - all dies erzeugt ziemlich viel syntaktisches Rauschen, was die Lesbarkeit erschwert (das Argument vom vermeidbaren Daten-Overhead einmal ausser Acht gelassen). Das Argument, dass man wenigstens über Parser verfügt, die man nicht selbst entwickeln muss, verliert viel an Bedeutung, seit das Wissen um Parsergeneratoren nicht mehr auf die Hörsäle der Universitäten beschränkt ist, sondern sich in weiten Kreisen verbreitet hat, und seit Entwicklungsumgebungen wie Eclipse eine eingebaute Unterstützung für Parsergeneratoren bieten. Damit ist es im Handumdrehen möglich, Parser für selbst erfundene Sprachen zu generieren, deren Syntax genau auf ein spezifisches Problem zugeschnitten ist - die domänenspezifischen Sprachen (DSL).

Ironischerweise hat das Konzept der DSL, dem viele sich nun zuwenden, noch viel mehr Jahre auf dem Buckel als XML. Als Vision war die "Natürlichsprachlichkeit" bereits bei den ersten für kommerzielle Anwendungen entworfenen Programmiersprachen wie COBOL präsent: COBOL-Programme sollten für "Business People" flüssig lesbar sein, wenn sie natürlich auch – wie jede Programmiersprache – festen Syntaxregeln folgen mussten.

Aber wie dem auch sei. XML wird noch lange Zeit ein verbreitetes Datenformat bleiben. Für die ABAP-Programmierung spielt es immer dann eine Rolle, wenn mit der Aussenwelt kommuniziert werden muss - sei es mit dem Web-Browser in einer Webanwendung, sei es mit Nicht-SAP-Systemen zum Datenaustausch.

Zurück zum DOM-Parser in ABAP. Hier ist ein Programm, das ein als String gegebenes XHTML-Dokument auf das Vorkommen bestimmter XML-Elemente im DOM untersucht:

http://pastebin.com/eBGPGjrc

Ich werde es nun blockweise dokumentieren.

report  zz_dom_parse_xhtml.

Die Form eines Reports mit Unterprogrammen als einziger Modularisierungseinheit habe ich gewählt, weil dieser Report self-contained ist und daher ohne weiteres per Copy/Paste in einem SAP-System angelegt, studiert und ausgeführt werden kann. Mit Klassen wäre das nicht so einfach möglich. Ich hätte den Report selbst mit lokalen Klassen gestalten können. Aber Unterprogramme sind einfacher, ohne dass mir die lokalen Klassen in diesem Fall einen Vorteil verschaffen. Daher Unterprogramme - und keine Methoden lokaler Klassen.

Ich habe mir angewöhnt, Testprogramme, bereits während ich sie verfasse, durch Unterprogramme zu modularisieren - auch wenn ein kleiner Extraaufwand dazukommt, um für jedes Unterprogramm eine geeignete Schnittstelle zu definieren. Das rentiert sich recht bald: Wenn das Testprogramm erfolgreich war, kann ich den Code der Unterprogramme in Methoden einer passenden Klasse übernehmen, die ich dann für den produktiven Einsatz vorsehe. So auch hier: Unterprogramme von Testprogrammen im XML-Bereich sind als Methoden in meine Klasse ZCL_XML_HELPER gewandert, für die es mittlerweile sehr viele Verwender gibt.

data: go_xml type ref to if_ixml,
      go_stream_factory type ref to if_ixml_stream_factory.

Sowenig globale Variablen wie möglich. Das XML-Basisobjekt und die XML Stream Factory sind Ausnahmen von dieser Regel. Ich benötige nur eine Instanz von ihnen, egal wie oft Code aus diesem Programm durchlaufen wird. Diese beiden Objekte mögen einen internen Zustand haben, der sich jedoch nicht auf die von ihnen erzeugten oder bearbeiteten Objekte auswirkt. Es gibt also kein Reentrance-Problem.

parameters: p_elnam type text30 default 'p',
            p_ns    type text128 default 'http://www.w3.org/1999/xhtml',
            p_aware as checkbox default space.

Dies sind Testparameter. Das Beispielprogramm soll alle <p>-Elemente in einem XHTML-Dokument herausfinden und deren ID's und Textinhalt ausgeben. p_elnam gibt dabei den Elementnamen an, p_ns den Namensraum. Ich verwende hier die Datentypen textNNN, die im Gegensatz zu charNNN gross/klein-sensitiv arbeiten. Das Flag p_aware steuert, ob im Parser die Namespace Awareness explizit angeschaltet werden soll. Wir werden jedoch sehen, dass die verwendete Methode get_elements_by_tag_name_ns() unabhängig von diesem Flag arbeitet.

Wo werden die Daten initialisiert? Beim Laden des Reports. Ich habe mir einen Report-Rumpf als Muster in den Code Editor eingespeist, der mir beim Tippen der Schlüsselwörter initialization oder start-of-selection vorgeschlagen wird. Er verknüpft diese beiden Events mit entsprechenden Unterprogrammen, so dass ich ab dort in sauberen Stack-Einheiten mit lokalen Daten arbeiten kann:

initialization.
  perform init.
 
start-of-selection.
  perform start.

Die Initialisierungsroutine ist nun das Erwartete - sie erzeugt die beiden globalen Objekte mit den dafür vorgesehenen create-Methoden:

*---
form init.
  go_xml = cl_ixml=>create( ).
  go_stream_factory = go_xml->create_stream_factory( ).
endform.                    "init

Kommen wir nun zur Routine start, die beim Druck auf "Ausführen" aufgerufen wird. Hierbei werden nacheinander drei Schritte ausgeführt: Ein Beispieldokument wird in ein Dokument vom Typ if_ixml_document eingelesen. Danach werden bestimmte Elemente in diesem Dokument gesucht und in einer Internen Tabelle vom Typ dcxmlelems zurückgegeben. Diese werden schliesslich in einer ganz altbackenen ABAP-Liste mittels write ausgegeben.

Genau diese drei Schritte sind in der Routine start dokumentiert:

* ---
form start.
 
  data: lo_xhtml type ref to if_ixml_document,
        lt_elements type dcxmlelems,
        lv_element_name type string,
        lv_namespace type string.
 
  try.
 
      perform build_test_xhtml using p_aware changing lo_xhtml.
 
      lv_element_name = p_elnam.
      lv_namespace = p_ns.
      perform search_elements using lo_xhtml lv_element_name lv_namespace
                              changing lt_elements.
 
      perform write_result using lt_elements.
 
    catch cx_ixml_parse_error.
* Error log has already been written
  endtry.
 
endform.                    "start

Das XHTML-Dokument wird in zwei Schritten aufgebaut. Zuerst wird es als String erzeugt, den man irgendwie als gegeben betrachten kann. Er könnte z.B. aus einer Datei eingelesen worden sein oder über einen HTTP-Request aus dem Internet stammen. In einem zweiten Schritt wird dieser String dann geparsed, d.h. in das interne DOM-Format gewandelt:

* ---
form build_test_xhtml
  using iv_ns_aware type flag
  changing eo_xhtml type ref to if_ixml_document
  raising cx_ixml_parse_error.
 
  data: lv_xhtml type string.
 
  perform get_test_html_as_string changing lv_xhtml.
 
  perform parse using lv_xhtml iv_ns_aware
                changing eo_xhtml.
 
endform.                    "build_test_xhtml

Die Routine get_test_html_as_string erzeugt den Beispielstring, den man drt für Testzwecke beliebig umbauen kann:

* ---
form get_test_html_as_string changing ev_xhtml type string.
  data: lv_xhtml type string.
  concatenate
`<?xml version="1.0" encoding="ISO-8859-1" ?>`
`<html xmlns="http://www.w3.org/1999/xhtml">`
`<head>`
`<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />`
`<title>Wenn HTML zu XHTML wird</title>`
`</head>`
`<body>`
``
`<h1><a name="start" id="start">Wenn HTML zu XHTML wird</a></h1>`
``
`<p id="erster" >Erster Paragraph.</p>`
`<p id="zweiter">Zweiter Paragraph.</p>`
`<p id="dritter">Na, wievielter Paragraph wohl?</p>`
`</body>`
`</html>`
  into ev_xhtml
  separated by cl_abap_char_utilities=>cr_lf. " Für Zeilenausgabe in Fehlermeldungen
endform.                    "get_test_html_as_string

Ich kann in ABAP nicht nur einfache Anführungszeichen, sondern auch Backticks (`) als Stringbegrenzer verwenden. Das ist nützlich in Fällen wie diesem: Meist kommen in XML- oder HTML-Dokumenten zwar eine Menge einfacher und doppelter Anführungszeichen vor, aber keine Backticks. So muss ich normalerweise nirgends Fluchtsequenzen für das Stringbegrenzungszeichen einführen. Ich konkateniere die Zeilen zu einem String, wobei ich aber Zeilenumbrüche als Trennzeichen verwende. Das hat den Vorteil, dass allfällige vom Parser ausgegebene Fehlermeldungen über die Zeilennummer leicht dem Quelltext zugeordnet werden können.

Nun zum eigentlichen Parsevorgang. Der DOM-Parser möchte nicht direkt einen String zur Eingabe haben, sondern einen Eingabestrom. Daher muss der übergebene String in einen Stream verwandeln. Ausserdem muss eine leere Instanz des Zieldokuments vom Typ if_ixml_document erzeugen und dem Parser übergeben. Er schreibt sein Ergebnis dann in diese Instanz:

* ---
form parse using iv_xml type string
                 iv_ns_aware type flag
           changing eo_doc type ref to if_ixml_document
           raising cx_ixml_parse_error.
 
  data: lo_parser type ref to if_ixml_parser,
        lo_stream type ref to if_ixml_istream.
 
  lo_stream   = go_stream_factory->create_istream_string( iv_xml ).
  eo_doc = go_xml->create_document( ).
 
  lo_parser   = go_xml->create_parser( 
                    document       = eo_doc
                    istream        = lo_stream
                    stream_factory = go_stream_factory ).
 
  if iv_ns_aware = 'X'.
    lo_parser->set_namespace_mode( 
                if_ixml_parser=>co_namespace_aware 
                ).
  endif.
 
  lo_parser->parse( ).
 
  if lo_parser->num_errors( ) > 0.
    perform do_parser_errors using lo_parser.
  endif.
 
endform.                    "parse

Wenn das Parsen ohne Fehler funktioniert hat, enthält eo_doc nun ein strukturiertes Abbild des eingelesenen XML-Dokuments. Nun kann man das Interface if_ixml_document verwenden, um dieses Dokument zu durchsuchen. Wenn wir den try-catch-Block in der Routine start noch einmal betrachten,

  try.
 
      perform build_test_xhtml using p_aware changing lo_xhtml.
 
      lv_element_name = p_elnam.
      lv_namespace = p_ns.
      perform search_elements using lo_xhtml lv_element_name lv_namespace
                              changing lt_elements.
 
      perform write_result using lt_elements.
 
    catch cx_ixml_parse_error.

so sind wir nun mit dem Erzeugen des XHTML-Dokuments lo_xhtml fertig. Das Programm kehrt auf diese Stackebene zurück und setzt, wenn es keinen Fehler gab, mit dem Aufruf der Routine search_elements fort. Vor dem Aufruf müssen die Eingabeparameter p_elnam und p_ns leider noch in Strings verwandelt werden, denn diesen Datentyp erwartet die if_ixml_document-Methode get_elements_by_tagname_ns, die wir aufzurufen gedenken. MOVEs von dieser Art sind in ABAP oft unvermeidlich. Zum Beispiel hier: Einerseits können Parameter nicht den Datentyp String haben. Andererseits werden die Schnittstellenparameter oft im Datentyp String erwartet.[2]

Wie sieht nun die Routine search_elements aus? Sie ruft die Dokumentmethode get_elements_by_tag_name_ns( ) auf, die eine if_ixml_node_collection aller gefundenen Elemente zurückliefert - deren Name und Namensraum also mit den angegebenen Werten übereinstimmt. Da der Zugriff auf diese Collection im Code etwas schwerfällig ist, erlaube ich mir den Luxus, sie in eine interne Tabelle von Objekten vom Typ if_ixml_element zu wandeln. Eine interne Tabelle in einer Loop abzuarbeiten, ist in ABAP viel lesbarer als das Iterieren einer Collection. Glücklicherweise gibt es für "eine Standardtabelle von iXML-Elementen" bereits den mit der SAP-Basis ausgelieferten und definierten Datentyp dcxmlelems:

* ---
form search_elements using io_xhtml type ref to if_ixml_document
                           iv_elnam type string
                           iv_ns    type string
                     changing et_elements type dcxmlelems.
 
  data: lo_elements type ref to if_ixml_node_collection.
 
  lo_elements = io_xhtml->get_elements_by_tag_name_ns(
                             name      = iv_elnam
                             uri       = iv_ns ).
 
  perform element_table_from_collection
    using lo_elements
    changing et_elements.
 
 
endform.                    "search_elements

Was macht element_table_from_collection? Was man erwarten würde: Es durchläuft die Collection, typisiert die Nodes als Elemente und fügt sie in eine interne Tabelle ein:

* ---
form element_table_from_collection
    using io_elements type ref to if_ixml_node_collection
    changing et_elements type dcxmlelems.
 
  data: lo_iterator type ref to if_ixml_node_iterator,
        lo_node type ref to if_ixml_node,
        lo_element type ref to if_ixml_element.
 
  lo_iterator = io_elements->create_iterator( ).
 
  do.
 
    clear lo_node.
    lo_node = lo_iterator->get_next( ).
    if lo_node is not bound.
      exit.
    endif.
 
    clear lo_element.
    lo_element ?= lo_node->query_interface( ixml_iid_element ).
    if lo_element is bound.
      append lo_element to et_elements.
    endif.
 
  enddo.
 
endform.             "element_table_from_collection

Wenn dies gemacht ist, geht es wieder in der Routine start weiter. Durch den Aufruf

      perform write_result using lt_elements.

werden die gesammelten Elemente an das Unterprogramm zur Ausgabe übergeben.

* ---
form write_result using it_elements type dcxmlelems.
 
  data: lo_element type ref to if_ixml_element,
        lv_id type string,
        lv_text type string.
 
  if it_elements is not initial.
    loop at it_elements into lo_element.
      lv_id = lo_element->get_attribute( 'id' ).
      lv_text = lo_element->get_content_as_string( ).
      write: / lv_id, at 15 ':', lv_text.
    endloop.
  else.
    write: / 
      'Keine Elemente mit diesem Namen und Namespace gefunden'.
  endif.
 
endform.                    "write_result

Zur Demonstration werden hier pro Element der Wert des Attributs id und der Textinhalt ausgegeben. Das erzeugt mit dem hier verwendeten Beispieldokument die Ausgabe:

DOM-Parser sucht nach einem Element in XHTML

erster        : Erster Paragraph.
zweiter       : Zweiter Paragraph.
dritter       : Na, wievielter Paragraph wohl?

Was ist, wenn es nicht funktioniert? Der Parser schreibt ein Protokoll aller beim Lesen des Streams aufgetretenen Fehler. Die Gesamtzahl dieser Fehler kann mit der Methode lo_parser->num_errors( ) abgefragt werden. Oben war in der Routine zu sehen, dass bei Fehlern in die Routine do_parser_errors abgesprungen wurde. Diese erzeugt eine Listausgabe aller gesammelten Fehler und löst dann die Ausnahme cx_ixml_parse_error aus. Diese propagiert im Callstack nach oben in die Routine start und wirkt dort als Stopsignal. Da eine Ausgabe bereits geschrieben wurde, ist keine explizite Behandlung der Ausnahme mehr nötig. Es genügt, dass die Ausführung der nachfolgenden Routinen search_elements und write_result verhindert wird, die ja sinnlos sind, wenn kein wohlgeformtes XML-Dokument eingelesen werden konnte.

* ---
form do_parser_errors
       using io_parser type ref to if_ixml_parser
       raising cx_ixml_parse_error.
 
  data: lo_error type ref to if_ixml_parse_error,
        lv_maxnum type i,
        lv_num type i,
        lv_text type string,
        lv_line     type i,
        lv_column   type i,
        lv_severity type i.
 
 
* Fehler im Nachrichtensammler einfügen
  lv_maxnum = io_parser->num_errors( ).
  while lv_num < lv_maxnum.
    lo_error = io_parser->get_error( lv_num ).
    lv_text  = lo_error->get_reason( ).
    lv_line  = lo_error->get_line( ).
    lv_column = lo_error->get_column( ).
    lv_severity = lo_error->get_severity( ).
    write: / lv_line left-justified no-gap, 
             '(' no-gap, 
             lv_column left-justified no-gap, 
             ')', 
             lv_text.
    add 1 to lv_num.
  endwhile.
 
* Wenn Fehler auftraten, Ausnahme auslösen
  if lv_maxnum > 0.
    raise exception type cx_ixml_parse_error
      exporting
        reason = lv_text
        line   = lv_line
        column = lv_column.
  endif.
 
endform.                    "write_parser_errors

Die ganze Thematik ist auch wunderbar – und viel umfassender als es ein Blog je sein könnte – in der SAP-Hilfe dokumentiert. Einsteigern empfehle ich zur Lektüre unbedingt den ABAP XML Jumpstart.

[1] Ich habe allerdings die Erfahrung gemacht, dass für kleine XML-Dokumente oft eine XSLT-Transformation die beste Wahl ist, die die gewünschten Inhalte gleich in die Komponenten einer passenden ABAP-Datenstruktur hineintransformiert. Aber trotz der guten Integration in die Workbench und der Möglichkeit, sogar die Transformationen zu debuggen, bedeutet die Sprache XSLT für viele leider eine (rein psychologische) Extrahürde.
[2] ... und nicht in den generischen Typen csequence oder clike, die in Schnittstellen oft die bessere Wahl sind, da sie einen Oberbegriff von type c und type string darstellen, so dass Datenobjekte beider Typen als Aktualparameter akzeptiert werden.

Savonarola - sein Horoskop und seine Direktionen

2012-01-08T12:25:00.039+01:00

Girolamo Savonarola (1452-1498) war ein Dominikanermönch, der inmitten der florentinischen Prachtentfaltung der Renaissance eine Abkehr von allen weltlichen Eitelkeiten predigte - und damit für einige Jahre grossen Erfolg hatte. Bekannt ist sein Feuer der Eitelkeiten - ein Scheiterhaufen auf der Piazza della Signoria in Florenz, auf dem viele bussfertige Bürger Symbole ihres weltlichen Lebenswandels verbrannten - darunter Frauengemälde, Parfüms, Salben, Puder, Spiegel, Perücken, Spielkarten, Würfel, Liederbücher, Musikinstrumente, Masken und andere Karnevalsutensilien, Bücher mit teilweise anstössigem Inhalt und dergleichen.[1] Bedauerlicherweise warf sogar Sandro Botticelli einige seiner Bilder in die Flammen. Und doch war das Feuer der Eitelkeiten nur ein Vorspiel zu einem anderen Feuer - zu Savonarolas Verbrennung als "Ketzer", die am 23. Mai 1498 am selben Ort durchgeführt wurde.

In der Monatsschrift Die Astrologie vom November 1932 befasste sich A. Schoeler mit dem Horoskop dieses Busspredigers, wobei er einige biographische Daten aus Savonarolas Leben mit den Primärdirektionen in Beziehung setzte.[2]

Die Geburtsdaten hatte Schoeler dem Liber de exemplis centum geniturarum von Hieronymus Cardanus entnommen.[3] Die Gestirnstände hatte er sich von Karl Weidner auf Basis dieser Daten nachrechnen lassen. Wie in solchen Fällen zu erwarten, musste er natürlich Abweichungen in den Positionsangaben zum Original feststellen. Wenn man mit einer modernen Ephemeride nachrechnet, erweisen sich - das ist ebenso natürlich - auch Weidners Angaben als fehlerhaft, wenn auch nur im Bogenminutenbereich. Beispielsweise steht der Mond richtig auf 16°44' Steinbock und nicht auf 16°50' wie bei Weidner. Immerhin stimmt der Mondstand auf ein Grad, der Aszendent auf zwei Grad mit der Angabe von Cardanus überein, so dass sich wenigstens keine Fehler bei der Datumsangabe eingeschlichen haben. Um Weidners Aszendenten zu reproduzieren, muss man die Weltzeit 16h42m45s am 21.9.1452 für Ferrara (44°50′ N, 11°37′ O) zugrundelegen (auch hier wieder eine beachtliche Abweichung zur Polhöhe 45°16', wie sie Cardanus angab - sie entspräche eher dem ca. 60 km nördlich von Ferrara gelegenen Ort Este, was allen bekannten Dokumenten über seinen Geburtsort widerspricht).

In der Figur sticht der Horoskopherrscher Mars ins Auge, in seinem Zeichen und im ersten Horoskophaus stehend. Er empfängt eine scharfe Opposition zum Saturn und ein Quadrat zum Mond im Steinbock im zehnten Haus. Dieses T-Quadrat von Mars, Saturn und Mond ist die Grundfigur seines Horokops. Die Willenskraft und Energie aus dem ersten Feld heizt hier das Saturn/Waage-Thema an, während der Mond im kühlen Steinbock die Freude an der Begrenzung, am Verzicht, an der Armut lehrt. Der Saturn in der Waage kann zwar, durch seine Stellung im "Du"-Haus, im Haus des öffentlichen Kontrahenten, mit den ihn bekämpfenden Exponenten der Kirche in Verbindung gesehen werden. Andererseits ist er auch eine Kraft in Savonarolas Wesen - das Predigen gegen den Luxus und die Annehmlichkeiten der "herrschenden Klasse" ist sicher verbunden mit einer tiefen Sehnsucht nach Gerechtigkeit, nach Frieden und Harmonie. Die Konjunktion des Saturn mit Merkur bringt eine geistige Vertiefung, die Konzentration auf das Wesentliche. Der Komplex steht - was schon Cardanus anmerkte - bei dem Fixstern Spica, der einen jungfrauhaft-kühlen, aber zugleich kämpferischen Einschlag geben soll. Baumgartner assoziiert das Bild der "Jungfrau von Orleans". Konjunktionen der Spica mit Merkur werden laut Baumgartner häufig mit einer besonderen Redegabe verbunden, für die Konjunktion Spica / Saturn weiss die Tradition: "Häretiker"! Das passt nicht schlecht, lautete doch das Urteil gegen Savonarola auf Häresie. Im weiteren Sinne kann schliesslich auch als Häretiker bezeichnet werden, wer eine gewohnte Lebensweise oder eingeschliffene soziale Strukturen angreift.[4]

Hören wir Schoelers Deutung:

Das ist die Figur eines energiegeladenen Herrenmenschen, der unbeugsam seinen Willen durchsetzt! Der Herr des Aszendenten, Mars, im eigenen Zeichen in Widder stehend, sechs Planeten über dem Horizont, fünf Planeten in positiven Zeichen und fünf Planeten in Eckhäusern: diese Konfiguration zeigt ohne weiteres einen Mann, der sich durch niemand und nichts hindern lässt, eine einmal als richtig erkannte Meinung gegen eine Welt von Feinden durchzufechten, und seien diese Feinde auch die vorgesetzte Kirchenbehörde oder sogar der Papst selbst. Dies ist der eifernde Zelot, welcher gegen jeden Übelstand und die Sittenlosigkeit der Zeit mit der Waffe der faszinierenden Rede zu Felde zieht! Gross wurde seine Macht und seine Wirksamkeit, denn der wachsende Mond im Steinbock und in der Himmelsmitte gab ihm eine einflussreiche Position. Die vielen Planeten im 7. Hause zeigen auch klar das Hervortreten seiner Person in der Öffentlichkeit und seine politische Tätigkeit, die weit über die Mauern des Florentiner Klosters San Marco ins Land hinaus reichte.

Aber auch die Selbstüberschätzung zeigen die Sterne; denn Mars im ersten Hause steht mit Saturn im siebenten Hause in scharfer Opposition. Und zu diesen beiden Planeten bildet der Mond im zehnten Hause noch Quadraturen. So gelang ihm denn auch nicht sein Plan, den Papst Alexander VI. zu stürzen. Im Gegenteil: Das Schicksal erreichte ihn selbst, als er öffentlich im Jahre 1498 auf dem Scheiterhaufen verbrannt wurde.

Schoeler listet nun einige Lebensereignisse Savonarolas auf und bringt sie in Verbindung mit den Primärdirektionen. Wie zu jener Zeit allgemein üblich, verwendet er die Halbbogenmethode zum Dirigieren und setzt ein Grad des Direktionsbogens einem Jahr gleich. Seine Direktionen kann man mit der Webanwendung primaries.jsp nachrechnen.

Eintritt in das Kloster der Dominikaner am 25.4.1475
Für dieses Ereignis bringt Schoeler, durchaus passend, die Direktion Sonne Opposition Jupiter convers, die allerdings bereits ein Jahr früher fällig wurde (12.4.1474).

Savonarola wird Prior des Klosters San Marco im Jahre 1490
MC Trigon Sonne direkt wurde am 1.12.1490 fällig. Wenig später wurde Savonarola als Kanzelredner berühmt (Mond Konjunktion Jupiter direkt Anfang 1492).

Savonarolas politische Tätigkeit beginnt im Jahre 1494
Schoeler führt für dieses, nur mit vager Jahresangabe versehene Datum die Direktion Mond Sextil Sonne convers auf, fällig am 27.5.1495. Auch Aszendent Trigon Sonne direkt (18.6.1493) und Mond Sextil MC direkt (6.12.1494) passen hierher.

Höhepunkt seiner Macht 1496/97
Schoeler nennt in diesem Zusammenhang die Direktion MC Konjunktion Venus convers, fällig am 18.2.1496.

Bann des Papstes am 12.5.1497
Nach Schoeler in Zusammenhang mit Glückspunkt Opposition Jupiter direkt zu sehen, eine Direktion, die recht genau zu diesem Zeitpunkt fällig wird. Am Himmel standen aber auch Mond Anderthalbquadrat Saturn direkt (1.8.1497) und Mond Anderhtalbquadrat Mars (1.8.1497).

Trotz des Verbotes betritt Savonarola wieder die Kanzel am 11.2.1498
Auch hier hat Schoeler wieder eine Direktion mit dem Glückspunkt als Signifikator: Glückspunkt Quadrat Jupiter convers. Man kann aber auch Mond Halbquadrat Mars direkt (20.4.1498) und Mond Halbquadrat Saturn convers (8.4.1498) in diesem Zusammenhang sehen.

Tod durch Verbrennen am 23.5.1498
Hier gibt Schoeler Aszendent Quadrat Mars convers an - eine Direktion, die von der Tradition sehr gut passt und bei ihm eine Abweichung von nur einer Woche zum Ereignis ergibt. (In Wirklichkeit fällt sie auf den 20.8.1498.) Eine Rektifikation der Geburtszeit, um diese Direktion passend zu machen, kann ausgeschlossen werden, da Cardanus den Mars fälschlich auf 13° Steinbock statt im Widder plaziert hat (und auch im Text erwähnt, der Mars stünde in dieser Figur im zehnten Haus).

Das Geheimnis liegt hier - wie auch sonst bei Direktionslisten - in der richtigen Auswahl der zu berücksichtigenden Direktionen. Es gibt eine Reihe weiterer Direktionen in diesen zwanzig betrachteten Lebensjahren, auch "starke" Direktionen, die man hätte in Betracht ziehen können. Aber sie sind nicht so gut in der Hauptstruktur des Horoskops, dem T-Quadrat von Mars, Mond und Saturn verankert wie die hier verwendeten. Darüberhinaus zeigt die Nachrechnung, dass es auch hier wieder einen beachtlichen Orbis gibt. Auch wenn sie auf den Tag genau berechnet werden kann, kann eine Primärdirektion durchaus erst ein Jahr vor oder nach ihrer exakten Fälligkeit wirksam werden. Dies weiss auch Schoeler:

Im allgemeinen aber ist zu sagen, dass überhaupt für die Direktion ein Umkreis zugestanden werden muss, der aber 1° nicht überschreiten soll. Dieser Umkreis für primäre Direktionen ist dadurch zu erklären, dass innerhalb eines Jahres Transite und eventuell auch Sekundärdirektionen ein Ereignis verzögern oder beschleunigen können. Immer aber wird ein wichtiges Ereignis durch eine primäre Direktion angezeigt.
Ferner ist eine gewisse Differenz dadurch möglich, dass mit einem gegebenen Datum nicht das eigentliche Ereignis bestimmt wird. Im vorliegenden Fall ist es sehr wohl möglich, dass die Zeit des Noviziats nicht so wichtig war wie der endgültige Eintritt ins Kloster.

Zu diesen Problemen kommen theoretische Fragen hinzu. Einmal eingestanden, dass die auch von Schoeler favorisierte Halbbogenmethode ohne Berücksichtigung eklitpikaler Breiten und mit dem Ptolemäusschlüssel für die Umrechnung in Lebenszeit das richtige Vorgehen ist, ist auch die Frage nach der Projektionsart auf die Ekliptik offen: Sollen die Gestirne, wenn sie nicht auf der Ekliptik stehen, vertikal auf diese projiziert werden, wie es die Astronomen und ihnen gleich die meisten Astrologen tun - oder sollte diese Projektion nicht richtiger längs ihrer mundanen Positionslinien erfolgen? Auch dadurch ergeben sich Abweichungen in den Auslösungen, die gut bei einem Jahr liegen können. Im Bewusstsein all dieser Unsicherheiten kommt es zu dem verhältnismässig grossen Umkreis der Primärdirektionen, der durch Hinzunahme anderer Methoden (Transite und wiederkehrende Konstellationen) weiter eingegrenzt werden kann.

[1] Ernst Piper: Savonarola, Prophet der Diktatur Gottes, Norderstedt 2009.
[2] Dr. A. Schoeler: Girolamo Savonarola, sein Horoskop und seine Direktionen. Die Astrologie, November 1932, S. 226-233.
[3] Hieronymus Cardanus, Liber de exemplis centum geniturarum, Online unter http://www.cardano.unimi.it/testi/operaomnia/vol_5_s_7.pdf, dort das Savonarola-Horoskop auf Seite 490.
[4] Baumgartner, Fixsterne und ihre Deutung in der Geburts-Astrologie, Sonderdruck 11 der Astrologischen Universal-Harmonien, Warpke/Billerbeck o.J. Spica ist dort Fixstern Nr. 49.

BIFF - eine Übung im Refaktorisieren

2011-12-07T21:01:00.024+01:00

Laut Statistik sind die Beiträge meines Blogs, die von Excel und XML handeln, besonders beliebt - neben dem Dauerbrenner Refactoring in ABAP. Das gibt mir die Rechtfertigung, mich hier erneut über ein Excel-Format auszulassen, und obendrein noch über das mittlerweile überholte Binary Interchange File Format (BIFF), das den Excel-Versionen bis einschliesslich Excel 2007 zugrundelag.

Dieses auf binären Records basierende Format, das von der Apache POI Gemeinde als Horrible Spreadsheet Format (HSSF) geführt wird, hat Microsoft selbst mit dem neuen Format Open XML (das den Dateien mit der Endung .xlsx zugrundeliegt) hinter sich gelassen.[1]

Dennoch gibt es immer noch User, die mit dem alten xls-Format arbeiten. Wenn die Daten aus solchen Excel-Sheets im SAP-System weiterverarbeitet werden sollen, verlangt man üblicherweise, dass der Benutzer sie als csv-Datei abspeichert, um sie danach als Textdatei mit einem CSV-Parser einlesen zu können - wie ich es im Blog Parser für komma-separierte Daten beschrieben habe.

Wenn dies nicht möglich ist, könnte man eine binäre Excel-Datei in ABAP mit den Objekten der OLE Automation einlesen und bearbeiten. In diesem Fall wäre das Format sogar egal: Ein OLE-Objekt spricht die Daten des darunterliegenden Spreadsheets über Zeilen-, Spalten- und Arbeitsblattnummer an, ohne dass der Aufrufer sich um die zugrundeliegende Datenstruktur kümmern muss.

Einziges Problem: Die OLE Automation erfordert einen SAP GUI. Damit ist sie für Hintergrundjobs, RFC-Bausteine oder Webanwendungen nicht geeignet.

Um zu sehen, ob es prinzipiell möglich ist, das native Excel-Format einer xls-Datei in ABAP direkt einzulesen, hatte ich im Jahre 2002 einen Baustein Z_EXCEL_TO_INTERNAL_TABLE geschrieben, der aber seitdem nie das Licht eines produktiven Einsatzes gesehen hat. Das Experiment war erfolgreich ausgegangen: Der Baustein war tatsächlich in der Lage gewesen, die wesentlichen Zellinhalte eines Excel-Files - Zahlen und Strings - in eine ABAP-Datenstruktur einzulesen.

Manche Dinge brauchen einfach ihre Zeit: Nach fast zehn Jahren wird dieser Baustein nun in einem produktiven Kontext benötigt: für die Eingangsbearbeitung von Dokumenten in einem Szenario, in dem den Benutzern keine Vorgaben über das verwendete Format gemacht werden können und Datenfiles sowohl im neuen (xlsx) als auch im alten (xls) Excel-Format eingehen.

Für das neue Format verwenden wir die von Ivan Femia und Gregor Wolf entwickelte Addon-Komponente abap2xlsx, die keine Wünsche offen lässt. Da auch das alte Format in der im Hintergrund laufenden Eingangsverarbeitung benötigt wird, war dies die Möglichkeit, den Baustein, der nun eine Dekade im Repository gelagert hatte, in kleinen Schritten zu verbessern: Ihn ein bisschen in Schuss zu bringen und zu entwanzen.

Programmiergewohnheiten ändern sich im Laufe der Jahre, und wenn es auch von Zeit zu Zeit nur wenige Änderungen zu sein scheinen, zeigen sich doch beim Blick auf zehn Jahre alten Code beträchtliche Unterschiede im Stil.

Die Namenskonventionen des CRM mit ihrem zweibuchstabigen Präfix verwendete ich allerdings schon damals. Und doch stimme ich mit Horst Keller [2] wie auch Robert C. Martin [3] überein, dass es sich bei diesen Präfix-Namenskonventionen nur um Krücken handelt und dass Variablennamen noch besser lesbar sind, wenn sie durch überhaupt kein Präfix verschmutzt werden. Aber präfixfreie Variablennamen können wir in uns in ABAP erst leisten, wenn es in der ABAP-Programmierergemeinde zur Gewohnheit geworden ist, wirklich kurze Methoden zu schreiben, d.h.: Nicht mehr hundert-, sondern zehnzeilige Methoden. Davon sind wir de facto noch entfernt. Solange das so ist, haben die "ungarische" und verwandte Konventionen noch ihre Existenzberechtigung: In einer Methode, die man nicht ganz auf dem Bildschirm zu sehen bekommt (also inclusive ihrer lokalen data-Definitionen), ist es nützlich, wenn man jeder Variablen sofort ihren Gültigkeitsbereich ansieht.

Natürlich würde ich heute für eine solche Aufgabe eine Klasse schreiben, keine Funktionsgruppe. Auch waren meine Funktionen damals viel länger als ich es mir heute erlauben würde. Insgesamt enthält diese Funktionsgruppe für das, was sie leistet, viel zu wenig Modularisierungseinheiten, d.h. vor allem zu wenig Unterprogramme.

In diesem speziellen Fall hatte ich mich aus Performancegründen obendrein zu einer intensiven Verwendung von Macros entschlossen: Der Stream eines einzelnen Worksheets ist im BIFF-Format ein langer binärer String, auf den ich immer wieder mit Offset und Länge zugreifen musste, um einzelne Bytes, Doppelbytes oder Vier-Byte-Wörter zu lesen. Um nicht für jedes einzelne Byte, das ich auf diese Weise lese, einen Unterprogrammaufruf machen zu müssen, hatte ich ein Macro _get_data mit zwei Parametern entworfen: Der Anzahl der zu lesenden Bytes und der Zielvariablen (ein Feld vom Typ x oder ein xstring), in die die Bytes hineingestellt werden sollen.

Nun ist es so, dass die Folge der zu lesenden Bytes im BIFF-Format an beliebiger Stelle durch das Ende des aktuellen Records unterbrochen werden kann. Es folgt dann meistens ein zweibytiger CONTINUE-Code und die Länge dieses CONTINUE-Records, und erst dann geht es weiter mit der Bytefolge. Um diesen Fall abzuhandeln, hatte ich in das Macro schrecklich viel Logik hineingepackt. Ich wundere mich nachträglich, wie ich diesen Code, ohne ihn debuggen zu können, verfasst haben kann [4]:

*---------------------------------------------------------------------*
* Macro zum Lesen von Daten aus dem Stream
*---------------------------------------------------------------------*
  define _get_data.
* Berechnen des Offsets nach erfolgtem Lesen
    lv_pos = gv_pos + &1.
* Zu gross? Fehler
    if lv_pos > gv_length.
      message 'Fehler: Speicherüberschreitung bei get data (1)' type 'X'.
    endif.

    if lv_next_key ne gc_record-continue or
       lv_pos < lv_next_pos.
*---------------------------------------------------------------------*
* Fall 1: Zu lesendes Datum liegt vollständig im aktuellen Record
*---------------------------------------------------------------------*
* Feld einlesen
      &2 = <gv_data>+gv_pos(&1).
* Globalen Positionszeiger vorsetzen
      add &1 to gv_pos.
    else.
* Abstand bis zum Offset des CONTINUE Key:
      lv_m_dist = lv_next_pos - gv_pos.
*---------------------------------------------------------------------*
* Fall 2: Zu lesendes Datum muss einen Continue-Record überspringen
*---------------------------------------------------------------------*
      if &1 > lv_m_dist.
* Erster Teil des Feldes kann eingelesen werden:
        &2 = <gv_data>+gv_pos(lv_m_dist).
* Jetzt Länge des CONTINUE Records ermitteln (little Endian Format!)
        lv_pos = lv_next_pos + 2.
        lv_m_xlength+1  = <gv_data>+lv_pos(1).
        add 1 to lv_pos.
        lv_m_xlength(1) = <gv_data>+lv_pos(1).
* lv_pos auf erstes Byte des CONTINUE Records setzen:
        add 1 to lv_pos.
* Neue lv_next_pos = Länge des CONTINUE Records + 4      + Offset von CONTINUE
*                  = Länge des CONTINUE Records + lv_pos
        lv_next_pos = lv_m_xlength + lv_pos.
* Der auf CONTINUE folgende nächste Key muss ermittelt werden:
        lv_length = lv_next_pos + 2.
        if lv_length <= gv_length.
          lv_next_key = <gv_data>+lv_next_pos(2).
          concatenate lv_next_key+1(1) lv_next_key(1) into lv_next_key in byte mode.
        else.
* Keine Daten mehr -> Schleife ist beendet
          exit.
        endif.
* Verbleibende, zu lesende Zeichenzahl ermitteln:
        lv_m_length = &1 - lv_m_dist.
* Reststring lesen und an &2 anhängen
        if lv_m_dist > 0.
          concatenate &2 <gv_data>+lv_pos(lv_m_length) into &2 in byte mode.
        else.
          &2 = <gv_data>+lv_pos(lv_m_length).
        endif.
* Globalen Positionszeiger vorsetzen
        gv_pos = lv_pos + lv_m_length.
      else.
* Jetzt Länge des CONTINUE Records ermitteln (little Endian Format!)
        lv_pos = lv_next_pos + 2.
        lv_m_xlength+1  = <gv_data>+lv_pos(1).
        add 1 to lv_pos.
        lv_m_xlength(1) = <gv_data>+lv_pos(1).
* lv_pos auf erstes Byte des CONTINUE Records setzen:
        add 1 to lv_pos.
* Neue lv_next_pos = Länge des CONTINUE Records + 4      + Offset von CONTINUE
*                  = Länge des CONTINUE Records + lv_pos
        lv_next_pos = lv_m_xlength + lv_pos.
* Der auf CONTINUE folgende nächste Key muss ermittelt werden:
        lv_length = lv_next_pos + 2.
        if lv_length <= gv_length.
          lv_next_key = <gv_data>+lv_next_pos(2).
          concatenate lv_next_key+1(1) lv_next_key(1) into lv_next_key in byte mode.
        else.
* Keine Daten mehr -> Schleife ist beendet
          exit.
        endif.
* String lesen und an &2 anhängen
        &2 = <gv_data>+lv_pos(&1).
* Globalen Positionszeiger vorsetzen
        gv_pos = lv_pos + &1.
      endif.
    endif.
  end-of-definition.

Der Code ist nicht falsch, aber trotzdem scheusslich und für das, was er tun soll, zu lang. Ein Beispiel: Wenn man sich die Bedingung des inneren if genau anschaut, so folgt sie bereits aus der Bedingung des umgebenden else-Zweigs. Das bedeutet, der innere else-Zweig kann nie durchlaufen werden und kann somit gelöscht werden.

Ich hatte nun die Möglichkeit, das Macro komplett durch ein Unterprogramm zu ersetzen. Um die ursprüngliche Intention (die Performance-Bedenken) zu berücksichtigen, habe ich das Macro aber so stehengelassen, dass wenigstens der Hauptfall weiterhin ohne Unterprogramm ausgeführt werden kann. Nur den eher weniger häufigen Fall, dass beim Einlesen von Bytes ein CONTINUE-Record übersprungen werden muss, habe ich in ein Unterprogramm ausgelagert. Das Macro sieht neu wie folgt aus:

  define _get_data.

    _compute_offset_by &1 lv_pos.

    if lv_next_key ne gc_record-continue or
       lv_pos <= lv_next_pos.

*---------------------------------------------------------------------*
* Fall 1: Zu lesendes Datum liegt vollständig im aktuellen Record
*---------------------------------------------------------------------*
* Feld einlesen
      &2 = <gv_data>+gv_pos(&1).
* Globalen Positionszeiger vorsetzen
      add &1 to gv_pos.

    else.

*---------------------------------------------------------------------*
* Fall 2: Zu lesendes Datum muss einen Continue-Record überspringen
*---------------------------------------------------------------------*
      perform read_over_continue using    &1 space
                                 changing &2
                                          lv_m_options
                                          lv_next_pos
                                          lv_next_key.
    endif.
  end-of-definition.

Das ist vor allem viel weniger Code als früher: So wenig, dass man sich trauen kann, das _get_data im Debugger mit einem Schritt auszuführen und das Ergebnis gerade noch mit blossem Auge nachvollziehen kann - zumindest wenn es nicht in den else-Zweig geht, aber in den könnte man mittels Einzelschritt (F5) hineindebuggen, da er ja in einem Unterprogramm ausgeführt wird.

Die anderen Macros wie _get_number zum Einlesen von einzelnen Records habe ich vollständig durch Unterprogramme ersetzt.

Mithilfe von Unit Tests konnte ich darüberhinaus einige Bugs aufdecken, die im Code noch schlummerten. Der erste einfache Test funktionierte noch so, dass ich ein komplettes File im Binärcode einlas:

  method test_simple.

    data: lv_xls type xstring,
          ls_xls type zexcel,
          ls_exp type zexcel.

* Einfaches XLS-Worksheet im Binärformat aufbauen
* | abc | 123 | xyz |
* | 456 | pqr | 789 |
    perform get_simple_xls in program zutil_excel_testdata changing lv_xls.

* ... und dem Funktionsbaustein vorlegen
    call function 'Z_EXCEL_TO_INTERNAL_TABLE'
      exporting
        iv_file_as_stream = lv_xls
      importing
        es_excel          = ls_xls.


* Testerwartung
    _insert_row_n_fields ls_exp-cells 'row;col;typ;ref' :
      '0001;0001;S;00000001',
      '0001;0002;F;00000001',
      '0001;0003;S;00000002',
      '0002;0001;F;00000002',
      '0002;0002;S;00000003',
      '0002;0003;F;00000003'.

    define _append.
      append &2 to &1.
    end-of-definition.

    _append ls_exp-strings:
      'abc',
      'xyz',
      'pqr'.

    _append ls_exp-float:
      123,
      456,
      789.

    cl_aunit_assert=>assert_equals( act = ls_xls
                                    exp = ls_exp ).

  endmethod.                    "test_simple

Um die Load der Funktionsgruppe nicht unnötig zu vergrössen, habe ich dabei die Herstellung des xls-Dokuments in ein externes Unterprogramm ausgelagert:

program zutil_excel_testdata.

form get_simple_xls changing cv_xls type xstring.

  data: lv_line type xstring.

  define _add_line.
    lv_line = &1.
    concatenate cv_xls lv_line into cv_xls in byte mode.
  end-of-definition.

* Binäres Bild einer Excel-Datei mit folgendem Inhalt:
* | abc | 123 | xyz |
* | 456 | pqr | 789 |

  _add_line:
'D0CF11E0A1B11AE100000...0FEFFFFFF00000000FEFF',
'FFFF000000001800000FF...FFFFFFFFFFFFFFFFFFFFF',
...
endform.

Würde ich diesen totalen Weg über den Funktionsbaustein für alle Testfälle wählen, die mir einfallen, so wäre die Gesamt-Ausführungszeit der Unit Tests zu hoch. Ich entschied mich daher, für die Teile des Codes, die die einzelnen Records auswerten, isolierte Tests zu schreiben.

Hier zum Beispiel ist eine Methode, die das Einlesen einer im Format RK_NUMBER codierten Ganzzahl testet:

  method test_get_rk_i.

    data: ls_excel type zexcel,
          lv_int type i.

    get_rk_number( exporting iv_data = '3A85F102'
            changing  cs_excel  = ls_excel ).

    read table ls_excel-int into lv_int index 1.
    assert_subrc( act = sy-subrc
                  msg = 'Die Ganzzahl wurde nicht erkannt' ).

    assert_equals( act = lv_int
                   exp = 12345678
                   msg = 'Ganzzahl wurde nicht korrekt gelesen' ).

  endmethod.                    "test_get_rk_i

Die RK_NUMBER-Tests laufen immer über die Hilfsmethode get_rk_number der Testklasse. Für die anderen Recordtypen gibt es ähnliche Hilfsmethoden. Sie stellen die benötigten globalen Daten - das Feldsymbol <gv_data> mit dem Stream, sowie gv_length mit dessen Länge, bereit.

  method get_rk_number.

    data: lv_next_pos type i,
          lv_next_key type recordkey,
          ls_cell type zexcelcell.

    assign iv_data to <gv_data>.
    gv_length = xstrlen( <gv_data> ).
    gv_pos = 0.

    perform get_rk_number using ls_cell
            changing lv_next_pos lv_next_key cs_excel.

  endmethod.                    "get_rk_number

Mit solchen kleinen Testmethoden konnte ich Probleme isolieren, die beim Einlesen von grösseren Excel-Dateien auftraten. Dann konnte ich den Code so lange ändern, bis auch der neue Test auf Grün ging. Wenn ich die Suite aktuell im Unit Test Browser mit Abdeckungsmesung laufen lasse, komme ich auf eine Prozedurenabdeckung von 85%. Für einzelne Routinen ist es klar, dass sie nicht durch Modultests abgedeckt werden können, z.B. read_file: Hier wird eine Datei aus dem Filesystem im Binärformat eingelesen und in einen xstring gestellt. Mehr als den Aufruf der Methode gui_upload() von cl_gui_frontend_services sowie dem Fehlerhandling enthält diese Routine aber auch nicht. Das ist also eine Lücke, die man lassen kann. Andere Stellen, die nicht abgedeckt sind, betreffen Grenzfälle: Nicht alle Parametrisierungen, mit denen der Baustein theoretisch aufgerufen würde, auch wenn sie zu einem Fehler führten, werden in einem Test durchgespielt. Wichtiger erschienen mir bei diesen nachträglich hinzugefügten Unit Tests die Kernfunktionen: Das Einlesen der verschiedenen Recordformate für Zahlen und Strings.

Natürlich bin ich noch lange nicht zufrieden mit dem Ergebnis der Refaktorisierungen. Man könnte die Sache noch weitertreiben. Da ich nur begrenzte Kapazitäten dafür aufwenden kann, muss aber irgendwo ein Punkt gemacht werden. Ich habe den Campingplatz sicher sauberer hinterlassen als ich ihn diesmal vorgefunden habe. Vielleicht gibt es ja ein nächstes Mal, um weitere Verbesserungen einzubringen.

Sehr hilfreich bei der Analyse des Formats und bei der Erstellung von Beispielen war mir übrigens ein altes, einfaches Programm namens biffview.exe, das den Stream eines Worksheets analysiert und die einzelnen Bestandteile hexadezimal ausgibt - mit Verweis auf die Spezifikation des jeweiligen Recordtyps.

[1] Was das neuere OpenXML-Format angeht, so ist die Konvertierung von und nach ABAP mit der sehr komfortablen Softwarekomponente abap2xlsx gelöst, die eine bemerkenswert grosse Teilmenge des Excel-Feature-Sets unterstützt.
[2] Horst Keller, Wolf Hagen Thümmel: ABAP-Programmierichtlinien, Galileo Press, 2009
[3] Robert C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall International, 2008.
[4] Es ist allerdings ein Mythos zu glauben, Macros liessen sich grundsätzlich nicht debuggen. Das Problem für den Debugger besteht ja nur darin, dass er den ausgeführten Anweisungen keine laufende Quelltextzeile zuordnen kann. Wenn man den Macro-Quelltext in eine Include-Datei auslagert - etwa so:

define _langes_macro.
  include z_langes_macro_corpus.
end-of-definition.

dann werden die einzelnen Anweisungen im Debugger ganz normal erreichbar. Das funktioniert allerdings nur für parameterlose Macros, denn die Symbole &1 etc. können vom Compiler nur im Gültigkeitsbereich einer Datei aufgelöst werden.

Eine kleine Anfrage - und die Folgen

2011-10-15T11:30:00.016+01:00

Am 22. September erhielt ich per Mail die Anfrage,

...ob Sie die Lösung von folgender Rechnung zufällig wissen:
1 2 3 4 5 6 7 8 9 = 2011

Die Zahlen müssen der Reihenfolge nach gebraucht werden, es darf mit +, -, · und : gerechnet werden und Klammern gesetzt.

Ich wünsche Ihnen einen schönen Abend!

Natürlich wusste ich die Lösung dieser Rechnung nicht. Ich wusste aber, dass Aufgaben dieser Art häufig in den Rätselecken von Zeitschriften zu finden und meist mit ein bisschen Getüftel und Probieren zu bewältigen sind – eine Tätigkeit, die von Laien oft mit Mathematik verwechselt wird, aber praktisch nichts mit ihr zu tun hat. Mathematik wäre es, wenn es einen "Top Down Approach" zur Lösung gäbe, man also aufgrund von systematischen, grundsätzlichen Überlegungen eine Lösung finden könnte. Das schien bei diesem Problem nicht der Fall zu sein.

Wen es als Tüftelei interessiert: Die Fussnote [1] zeigt einen Weg zu einer Lösung. Was man dabei nicht erfährt: gibt es eventuell noch mehr Lösungen? Der Lösungsweg ist nicht systematisch, sondern eine Art zielgerichtetes Probieren. Gibt es auch einen Ansatz, mit dem man mit Papier und Bleistift systematisch alle Lösungen herausfinden kann? (Vermutlich nicht.)

Da mir aber kein mathematischer systematischer Zugang zum Problem einfiel, wechselte ich schliesslich die Rolle: Ich schaute mir das Problem als Informatiker an. Wie praktikabel ist zum Beispiel die Holzhammermethode, alle möglichen Ausdrücke mit einem Computer auszurechnen? Mit wie vielen Möglichkeiten hat man es eigentlich zu tun?

Es fällt auf, dass die Zahl der Möglichkeiten offenbar ein Produkt ist: Die Zahl der möglichen Klammerungen multipliziert mit den Wahlmöglichkeiten für die acht Operationen. Letztere Anzahl ist leicht zu bestimmen: Da nur die vier Grundrechenarten zulässig sind und jede der acht Operationen unabhängig von den anderen gewählt werden kann, gibt es

4⁸ = 65'536

Wahlmöglichkeiten für die Operationen.

Die möglichen Klammerungen führen zu den Baumdarstellungen arithmetischer Ausdrücke und schliesslich zu den sogenannten Catalanschen Zahlen. In diesem Fall kommt man auf

C₈ = 1430

verschiedene Möglichkeiten, den Ausdruck zu klammern. Hier fragte ich mich - von diesem Problem ausgehend: Kann man die möglichen Klammerungen in Form eines Algorithmus der Reihe nach durchzählen? Im Blog Ein Algorithmus zum Aufzählen von Ausdrucksbäumen habe ich das Problem und die Lösung skizziert. In allen Details dargelegt, führte das zu einem kleinen Artikel, in dem ich den Weg vom Ausdrucksbaum über ein zugeordnetes Schema, eine Signatur und Zahlenfolgen, die ich "gerichtet" nannte, beschritt. In diesem Artikel beschreibe ich auch den gesuchten Algorithmus.

Das Produkt der Klammerungen mit den möglichen Belegungen der acht Operationen ergibt also 93'716'480 zu prüfende Ausdrücke - eine vom Rechner leicht zu handhabende Grösse, falls man sich für die richtige Programmiersprache entscheidet.[2]

Hier noch einmal die Anforderungen:

Es sollte nicht mit den üblichen Gleitkommazahlen, sondern mit rationalen Zahlen, also Paaren {zaehler,nenner} ganzer Zahlen gerechnet werden, damit nicht aufgrund von Genauigkeitsverlusten eine Lösung verlorengeht.

Die Auswertung eines Ausdrucks kann natürlich abgebrochen werden, sobald eine Division durch Null auftritt.

Nach dem Assoziativgesetz identische Ausdrücke wie a·(b·c) und (a·b)·c sollen nur einmal in der Ergebnisliste vorkommen.

Die gefundenen Klammerausdrücke sollten in einer für Menschen lesbaren Form ausgegeben werden – unabhängig davon, welche Datenstruktur intern zur Darstellung der Ausdrücke gewählt wird.

In der Produktbildung

Klammerungen × Mögliche Wahlen der Operationen

ist bereits ein ideales Schema für die Parallelisierung angelegt: Für jedes festes Klammerschema ergibt sich die Aufgabe, alle acht Plätze mit den verschiedenen möglichen Operationen zu belegen, den entstehenden Ausdruck zu evaluieren und zu prüfen, ob er das gewünschte Ergebnis liefert. Der Zeitpunkt, wenn neue Klammerschemata aufgebaut wurden, ist daher gut für einen Schnitt geeignet, bei dem man Threads starten und parallel abarbeiten kann.

Den vollständigen Quelltext und die Binaries des Programms, das ich zur Lösung dieser Aufgabe implementiert habe, findet man bei github unter dem Link

https://github.com/rplantiko/computeExpressions

Hier will ich einige Ideen der Implementierung genauer erörtern.

Eine grundlegende Designentscheidung war, für ein einzelnes Klammerschema eine Klasse ExpressionTemplate einzuführen. Ein Objekt des Type ExpressionTemplate enthält die Angaben über ein konkretes Klammerschema, aber auch einen Vektor für die gefundenen Ergebnisse. Es kann also mit seinen eigenen Daten arbeiten, ohne vom Rest des Programms abzuhängen.

Immer wenn der Algorithmus für Klammerungen ein neues Klammerschema aufgebaut hat, wird eine neue Instanz von ExpressionTemplate gebildet und kommt in einen Vorrat, die globale Variable

std::vector<ExpressionTemplate*> worklist;

Dies ist übrigens die einzige globale Variable, die sich während des Programmlaufs noch ändert.

Über einen Parameter numThreads, den man dem Programm zur Ausführung mitgeben kann, wird gesteuert, wieviele Klammerschemata von der CPU auf einmal verarbeitet werden dürfen. Sobald die worklist diese Anzahl von Einträgen erreicht hat, werden die Threads gestartet. Jeder Thread arbeitet auf einer eigenen Instanz von ExpressionTemplate und kommt damit weder den anderen noch dem aufrufenden Thread ins Gehege. Da die Threads ungefähr alle die gleiche Verarbeitungszeit haben, genügt ein FIFO-Join, um die Beendigung aller Threads abzuwarten: Auf die Beendigung des zuerst gestarteten Threads wird als erstes gewartet, danach auf den zweiten usw.[3]

Hier die Besucherfunktion nextExecutionPlan, die für jedes Klammerschema einmal aufgerufen wird.[4]

void nextExecutionPlan( node* root ) {

  if (root != 0) {  // There must be a final cleanup call with root = 0
    worklist.push_back( 
      new ExpressionTemplate(root,numbers,expectedResult,size) 
      );
    }
    
  if (worklist.size() >= numThreads || root == 0) {
  
    std::vector<pthread_t> threads;
  
    for (auto templ = worklist.begin(); templ != worklist.end(); ++templ) {
      pthread_t t;
      pthread_create( &t, 0, evaluate, *templ );
      threads.push_back( t );
      }
    
// Waiting for the end of the threads, in the order of their creation 
// (not so bad, but could be improved, of course)    
    for (auto t = threads.begin(); t != threads.end(); ++t ) {
      pthread_join( *t, 0 );      
      }

// The work of this package is done. Print the result & free the ressources   
    for (auto templ = worklist.begin(); templ != worklist.end(); ++templ) {
      (*templ)->printResults();
      delete *templ;
      }    
    
    worklist.resize( 0 );
    
    }
    
  }

Nach Ausführung muss schliesslich noch ein allfällig verbliebener Rest von Threads abgearbeitet werden (wenn nämlich die Gesamtzahl der Klammerschemata nicht durch die gewählte numThreads teilbar ist). Das erledige ich, indem ich am Schluss die Funktion noch einmal mit root = 0 aufrufe.

Wie habe ich die Auswertung eines Ausdrucks implementiert? Das Klammerschema wird im Konstruktor der Klasse ExpressionTemplate in eine "angereichertes" Datenstruktur überführt. Hier ist der Typ eines angereicherten Knotens:

typedef struct valuatedNode {
  bool isLeaf;
  int* op;
  rational value;
  struct valuatedNode* left;
  struct valuatedNode* right;
} valuatedNode;

Neben den bekannten Elementen isLeaf, left und right gibt es einen Zeiger auf eine Ganzzahl in einem für die ganze Laufzeit der Klasse fixen Array ops = new int[size]; Die Plätze dieses Arrays nehmen nur die Zahlen 0 bis 3 an und werden als Offsets für die Ermittlung des richtigen Funktionszeigers aus der Konstanten OPERATION verwendet.

// Operations with rational numbers  
void plus(rational *first, rational second);
void minus(rational *first, rational second);
void times(rational *first, rational second);
void by(rational *first, rational second);

// Any operation on rationals
typedef void(*operation)(rational*, rational);

const operation OPERATION[4] = { plus, minus, times, by  };

So braucht man für jede neue Auswahl von Operationen nur die Ganzzahlen im Array ops zu ändern, und die Evaluierung greift dann automatisch auf die richtige Operation zu.

Um die Kombinationen der Operationen der Reihe nach durchzugehen, verwende ich eine Ganzzahl, die ich einfach von 0 bis 65535 durchzähle. Ihre acht Bitpaare, die ich in den Array ops schreibe, liefern dann alle möglichen Variationen der Operationen. Ein weiterer Trick ist, dass ich die Stelle value des valuatedNode-Typs, die ja streng nur für Blätter, nicht für Operationsknoten nötig ist, für Operationsknoten mit dem aktuellen Zwischenergebnis besetze. Da ich den Array der Knoten von hinten nach vorne durcharbeite, sind alle Referenzen, auf die ein Knoten verweist, bereits mit Werten belegt. So kann der Ausdruck ohne Rekursion in einer ganz gewöhnlichen Schleife abgearbeitet werden.[5]

void ExpressionTemplate::evaluateAllocations() {

// Create all 4**size combinations of operations,
// using a bit field of length 2*size
// If size becomes > 31, think of another implementation of this part
  long long int counter = 1 << 2*size;

  while (counter) {
    counter--;

    long long int allocation = counter;
    nodes[0].value.denom = 0;  // Makes result unequal to everything
    int iOp = size-1;

    for (valuatedNode* current =  nodes + 2*size;
                       current >= nodes;
                       current-- ) {

      if (!current->isLeaf) {

// Pop next operation from bit field
        ops[iOp--] = allocation & 0b11;
        allocation >>= 2;

// Skip [ *, [ *, ...], <>[*,...] ] & the like by associativity
        if  (isDuplicateByAssociativity( current )) break;
        
// Compute next intermediate result
        current->value = current->left->value;
        OPERATION[*current->op](&current->value,current->right->value);

// ignore div 0
        if (current->value.denom == 0) break;

        }

      }

    if (equals(&expectedResult,nodes[0].value)) {
      int* result = new int[size];
      for (int i=0;i<size;i++) result[i] = ops[i];
      results.push_back( result );
      }
    }
  }

Die Laufzeiten des Programms ergaben noch eine Überraschung. Bei leichten Schwankungen von +/- 0.5 sec ergibt sich folgende Aufstellung [6].

Anz. Threads    Laufzeit
1             : 6.1 sec
2             : 4.1 sec
3             : 4.0 sec
5             : 3.3 sec
10            : 2.5 sec
20            : 2.5 sec
50            : 2.0 sec
100           : 1.9 sec
200           : 1.6 sec
500           : 1.6 sec
1000          : 1.5 sec
1500          : 1.4 sec

Naiv könnte man ja meinen, dass es nichts bringt, eine CPU, die acht Prozessorthreads hat, mit mehr als acht Threads zu behelligen. Die interne Pufferung von auszuführenden Threads ist aber auf modernen CPUs mittlerweile so weit optimiert, dass man offenbar am besten fährt, gleich alles was man hat, auf die CPU zu werfen und ihr selbst die Ausführung zu überlassen! Die Ausführungszeit sinkt kontinuierlich mit der Anzahl der gleichzeitig gestarteten Threads, ohne dass hier ein Minimum erkennbar wird! Wenn alle 1430 Threads gleichzeitig gestartet werden, ist man um den Faktor vier schneller als bei der serieller Abarbeitung.

Ach ja, die Ergebnisse selbst sollen nicht verschwiegen werden! Das Programm gibt die folgenden 41 Lösungen aus. Viele Mehrfachnennungen aufgrund des Assoziativgesetzes werden durch die Implementierung bereits unterdrückt. Manche der Lösungen würde man trotzdem noch als gleichartig betrachten.

2011 = 1-(2·(3+(((4-5)-(6+7))·8·9)))
2011 = 1-((2·3)+(4:((5-6):7)·8·9))
2011 = 1-((2·3)+(4·(5-6)·7·8·9))
2011 = 1+(2:(3:(((4+5)·6·7·8)-9)))
2011 = 1-((2·3)+(4:(((5-6):7):(8·9))))
2011 = 1-((2·3)+(4·(5-6)·7·8·9))
2011 = ((1+(2·(3+(4·5))·6))·7)+(8·9)
2011 = 1-(2·(3+((4-(5+6+7))·8·9)))
2011 = (((1:2)-((3-(4+5))·6·7))·8)-9
2011 = 1-(((2:3)+(4:(5-6)·7·8))·9)
2011 = 1-(((2:3)+(4·(5-6)·7·8))·9)
2011 = 1-(((2:3)+(4:((5-6):(7·8))))·9)
2011 = 1-(((2:3)+(4·(5-6)·7·8))·9)
2011 = 1+(2·3·((4·((5·6)+(7·8)))-9))
2011 = 1-(2:(3:(4+5-(6·7·8·9))))
2011 = (1·2)+((3+4)·((((5·6)+7)·8)-9))
2011 = 1·(2+((3+4)·((((5·6)+7)·8)-9)))
2011 = (1·2)+((3+4)·(5+(6·((7·8)-9))))
2011 = 1·(2+((3+4)·(5+(6·((7·8)-9)))))
2011 = 1+((2+((3-(4·((5:6)-7)))·8))·9)
2011 = 1-((2·3)+(4:(5-6)·7·8·9))
2011 = 1-((2·3)+(4·(5-6)·7·8·9))
2011 = 1+(2:(3:(((4+5)·6·7·8)-9)))
2011 = 1-((2·3)+(4:((5-6):(7·8·9))))
2011 = 1-((2·3)+(4·(5-6)·7·8·9))
2011 = ((1+2+3+4)·((5·6·7)-8))-9
2011 = 1·((((2·3)+4)·((5·6·7)-8))-9)
2011 = (1·((2·3)+4)·((5·6·7)-8))-9
2011 = (((1·2·3)+4)·((5·6·7)-8))-9
2011 = ((1+2+3+4)·((5·6·7)-8))-9
2011 = (1·2)-((3+4)·(((5-(6·7))·8)+9))
2011 = 1·(2-((3+4)·(((5-(6·7))·8)+9)))
2011 = 1-(((2:3)-4)·(5+6+(7·8))·9)
2011 = 1-(2·3·(((4-(5+(6·7)))·8)+9))
2011 = 1+(2:3·(4-(5-(6·7·8)))·9)
2011 = 1+(2:(3:((4-(5-(6·7·8)))·9)))
2011 = (1:(2-3))+(4·(5-(6-(7·8·9))))
2011 = (1·(2-3))+(4·(5-(6-(7·8·9))))
2011 = (1·2)-(3-(4·(5-(6-(7·8·9)))))
2011 = 1·(2-(3-(4·(5-(6-(7·8·9))))))
2011 = 1-(2:(3:(4+5-(6·7·8·9))))

Fussnoten

[1] Mein Kollege Rolf Bertschinger fand die folgende Lösung: Von 2011 eins abgezogen, ergibt 2010, eine durch 6 = 2*3 teilbare Zahl. Man hat also eventuell gute Chancen, wenn man den Ausdruck mit

1 + 2·3·...

beginnen lässt. 2010 ergibt, durch 6 dividiert, 335. Der gepunktete Teil des Ausdrucks sollte also irgendwie 335 ergeben. Nun muss man die Grösse der verbleibenden Möglichkeiten, Produkte zu bilden, ins Spiel bringen: Wir haben noch die Zahlen 4 bis 9 zur Verfügung. Wenn man Produkte von drei Zahlen bildet, ergibt 6·7·8 schon fast das Gewünschte, nämlich 336. Wenn wir die 9 einen Moment aussen vor lassen, hätten wir mit

4 - 5 + 6·7·8 = 335

schon einen brauchbaren Ansatz. Leider stört dann aber die 9. Es scheint hoffnungslos, die 9 nun noch wegzubekommen, wenn doch alle anderen Zahlen schon verbraucht sind! Das Aha ist nun: Wenn man vorne, statt, mit 3 zu multiplizieren, durch 3 dividiert, hat man im Vergleich den nachfolgenden Ausdruck durch 9 dividiert. Das wird gerade korrigiert, wenn man am Schluss noch mit 9 malnimmt! So kommt man auf

1 + ( 2 : 3 ) · ( 4 - 5 + 6·7·8) · 9

[2] Weil ich bei dieser Gelegenheit die Groovy-Bibliothek GPars kennenlernen wollte, machte ich eine erste Implementierung in Groovy. Das war für dieses Problem eine schlechte Wahl. Da Groovy eine hoch dynamische Sprache ist, die alles Nötige erst zur Laufzeit ermittelt, benötigte mein Programm, obwohl es parallelisiert auf 8 Prozessorthreads lief, zehn Stunden, bis es alle Ergebnisse ermittelt hatte! Das ist keine Kritik, sondern nur eine Beobachtung! Groovy ist eine extrem ausdrucksstarke Sprache, die sich dem Ideal "Development by Config" schon sehr stark nähert. Applikationsdesign, bei dem man es mit einem User Interface zu tun hat, kann bei Einsatz von Groovy nur gewinnen – wie etwa das Webframework Grails, oder das auf Swing aufsetzende MVC-Framework Griffon. Aber für rechenintensive Aufgaben wie diese ist Groovy eher nicht zu wählen.

Wen es interessiert: Meine Groovy-Implementierung für diese Aufgabe findet man bei pastebin unter http://pastebin.com/GzcSW0d9.

[3] Wenn die Ausführungszeiten der einzelnen Threads stark streuen, wäre hier ein anderes Verfahren angebracht. Man könnte eine synchronisierte Variable int threadsWorking einführen, die vom Thread beim Start hoch- und bei Beendigung heruntergezählt wird. Der Master-Thread wartet dann darauf, dass threadsWorking == 0 wird.

[4] Ich verwende aus technischen Gründen POSIX-Threads, obwohl ich eigentlich gerne einmal das neu in C++11 eingebaute Multithreading ausprobiert hätte. Leider ist es auf meinem Windows-System noch nicht verfügbar, da die MinGW es noch nicht enthält, und ich hatte bislang noch keine Lust, mir eine zweite Festplatte mit Linux einzurichten. (Alles, was mit blosser Computeradministration zu tun hat, ist unproduktiver, lästiger Zeitfrass.)

[5] Die Rekursion ist für Baumstrukturen im allgemeinen vorzuziehen, da sie lesbarer ist. An dieser Stelle aber, wo es auf höchstmögliche Effizienz ankommt, ist schon der Aufbau neuer Stackebenen pro Operation ein zu vermeidender Overhead.

[6] Ausgeführt auf meinem Rechner, der einen Prozessor vom Typ Intel Core i7 2600K @3.4 GHz hat und somit über acht Prozessorthreads verfügt.

Ein Algorithmus zum Aufzählen von Ausdrucksbäumen

2011-10-02T21:10:00.031+01:00

Damit über das Ergebnis eines ohne Klammern hingeschriebenen Terms wie

24 - 3 * 5 - 4

keine Diskussionen entstehen, gibt es bekanntlich einige Vorrangregeln: Die Punktrechnung wird der Strichrechnung vorgezogen, und der Ausdruck wird von links nach rechts ausgerechnet. Wenn man sich an diese Konventionen hält,ergibt obiger Ausdruck den Wert 5. Wenn man es anders wünscht, muss man Klammern setzen. Zum Beispiel liefert der folgende Ausdruck

( 24 - 3 ) * ( 5 - 4 )

ein anderes Ergebnis, obwohl die Zahlen und Rechenoperationen immer noch in der gleichen Reihenfolge dastehen. Durch die hinzugefügten Klammern wurde die entscheidende Information hinzugefügt, dass die in den Klammern stehenden Ausdrücke zuerst gerechnet werden sollen.

Eine gegebene Folge von Zahlen und Rechenoperationen vorausgesetzt: Wie viele unterschiedliche Ausführungsreihenfolgen gibt es denn insgesamt für die Ausrechnung? Das heisst: Auf wie viele verschiedene Weisen kann man klammern?

Um an ein solches Problem heranzugehen, muss man es zuerst auf geeignete Art modellieren. Unsere übliche Notation mit Klammern und Vorrangsregeln ist für eine theoretische Betrachtung eher ungeeignet. Es empfiehlt sich eine Stippvisite bei den Informatikern. Diese bevorzugen für Terme wie den obigen eine Baumdarstellung. Jede Rechenoperation wird durch einen Knoten mit zwei Kindknoten repräsentiert. Diese können selbst wieder Kinder haben - wenn sie wiederum eine Rechenoperation sind - oder nicht: wenn es Zahlen sind. Die Zahlen sind also die terminalen Knoten des Ausdrucksbaums, die auch Blätter genannt werden. Die Rechnung 1 + 1 wird dann durch folgendes Diagramm repräsentiert:

Der Ausdruck 24 - 3 * 5 - 4, der mir hier als Aufhänger diente, sieht mit der Brille des Informatikers so aus:

Der Ausdruck (24 - 3) * (5 - 4) behält die Reihenfolge der Zahlen und Operationen bei, klammert sie aber anders. Das ergibt den folgenden Baum:

Bei Wahl dieses Modells lässt sich die Aufgabe, alle möglichen Klammerungen eines Ausdrucks aufzuzählen, leichter behandeln. Für einen Ausdruck mit n Operationen und - daraus folgend - mit n+1 Zahlen haben wir also alle "Ausdrucksbäume" mit insgesamt 2n+1 Knoten zu bilden, wobei genau n+1 Knoten Blätter sind. Die n inneren Knoten, die den Operationen entsprechen, also zwei Kindknoten haben, wollen wir Operationsknoten nennen.

Bei der Suche nach einem rekursiven Algorithmus, um alle Ausdrucksbäume aufzuzählen, verrannte ich mich zuerst in dem Bestreben, den Algorithmus gewissermassen "von oben" beginnen zu lassen, beim Wurzelknoten. Ich habe den Verdacht, dass dies überhaupt nicht oder nur unter grossen Qualen möglich ist.

Der Trick bei dieser Aufgabe ist, dass man besser "von unten" anfängt: Mit einer Operation wie 1+1, also einem Knoten, der zwei Blätter als Kinder enthält und damit eine Art "Ende" des Graphen darstellt. Wenn man den Algorithmus bei einem solchen Knoten beginnen lässt, wird alles ganz einfach: Von dort aus kann man die möglichen Ausdrücke wie folgt aufbauen:

Auf jeder Stufe des Algorithmus wollen wir einen neuen Operationsknoten mit Kindknoten besetzen. Als Kindknoten können wir uns aus einem Vorrat von "freien", d.h. schon auf einer früheren Stufe mit Kindknoten besetzten, aber noch nicht in den Ausdruck eingebauten Operationsknoten bedienen.
Dieser Vorrat, der auch leer sein kann, darf auf jeder Stufe höchstens gleich der Anzahl der noch verfügbaren, d.h. noch gar nicht eingebauten Operationsknoten sein. Sonst liessen sich nicht mehr alle freien Operationsknoten in den Baum einbauen.
Um einen Operationsknoten mit Kindknoten zu besetzen, können wir keinen, einen oder zwei freie Operationsknoten zu Kindern erklären. Die offene oder offenen Stellen des Operationsknotens besetzen wir mit Blättern. Bei der Alternative, einen Operationsknoten zu besetzen, sind auch noch die beiden Fälle zu unterscheiden, dass man das linke oder rechte Kind mit dem Operationsknoten belegt.

Der Algorithmus terminiert beim Wurzelknoten: Aufgrund der Restriktion an die Zahl der freien Operationsknoten liegen beim Wurzelknoten höchstens zwei freie Operationsknoten vor, die man auf jeden Fall in einer letzten Operation "verdrahten" kann.

Zur Verdeutlichung will ich den Algorithmus am Fall n=3 einmal durchspielen. Das folgende Schema zeigt die möglichen Klamemerausdrücke am Beispiel eines Ausdrucks mit drei Operationen O₀ (der Wurzeloperation), O₁, O₂ und vier Zahlen:

Jedes Doppelkästchen steht für die beiden Kindknoten der Operation. Ein graues Kästchen steht für die Belegung mit einem Operationsknoten, ein weisses Kästchen für die Belegung mit einem Blatt. Jede Zeile steht für eine mögliche Klammerung.

Man beginnt ganz rechts, also mit der Ausprägung von O₂. Da es am Anfang noch keine freien Operationsknoten gibt, muss O₂ in jedem möglichen Fall mit zwei Blättern belegt werden. Nun ist ein freier Operationsknoten entstanden.

Erst beim nächsten Operationsknoten O₁ ergeben sich nun Wahlmöglichkeiten: Entweder belegt man auch diesen Knoten mit zwei Blättern – das ergibt die erste Möglichkeit – oder man belegt einen der beiden Kindknoten von O₁ mit O₁. Das ergibt jeweils zwei weitere Fälle.

Schliesslich sind wir auf der dritten und letzten Ebene: Der Wurzelknoten O₀ ist zu belegen. In der ersten dargestellten Zeile haben wir nun zwei freie Operationsknoten. Diese müssen nun mit dem Wurzelknoten verdrahtet werden. Die Reihenfolge spielt, wenn zwei Operationsknoten verdrahtet werden, keine Rolle – wie in diesem Fall. Wenn aber nur ein Operationsknoten zugeordnet und die andere Stelle mit einem Blatt besetzt wird, spielt die Reihenfolge durchaus eine Rolle.

So ergeben sich insgesamt fünf Möglichkeiten, einen Ausdruck mit vier Zahlen und drei Operationen zu klammern. Aus dem Algorithmus ergibt sich, dass es für das Resultat auf die zahlenmässige Zuordnung (also die Subskripte 0,1,2 der Operationsknoten) nicht ankommt. Eine Möglichkeit lässt sich zahlenmässig durch eine "Signatur" beschreiben: Ein Tupel (a_n-1, a_n-2, …, a₀) von Zahlen zwischen 0 und 2, wobei in den Fällen a_i=1 noch zu notieren ist, ob das linke (L) oder rechte (R) Kindelement für den Operationsknoten verwendet wurde. Die im Beispiel resultierenden Signaturen habe ich oben angefügt.

Diese Zuordnung ergibt einen Zusammenhang zwischen der Anzahl binärer Ausdrucksbäume und den sogenannten Kombinationen, also verschiedenen möglichen Auswahlen einer Teilmenge aus einer grösseren Menge — hier den Auswahlen von n-1 aus 2n Elementen. Von hier gelangt man zu den wohlbekannten Catalanschen Zahlen. Da die Diskussion die Grösse eines Blogs sprengt, habe ich diesen Zusammenhang in einem kleinen Artikel erläutert:

http://ruediger-plantiko.net/etree.pdf

Ein vollständiges C-Programm, das die Ausdrucksbäume gemäss diesem Algorithmus aufzählt, habe ich auf Pastebin unter der URL http://pastebin.com/mehTM4Z0 verfügbar gemacht.

Das Programm erzeugt z.B. für n=4 die folgende Aufzählung der 14 möglichen Klammerungen eines Ausdrucks mit vier Operationen:

[op,[op,[op,num,num],num],[op,num,num]]
[op,[op,num,[op,num,num]],[op,num,num]]
[op,[op,[op,num,num],[op,num,num]],num]
[op,num,[op,[op,num,num],[op,num,num]]]
[op,[op,num,num],[op,[op,num,num],num]]
[op,[op,[op,[op,num,num],num],num],num]
[op,num,[op,[op,[op,num,num],num],num]]
[op,[op,num,[op,[op,num,num],num]],num]
[op,num,[op,num,[op,[op,num,num],num]]]
[op,[op,num,num],[op,num,[op,num,num]]]
[op,[op,[op,num,[op,num,num]],num],num]
[op,num,[op,[op,num,[op,num,num]],num]]
[op,[op,num,[op,num,[op,num,num]]],num]
[op,num,[op,num,[op,num,[op,num,num]]]]

Daten und Code

2011-09-18T20:17:00.018+01:00

Der Mathematiker Bill Gosper hat einmal gesagt: "Data is just a dumb kind of programming."[1] Das widerspricht unseren Denkgewohnheiten: Wir finden es gut und richtig, Code und Daten sorgfältig voneinander zu trennen. Es gilt als unsauber, in den Code Daten aufzunehmen und als unmöglich, Daten direkt auszuführen: Sie können allenfalls von einem Programm eingelesen werden und die Programmausführung steuern - etwa in Form von Customizing.

Aber das Zitat von Gosper weist zuerst einmal darauf hin, dass Code und Daten näher beieinanderliegen, vergleichbarer sind als es den Anschein hat. Schliesslich besteht auch Programmcode aus Daten: Er ist eine Aneinanderreihung von Schlüsselwörtern, Symbolen, Literalen und besonderen Zeichen aus dem Vorrat einer Programmiersprache. Wie alle Daten ist Programmcode "nur" Information. Ein Compiler erzeugt aus Code ein ausführbares Programm: Das ist eine Abfolge von Bytes, die zur Laufzeit dem Prozessor (oder der virtuellen Maschine) zur Ausführung vorgelegt werden. Die Bits und Bytes der Op-Codes werden dann im Prozessor nach fest verdrahteten Regeln interpretiert und ausgeführt. Auch Codezeilen sind demnach Daten. Es gibt keinen grundsätzlichen Unterschied zwischen Customizingdaten, die von einem Programm eingelesen werden und seinen Ablauf beeinflussen, und Programmcode, der von einem Prozessor eingelesen und verarbeitet wird.

Da alle Änderungen in unserem System über das Transportwesen vom Entwicklungs- über das Konsolidierungs in das Produktivsystem gelangen und all diese Transporte in einer Liste dokumentiert werden, habe ich mir eine Liste der letzten 100 Änderungen in unserem System auf die Frage hin angesehen, welcher Art die durchgeführten Änderungen waren [2] – mit folgendem Ergebnis:

Etwa die Hälfte aller Änderungen wurden am Code vorgenommen.

Etwa ein Drittel der Änderungen betraf steuernde Daten: Customizing, Anwendungsparameter und transportrelevante Stammdaten.

Die übrigen Einträge der Liste führten teilweise gar nicht zu Transporten, weil sie reine Beratungsfragen darstellten oder ein nicht reproduzierbares Symptom beschrieben. Ferner gab es Transporte von Texten und Übersetzungen

Interessanter als "Ist es eine echte Fehlermeldung oder die Anforderung eines neuen Features?" finde ich jedenfalls die Frage, auf welcher Ebene und mit welchem Aufwand geändert wurde: Gibt es Änderungsarten, die günstiger sind als andere?

Jede Änderung bedeutet, dass der Wert einer bestimmten steuernden Grösse geändert wird - seien es Teile von Programmcode oder Einträge im Customizing. Die Frage nach dem Aufwand ist die Frage, wie gut man an diese Steuergrösse herankommt, wie gut der Kontext der Steuergrösse im System die Semantik dieser Grösse darstellt, wie kontrollierbar die Auswirkungen der Änderung sind und zuletzt: ob ein Entwickler nötig ist, um die Änderung durchzuführen.

Lokalisierung der Steuergrösse Wie viel Aufwand benötige ich, um die Schraube zu finden, an der ich drehen muss?

Isoliertheit Wie seiteneffektfrei ist die nötige Änderung?

Darstellung Wie steuert die änderbare Grösse das System? Wie ist diese änderbare Grösse modelliert? Wie leicht ist diese Steuerung für den Leser des Modells (des Codes, der Customizingtabelle etc.) nachvollziehbar?

Zuständigkeit Muss die Änderung durch einen Entwickler oder kann sie durch den Prozessberater, der die Änderung anfordert, selbst geleistet werden? Im letzteren Fall würde man sich eine Instanz sparen, was den Aufwand für die Durchführung der Änderung natürlich reduziert.

In komplexen Systemen, die einen Querschnittsaspekt der Betriebswirtschaft eines grossen Unternehmens abbilden, etwa dessen Logistik, kann eine steuernde Codestelle praktisch nicht mehr per Dokumentation ermittelt werden. Die Dokumentation kann bestenfalls noch einen groben Anhalt geben, in welcher Richtung (in welchen Programmen, Klassen, Funktionsgruppen) man suchen muss. Es wird für die Änderung ein konkreter Anwendungsfall benötigt, der die fehlgeschlagene Erwartung zeigt. Da in der Regel keine strikte, sondern nur die schwache Form von Code Ownership praktiziert wird, muss man als Nicht-Experte des jeweiligen Gebietes mit dem Debugger herausfinden, wie das System aktuell funktioniert und an welcher Stelle man es verändern müsste, um den Ablauf zu ändern. Ohne tiefere Kenntnis des Programmentwurfs, ohne Kommunikation mit den Programmautoren, ist das eine heikle Aufgabe, an der man grandios scheitern kann.

Der Code in einer 3GL-Programmiersprache ist meist ausführungsorientiert, nicht problemorientiert. Man muss sich beim Programmieren gewissermassen in das Ausführungsmodell der Maschine eindenken, und meist bleibt es dabei: Der Code entsteht in einer Anpassung an die Ausführungslogik der Maschine. Die Sichtweise von Jack Reeves "Der Code ist Design"[3], wonach der Programmcode vor allem als ein Text für menschliche Leser gedacht ist - und nur in einer speziellen Syntax formuliert ist, die die maschinelle Ausführung ermöglicht - dass Programmcode also ein maschinell ausführbares Designdokument ist, ist in den Köpfen noch nicht sehr verbreitet. Man klebt zu sehr an den Details der Maschine, hört zu schnell mit Code-Verbesserungen auf, sobald "es läuft" oder gibt zu schnell auf, wenn die Maschine nicht so reagiert wie erwartet, nur um dann an anderen Orten eine brutale Alternativlösung einzubauen.

Das leitet zum zweiten Thema über, der Isoliertheit einer Änderung. Je mehr ein System bereits durch Änderungen verschraubt ist, umso schwieriger ist es, Seiteneffekte zu überblicken. Das gilt vor allem, wenn der Code Wiederholungen enthält. Mit statischer Codeanalyse ist es meist zu aufwendig, alle Prozesse zu finden, auf die sich eine Änderung auswirkt. Die einzige Möglichkeit, die Seiteneffekte von Änderungen mit guter Qualität zu kontrollieren, wäre ein dichtes Sicherheitsnetz von automatischen Tests – Unit Tests ebenso wie Integrationstests. Je weniger automatische Tests existieren, umso grösser ist das mit einer Änderung verbundene Risiko, umso grösser wird bei jeder Änderung die Angst, unerwünschte Nebeneffekte zu produzieren. Das bremst auch den allfällig vorhandenen guten Willen zur Verbesserung von Codequalität!

Wie kann man die Darstellung von Code verbessern? DSLs sind ein Ansatz, um von ausführungsorientierter zu problemorientierter Programmierung überzugehen. Ich habe im Blog Domänenspezifische Programmierung in ABAP einige Beispiele gegeben, wie man Ausführungsdetails im Programmcode verbergen kann. Die DSL ist eine Ebene über der 3GL-Programmiersprache angesiedelt und steuert mit einer klareren, aber auch spezialisierteren Syntax bestimmte Teilaspekte des Systems. Das alles ist aber noch Zukunftsmusik, auch wenn sich im Bereich der Tools und Frameworks für DSLs einiges tut[4], und wir in ABAP das Business Rules Framework BRFplus als neues Werkzeug in unserem Instrumentarium erhalten haben.

Wer ist schliesslich für eine Änderung zuständig? Änderungen am Code müssen natürlich immer von einem Entwickler gemacht werden - bei schwacher Code Ownership von irgendjemandem aus dem Team. Ein SAP-Prozessberater kann zwar den Code anschauen, aber da er in seiner täglichen Arbeit an Prozessen und nicht am Ausführungsmodell einer Maschine orientiert ist, ist selbst das Lesen von Programmcode für ihn eine mühsame Übung. Anders sähe es aus, wenn der Code selbst prozessorientiert wäre, das steuernde Modell des Programms also aus dem für die blosse Programmausführung nötigen Code herausextrahiert wäre. Womit wir wieder beim DSL-Thema sind. Der Berater könnte dann, so wie er aktuell das Customizing seine Domäne gut kennt, auch ein in einer DSL formuliertes Programm gut kennen und Änderungen entweder vorschlagen oder sogar selbst durchführen.

In allen vier Punkten gewinnen die Daten – der "dumme Code" nach Gosper – gegenüber dem schlauen Code, dem 3GL-Programmcode, was die schnelle Änderbarkeit betrifft. Die für eine Änderung des Systemverhaltens nötige Customizingeinstellung ist in der Regel schneller lokalisiert als eine Codestelle. Sie ist auch leichter zu ändern und ist im Kontext – Viewpflege mit Anwendungsdoku und F4- und F1-Hilfe für das steuernde Feld – klar nachvollziehbar. Wenn nicht der Umweg über einen Entwickler gewählt werden muss, sondern der Anforderer der Änderung diese auch gleich selbst umsetzen kann, spart man weitere Zeit. Lediglich bei der Isoliertheit kann man bei einer Datenänderung ebenso in die Komplexitätsfalle laufen wie bei Codeänderungen. Wenn ich eine neue Auftragsart einführe, kann ich nicht wissen, an welchen Stellen auf die bestehenden Auftragsarten programmiert ist und die neue Auftragsart mit aufgenommen werden muss.[5] Egal ob Code oder Daten - zur zuverlässigen Kontrolle von Seiteneffekten hilft letztlich nur das Netz automatischer Tests.

Wenn sich das Verhältnis in der Changeliste umkehren würde: Wenn die Hälfte der Änderungen als Datenänderungen und nur ein Drittel als Codeänderungen gemacht werden müssten, hätte das bereits eine deutliche Verringerung der Aufwände zur Folge und würde das Unternehmen somit agiler machen: Es kann schneller auf Änderungen reagieren. Wir arbeiten an diesem Ziel, wenn wir, wo immer es möglich ist, die Steuerung des Programms – in der betriebswirtschaftlichen Begrifflichkeit, nicht in Begriffen der Maschine – aus dem Programmcode extrahieren und in geeignete Daten auslagern. Das können klassische Customizingtabellen sein, oder auch moderne Datenstrukturen wie die des Business Rule Frameworks, oder eine Instanz einer geeignet definierten DSL.

[1] Zitiert in dem Aufsatz von Charles Petzold, On-the-Fly Code Generation for Image Processing, in: Andy Oram, Greg Wilson (Eds.), Beautiful Code, O'Reilly, Cambridge 2007, S. 105.
[2] Über die Frage, ob es sich bei den Änderungen um "echte Fehler" oder um Entwicklungswünsche, Nice-To-Haves und dergleichen handelt, kann man sich in Meetings sehr schön erhitzen. Aber für die Reflexion sind diese Klassifizierungen uninteressant. Ich versuche, die vorbelasteten Ausdrücke "Bug", "Fehler", "Korrektur" zu vermeiden und spreche schlicht von "Änderungen".
[3] Jack W. Reeves, What is Software Design?, http://www.developerdotstar.com/mag/articles/reeves_design_main.html
[4] Siehe http://www.languageworkbenches.net/
[5] Die Ursache dafür ist also wieder der nicht überblickbare Code. Zwar kann man im Beispiel der Auftragsarten eine globale Konstante mit allen verwendeten Werten einführen. Man hat aber keine Garantie, dass sich jeder daran hält oder ob nicht ein zweiter Entwickler in Unkenntnis der Existenz der ersten einfach eine weitere, zweite Konstante mit derselben oder einer leicht abweichenden Wertemenge definiert hat. Und das ist kein theoretisches Beispiel!

Ein JSON-Builder in ABAP

2011-09-12T20:56:00.028+01:00

Zu dem in einem früheren Post beschriebenen JSON-Parser gibt es ein Gegenstück – den JSON-Builder. Er kann gegebene ABAP-Daten in das JSON-Datenformat wandeln. Die ABAP-Daten sind dabei – wie der Zieltyp des JSON-Parsers – vom Typ ZUT_DATA und ermöglichen beliebig tiefe Schachtelung. Hier der Typ von ZUT_DATA, wenn man ihn nicht, wie es richtig ist, im DDIC, sondern als lokalen Datentyp definieren würde:

types:
  begin of zut_data,
    type type c,
    value type ref to data,
  end of zut_data.

Der Typschlüssel type kann dabei die Wert S für String, N für Zahl, B für Boolesch, a für Array und h für Hash annehmen.

Es gäbe verschiedene Strategien für die Implementierung eines solchen Builders. Man könnte alles in ABAP ausprogrammieren oder sich eine andere der in ABAP verfügbaren Sprachen zunutze machen – in diesem Fall bietet sich der JavaScript-Interpreter cl_java_script oder der XSLT-Prozessor an (in ABAP mit der Anweisung call transformation integriert).

Ich habe mich in diesem Fall gefühlsmässig für XSLT entschieden: Die erforderliche Rekursion durch tiefe Datenstrukturen wird durch XSLT gut unterstützt, auch gilt der in ABAP eingebaute XSLT-Prozessor als schnell. Über den JavaScript-Prozessor kenne ich keine Performance-Angaben, jedoch habe ich Forenbeiträge gelesen, in denen der JavaScript-Prozessor als sehr ressourcenintensiv beschrieben wurde. Eine reine ABAP-Implementierung schliesslich wäre ebenso gut möglich gewesen. Ob die Stringverarbeitung von ABAP für grosse Datenobjekte mit der XSLT-Verarbeitung konkurrieren kann, wäre eine interessante Frage. Hier will ich aber den Weg über eine XSLT-Transformation zabap2json beschreiben.

Bei Verwendung einer Transformation ist die zentrale build-Methode, die einen zut_data-Parameter entgegennimmt und einen String im JSON-Format zurückgibt, eine reine Delegation:

method build.
  call transformation zabap2json
    options data_refs = 'heap-or-create'
    source data_root = is_data
    result json = ev_json.
  replace regex '^\s+' in ev_json with space.
  replace regex '\s+$' in ev_json with space.
endmethod.

Wichtig ist hier allerdings der Zusatz data_refs = 'heap-or-create'. Hiermit weisen wir den Prozessor an, alle nicht selbständigen, also auf den Stack oder auf globalen Daten verweisende Referenzen so zu behandeln wie selbständige, also mit create data auf dem Heap angelegte Datenobjekte. Würden wir diese Option nicht angeben, so würden die nicht selbständigen Datenreferenzen nicht ins ABAPXML-Format serialisiert und könnten daher nicht von der XSLT-Transformation bearbeitet werden.

In diesem Fall haben wir einen Aufruf von call transformation, der ABAP-Daten entgegennimmt und auch wieder an den Aufrufer zurückgibt. XML tritt nur als Zwischenformat auf - als Quell- und Zielformat der Transformation.

Wie sieht nun die Transformation zabap2json aus? Die ersten Templates steigen zunächst bis zum Basistemplate showData der Rekursion ab und spezifizieren, dass der Ergebnisstring in ein <JSON>-Element eingepackt werden soll – unter diesem Namen kann das Ergebnis dann in ABAP als String abgeholt werden:

  <xsl:template match="/">
    <xsl:apply-templates select="/asx:abap/asx:values"/>
  </xsl:template>

  <xsl:template match="DATA_ROOT">
    <xsl:call-template name="getData"/>
  </xsl:template>

  <xsl:template name="getData">
    <asx:abap>
      <asx:values>
        <JSON>
          <xsl:call-template name="showData">
            <xsl:with-param name="data" select="."/>
          </xsl:call-template>
        </JSON>
      </asx:values>
    </asx:abap>
  </xsl:template>

Das zentrale Template showData muss nun den Typschlüssel auswerten und an ein dazu passendes Template delegieren. Da es in XSLT keine Möglichkeit gibt, Templates dynamisch aufzurufen, muss der passende Templateaufruf in einem <xsl:choose>-Block programmiert werden:

  <xsl:template name="showData">
    <xsl:param name="data"/>
    <xsl:variable name="type" select="$data/TYPE"/>
    <xsl:for-each select="$data/DATA">
      <xsl:choose>
        <xsl:when test="$type = 'N'">
          <xsl:call-template name="simpleValue"/>
        </xsl:when>
        <xsl:when test="$type = 'S'">
          <xsl:call-template name="stringValue"/>
        </xsl:when>
        <xsl:when test="$type = 'B'">
          <xsl:call-template name="booleanValue"/>
        </xsl:when>
        <xsl:when test="$type = 'h'">
          <xsl:call-template name="showHash"/>
        </xsl:when>
        <xsl:when test="$type = 'a'">
          <xsl:call-template name="showArray"/>
        </xsl:when>
      </xsl:choose>
    </xsl:for-each>
  </xsl:template>

Das <for-each> wird natürlich nur einmal durchlaufen und setzt dabei den current node für die Templates.

Die Regel für den Hash zeigt, dass das Template showData bei der Auflösung tiefer Datenstrukturen parametrisiert aufgerufen wird. Auch sieht man am select-Attribut der <for-each>-Schleife über die Hash-Elemente, wie der Zugriff auf eine Datenreferenz im Heap zu bewerkstelligen ist: Die ID im Heap entspricht dem Wert des Attributs href in der Referenz ab dem 2. Zeichen (XLink- bzw. XPointer-konform wird einem href-Verweis auf ein Element mit einer ID im aktuellen Dokument ein # vorangestellt):

  <xsl:template name="showHash" match="ZUT_DATA" mode="h">
    <xsl:variable name="id" select="substring(@href,2)"/>
    {
    <xsl:for-each select="/asx:abap/asx:heap/*[@id = $id]/*">
      <xsl:if test="position() > 1">,</xsl:if>
      <xsl:call-template name="showHashRow"/>
    </xsl:for-each>
    }
  </xsl:template>

  <xsl:template name="showHashRow">
    "<xsl:value-of select="KEY"/>":
    <xsl:call-template name="showData">
      <xsl:with-param name="data" select="."/>
    </xsl:call-template>
  </xsl:template>

Das Template für einen simpleValue ist so gestaltet, dass es mit Direktwerten ebenso wie mit Referenzen umgehen kann:

  <xsl:template name="simpleValue">
    <xsl:choose>
      <xsl:when test="@href">
        <xsl:call-template name="getReference">
          <xsl:with-param name="href" select="./@href"/>
        </xsl:call-template>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="."/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>

Umständlich wird leider nur das Template zur Darstellung eines Strings. Es müssen ja alle " im String druch \" und alle einfachen Backslashs \ durch doppelte \\ maskiert werden. Da es keine XPath-Funktion zum Ersetzen von Strings gibt, ist diese Funktion separat dazuzuprogrammieren. Gott sei Dank gibt es das Internet, in dem sich Funktionen wie XSLT string-replace auffinden lassen - danke Erik!

  <xsl:template name="stringValue">
    "<xsl:call-template name="string-replace-all">
      <xsl:with-param name="text">
        <xsl:call-template name="string-replace-all">
          <xsl:with-param name="text">
            <xsl:call-template name="simpleValue"/>
          </xsl:with-param>
          <xsl:with-param name="replace">\</xsl:with-param>
          <xsl:with-param name="by">\\</xsl:with-param>
        </xsl:call-template>
      </xsl:with-param>
      <xsl:with-param name="replace">"</xsl:with-param>
      <xsl:with-param name="by">\"</xsl:with-param>
    </xsl:call-template>"
  </xsl:template>

<!-- Template dankend übernommen
     aus http://geekswithblogs.net/Erik/archive/2008/04/01/120915.aspx -->
  <xsl:template name="string-replace-all">
    <xsl:param name="text" />
    <xsl:param name="replace" />
    <xsl:param name="by"/>
    <xsl:choose>
      <xsl:when test="contains($text, $replace)">
        <xsl:value-of select="substring-before($text,$replace)" />
        <xsl:value-of select="$by" />
        <xsl:call-template name="string-replace-all">
          <xsl:with-param name="text"
          select="substring-after($text,$replace)" />
          <xsl:with-param name="replace" select="$replace" />
          <xsl:with-param name="by" select="$by" />
        </xsl:call-template>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$text" />
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>

Wer sich für die Transformation näher interessiert, kann den vollständigen Quelltext bei Pastebin betrachten oder herunterladen.

Groovy vereinfacht SAP-Zugriffe mit dem Java Connector

2011-08-30T19:21:00.018+01:00

Es ist keine Propaganda zur Verbreitung einer (nicht mehr so ganz) neuen Programmierprache, sondern es stimmt wirklich: Wer seine Aufgaben in Groovy statt in Java löst, produziert wesentlich weniger Code, der obendrein noch besser lesbar ist. Das kann man mit allen möglichen Aufgaben zeigen – zum Beispiel auch mit einem RFC-Aufruf in ein SAP-System und der Auswertung der Rückgabewerte, wobei für die Verbindung der Java Connector zum Einsatz kommt.

Die Besonderheit von Groovy ist, dass es - als dynamische Programmiersprache - zur Laufzeit versucht, das Gemeinte zu erraten und damit meistens erstaunlich richtig liegt. Wenn es sich doch einmal anders als gewünscht entscheidet, kann man ihm diese Unarten ohne viel Aufwand abgewöhnen. So entfällt im Code viel "syntaktisches Rauschen" (syntactic noise), wie man es von statischen Programmiersprachen kennt. Übrig bleibt der näher beim Problem liegende Code. Durch diese Beschränkung auf das Wesentliche wird der verbleibende Code automatisch lesbarer. Es gibt in Groovy die Möglichkeit, bei wichtigen grundlegenden Zeitpunkten zur Laufzeit einzugreifen, etwa beim Methoden-Lookup und beim Setzen und Abfragen eines Attributs. Dadurch hat man die Möglichkeit, die Syntax des Codes zu gestalten. Diese Freiheit kann genutzt werden, um die Klarheit, Lesbarkeit und Kompaktheit des Codes noch weiter zu steigern.

Was ist der Preis? Man könnte argwöhnen, dass die Performance durch die vielen dynamischen Features von Groovy leidet. Zunächst wird man überrascht sein zu sehen, dass die Performance von Groovy-Programmn entgegen solchen Erwartungen sehr gut ist. Dennoch mag der Einwand für Programmteile stimmen, in denen hochperformant gearbeitet werden muss. Da Groovy mit Java kompatibel ist, hat man aber immer die Möglichkeit, mit Plain Old Java Objects (POJOs) zu arbeiten oder im Extremfall – wie in Java – native Bibliotheken aufzurufen. Je näher man aber in den Bereich der Benutzerschnittstelle kommt – wenn Dialoge involviert sind oder auf irgendeine Art die unendlich langsame menschliche Reaktionszeit ins Spiel kommt – desto unerheblicher wird die Frage, ob man mit einer statischen oder dynamischen Sprache arbeitet. Für Dinge wie automatische Tests - in denen Benutzerschnittstellen durchlaufen werden - ist das Laufzeitverhalten einer dynamischen Sprache wie Groovy mehr als ausreichend.

Wie gut man eine Sprache wie Groovy zur Formulierung von automatischen Tests verwenden kann, habe ich in meinem letzten Blog über Selenium und Groovy gezeigt.

Hier will ich beschreiben, wie sich die Zugriffe auf komplexe ABAP-Datenstrukturen mit Groovy vereinfachen. Für den Zugriff selbst verwende ich dabei den SAP Java Connector (JCo). Der JCo ist ein Tool zur Ausführung entfernter Funktionsbausteinaufrufe (RFC) in einem SAP-System. Mittels eines Metadaten-API kann man den Aufruf vor dem Baustein mit Daten versorgen und hinterher aus den Rückgabewerten Daten auslesen, wobei viele Daten bereits passend konvertiert werden: Ein ABAP-Feld vom Typ D (Datum) ergibt z.B. in Java einen Feldwert vom Typ java.util.Date.

Nun muss man zum Auslesen komplexer Daten auch in Java viel hinschreiben. Für jede einzelne Auswertung bedarf es eines eigenen Methodenaufrufs, und Zwischenergebniss müssen häufig in lokalen Variablen gehalten werden. Eine komplexe Struktur beleg müsste man mit dem JCo z.B. wie folgt auslesen, um den Preis der 5. Position zu ermitteln:

double getPrice( JCO.Record order, int pos) {
// ITEMS sei Komponente der ABAP-Struktur BELEG
  JCO.Table items = order.getValue( "ITEMS" ); 
// Workarea der JCO.Table auf Position pos setzen  
  items.setRow( pos );
// Nun kann der Preis ausgelesen werden  
  return items.getValue( "PRICE" );
  }

Diese aufwendigen Folge von im Grunde uninteressanten Methodenaufrufen stört das Auge und erschwert den Blick auf das Wesentliche. Wäre es nicht schöner, einfach folgendes schreiben zu können?

order.ITEMS[pos].PRICE

Groovy bietet die Möglichkeit, die Wertabfrage komplexer Daten genau so zu notieren. Man könnte den Ausdruck sogar auf der linken Seite stehen haben,

order.ITEMS[pos].PRICE = 10.00

und es würde eine Zuweisung an die Komponente PRICE der Zeile pos in der tabellenförmigen Komponente ITEMS der Struktur order ausgeführt.

Wie könnte man so etwas erreichen? Zunächst braucht man einen Wrapper (Adapter) - eine Klasse, die intern Referenzen auf die JCO-Objekte verwaltet, deren Methoden aufruft und die Möglichkeit der Rekursion bietet – denn Rekursion ist für Werteabfragen komplexer Datenobjekte das passende Verfahren:

class Data {

  private JCO.Record record
  
  Data( JCO.Record record) {
    this.record = record;
    }
...    
  }

Nun kommt etwas Groovy-Spezifisches: Mit den Methoden getProperty(name) und setProperty(name,value) kann in Groovy der Member-Operator "." überschrieben werden. Wenn die Groovy-Laufzeit auf den "." trifft, so versucht sie, bevor der Zugriff auf ein statisches Attribut gemacht wird, zuerst die Methode getProperty (oder setProperty auf der linken Seite einer Zuweisung) auszuführen, wenn eine Methode dieses Namens vorhanden ist. Ist dies der Fall, so wird die Operation auf die Methoden umgelenkt. Das heisst, an Stelle des Zugriffs a.b wird intern a.getProperty( "b" ) evaluiert, und an Stelle der Zuweisung a.b = c wird intern die Methode a.setProperty( "b", c ) ausgeführt.

Obwohl also ein Data-Objekt für die Zeilenstruktur der USERLIST kein Attribut USERNAME besitzt, kann der Zugriff so ausgeführt werden, als wäre es vorhanden. Hinter den Kulissen werden dabei die Methoden getProperty bzw. setProperty aufgerufen. Die Rekursion lösen wir, indem wir das Ergebnis automatisch in eine neue Data-Instanz einpacken, falls es wieder ein komplexes Datenobjekt ist. Die Methoden sehen daher im wesentlichen so aus:

class Data {
...
  def getProperty(String name) {
// Spezielle Attribute des Datenobjekts müssen hier gesondert behandelt werden
    if (name == "length") return record.getNumRows()
    if (name == "record") return record
// Allgemeiner Fall: Mit JCo in der Struktur record suchen    
    def f = record.getValue( name )
    if (record.isTable( name ) || record.isStructure( name )) 
      return new Data( f )
    else {
      return f
      }
    }
    
  void setProperty(String name, Object value) {
    record.getField( name ).setValue( value );
    }      
  ...
}

Auch den Subscript-Operator [] können wir für Data-Objekte nach eigenem Gusto definieren.

  def getAt(i) {
    record.setRow( i );
// Danach erfolgt ein Komponetenzugriff 
    this   
    }

Hier wird nur die Anfrage nach der i-ten Tabellenzeile vom Data-Objekt an das JCo-Repository-Objekt record delegiert. Die Rückgabe von this dient nur dem method chaining: Nachdem man in eine JCo.Table mittels setRow eine Zeile eingestellt hat, funktioniert sie so wie eine JCo.Structure – man kann auf einzelne Komponenten der Zeile mittels getValue zugreifen. Das wäre aber genau das, was Data beim Komponentenzugriff sowieso macht.

Als angenehme Zugabe habe ich noch eine Methode set vorgesehen, die es erlaubt, mehrere Komponenten einer Struktur auf einmal zu setzen. So kann ich mehrere Name/Wert-Paare auf einmal übergeben. Hier ein Beispielaufruf, um zwei Importparameter eines Funktionsbausteins auf einmal zu setzen:

    userList.importParameter.set( 
      MAX_ROWS : 50,
      WITH_USERNAME : "X"
      )

Die Lesbarkeit ist deutlich besser - während die Implementierung der benötigten set()-Methode denkbar einfach ist:

  def set = { pairs ->
    for (p in pairs) {
      setProperty p.key, p.value
      }
    }

Schliesslich können wir noch das Interface Iterator sinnvoll für interne Tabellen implementieren:

class Data implements Iterator { 
...
// Iterator interface  
  void remove() {}

  boolean hasNext() {
    return !record.isLastRow()
    }

  def next() {
    record.nextRow()
    this
    }

Was ist der Gewinn? Wir können in Groovy (und auch in Java) nun mit dem for ( .. in .. ) wie in einer ABAP-Loop die Zeilen der Tabelle durchlaufen. Mit der folgenden kleinen display-Methode bilden wir z.B. aus den Spalten USERNAME und FULLNAME einer internen Tabelle einen zweidimensionalen Array, wie ihn die JTable als Datenoobjekt entgegennimmt:

// Show a JTable with the result    
  void display( userlist ) {
    def data = []
    for (record in userlist) { 
      data.add( [ record.USERNAME, record.FULLNAME ] )
      }
    new GUI().showTable( data, ["Benutzername","Bürgerlicher Name"] )  
    }

Der record ist hier, was in ABAP eine Workarea wäre. Die Schleife ist in dieser angenehm lesbaren Form verwendbar, weil userlist das Interface Iterator implementiert.

Die folgende Testmethode ruft den Funktionsbaustein BAPI_USER_GETLIST per RFC auf und stellt die Ergebnisse in einer Tabelle dar. Was sich für andere Aufgaben wiederverwenden lässt, ist in Hilfsklassen ausgelagert.

  @Test void test() {      
  
// Provide handle to a remotely callable function  
    def userList = repo.getFunction "BAPI_USER_GETLIST"
    
// Parametrize it       
    userList.importParameter.set( 
      MAX_ROWS : 50,
      WITH_USERNAME : "X"
      )
      
// Do the call      
    userList.execute( )

// Get and display result
    display userList.tableParameter.USERLIST

  }

Ich habe nicht geschummelt. Das vollständige Codebeispiel zum Auslesen und Anzeigen der Tabelle von Benutzern eines SAP-Systems ist nicht wesentlich grösser als die hier gezeigten Ausschnitte und kann auf Pastebin unter folgendem Link eingesehen werden:

Accessing ABAP data efficiently

[1] Ich verwende die Groovy-Version 1.8.0, in das gemäss Release Notes einiger Aufwand in Performance-Optimierungen gesetzt wurde. Im übrigen gilt für Groovy wie für alles andere: "Don't blame the tools". 90% aller Performanceprobleme kommen nicht der verwendeten Plattform, sondern dem Applikationscode zuschulden.

Selenium mit Groovy

2011-08-08T19:56:00.035+01:00

Hin und wieder muss man sich einfach einmal umsehen. Zwar verwendet meine Firma für die Testautomatisierung Quick Test Professional - aber wie fühlt es sich im Vergleich dazu an, mit einem anderen System wie etwa Selenium zu arbeiten?

Schon länger benutze ich einen kleinen Teil von Selenium - die sogenannte Selenium IDE. Es handelt sich um ein auch für sich allein sehr nützliches Plugin für den Firefox.[1] Es hat eine Recorderfunktion und kann Dialogschritte im Web aufzeichnen und in Form einer XHTML-Tabelle abspeichern. Angenehm ist die Möglichkeit, über die rechte Maustaste Assertions und Verifications in den Test einzufügen. Eine ausgezeichnete kontextsensitive Hilfe unterstützt beim Einfügen von Kommandos. Und die Identifizierung von Elementen ist auf verschiedene, unter Web-Entwicklern verbreitete Weisen möglich: Natürlich kann man direkt den Elementnamen oder die ID verwenden. Aber auch CSS-Selektoren, JavaScript-DOM-Terme und XPath-Ausdrücke sind möglich.

Ich verwende die Selenium-IDE hauptsächlich, um immer gleich Sequenzen von Dialogschritten in einer Web-Anwendung abzuspielen. Das ist vor allem während des Entwickelns nötig: Wenn ich das fünfte Bild einer Anwendung entwickle, kommt mir ein Tool entgegen, das auf Knopfdruck alle Daten initialisiert und sich dann auf "die normale Weise" bis zu diesem fünften Bild durcharbeitet. So kann ich die Applikation schnell immer wieder in den gleichen Zustand bringen und mir anschauen, wie sich meine letzten Änderungen auswirken. Wenn dieses "Anschauen" - das ja ein Kontrollieren ist - sich in Form von Assertions formulieren lässt, baue ich sie gleich in den Test ein. Wenn ich dann mit dem sechsten Bild fortfahre, habe ich durch das Abspielen des Tests zugleich eine gewisse Sicherheit, dass alle vorigen Bilder weiterhin korrekt durchlaufen werden.

Wenn der Geradeausfall realisiert ist, kommen Randfälle an die Reihe, Sonderfunktionen einzelner Bilder, aber auch Tests zum Nachstellen eines Bugs.
So entsteht im Laufe des Projekts eine Halde von XHTML-Dateien mit Tests. Tests, die wirklich nicht mehr sind als eine Aufzeichnung von Dialogschritten.

Allerdings: Wiederverwendbarkeit ist auf dieser Ebene nicht möglich. Es gibt meines Wissens innerhalb der Selenium-IDE keine Möglichkeit, Tests in Tests aufzurufen oder auf irgendeine andere Weise Folgen von Selenium-Kommandos zu Modulen zusammenzufassen. Das ist auch nicht so gedacht. Der vorgesehene Ablauf ist, dass diese Aufzeichnungen nun in eine geeignete Programmiersprache exportiert werden und dort z.B. mittels eines UnitTest-Frameworks ausgeführt, zu Suiten zusammengefasst, modularisiert, parametrisiert, nachgebessert, refaktorisiert werden. Erst auf dieser Ebene hat man ein geeignetes Programmierumfeld. Dort beginnt erst das solide Arbeiten an Testcode.

Um auch diese Dimension von Selenium einmal kennenzulernen, habe ich mich dazu entschieden, einige der Tests as meinem letzten Projekt in die Programmiersprache Groovy zu exportieren und den Code dann dort nachzubearbeiten.

Groovy ist vor allem wegen seiner DSL-Features zur Formulierung von Testfällen ideal geeignet. Das gilt auch für Selenium - obwohl, wie ich feststellen musste, der Groovy-Export nur unvollständig funktioniert[2], und obwohl eine zunächst vorgesehene Hilfsklasse GroovySeleneseTestCase als Basisklasse in früheren Releases einmal vorgesehen war, aber mittlerweile nicht mehr in der Distribution enthalten ist.

Auch davon abgesehen, bietet der generierte Code nur einen groben Anhalt. Wenn man sich aber anschaut, wie die Kommandos unter Verwendung des Objekts Selenium.java abgesetzt werden können, ist es nicht besonders mühsam, die Scripts manuell zu erfassen. Auch wäre es kein Hexenwerk, einen eigenen Exporter des XHTML-Testfalls nach Groovy zu schreiben. Beispiele, wie man so etwas mit XSLT machen könnte, finden sich im "XSLT-Kochbuch" von Sal Mangano.[3]

Ich habe den GroovySeleneseTestCase.groovy wieder auferstehen lassen, aber nur mit dem Zweck, den Setup- und Teardown-Code nur einmal hinzuschreiben, mit dem der "Selenium-Server", der Vermittler zwischen dem Testscript und der zu testenden Anwendung, gestartet und heruntergefahren wird:

import org.junit.*;
import com.thoughtworks.selenium.*;

public class GroovySeleneseTestCase {
  @Delegate protected SeleniumHelper seleniumHelper;        
  @Before
  public void startSelenium() {	
    Selenium s = new DefaultSelenium(
      "localhost", 
      4444, 
      "*chrome", 
      "http://test.mgb.ch/sap/bc/bsp/sap/ztm_bestellung/main.do"
      );
    seleniumHelper = new SeleniumHelper( s );
    start()    
    }	    
  @After
   public void tearDown() {
     stop()
     }
  @Test @Ignore void dummy() {}       
}

Den nicht auszuführenden Dummy-Test habe ich nur eingefügt, um die Ausführung der Setup- und Teardown-Methode zu verhindern, wenn man aus irgendwelchen Gründen diese Groovy-Klasse nicht nur kompilieren, sondern ausführen will.[4] Denn diese Klasse ist nur als Oberklasse für die anderen, die eigentlichen Testklassen gedacht.

Man beachte die schöne Groovy-Annotation @Delegate. Sie wirkt so, als würde man in einem statischen Programm alle Methoden der Klasse SeleniumHelper zu eigenen erklären, also

public void start() {
  seleniumHelper.start();
  }
public void stop() {
  seleniumHelper.stop(); 
  } 
usw.

Allerdings wirkt die Annotation @Decorate nicht statisch, sondern dynamisch – indem sie dem Trägerobjekt beim Methoden-Lookup eine Methode des Delegationsobjekts mit der gleichen Signatur anbietet.

Der SeleniumHelper.groovy wiederum ist meine Erweiterung der Selenium-Klasse. Mit demselben Trick @Decorate sind alle Methoden von Selenium.java verfügbar - darüberhinaus aber ist diese Klasse ein Pool, in den ich alle wiederkehrenden Code-Abschnitte auslagern kann, die nicht anwendungsspezifisch sind, sondern die Ausführung von Selenium-Kommandos betreffen.

class SeleniumHelper implements Selenium {  
  @Delegate Selenium selenium;    
  SeleniumHelper(Selenium s) {
    selenium = s;
    }  
  static final timeout = "30000"  	      
  def pageLoaded = {
    waitForPageToLoad(timeout);
    true
    }      
  def clickAndWait = {
    click it
    waitFor pageLoaded
    }        
  public waitFor(f) {
    if (f == pageLoaded)
      pageLoaded()
    else 
      for (int second = 0;; second++) {                        
        Thread.sleep(1000);                                    
        if (second >= 60) fail("timeout");                     
        try { if (f) break; } catch (Exception e) {}			     
        }                                                      
    }    
  }

Wie in Scriptsprachen üblich, verwende ich die Datenstrukturen von Hashs und Arrays, um die Testdaten zu notieren - Dinge wie Partner-, Kontrakt-, Artikelnummern usw., wie sie für den zu testenden Bestellvorgang benötigt werden:

// Testdaten
    def test = [
      partner:"0010006179",
      kontrakt:"0020007901",
      items: [
        [
          matnr:"400617200000",
          menge:"2",
          vkhm:"8000000851",
          type:"P",
          lieferantPos:"0",
          listPos:"0003"          
        ],
        [
          matnr:"400617200000",
          menge:"2",
          vkhm:"8000001585",
          type:"N",
          lieferantPos:"1",
          listPos:"0005"
        ]       
      ]
    ]

Den eigentlichen Testfall kann ich unter Verwendung der Groovy-Sprachfeatures sehr kompakt programmieren. Hier ist er:

class StraightOrder extends GroovySeleneseTestCase {  
  @Delegate OrderSteps orderSteps  
  @Before
  void setup() {
    orderSteps = new OrderSteps( seleniumHelper )
    clearSessionData
    }
  @Test
  void selectIndividualItemsAndSave() {    
    selectTagsWithContract partner:test.partner, kontrakt:test.kontrakt    
    takeToBasket test.items 
    selectPrintOfficeFor test.items    
    goTo "OrderData"
    setRequestedDeliveryDateToday()
    goTo "Bestellung"
    assert isElementPresent("final_item_list")    
    click "jurinfo_gelesen"
    clickAndWait "saveBestellung"
    // Erfolgsmeldung nach dem Sichern:
    assert getText("msg") =~ /^Ihre Bestellung .* wurde versendet!$/
    }
  }

Einige der hier verwendeten Methoden - wie click, isElementPresent und open gehen direkt an Selenium.java. Andere wie selectTagsWithContract sind bereits das Ergebnis einer Modularisierung, die ich in eine Delegationsklasse OrderSteps.groovy ausgelagert habe. Dort stehen sie für weitere Testklassen und -methoden zur Verfügung.

Hier der Beginn der Klasse OrderSteps.groovy mit der Implementierung von selectTagsWithContract:

class OrderSteps {
  @Delegate private SeleniumHelper seleniumHelper;
  OrderSteps( SeleniumHelper s) {
    seleniumHelper = s;
    }
  def clearSessionData = {
    open "/ztm/bestellung/clearBasketAndSession"
    }
  def selectTagsWithContract = { selected ->
    open "../ztm_suche/main.do"
    type "partner", selected.partner
    type "kontrakt", selected.kontrakt
    clickAndWait "startSelection"
    }
  def goTo = {
    clickAndWait "css=.goto$it"
    }
  ...

Was ist mein Fazit? Die Kombination Selenium mit Groovy, auch wenn sie vom Selenium-Team eher stiefmütterlich behandelt wird, ist vielversprechend und macht Appetit auf mehr!

Der Testcode ist ein wichtiger Teil eines Automatisierungstools. Die Entscheidung des ehemaligen Mercury-Teams, im QuickTestProfessional System ausgerechnet vbScript zugrundezulegen, zeugt von einer unangemessenen Verachtung der Code-Ebene. Auch als das Tool entstand, gab es bereits bessere Optionen. Hier ist Selenium klar im Vorteil, denn es wurde im Design auf eine Entkopplung der Ausführungsumgebung vom steuernden Code grosser Wert gelegt.

Aus Entwicklungssicht bedeutet genau diese Eigenschaft des Selenium-Systems den entscheidenden Vorteil. Für eine Gesamtbeurteilung muss aber auch das Umfeld einbezogen werden. QTP ist ab Werk mit dem Quality Center verknüpft, und damit mit einem Bugtrackingsystem, mit Planungs- und Auswertungsmöglichkeiten für ganze Entwicklungsprojekte - die Betriebsphase eingeschlossen. Ob Selenium (eventuell in Kombination mit auf Selenium aufsetzenden anderen Produkten) hier mithalten kann, weiss ich nicht.

[1] Leider ist die Selenium IDE aktuell (Stand 8.8.2011) noch nicht für Firefox 4 und höher freigegeben. Sie ist aber trotzdem auch in Firefox-Releases ab 4.0 verwendbar, indem man sich durch Installation des Add-on Compatibility Reporters zum Releasetester erklärt. Ich habe das gemacht und bislang noch keinen Fehler bei der Verwendung in FF 4 entdeckt.
[2] Beispielsweise wird ein in regulären Ausdrücken vorkommendes Dollarzeichen nicht maskiert, was zu einem Fehler in groovyc führt, der beim Dollarzeichen einen Variablennamen oder einen evaluierbaren Ausdruck erwartet.
[3] Sal Mangano, Das XSLT-Kochbuch, O'Reilly 2006.
[4] Und solche "irgendwelchen Gründe" liegen bei mir vor. Ich habe mir nämlich in UltraEdit ein Werkzeug für die Groovy-Bearbeitung eingerichtet, das erfolgreich compilierte Klassen immer auch gleich ausführt.

Dekorierte BSP-Elemente

2011-08-05T22:02:00.020+01:00

Ein BSP-Element ist eine Softwareobjekt mit einer besonderen Aufrufkonvention: Es wird nicht direkt von ABAP-Codeeinheiten wie Methoden, Routinen oder Funktionsbausteinen aufgerufen, sondern als XML-Codefragment in einem View. In einem früheren Blog habe ich gezeigt, dass dies Auswirkungen auf die Unittests eines BSP-Elements hat: Der normale Aufrufrahmen für die Testklasse eines BSP-Elements enthält die Ausführung eines HTTP-Requests auf eine spezielle Testseite.

In diesem Blog will ich die Konsequenzen hinsichtlich der Erweiterbarkeit von BSP-Elementen nach dem Open-Closed-Prinzip von Bertrand Meyer betrachten:

Modules should be both open (for extension) and closed (for modification).

Lässt sich also ein bestehendes (z.B. in der BSP-Extension eines Drittlieferanten ausgeliefertes) BSP-Element erweitern, ohne das Element selbst modifizieren zu müssen?

Die Schnittstelle eines BSP-Elements besteht nicht aus Import- und Exportparametern, sondern aus Attributen und dem Elementinhalt. In Analogie zu den domänenspezifischen Sprachen (DSL), die ja nach Martin Fowler als eine API mit einer auf den Verwender angepassten Syntax aufgefasst werden sollten (er betrachtet DSL als "an alternative interface to a library than the usual command-query API" [1]), können wir auch ein BSP-Element als eine domänenspezifische Schnittstelle betrachten: Denn die BSP-Elemente fügen sich dank ihrer XML-Syntax nahtlos in den HTML-, XHTML- oder XML-Code ein, mit dem ein View üblicherweise formuliert wird.

Ein einfaches Beispiel: Um eine HTML-Tabelle mit den drei Spalten für Position, Material und Bezeichnung aus Modeldaten, etwa einer internen Tabelle gt_items in einem Model bestellung zu erzeugen, kann ich mit Vorteil das BSP-Element <z:table> verwenden, indem ich es im View auf folgende Weise aufrufe:

<z:table table_id="items" binding="//bestellung/gt_items">
  <z:column name="posnr"
               text="<=otr(z_bestellung/position>"
               listPos="010"/>
  <z:column name="matnr"
               text="<=otr(z_bestellung/material>"
               listPos="020"/>
  <z:column name="arktx"
               text="<=otr(z_bestellung/bezeichnung>"
               listPos="030"/>
</z:table>

Das Element <z:table> aus der Tag Library Z meines BSP-Frameworks erzeugt bei diesem Aufruf eine HTML-Tabelle mit den angegebenen Spalten, von der Art dieses Beispiels.

Über das nackte Gerüst einer (mit Stylesheetklassen und ID's versehenen) HTML-Tabelle hinaus bietet die <z:table> eine Reihe von Features, die es selten nötig machen, das Element wirklich grundsätzlich erweitern zu müssen. Einige dieser Features habe ich in meiner Artikelserie zum Tabellentag erläutert.[2] Vor allem der Beitrag über die Exits des Tabellen-Tags zeigt, dass mit den eingebauten Zeitpunkten bereits viele Erweiterungen im Sinne des Open-Closed Principle möglich sind, d.h. ohne die Implementierung des <z:table>-Elements ändern zu müssen.

Hier will ich aber den Fall diskutieren, dass man sich die Logik des <z:table>-Elements in einem eigenen Tabellenelement zueigen machen möchte, sagen wir <zz:table>, indem man sie wiederverwendet - und damit den Teil des Elements, der aus der internen Tabelle die HTML-Elemente <table>, <tr>, <td> usw. generiert, nicht selbst implementieren muss.

Für gewöhnliche Klassen würde man in einem solchen Fall das Entwurfsmuster Dekorierer verwenden: Die neue Klasse enthält eine Referenz auf die bestehende Klasse in Form eines privaten Attributs und trägt (mindestens) die gleiche Schnittstelle wie die bestehende Klasse, indem sie z.B. ein Interface implementiert. Diese Implementierungen enthalten neben dem delegierenden Aufruf derselben Interfacemethode in der bestehenden Klasse noch den weiteren Code, um den sie durch die neue Klasse "angereichert" wird (daher der Name Dekorierer).

Nun steckt hinter einem BSP-Element ebenfalls eine Klasse: Seine Elementbehandlerklasse. Hier lässt sich der Dekorierer-Ansatz sofort übertragen. Die gemeinsame Schnittstelle ist das Interface if_bsp_element. Wir benötigen also zunächst einmal in der neuen Behandlerklasse – wenn das Element <zz:table> heisst, sollte sie zcl_bsp_zz_table heissen – eine Referenz auf eine Instanz der bestehenden Klasse zcl_bsp_z_table. Nennen wir diese Variable go_table.

Zum Zeitpunkt do_at_beginning (d.h. in der if_bsp_element-Methode dieses Namens) konstruieren wir das neue Objekt mit der dafür vorgesehenen Fabrikmethode:

method if_bsp_element~do_at_beginning.
* <z:table>-Element zum Erzeugen der Tabelle
call method zcl_bsp_z_table=>factory
  exporting
    binding            = binding
    ...
    zebra              = zebra
  receiving
    element            = go_table.
...    
endmethod.

Bevor wir nun an das <z:table>-Element delegieren, müssen wir allerdings noch zwei weitere Dinge tun:

Erstens müssen wir den Viewkontext der BSP-Laufeit an das Delegationsobjekt übergeben:

* Seitenkontext an <z:table> übergeben
go_table->m_page_context = m_page_context.

Kaum ein BSP-Element, das wirklich etwas Nichttriviales macht, wird ohne diese Zuweisung richtig funktionieren. Die aktuellen Informationen zum Seitenkontext werden an zahlreichen Stellen in der Implementierung benötigt – nicht zuletzt braucht ein BSP-Element eine aktuelle writer-Instanz (die über den Seitenkontext zugänglich wird), um z.B. den generierten HTML-Code auszugeben.

Zweitens hängen wir das neu erzeugte BSP-Element, auch wenn es im View-Code nicht sichtbar ist, sondern verdeckt unter der Fassade des <zz:table>-Elements lebt, in den aktuellen Elementstack ein (das Casting auf die Context-Klasse ist hier nötig, weil die Operationen auf dem Elementstack bewusst nicht als Teil der Schnittstelle if_bsp_page_context entworfen wurden, sondern nur als öffentliche Methoden der implementierenden Klasse cl_bsp_page_context verfügbar sind):

  data: lo_page_context type ref to cl_bsp_page_context,
      lo_delta0 type ref to if_bsp_delta_handler.

lo_page_context ?= m_page_context.
lo_page_context->element_push( element = go_table delta_handler = lo_delta0 ).

Das hat den Vorteil, dass innere Elemente, wie im obige Beispiel das Element <z:column>, mittels der Methode get_class_named_parent() genau wie im Standardfall mit dem übergeordneten <z:table>-Element kommunizieren können. Würden wir das Element nicht auf den Stack legen, so würden innere Elemente i.a. nicht mehr wie vorgesehen funktionieren.

Natürlich müssen wir das eingehängte Element nach Abarbeitung des erweiterten Elements auch wieder aus dem Elementstack entfernen. Das geschieht gegen Ende der Implementierung von do_at_end():

  data: lo_page_context type ref to cl_bsp_page_context,
      lo_delta0 type ref to if_bsp_delta_handler.

lo_page_context ?= m_page_context.
lo_page_context->element_pop( element       = go_table
                              delta_handler = lo_delta0 ).

Nun können wir wie beim Dekorierermuster verfahren und neben der Delegation neue Funktionalität hinzufügen. In der Regel wird das zu den Zeitpunkten do_at_beginning und do_at_end geschehen, es stehen aber natürlich auch alle anderen Methoden des Interface if_bsp_element für Erweiterungen zur Verfügung.

Ist dies gemacht, können wir das neue Element <zz:table> genauso wie das alte aufrufen,
aber auch zusätzliche Funktionen einfügen. Im folgenden Beispiel gibt es ein neues Attribut funkyAttribute und ein neues inneres Element <zz:funkyInnerElement>:

<zz:table table_id="items"
       binding="//bestellung/gt_items"
       funkyAttribute="dizzle">
  <zz:funkyInnerElement foo="bar"/>
  <z:column name="posnr"
               text="<=otr(z_bestellung/position>"
               listPos="010"/>
  <z:column name="matnr"
               text="<=otr(z_bestellung/material>"
               listPos="010"/>
  <z:column name="arktx"
               text="<=otr(z_bestellung/bezeichnung>"
               listPos="010"/>http://www.blogger.com/img/blank.gif
</z:table>

[1] Interview mit Martin Fowler und Rebecca Parsons über DSL in
Dr. Dobb's Journal (12/2010), http://drdobbs.com/architecture-and-design/228200852.
[2] Darstellung interner Tabellen mit CSS, Präsentation von Tabellen: die Datenquelle und Contexte und Tabellen-Exits.

Der Microblog

2011-07-30T16:18:00.039+01:00

Mehr als Twitter, aber weniger als Blogspot – einen solchen Microblog wünschte ich mir. Nun kann er schon seit einigen Monaten unter http://ruediger-plantiko.net/microblog/ betrachtet werden. Hier will ich meine Ankündigung wahrmachen, ihn kurz zu dokumentieren.

An dem, was ich hier auf den "Blogspot" stelle, habe ich meist längere Zeit laboriert – habe es im Geiste vorbereitet, abgewogen, das Für und Wider bedacht, es dann aufgeschrieben, korrigiert, überarbeitet, ...

Auf der anderen Seite nutze ich meinen Twitter-Account, um schnell zwischendurch einmal etwas in die Welt zu posaunen: Eine Mini-Zustandsmeldung, einen bedenkenswerten Artikel, den ich gerade gelesen habe, einen Link auf ein Stück ausführbaren Code, an dem ich gerade herumexperimentiere, und so weiter. Die Beschränkung auf 140 Zeichen für eine Nachricht ist für diese Art von Zustandsmeldung gerade richtig.

Aber manchmal gibt es auch Gedanken, Themen, Fragen, die sich einfach nicht in 140 Zeichen fassen lassen, sondern ein oder zwei Abschnitte Prosa erfordern, um sie klar zu vermitteln. Ich hatte das Bedürfnis, sie in kurzer Frist niederzulegen - ohne sie erst lange mit mir herumzutragen und zu einem umfangreichen Artikel zu verarbeiten. Genau für diese Zwecke erbaute ich mir meinen persönlichen Microblog. Wenn ich dort - mit einer sprechenden URL - etwas hineinstelle, steht es mir frei, diese URL zusätzlich auch noch zu twittern, um den Inhalt zu verbreiten. Die - durchaus sinnvolle - Begrenzung von Twitter ist im Microblog aufgehoben.

Meine URLs sind rein semantisch aufgebaut und folgen dem Schema "Wer - macht - was". Ein Beispiel:

http://ruediger-plantiko.net/microblog/?eine-bresche-schlagen

Der URL kann man entnehmen, dass Rüdiger Plantiko einen Microblog geschrieben hat, der anscheinend das Thema Eine Bresche schlagen hat. Mehr nicht. Ob der angezeigte Inhalt eine HTML-Seite ist oder einen anderen Inhaltstyp hat, ist nicht erkennbar. Auch nicht, ob für die Anzeige des Blogs CGI oder irgendeine andere Technologie verwendet wird. Statt einer künstliche Artikel-ID (etwa in der Art ?article_id=D0F5C7) nutze ich den Queryteil der URL für eine lesbare Kennzeichnung des Artikels, die nach einer unmittelbar nachvollziehbaren Regel aus der Überschrift gewonnen ist.

Diese URLs werden gültig bleiben - auch wenn es mir irgendwann einmal in den Sinn kommen sollte, das dahinterliegende technische Konzept völlig zu ändern. Egal mit welcher Programmiersprache der Request bedient wird, egal ob eine rein serverseitige Generierung oder eine Mischung aus Client- und Servercode verwendet wird: Die URL kann immer für den Abruf des entsprechenden Inhalts verwendet werden.

Wie aber ist der Microblog aktuell implementiert? Ich habe eine Mischung aus JavaScript und Perl in Form eines "Client-Server-Handshaking" gewählt, die sich auch schon bei früheren Aufgaben bewährt hat. Statt einer Framework-Kanone wie Prototype oder jQuery verwende ich meine eigene minimalistische JavaScript-Bibliothek minlib, vor allem da sie unkomprimiert nur etwa 10 KB benötigt, was sich günstig auf die Ladezeiten auswirkt.

Egal welchen Eintrag meines Microblogs man abruft, wird zunächst eine immer gleiche HTML-Seite an den Browser übergeben, die als Rahmen dient. Nach dem Laden der Seite wird der gewünschte Text mittels eines Ajax-Requests vom Server abgeholt und in den dafür vorgesehenen Inhaltsbereich gestellt.

Wenn ich einen Eintrag erstelle, wird dieser auf dem Server in einer Datei microblog.dat eingefügt. Hier ein Beispieleintrag:

---
title:Eine Bresche schlagen
id:eine-bresche-schlagen
timestamp:20110524205854
content:Beim Entwickeln einer Applikation ist es eine brauchbare 
Strategie, zuerst <i>eine Bresche bis zum Ziel zu schlagen</i>:
<ul>
  <li>Die für jede Applikation im jeweiligen Konzept benötigten ...

Wie man sieht, beginnt jeder Eintrag mit dem speziellen Trennzeichen ---, das in einer Zeile für sich stehen muss. Ein Eintrag hat vier Attribute, von denen drei in eine Zeile passen und das vierte, der eigentliche Text des Eintrags, von beliebiger Länge ist.

Es hat sich bewährt, bei allen Anwendungen, die mit Ajax operieren, durchgängig mit dem UTF8-Format zu arbeiten. Die Datei microblog.dat ist daher ebenso im UTF8-Format codiert wie die zu sendende Webseite. Sowohl in Perl (mein Provider verwendet aktuell die Version 5.8.4) als auch in JavaScript ist bei Verwendung von UTF8 kein Extra-Code für die Umwandlung der Zeichencodierung nötig.[1]

Das Perl-Script kann nun anhand des Query-Strings zu verschiedenen Aktionen veranlasst werden. Der Query-String kann einerseits die ID eines Topics sein – dann werden die Attribute dieses Topics im JSON-Format angeliefert:

/cgi-bin/microblog.pl?cassian-ueber-die-fressgier

bringt die Antwort:

[
{
id:"cassian-ueber-die-fressgier",
title:"Cassian über die Fressgier",
timestamp:"20110724210423",
content:"Der Mönch Johannes Cassian (ca. 360 - ca. 435) ..."
}
]

Die URL kann statt der ID eines Topics aber auch ein Verb enthalten, um gezielt eine bestimmte Aktion auszuführen. Mit der folgenden URL beispielsweise werden die letzten 5 Topics im JSON-Format beschafft.

/cgi-bin/microblog.pl?last-5

Das obige Datenbeispiel zeigt, dass als Übergabeformat die Datenstruktur eines Arrays of Hashs (AoH) gewählt wurde. In dieser Form lassen sich die Daten auch auf der JavaScript-Ebene leicht verarbeiten und ins HTML-Dokument einmischen.

Da einem Querystring nicht auf Anhieb angesehen werden kann, ob es sich um eine ausführbare Aktion (wie last-5) oder um eine Topic-ID (wie cassian-ueber-die-fressgier) handelt, muss das aus Performancesicht Günstigere zuerst ausprobiert werden: Das Programm prüft zunächst, ob es sich beim Querystring eventuell um den Namen eines Unterprogramms handelt (das ist nämlich nur ein Lookup in der Symboltabelle, die nach dem Parsen des Programms durch den Perl-Interpreter sowieso im Speicher vorliegt). Nur wenn kein Unterprogramm dieses Namens gefunden wird, wird das Argument als Themen-ID interpretiert:

#!/usr/bin/perl
use strict;
use warnings;

print "Content-Type:text/plain\n\n";

_do( $ENV{"QUERY_STRING"} || "get-all" );

# --- Eine Aktion ausführen
sub _do {
  my $action = shift;
# Ausführbare Aktion?
  if (not _do_action( $action )) {
# Letzter Versuch: Ist es vielleicht eine ID?  
  _get($action);
  }
}

Als Konvention, um Verwechslungen mit Topic-ID's zu vermeiden, lasse ich alle Aktionen = Unterprogramme in diesem Script mit einem Unterstrich beginnen. Das Unterprogramm _do_action führt ein Unterprogramm des im Querystring angegebenen Namens aus, falls es ein solches gibt, und gibt in diesem Fall eine 1 zurück. Wenn es kein solches Unterprogramm gibt, wird 0 zurückgegeben:

# --- Die übergebene Aktion ausführen
sub _do_action {
  my $action = shift;
  my ($subname,$arg);
# Ein numerisches Argument am Schluss finden, z.B. bei  "last-25"  
  ($subname,$arg) = ($action =~ /^([\w-]+?)(?:-(\d+))?$/);
# Hyphens sind netter lesbar als Unterstriche
  $subname =~ s/-/_/g;
# Ggf. führenden Unterstrich setzen
  $subname =~ s/^(?!_)/_/;
# Unterprogramm dynamisch aufrufen   
  return _call( $subname, $arg );
  }

Für den dynamischen Aufruf eines Unterprogramms ist es nötig, die strenge Syntaxprüfung strict 'refs', die mit use strict; normalerweise eingeschaltet ist, zu deaktivieren. Dies sollte natürlich für einen möglichst kleinen Codeabschnitt geschehen. Das war einer der Gründe, warum ich den tatsächlichen Aufruf des Unterprogramms wieder in einer eigenen Subroutine gekapselt habe.

# --- Unterprogramm dynamisch aufrufen
sub _call {
  no strict 'refs';  
  my ($subname,$arg) = @_;
  if (defined &{$subname}) {
    &{$subname}($arg);
    return 1;
    }
  return 0;      
  }

Nun verbleiben wir mit dem Fall, dass der Querystring eine Topic-ID enthält, das heisst mit dem Top-Level-Aufruf des Unterprogramms _get():

# --- Einen einzelnen Post über seine ID zurückgeben
sub _get {
  my $id = shift;
  my $posts = _select_posts();
  my $post = $posts->{$id};
  print "[\n";
  _print_post( $post ) if $post;
  print "]\n";
  }

Wenn ich einmal mehr als ca. 500 Einträge im Microblog habe, werde ich den Zugriff auf einen einzelnen Post eventuell optimieren. Bis dahin ist es völlig ausreichend, bei jedem Zugriff die volle Datei microblog.dat als Hash of Hashs einzulesen und den Eintrag mit der gewünschten ID auszugeben, falls ein solcher existiert.

Hier die Routine zum Einlesen:

# --- microblog.dat einlesen und in Hash wandeln
sub _select_posts {    
  my ($posts, $post, $fields, $content);  
  
  local $/;
  $/ = "---";
  open BLOG, "microblog.dat" 
    or die "Kann Datei microblog.dat nicht zum Lesen öffnen";
  foreach $post (<BLOG>) { 
    chomp $post;
    $fields = {};
# Progressives Matching für die Ausdrücke der Form "Feldname:Feldwert"
# Ausser für "content" enthalten die Feldwerte keine Zeilenumbrüche
    while ( $post =~ /(\w+)\s*:\s*(.*?)\s*\n/g ) {
      $fields->{$1}=$2;
# Wenn das Feld "content" als nächstes erreicht wird, ...
      if ($post=~ /\Gcontent:(.*)/s) {
# dann den ganzen Rest dieses "Records" als Feldwert aufnehmen        
        $content = $1;
# Anführungszeichen und Umbrüche müssen maskiert werden        
        $content =~ s/"/\\"/mg;
        $content =~ s/\n/\\n/mg;
        $fields->{content} = $content;
        last;
        } 
      }    
    $posts->{$fields->{id}} = $fields; 
    }
  close BLOG;
  return $posts;  
  }

Hier finden ein paar nützliche Perl-Idiome Verwendung, aufgrund derer der Code ziemlich kompakt gestaltet werden kann. Indem ich den Record Separator $/, das Trennzeichen zwischen zwei Records, das standardmässig ein Zeilenumbruch ist, für dieses Unterprogramm begrenzt auf --- setze, liefert mir das foreach der Reihe nach die einzelnen Topics an. Pro Topic suche ich nun mittels progressivem Matching nach Paaren der Form Name:Wert, die dann in die innere Hashreferenz $fields aufgenommen werden. Der äussere Hash verwendet danach die ID als Schlüssel und $fields als Wert.

Das Feldwert zum Namen content wird im Gegensatz zu den vorigen nicht durch einen Zeilenumbruch beendet, sondern ist bis zum Ende des Records zu übernehmen. Ich verwende daher innerhalb des progressiven Matchings, nach Zuweisung des aktuellen Namens und Wertes, einen "vorausschauenden" zweiten regulären Ausdruck, der mit der Zusicherung \G für das Ende des aktuellen Treffers schaut, ob der nächste Feldname wohl content ist. In diesem Fall übernimmt der reguläre Ausdruck den ganzen Rest des Records in den Feldwert, nimmt das Feld in den $fields-Hash auf und verlässt die Schleife mit last (denn content ist das letzte Feld im Record, und das muss auch so sein).

Damit sollte die Wirkungsweise des serverseitigen Scripts ausreichend beschrieben sein. Wie ist dieses nun im Client eingebunden? Wie erwähnt, wird nach dem Laden der Seite ein Request an das Perl-Script abgesetzt und das Ergebnis in das HTML-Dokument eingemischt. Hier ist die zuständige doOnLoad()-Funktion:

// --- Post(s) einlesen und anzeigen
function doOnLoad() {
  var microblog = byId("microblog");
  var queryPart = document.location.href.match(/(\?.+)/) ? 
                    RegExp.$1 : "";
  doRequest( "../cgi-bin/microblog.pl"+queryPart, function() { 
    var p;
    eval("p="+this.responseText);
    p.each( function() {
      microblog.appendChild(createPost(this));
      }); 
    if (window.sh_highlightDocument) sh_highlightDocument();  
    });
  }

Die zur Ausführung des Requests verwendete Funktion doRequest() entstammt meiner JavaScript-Bibliothek minlib (Die Verwendung ist unter diesem Link dokumentiert). Der zurückgegebenen Array of Hashs wird in einem each()-Iterator abgearbeitet. Dabei wird aus jedem Topic mittels createPost() ein HTML-Fragment aufgebaut, das dann in den Seitenbereich microblog eingefügt wird. Schliesslich wird explizit noch einmal das Syntax-Highlighting aufgerufen, da der Zeitpunkt onload, zu dem dies normalerweise erfolgt, beim Empfang der Ajax-Antwort ja schon längst verstrichen ist.

Zum Aufbau des HTML-Fragments für einen Topic verwende ich die DOM-API. Es empfiehlt sich, für jedes Teil des Gesamtobjekts eine passend benannte Funktion zu definieren, das macht den Code übersichtlicher und steigert die Wiederverwendbarkeit:

// --- DOM-Fragment für einen Post erzeugen
function createPost( post ) {
  var t = createDiv( "post", {id:post.id} );
  createLabel( post.id, t );  
  var title = createDiv( "title", "", t );
  createLink( "?"+post.id, post.title, title );  
  createDiv("content", {innerHTML:formatHTML(post.content) }, t );  
  createDiv("timestamp", {innerHTML:getPublishedText(post.timestamp) }, t);  
  return t;
  } 
  
// --- Einen <div> erzeugen und in das Element parent einhängen
function createDiv( className, more, parent ) {
  var div = newElement( "div", more, parent );
  div.className = className;
  return div;
  }

// --- Einen <a href> erzeugen und in das Element parent einhängen  
function createLink( href, content, parent ) {
  return newElement( "a", {href:href,innerHTML:content}, parent );
  }     
  
// --- Einen Label <a name> erzeugen und in das Element parent einhängen  
function createLabel( name, parent ) {
  return newElement( "a", {name:name}, parent );
  }  

// Element mit Attributen erzeugen und in das Element parent einhängen
function newElement( elementName, more, parent ) {
  var el = document.createElement( elementName );
  if (more) setAttributes( el, more );
  if (parent) parent.appendChild( el );
  return el;
  }

Die hier verwendete Funktion setAttributes() (alle Paare des als zweites Argument übergebenen Hashs in das im ersten Argument übergebene Objekt einsetzen) entstammt meiner Bibliothek minlib – im übrigen wird auf dieser Ebene nur noch die DOM-API verwendet.

Bevor der Text in die Seite gesetzt wird, habe ich mir in der Funktion formatHTML noch die Gelegenheit gegeben, ihn nach bestimmten Regeln zu überarbeiten. So möchte ich beispielsweise, dass Wörter, die mit http://... anfangen, automatisch als Links gesetzt werden. Ausserdem sollen Absätze im Text als HTML-Absätze mit dem Element <p> gerendert werden:

// --- HTML-Code eines Post-Contents überarbeiten
function formatHTML( content ) {
  return content.
    replace(/\n\n/g,"<p>").
    replace( /(\s+|^|>)(https?:\/\/[^\s<]+)/g, '$1<a href="$2">$2</a>' );
  }

Weitere Formatierungen sind mir nicht eingefallen. Sollte mir noch etwas in den Sinn kommen, wäre dies die Stelle, um es einzufügen.

Ich sehe nur einen Nachteil dieser Lösung: Menschen, die mit einem Textbrowser wie lynx im Internet unterwegs sind, werden die Inhalte des Microblogs nicht zu sehen bekommen. Das liegt natürlich daran, dass clientseitige Logik zur Datenbeschaffung verwendet wird. Das Problem liesse sich lösen, indem die Logik komplett auf die Serverseite verlagert wird. Ich erlaube mir aber, diesen Punkt bis auf weiteres zu ignorieren – Menschen, die mit einem Textbrowser unterwegs sind, dürften nicht nur an meinem Microblog, sondern überhaupt am Internet wenig Freude haben.[2]

[1] Umgekehrt ist es aber nicht ohne grosse Klimmzüge möglich, Ajax-Requests beispielsweise in der Latin1-Codierung zu versenden und entgegenzunehmen - selbst wenn die umgebende HTML-Seite Latin1-codiert ist.
[2] Womit ich nicht sage, dass Textbrowser grundsätzlich unnütz sind. Sie können sinnvoll sein, um automatisierte Anfragen im Web zu erstellen, z.B. bei einem Wetterdienst, der seine Prognosen immer in einem wohlbestimten Format liefert. Aber auch dafür verwendet man wohl besser eingebaute Funktionen, in Perl zum Beispiel LWP::Simple.

ABAP Unit Tests für BSP-Elemente

2011-07-25T21:13:00.022+01:00

Unit Tests sollten möglichst wenig Abhängigkeiten von der Aussenwelt aufweisen. Sie sollten sich darauf beschränken, eine isolierte Softwarekomponente aufzurufen und die erwarteten Ergebnisse zu prüfen.

Soweit die Theorie. Wie ist diese auf ein BSP-Element anzuwenden? Wir werden sehen, dass in diesem Fall Abstriche beim Prinzip der Isoliertheit von Modultests gemacht werden müssen – nach dem Motto "Keine Regel ohne Ausnahme". Ausnahmen erfordern allerdings eine Begründung.

Ein BSP-Element wird in einem View aufgerufen und produziert HTML-Code (in der Regel). Um diesen Aufruf in einem automatischen Test durchzuführen, muss die nötige Infrastruktur bereitgestellt werden: Der View kann sich nur in einer BSP-Applikation befinden. Diese muss durch die BSP-Runtime aufgerufen werden. Der Test muss also in irgendeiner Form in der Lage sein, einen HTTP-Request auszuführen und das Ergebnis beispielsweise in Form eines Strings entgegenzunehmen, um es gegen das erwartete Ergebnis zu prüfen.

Das ist die einzige Möglichkeit, BSP-Elemente über ihre "öffentliche Schnittstelle" zu testen, denn die öffentliche Schnittstelle besteht in diesem Fall nicht aus einem Interface im technischen Sinne: Obwohl alle BSP-Elementbehandlerklassen das Interface IF_BSP_ELEMENT implementieren, kann es für den Testaufruf ebensowenig dienen wie irgendeine andere öffentliche Methode. Damit ein Element korrekt arbeitet, muss nämlich ein aktueller Seitenkontext bereitstehen - mindestens in Form einer Referenz auf einen View und einer HTTP-Response-Instanz.

Die vollständige Liste aller benötigten Zutaten verbirgt sich aber in den Details der BSP-Runtime. Es wäre also eine schlechte Strategie, für alle Hilfs- und Kontextobjekte, von denen wir feststellen, dass sie benötigt werden, Stub-Objekte bereitzustellen. Mit dieser Strategie würden wir uns von den Implementierungsdetails der BSP-Runtime abhängig machen.

Die natürliche öffentliche Schnittstelle eines BSP-Elements ist ihr Aufruf in einem BSP-View. Der natürliche "Rückgabewert" eines solchen Aufrufs ist HTML-Code.

Der Unit Test eines BSP-Elements muss also einen HTTP-Request ausführen, um eine Testseite aufzurufen, die ausser dem BSP-Element selbst gar keinen oder nur wenig Code enthält. Der Test ist somit nicht mehr wirklich isoliert. Es werden Hilfsklassen, sogar eine Hilfs-BSP benötigt, und die Basisklassen für die Durchführung von HTTP-Requests müssen aufgerufen werden, so dass sehr viel mehr Code mitläuft als nur der Code der zu testenden Elementbehandlerklasse.

Aber: Die Verletzung des "Isoliertheits"-Prinzips für Modultests ist im Fall der BSP-Elemente wirklich notwendig, um das Element über seine öffentliche Schnittstelle, also in seinem normalen Laufzeit-Einsatz zu beobachten.

Wie macht man das nun konkret?

Es empfiehlt sich, alle Modultestklassen von einer gemeinsamen (lokalen) Oberklasse erben zu lassen. In dieser Oberklasse implementiert man die Ausführung des HTTP-Requests, denn dieser Code wird in allen Modultestklassen benötigt werden, gehört also "nach oben".

In der Modultestklasse kann man dann den Request ausführen, indem man die dafür zuständige Methode der Oberklasse aufruft: frühestens in der Methode CLASS_SETUP und spätestens in der einzelnen Testmethode selbst (wenn der Request nur dort gebraucht wird). Die Ausführung des Requests erfolgt mit der Klasse CL_HTTP_CLIENT.

Die folgende Abbildung zeigt einen typischen Callstack, der dabei entsteht:

Der Callstack eines beliebigen Modultests beginnt immer mit dem Basisreport RS_AUNIT_CLASSTEST_SESSION. Dieser wird vom Modultestframework per SUBMIT aufgerufen: So ist sichergestellt, dass jeder Test in einem eigenen internen Modus läuft, so dass er gegenüber der Laufzeit und gegenüber anderen Tests besser gekapselt ist.
In diesem Beispiel wird der HTTP-Request bereits beim CLASS_SETUP ausgeführt, der auf Ebene 11 aufgerufen wird.
Der CLASS_SETUP ruft daher in der allen Modultestklassen gemeinsamen Oberklasse LCL_AU_ALL die Methode RENDER_VIEW auf (Ebene 12).
Ebene 13 ist die Utility-Methode zcl_http_util->do_request, die einen vereinfachten Zugriff auf das HTTP-Client-Objekt cl_http_client durchführt.
Jeder HTTP-Request an den ABAP-Stack eines SAP-Systems durchläuft den Funktionsbaustein HTTP_DISPATCH_REQUEST (hier auf Ebene 16).
Das ICF stellt fest, dass ein BSP-Controller aufzurufen ist, was über den Behandler CL_HTTP_EXT_BSP gemacht wird: Ebene 18.
Das BSP-Framework ruft den zuständigen Controller auf, in dessen DO_REQUEST-Implementierung (Ebene 21)...
... dann die Testseite aufgerufen wird (Ebene 26).
In dieser Seite befindet sich das hier zu testende <z:table>-Tag. Dessen DO_AT_END()-Methode enthält schliesslich den zu testenden Code (Ebene 29)!

Interessant an diesem Callstack ist noch, dass Aufruf des HTTP-Requests und seine Behandlung im selben Callstack stattfinden. Das ist nicht normal: Normalerweise würde ein eingehender HTTP-Request über einen ganz eigenen Prozess vom System abgearbeitet. In diesem Fall aber wird der Funktionsbaustein HTTP_DISPATCH_REQUEST direkt aufgerufen. Um dies zu erreichen, haben wir das HTTP-Clientobjekt mit der dafür vorgesehenen Methode cl_http_client=>create_internal erzeugt. Der Vorteil ist, dass man bei Bedarf vor oder nach Ausführung des Requests im Test auf öffentliche statische Komponenten des zu testenden Objekts zugreifen kann. Das kann manchmal nützlich sein.

Der Preis für den internen HTTP-Request ist, dass pro Testklasse nur ein Request auf einen BSP-Controller ausgeführt werden kann: Die klasse CL_BSP_RUNTIME merkt sich nämlich in einer statischen Variablen einige Objekte des aktuellen Kontexts, z.B. die Controllerinstanz, und baut diese nach Abarbeitung des Requests nicht ab. Erfolgt im selben Modus ein zweiter Request, wird die Controllerinstanz des letzten Aufrufs verwendet, was zu unerwarteten Ergebnissen führt.

Die Lösung dafür ist: Man organisiere seine Tests so, dass pro Modultestklasse genau ein HTTP-Request ausgeführt wird! Das Ergebnis, beispielsweise in Form eines Instanzattributs gv_html, kann dann von den einzelnen Testmethoden nach verschiedenen Gesichtspunkten geprüft werden.

Trotz des beeindruckend grossen Callstacks bei der Ausführung kann der eigentliche Testcode des Unittests durchaus kompakt und lesbar bleiben. Um dies zu demonstrieren, sei hier eine Testmethode gezeigt, die verifiziert, dass das vom Element <z:table> gerenderte HTML-Fragment eine HTML-Table <table> mit der übergebenen ID ist (in weiteren Methoden derselben Testklasse wird dann der Inhalt dieser <table> geprüft:

  method check_table_id.
    data: lo_root     type ref to if_ixml_element,
          lv_name     type string,
          lv_id       type string.
* <table id="test">
    lo_root = go_document->get_root_element( ).
    lv_name = lo_root->get_name( ).
    assert_equals( exp = 'table'
                   act = lv_name
                   msg = 'Root-Element ist nicht <table>' ).
    lv_id   = lo_root->get_attribute( 'id' ).
    assert_equals( exp = 'test'
                   act = lv_id
                   msg = 'Tabellen-ID ist nicht ''test''' ).
  endmethod.                    "check_table_id

Da das vom Element <z:table> erzeugte HTML-Codefragment nach XML-Syntax wohlgeformt ist (nähere Infos zum erzeugten HTML-Code des <z:table>-Tags enthält mein Artikel Präsentation von Tabellen mit CSS), parse ich es mit Vorteil in ein Objekt go_document vom Typ ref to if_ixml_document und kann dieses dann in den Testmethoden mit den XML-DOM-Zugriffsfunktionen untersuchen.

Ergänzend möchte ich hier noch den immer gleichen Code zeigen, der zur Ausführung eines HTTP-Requests benötigt wird. Ich habe ihn in die Methode do_request einer Utility-Klasse zcl_http_util gepackt, deren vollständiger Code auch unter http://bsp.mits.ch/code/clas/zcl_http_util betrachtet werden kann. Diese Klasse wird natürlich nicht nur für den hier diskutierten Fall verwendet, sondern überall im ganzen System, wenn es darum geht, vom SAP-System aus HTTP-Requests auszuführen (an welches System auch immer diese gerichtet sind).

Wie man sieht, lasse ich dem Aufrufer neben der Ausführung des Requests im eigenen Callstack auch die Option eines "normalen" Requests, der für URLs ohne Host und Port (deren erstes Zeichen also ein '/' ist) über die eingebaute HTTP-Destination 'NONE' an das eigene System gerichtet wird. Alle anderen Requests richten sich wirklich an einen anderen Server.

method do_request .

  data: lv_text   type string,
        lv_url    type string.

* Einen HTTP-Request ausführen
  lv_url = iv_url.
  if iv_internal eq 'X'.
* Request geht auf diesen Server - dann wird gleich der FB
* HTTP_DISPATCH_REQUEST aufgerufen (im selben Callstack!)
* Achtung: Das Attribut server->request wird überschrieben,
* da die aktuelle server-Instanz wiederverwendet wird!
* Daher iv_internal = 'X' nur verwenden,
* wenn man nicht bereits in einer Requestbearbeitung ist.
    cl_http_client=>create_internal(
      importing client = go_client ).
    cl_http_utility=>set_request_uri( request = go_client->request
                                      uri     = lv_url ).
  else.
    if iv_reuse_client_object eq space or
       go_client is initial.
      if lv_url(1) = '/'.
* URL = Pfad bedeutet, Request geht auf diesen Server
* iv_internal = space: Request mit eigenem Callstack absetzen
        call method cl_http_client=>create_by_destination
          exporting
            destination              = 'NONE'
          importing
            client                   = go_client
          exceptions
            argument_not_found       = 1
            destination_not_found    = 2
            destination_no_authority = 3
            plugin_not_active        = 4
            internal_error           = 5
            others                   = 6.
        if sy-subrc <> 0.
          message id sy-msgid type sy-msgty number sy-msgno
            with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
            raising http_error.
        endif.
        cl_http_utility=>set_request_uri( request = go_client->request
                                          uri     = lv_url ).
      else.
* Normalfall: Externer HTTP-Request
        call method cl_http_client=>create_by_url
          exporting
            url                = lv_url
          importing
            client             = go_client
          exceptions
            argument_not_found = 1
            plugin_not_active  = 2
            internal_error     = 3
            others             = 4.
        if sy-subrc ne 0.
          message id sy-msgid type sy-msgty number sy-msgno
            with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4
            raising http_error.
        endif.
      endif.
    else.
      cl_http_utility=>set_request_uri( request = go_client->request
                                        uri     = lv_url ).
    endif.
  endif.

* CDATA angegeben? Dann mit senden
  if iv_cdata is not initial.
    go_client->request->set_cdata( iv_cdata ).
  endif.

* Weitere spezifische Anreichungen des Request-Objekts?
  raise event prepare_request
    exporting
      eo_request = go_client->request.

* Request absenden
  call method go_client->send
    exceptions
      http_communication_failure = 1
      http_invalid_state         = 2
      http_processing_failed     = 3
      others                     = 4.
  if sy-subrc ne 0.
    go_client->get_last_error( importing message = lv_text ).
    message lv_text type 'I'
      raising http_error.
  endif.

  go_client->receive( exceptions others = 1 ).
  if sy-subrc ne 0.
    go_client->get_last_error( importing message = lv_text ).
    message lv_text type 'I'
      raising http_error.
  endif.

  ev_html = go_client->response->get_cdata( ).

* Aus Kompatibilitätsgründen muss et_html angeboten werden
  if et_html is requested.
    call function 'Z_SPLIT_STRING_TO_TABLE'
      exporting
        iv_string = ev_html
      importing
        et_table  = et_html.
  endif.

* Ggf. Verbindung schliessen
  if iv_reuse_client_object eq space.
    go_client->close( ).
    clear go_client.
  endif.

endmethod.

Resultatbaumfragmente sind keine Knotenmengen!

2011-05-13T19:10:00.025+01:00

XML ist eine Auszeichnungssprache für strukturierte Daten. XSLT ist eine Programmiersprache zur Transformation von XML-Dokumenten. Wenn wir also ein XSLT-Programm schreiben und darin strukturierte Daten benötigen (in einer Situation, in der man in anderen Programmiersprachen eine auf Hashs, Arrays und Records aufgebaute Datenstruktur verwenden würde), liegt es nahe, auch diese Datenstruktur in XML-Form zu notieren.

Als triviales, illustrierendes Beispiel – ohne jeden praktischen Nutzen – nehmen wir an, wir wollen eine Übersetzung von Zahlwörtern in die Zahlen implementieren, für die sie stehen. Dann könnten wir mit einer Variablen $dict arbeiten, die einen XML-Baum als Inhalt hat:

<xsl:variable name="dict">
  <one>1</one>
  <two>2</two>
  <three>3</three>
</xsl:variable>

Wir könnten versucht sein, den Zugriff auf diese Variable mit einem XPath-Ausdruck auszuführen: Wenn ein Parameter $key ein Zahlwort enthält, könnten wir probieren, die zugeordnete Zahl mit dem Ausdruck

<xsl:value-of select="$dict/*[name(.)=$key]"/>

zu ermitteln. Das sieht so aus, als könnte es funktionieren. Es funktioniert aber nur für einige XSLT-Prozessoren, nämlich im Internet Explorer und in ABAP.

Mehr noch: Gemäss XSLT-Spezifikation muss es auch gar nicht funktionieren! Denn der Inhalt einer <xsl:variable>-Anweisung evaluiert nicht zu einer Knotenmenge (worauf sich ein XPath-Ausdruck anwenden liesse), sondern zu einem Resultatbaumfragment (worauf sich ein XPath-Ausdruck nicht anwenden lässt).

Der folgende Code, von dem man erwarten könnte, dass er eine 2 ausgibt,

<xsl:variable name="key" select="'two'"/>
<xsl:value-of select="$dict/*[name(.)=$key]"/>

liefert beispielsweise auf dem in Java eingebauten Xalan-Prozessor nicht eine '2', sondern die nicht ganz klar nachvollziehbare Fehlermeldung

Fehler beim Überprüfen des Typs des Ausdrucks 'FilterParentPath(variable-ref(dict/result-tree), step("child", 1, pred(=(funcall(name, [step("self", -1)]), variable-ref(key/string)))))'.

Um dieses Problem zu lösen, gibt es eine Erweiterungsfunktion: Die unter dem Namen exslt (mit dem Namensraum-URI http://exslt.org/common) zusammengefassten Erweiterungen enthalten eine Funktion namens node-set( ), die ein Resultatbaumfragment in eine Knotenmenge konvertieren kann. Das obige Beispiel funktioniert also in Xalan, wenn wir es leicht modifizieren:

<xsl:variable name="key" select="'two'"/>
<xsl:value-of select="exslt:node-set($dict)/*[name(.)=$key]"/>

Das ist schön für Xalan, Google Chrome, Firefox und viele andere. Nicht so schön aber für Prozessoren, die die Erweiterungen von exslt nicht kennen, wozu der XSLT-Prozessor von ABAP und der des Microsoft Internet Explorers gehören.

Wenn es nur darum geht, auch noch Microsofts IE in den Kreis der Prozessoren aufzunehmen, die unser XSLT-Programm ausführen sollen, gibt es einen schönen Trick von David Carlisle. Er definiert die Funktion exslt:node-set() im Erweiterungsraum msxml von Microsoft:

<msxsl:script language="JScript" implements-prefix="exslt">
  this['node-set'] =  function (x) {
    return x;
    }
</msxsl:script>

Dabei macht er sich zunutze, dass die Variable $dict bei Microsoft ja bereits eine Knotenmenge ist. Daher ist die Implementierung von exslt:node-set() für diesen Prozessor einfach die identische Funktion.

Ein Trick, der aber leider nicht auf den ABAP-Prozessor anwendbar ist. Wenn wir eine Lösung für alle aufgeführten XSLT-Prozessoren suchen (die Prozessoren von Firefox, MSIE, ABAP und Java (Xalan) ), führt ein anderer Weg zum Erfolg, der leider nicht ganz so kurz ist: Wir packen für den Anfang unsere Beispielaufgabe in ein mit zwei Parametern versehenes Template: Der Parameter $dict enthält unsere strukturierten Daten als Knotenmenge. Der zweite Parameter $key ist ein String: Der Name des Elements, das wir suchen. Das Template stellt den Inhalt dieses Elements ins Ergebnis:

<xsl:template name="_getValue">
  <xsl:param name="dict"/>
  <xsl:param name="key"/>
  <xsl:value-of select="$dict/*[local-name(.) = $key] "/>
</xsl:template>

Statt nun dieses Template direkt aufzurufen, rufen wir es indirekt über einen Wrapper auf, der den Parameter $dict je nach Prozessor zunächst mit exslt:node-set() in eine Knotenmenge verwandelt oder ihn direkt durchreicht (weil er schon eine Knotenmenge ist). Um prozessorabhängig festzustellen, welcher Fall vorliegt, können wir die Standardfunktion function-available() verwenden:

<xsl:template name="getValue">
  <xsl:param name="dict"/>
  <xsl:param name="key"/>
  <xsl:choose> 
    <xsl:when test="function-available('exslt:node-set')">
      <xsl:call-template name="_getValue">
        <xsl:with-param name="dict" select="exslt:node-set($dict)"/>
        <xsl:with-param name="key" select="$key"/>
      </xsl:call-template>
    </xsl:when>
    <xsl:otherwise>
      <xsl:call-template name="_getValue">
        <xsl:with-param name="dict" select="$dict"/>
        <xsl:with-param name="key" select="$key"/>
      </xsl:call-template>
    </xsl:otherwise>
  </xsl:choose>    
</xsl:template>

Dieses einhüllende Template ist also die Zwischenschicht, die von den konkreten Prozessorimplementierungen abstrahiert. Die implizite Annahme dieses Templates ist, dass ein Prozessor, der die Funktion exslt:node-set nicht kennt, einen Variableninhalt ohne weiteres Zutun als Knotenmenge behandeln kann. Für alle von mir betrachteten Prozessoren ist das der Fall.

Der folgende Aufruf des Templates stellt also die Zahl 3 in die Ausgabe - sowohl wenn er auf dem Web Application Server als auch wenn es in einem Browser durchlaufen wird (und darum ging es mir):

<xsl:call-template name="getValue">
  <xsl:with-param name="dict" select="$dict"/>
  <xsl:with-param name="key" select="'three'"/>      
</xsl:call-template>

Das Zwischen-Template kann man sich übrigens nicht ersparen. Eine direkte, bedingte Verwendung, je nach Fall von $dict oder exslt:node-set($dict) führt zu Fehlermeldungen: sobald der Prozessor herausfindet, dass die Variable $dict ein Resultatbaumfragment enthält, lehnt er es ab, sie in einem XPath-Ausdruck als Node-Set zu verwenden, auch wenn dieser Ausführungszweig ihn zur Laufzeit gar nicht betreffen wird. Nur durch den Templateaufruf wird eine Zwischenebene geschaffen: das Wissen um den Typ des Aktualparameters geht beim Abstieg im Callstack gewissermassen verloren, es darf bei der Prüfung des Templates selbst keine Rolle spielen. Nur dieser Tatsache ist es zu verdanken, dass die hier vorgestellte Lösung funktioniert.

Das Geschenk der Freiheit

2011-04-20T20:33:00.013+01:00

Dreissig Speichen umgeben eine Nabe.
In ihrem Nichts besteht des Wagens Werk.
LaoTse

Die Welt, in der wir leben, ist eigentlich eine doppelte. Neben der gewordenen, um uns sichtbaren, fertig gestalteten Welt ist da immer auch die noch unsichtbare, werdende, sich gerade ins Sein schickende Welt, eine Welt der Möglichkeit, die von einer zarten Morgenröte umgeben ist. Sie ist eben gerade nicht vorhanden, so wie etwa ein Tisch vorhanden ist, und doch ist sie spürbar, ist sie die eigentliche Essenz des Seins. Wenn der Gnostiker Valentinus sagt, dass ein erstes Götterpaar des Urgrundes (bythos) und des Schweigens (sige) die Welt ins Sein brachte, geht das in die gleiche Richtung: Der Urgrund trägt den Stoff bei, aber erst in der dialektischen Spannung zum Schweigen – zu dem, das eben kein Stoff, kein Inhalt, keine Aussage ist, entzündet sich die Welt. Das ist das wahre Geheimnis der "schöpferischen Pause".

Die Freiheit ist ein solches Nichts im Sinne von LaoTse. Jemand, der die Freiheit hat, bekommt zwar alle Möglichkeiten der Gestaltung, ist aber gerade aufgrund dieser Freiheit auf nichts festgelegt. Im Fehlen des Festgelegten liegt die Freiheit. Insofern ist Freiheit ein negativer Wert, da sie nicht konkret ausgefüllt werden kann.

Für die Freiheit lässt sich daher nicht gut Werbung machen, sie macht keine konkreten Versprechungen. In den Freiheitsrechten geht es um den freien, unbestimmten Raum, der geschützt werden muss vor den Machtansprüchen anderer, damit Individuen sich ihren Freiraum nach ihrem eigenen Gutdünken gestalten, ihr individuelles Streben nach Glück (Richard Cumberland/John Locke) verwirklichen können. Für einen leeren Raum ist eben schwierig Werbung zu machen.

Einfacher haben es da die Feinde der Freiheit, die die weissen Wände mit verlockenden Versprechungen bemalen. Wie einfach könnte euer Leben sein, seht hier diese klare und einfache Rechtleitung, euren Plan für den Seelenfrieden, die Einladung in die beste Gemeinschaft, die Einladung zum Paradies: Der kleine Preis für all diese konkreten Herrlichkeiten ist nur, dass ihr "niederfallen und euch unterwerfen" müsst (vgl. Mt. 4,9).

Ohne Frage: Die Versuchung, diesen "kleinen Preis" zu bezahlen ist gross. Auch deshalb, weil die Freiheit furchterregend und anstrengend ist. Die Gefühle, die uns von der Freiheit Abstand nehmen lassen, sind vornehmlich Furcht und Faulheit. Furcht nicht nur vor der Gewalt, mit der die Feinde der Freiheit uns ihre Alternativen aufdrängen, sondern vor allem die Furcht vor der Freiheit selbst, eine Art horror vacui vor der mit dem Wahrnehmen der Freiheit verbundenen transzendentalen Obdachlosigkeit (Georg Lukács). Wer die Freiheit annimmt, wird einsam, denn er begibt sich der Geborgenheit einer Gemeinschaft oder geschlossenen Ideologie. Ein bisschen wird man darin dem Lehrer ähnlich, der sagte: Die Füchse haben Höhlen, die Vögel des Himmels haben Nester; aber der Sohn des Menschen hat keinen Ort, wo er sein Haupt niederlegen kann (Mt 8,20). Wieviel bequemer und einfacher ist es da, auf dem Pfad der Unfreiheit zu wandeln, sich seine Wege und Werte vorgeben zu lassen, die anstrengende kontinuierliche Bemühung um die Freiheit aufzugeben – und von Tag zu Tage zu leben wie der letzte Mensch: Man hat sein Lüstchen für den Tag und sein Lüstchen für die Nacht: aber man ehrt die Gesundheit (Nietzsche).

Über diese Dinge hinaus, die allein schon der Freiheit eine ungeheure Bedeutung und Würde geben, hat die Freiheit auch eine beachtliche religiöse Tiefendimension. Die Freiheit ist der einzige Reim, den ich mir mit meinem beschränkten Verstand auf das Theodizee-Problem machen kann, also auf die Frage, warum Gott nicht machtvoll eingreift, um unsere Geschichte zum Besseren zu korrigieren, wenn er doch allmächtig ist – salopp gesagt: warum er Lissabon, Sumatra und Auschwitz zugelassen hat. Wenn Gott solche Ungeheuerlichkeiten zulässt, ohne einzugreifen, muss ein solches Nichteingreifen um eines unendlich Kostbareren willen geschehen. Dieses unendlich Kostbarere kann nur das Geschenk der Freiheit sein: weil nämlich die Freiheit der einzige Wert ist, der durch eine machtvolle göttliche Intervention bis in seine Grundfesten vernichtet würde.

Es ist derselbe Grund, warum Gott nicht als mächtiger König in die Welt kommt – stattdessen lässt er sich von den Menschen wie ein Verbrecher kreuzigen, und nur zum Hohn bekommt er am Kreuz den Königstitel. Deswegen irren die, die in Reichtum und Macht ein Zeichen von Gottgefälligkeit sehen, so wie sie umgekehrt in Leid und Katastrophen Strafen Gottes sehen wollen. Naturgewalten, selbst die Widerfahrnisse eines persönlichen Schicksals sind oft genug blind gegenüber den Individualitäten, die durch sie zum Opfer werden. So kann sich göttliche Führung doch nicht äussern!

Wie ich schon im Blog Zufall und Notwendigkeit angedeutet hatte, ist das Geheimnis der Freiheit mit der Existenz echten Zufalls verknüpft. Dass echter Zufall existiert, also Ereignisse, die sich prinzipiell nicht vorhersagen lassen, selbst bei theoretisch noch so genauer Kenntnis der Umstände, ist in der Quantenmechanik eine gesicherte Erkenntnis. Der radioaktive Zerfall eines Teilchens ist von dieser Art: Man kann grundsätzlich nicht sagen, zu welchem Zeitpunkt ein konkretes strahlendes Teilchen zerfallen wird, auch nicht in einer perfektionierten Physik der Zukunft, die alle uns noch "verborgenen Parameter" des Vorgangs kennt. Die Dualität von Zufall und Notwendigkeit, in die unsere Welt zerfällt, korrespondiert mit den am Anfang dieses Blogs beschriebenen zwei Welten: Die gewordene Welt entspricht dem Reich der Notwendigkeit – die Welt des Werdens dagegen ist sinngemäss dem Reich des Zufalls oder besser: dem Reich der Freiheit zuzuordnen. Das Schöpferische als spontane Realisierung der Freiheit ist ebensowenig vorhersehbar wie der Zerfall eines Radium-Atoms. Die Freiheit ist von ähnlicher Natur wie der Zufall: Ein Nichtsein, das unvermutet und spontan in die Wirklichkeit überspringen kann. Kreativität ist ein spontanes Ereignis wie der Lichtbogen, der plötzlich aufflammend das Nichts zwischen den Polen überbrückt.

Ein Ort, in dem sich die Kreativität als spontanes Verwirklichen der Freiheit in besonders herausragender Weise manifestieren kann, ist das Gespräch. Das wache Gespräch, das in Rede und Gegenrede versucht, die Wahrheit zu umkreisen: fair, ohne zu monologisieren, ohne zu belehren, ohne zu moralisieren, in jedem Moment auf das völlig Neue eingestellt, auf das neue Argument, den neuen Gesichtspunkt, stets - mit dem Gegenüber - bemüht, in wacher Aufmerksamkeit das Richtige zu erkennen. Das ist der kostbarste Gipfelpunkt der Freiheit, es ist der Moment, in dem wir uns in besonderem Masse als lebendige Wesen spüren und verwirklichen können.

Automatische Tests für JavaScript-Code

2011-03-06T14:48:00.038+01:00

Vor kurzem habe ich auf diesem Blog meine minimalistische JavaScript-Bibliothek beschrieben. Der Post wäre nicht ganz vollständig, wenn ich nicht darauf hinweisen würde, dass diese Bibliothek namens minlib.js unter der milden BSD-Lizenz für alle Interessierten verfügbar ist.

Wie immer, erschliesst sich die Verwendung einer Bibliothek nicht nur durch die Dokumentation, sondern auch durch die Unit-Tests: Unit Tests zeigen, wie die Funktionen konkret aufgerufen werden und welche erwarteten Ergebnisse die Funktionsaufrufe produzieren. Auf der Unit-Testseite können diese Aufrufe darüberhinaus in action beobachtet werden. Man kann sie bei Interesse debuggen und sich Schritt für Schritt ansehen, was die Funktionen tun.

Vor mehreren Jahren hatte ich mich zum Testen von JavaScript-Code für das schmale Unittest-Framework ECMA Unit aus dem Kupu-Projekt entschieden. Auch in diesem Blog schrieb ich darüber bereits am 1.6.2007. Bislang hatte ich keinen Anlass, diese Entscheidung zu bereuen. Ein Framework für Unit Tests muss eben nicht üppig sein. Man muss nur in der Lage sein, ohne viel redundanten Code sofort die geplanten Selbsttestfunktionen hinschreiben und ausführen zu können.

"Testfälle" sind in ECMA Unit Objekte zur Gruppierung von "Tests". Sie sind von einem zentralen Objekt TestCase abgeleitet, das auch die verschiedenen Zusicherungen wie assert, assertEquals, assertFalse usw. beinhaltet. Die einzelnen Tests sind diejenigen Methoden des Testobjekts, deren Name mit dem Präfix test beginnt. Vor Ausführung eines Testfalls wird eine setUp()-Methode aufgerufen, falls eine solche im Testobjekt hinterlegt ist; ebenso wird nach Ausführung eine tearDown()-Methode aufgerufen. Eine Reihe von Testfällen kann zur Ausführung in einer Suite registriert werden, die schliesslich mit runSuite() aufgerufen wird. Für die Protokollierung gibt es ein Objekt HTMLTestReporter, oder, für die Ausgabe auf der Konsole, einen StdoutReporter. Das ist alles. Die (spartanische) Ausgabe des HTML-Reporters sieht folgendermassen aus:

Im Fehlerfall erhält man auch den Hinweis darauf, welcher Test in welchem Testfall welche Assertion verletzte:

Beim Entwickeln von JavaScript-Code kann man also ein Browserfenster mit der einmal eingerichteten ECMA-Unit-Testseite geöffnet lassen und nach jeder Änderung mittels Auffrischen sehen, ob die bisherigen Tests noch alle erfolgreich durchlaufen werden.

Beim Schreiben von Testcode kommt es darauf an, den Test so kurz und lesbar wie möglich zu formulieren. Ein Kommentar ist meistens besser als Meldungsstring für eine Assertion plaziert. Das erhöht die Chance, dass der Text im Fehlerfall von einem Entwickler wirklich gelesen wird.

Hier ein einfaches Beispiel, das die zu testende Funktion byId() an einem Element der Testseite ausprobiert:

this.testById = function(){
  var element = byId( "form2" );               
  this.assert( element,
    "Element der ID 'form2' muss gefunden werden");
  this.assertEquals( element.id, "form2",
    "Element der ID 'form2' muss korrekt identifiziert werden");
  };

Die erste Zusicherung mit assert prüft, ob die Methode byId() überhaupt ein Objekt zurückgeliefert hat. Mit assertEquals folgt dann die spezifischere Zusicherung, dass es auch das richtige Element ist, das gefunden wurde. Die Aufteilung auf zwei Zusicherungen hat den Vorteil einer besseren Lesbarkeit im Fehlerfall. Würde byId() nämlich null oder undefined zurückgeben, so bekäme man ohne den vorgängigen assert beim Zugriff auf element.id eine Ausnahme, etwa "element.id is null or not an object". In der obigen Form aber würde der Test die Meldung "Element der ID 'form2' muss gefunden werden" bringen, was einen spezifischeren Hinweis auf die Fehlerursache enthält.

Für den Test von Callbackfunktionen können wir uns Closures zunutze machen. Die folgende Methode prüft, ob eine each()-Iteration mit der speziellen Ausnahme $break wirklich verlassen wird:

// ---
this.testLeaveEachWithBreak = function() {
  var lastItem;
  [1,2,3,4,5,6,7].each( function() { 
    lastItem = this;
    if (this==5) { throw $break; }  
    });
  this.assertEquals( lastItem, 5, 
    "each() muss mit $break abgebrochen werden können"
    ); 
  };

Die anonyme Iteratorfunktion dieses Tests kann auf die lokale Variable lastItem zugreifen, obwohl diese nicht in ihrem eigenen Geltungsbereich, sondern in dem der Testmethode deklariert wurde. Somit können wir nach Ausführung der Schleife bequem prüfen, ob lastItem wirklich den erwarteten Wert hat.

Ich hatte angekündigt, die Datei minlib.js nicht mehr wesentlich erweitern zu wollen. Die Funktion extend(), die ich noch hinzugefügt habe, ist von ihrer Grösse her sicher unwesentlich, nicht aber von ihrer Bedeutung. Die Funktion ist der von der Mozilla Developer Community empfohlene Vererbungsmechanismus. Unter Verwendung von extend() kann man Vererbung so implementieren, wie es der folgende testRedefineFunction vorführt:

this.testRedefineFunction = function() {

  var A = function(x,y) {
    this.x = x;
    this.y = y;
    };

  A.prototype = {
    t:1,
    x:null,
    y:null,
    f:function() {
      return "t:"+this.t+",x:"+ this.x + ",y:" + this.y ;
      }
    };

  var B = function(x,y,z) {
    A.call(this,x,y);
    this.z = z;
    };

  B.prototype = { z:null,
    f:function() {
      return A.prototype.f.call(this) + ",z:" + this.z;
      }
    };

  extend( B, A);

  var b = new B(2,3,4);

  this.assertEquals( b.f(), "t:1,x:2,y:3,z:4");

  };

Der Test zeigt mehreres auf einmal:

Methoden eines Objekts definiert man nicht im Konstruktor, sondern im Prototyp. Damit wird die Deklaration nur einmal durchlaufen (und nicht bei jeder Instanzbildung).
Alle Komponenten des Objekts sollten im Prototyp aufgezählt sein.
Es müssen aber nicht alle Komponenten bereits im Konstruktor auftreten. Hier kommt z.B. das Attribut t nur über den Prototyp ins Objekt.
Im Konstruktor von B sieht man einen Aufruf des Superkonstruktors mittels A.call(this,x,y) (und nicht etwa einfach nur A(x,y)). Nur so arbeitet man auf der gewünschten Instanz, nämlich der gerade zu bildenden Instanz von B.
Die extend()-Funktion übernimmt den Prototyp von A in den Prototyp von B. Wenn möglich, durch blosse Zuweisung der Referenz des Prototyps (der ja wie alles in JavaScript nur ein Hash ist) an das dafür vorgesehene Pseudo-Attribut __proto__. Falls dieses von der JavaScript-Implementierung nicht offengelegt ist, werden wenigstens alle Prototypkomponenten von A in B übernommen, die in B nicht definiert wurden.
Der Zugriff auf x und y würde auch ohne extend(B,A) im Subtyp B funktionieren, da diese Komponenten auch im Konstruktor von A definiert werden. Der Zugriff auf t wäre aber ohne extend(B,A) erfolglos, da t im Prototyp, aber nicht im Konstruktor verwendet wird.
Man redefiniert Funktionen, indem man sie mit gleichem Namen im Prototyp des Subtyps definiert. Wie im Konstruktor den Superkonstruktor, kann man in der redefinierten Methode mittels A.prototype.f.call(this,...) die Supermethode aufrufen.

Wie testet man eine Funktion, die HTTP-Requests durchführt – z.B. die Funktion doRequest von minlib.js? Der Unit Test muss nur den Code der Funktion doRequest selbst überprüfen, nicht aber den auszuführenden HTTP-Request. Der Unit Test prüft also, ob das XMLHttpRequest-Objekt anhand der Aufrufparameter von doRequest richtig instrumentiert wird. Hierzu kann die Funktion getRequestor, die je nach Browser die richtige Version von XMLHttpRequest beschafft, durch eine passende Mock-Funktion überschrieben werden.

Im Testfall für HTTP definieren wir also mit folgendem Code ein billiges Ersatzobjekt für XMLHttpRequest – ein Objekt, das so tut, als beherrschte es alle Operationen eines veritablen XMLHttpRequests:

function RequestorMock() {};
RequestorMock.prototype = {
   headerFields:{},
   readyState:0,
   onreadystatechange:null,
   body:null,
   open:function(action,url,sync) {
     this.url = url;
     this.action = action;
     this.sync = sync;
     },
   send:function(data) {
     this.body = data;
     this.readyState = 4;
     if (this.onreadystatechange) {
       this.onreadystatechange.call(this);
       }
     },
   setRequestHeader:function(name,value) {
     this.headerFields[name] = value;
     }
   };

In der send()-Methode des Mocks wird sofort der readyState=4 hergestellt und die Callbackfunktion aufgerufen. Das reicht, um die richtige Verwendung des XMLHttpRequest-Objekts in doRequest zu prüfen.

function() {
  this.name = "HttpRequest";
  var getRequestorSave = null;
  var requestorMock = null;
  this.setUp = function() {
    getRequestorSave = getRequestor;
    getRequestor = function() {
      return requestorMock = new RequestorMock();
      };
     };
  this.tearDown = function() {
    getRequestor = getRequestorSave;
    };

  this.testDoRequest = function() {

    var data = 'var i=0;',
        url = 'http://ruediger-plantiko.net',
        callbackCalled = false;

//  doRequest(url,callback,data,action,headerFields)
    doRequest( url,
               function() { callbackCalled = true; },
               data,
               "POST",
               { "Content-Type":"text/javascript" } );

    this.assertEquals( requestorMock.url,  url );
    this.assertEquals( requestorMock.body, data );
    this.assertEquals( requestorMock.headerFields["Content-Type"], 
      "text/javascript" );
    this.assertEquals( requestorMock.action, "POST" );
    this.assert( callbackCalled, 
      "Die Callbackfunktion muss aufgerufen werden" );
    };

  }

Im Setup also wird die (globale) getRequest-Funktion durch den Zeiger auf eine anonyme Funktion überschrieben, die eine Mock-Instanz zurückliefert. Wir merken uns die Instanz noch in einer lokalen privaten Variablen requestorMock, um den Zustand des Objekts im Zusicherungsteil des Tests verwenden zu können. Im Teardown wird die ursprüngliche Funktion wiederhergestellt.

In der Testmethode selbst wird nur noch die doRequest()-Methode mit einigen Dummydaten aufgerufen. Der HTTP-Request selbst wird dann zwar niemals ausgeführt. Wohl aber wird geprüft, dass der Aufruf korrekt ist. Und das ist genau die Aufgabe der Funktion doRequest(): Den HTTP-Request entsprechend den beim Aufruf übergebenen Parametern korrekt auszuführen.

Der Versand von Formularen lässt sich auf noch einfachere Weise überprüfen, indem man das Formularattribut action, das normalerweise die Ziel-URL enthält, durch eine Dummy-URL ersetzt, zum Beispiel action="javascript:void(-1);". Dann kann nach dem submit() inspiziert werden, ob das Formular wie gewünscht gefüllt wurde. So funktioniert der Test der gotoURL()-Funktion:

this.testGotoURL = function() {

  var elem, parent;
  var action = "javascript:void(-1);";

  gotoURL( action, { testField:"testValue" } );

  elem = firstByName("testField");
  this.assert( elem, "gotoURL() muss Formularfeld erzeugen" );
  this.assertEquals( elem.nodeName, "INPUT" );
  this.assertEquals( elem.type, "hidden" );
  this.assertEquals( elem.value, "testValue" );

  parent = elem.parentNode;
  this.assertEquals( parent.nodeName, "FORM" );
  this.assertEquals( parent.action, action );
  this.assertEquals( parent.method, "post" );

  };

Auch die korrekte Registrierung und Deregistrierung von Ereignisbehandlern durch die Funktionen registerFor() und unregister() lässt sich automatisch testen, sobald man weiss, wie man simulativ ein Ereignis produzieren kann, z.B. ein Click-Event. In diesem Fall punktet einmal der Internet Explorer: um einen Mausclick auf das Element e auszulösen, programmiert man hier e.click() – einfacher geht es nicht!

fireClick = navigator.userAgent.match(/MSIE/) ?
function( element ) {
// IE = wunderbar einfach
  element.click();
  } :
function( element ) {
// Alle anderen: Dasselbe total umständlich
  var evObj = document.createEvent('MouseEvents');
  evObj.initEvent( 'click', true, true );
  element.dispatchEvent(evObj);
  };

Der Geradeausfall zum Testen, ob ein registrierter Click-Behandler auch aufgerufen wird, lässt sich dann folgendermassen schreiben:

function() {
  var f = null;
  var idCopiedByHandler = "";
  this.setUp = function() {
    idCopiedByHandler = "";
    f = registerFor( byId("btnTest"), "click", function() {
      idCopiedByHandler = this.id;
      });
    };

  this.tearDown = function() {
    unregister( byId("btnTest"), "click", f );
    };

// ---
  this.testHandlerCalledOnClick = function() {

    var btnTest = byId("btnTest");

    fireClick( btnTest );
    this.assertEquals( idCopiedByHandler, "btnTest",
      "Registrierter Clickbehandler muss bei Click aufgerufen werden" );

    };
  ...  
  }

Ob der Callback aufgerufen wurde, erkennt man daran, dass die ID des Elements (auf das im Behandler mit der Pseudovariable this zugegriffen werden kann) in die private Variable idCopiedByHandler kopiert wurde.

Um mehrere Tests mit derselben Registrierungsfunktion ausführen zu können, gefiel es mir, die Registrierung in den setUp zu setzen und im tearDown wieder zu entfernen. So reduziert sich der Code der Testmethode, wie man sieht, drastisch auf das absolut Wesentliche: Das Auslösen des Clicks und die Prüfung, dass der Clickbehandler aufgerufen wurde.

Für JavaScript-Bibliotheken sind Unit Tests dieser Art bereits ausreichend. Für Webanwendungen, die intensiv mit JavaScript arbeiten, sind natürlich weitergehende Anwendungstests angebracht, zum Beispiel mit QTP oder Selenium. Das wäre Thema eines separaten Blogs.

Workflow-Events bei Änderungen

2011-02-18T07:49:00.009+01:00

Wenn das Workflow-Laufzeitsystem in einem SAP-System einmal eingerichtet ist, unterstützt es die Erweiterung aller Geschäftsprozesse – in vielen Fällen ohne zusätzlichen Programmieraufwand, mit einem modellbasierten Ansatz. Mit dem Workflow Builder können Abläufe auf Basis der im BOR (Business Object Repository) definierten Objekte im Zusammenspiel mit manuellen Schritten (Entscheidungen, Bekanntmachungen usw.) definiert und implementiert werden.

Grundidee ist dabei die lose, customizebare Kopplung von BOR-Ereignissen an Verbraucher. Die Kopplung kann auch im Produktivsystem noch an- und abgeschaltet werden. Verbraucher können Workflows, Tasks, BOR- oder Klassenmethoden oder auch Funktionsbausteine sein. Die Ereignisauslösung ist dabei im gesamten System omnipräsent. Es dürfte kaum ein betriebswirtschaftlich relevantes Ereignis geben, das nicht im Workflowsystem eine Entsprechung findet. Typische Beispiele sind die Anlage neuer Belege oder die Änderung von System- oder Anwenderstatus. Selbstverständlich können Workflow-Ereignisse auch programmgesteuert ausgelöst werden (falls unwahrscheinlicherweise doch einmal eines fehlen sollte), wofür man die Methode raise der Klasse cl_swf_evt_event verwenden sollte.

Hier will ich zeigen, wie man sich für die Änderung bestimmter Felder im Artikelstamm registrieren kann. Im konkret vorliegenden Fall sollte sich ein Verbraucher für die Änderung zweier bestimmter Felder registrieren. Um nun nicht für jede Änderung ein Ereignis auszulösen, erschien es mir nötig, ein Custom Event genau für diesen Änderungsfall zu definieren.

Ereignisse sind Bestandteile von BOR-Objekten. Um modifikationsfrei ein neues Ereignis zu definieren, habe ich einen Subtyp des BOR-Objekts BUS1001001 (Handelsartikel) definiert:

Den neuen Typ ZBU1001001 verwende ich, um ein neues Ereignis FIELDSET_CHANGED zu definieren:

Dieses Workflow-Ereignis muss nun an die gewünschten Änderungen des Artikelstamms gebunden werden. Das SAP-System schreibt Änderungen an Geschäftsobjekten in den Tabellen CDHDR und CDPOS fort. Dabei gibt es pro Geschäftsobjekt einen Typschlüssel, das sogenannte Änderungsbelegobjekt. Beim Entwickeln des Geschäftsobjekts (also in der Regel in der SAP-Standard-Entwicklung) wurde dieses Änderungsbelegobjekt eingerichtet, wobei auch automatische Funktionsbausteine zum Fortschreiben generiert wurden. Heisst das Änderungsbelegobjekt beispielsweise MAT_FULL, so bekommt der zugeordnete Funktionsbaustein den Namen MAT_FULL_WRITE_DOCUMENT. Dieser Baustein wird dann, im allgemeinen in der verzögerten Verbuchung (V2), beim Sichern des Geschäftsobjekts aufgerufen.

Um nun dem Änderungsbelegobjekt mitzuteilen, dass es das Ereignis eines BOR-Objekts auslösen soll, definiert man eine Zuordnung in der Transaktion swec.

Im Detailbild zu dieser Zeile kann man über den Bedingungseditor beispielsweise noch festlegen, dass das Ereignis nur bei Änderung bestimmter Felder ausgelöst werden soll:

Nach diesen Einstellungen wird das neue Ereignis bereits ausgelöst. Bis hierhin liess sich alles mit blossem Customizing erledigen. Wenn nun an das Ereignis an einen Verbraucher gekoppelt werden soll, kann man sich entscheiden: Möchte man selbst einen spezifischen Verbraucher implementieren, oder kann man die gewünschten Funktionen im Rahmen eines Workflows modellieren. Der häufig gewünschte 08/15-Fall, dass irgendjemand gern eine E-Mail-Benachrichtigung hätte, lässt sich eigentlich immer mit Workflowmitteln lösen, d.h. ohne Programmierung. Die Verwendung einer Workflow-Aufgabe zur E-Mail-Erzeugung hat darüberhinaus den Vorteil, dass die Kopf- und Detaildaten der Mail frei einstellbar sind, wobei als Platzhalter Anwendungsdaten verwendet werden können.

Wenn man es möchte, kann man auch programmierte Logik an das Ereignis koppeln. In der folgenden Ereignis-Typ-Kopplung wird zum Beispiel der Funktionsbaustein Z_CONSUME_FIELDSET_CHANGED mit dem neuen Ereignis FIELDSET_CHANGED verknüpft. Die Kopplung bekommt einen symbolischen Namen (der im System nicht weiter verprobt wird), hier MARA_FIELDSET_CHANGED:

Der Funktionsbaustein muss die folgende Schnittstelle aufweisen und ist ansonsten frei definierbar. Die interne Tabelle EVENT_CONTAINER enthält Detaildaten zum Anwendungsobjekt: in diesem Fall die Nummer des Änderungsbelegs.

function z_consume_fieldset_changed.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     VALUE(EVENT) TYPE  SWETYPECOU-EVENT
*"     VALUE(RECTYPE) TYPE  SWETYPECOU-RECTYPE
*"     VALUE(OBJTYPE) TYPE  SWETYPECOU-OBJTYPE
*"     VALUE(OBJKEY) TYPE  SWEINSTCOU-OBJKEY
*"     VALUE(EXCEPTIONS_ALLOWED) TYPE  SWEFLAGS-EXC_OK DEFAULT SPACE
*"  EXPORTING
*"     VALUE(REC_ID) TYPE  SWELOG-RECID
*"  TABLES
*"      EVENT_CONTAINER STRUCTURE  SWCONT
*"----------------------------------------------------------------------

Erwähnenswert ist noch, dass es für Workflowereignisse ein sehr nützliches Trace gibt, das sich über die Transaktion swels ein- und ausschalten lässt (das Ausschalten ist natürlich wichtig, vor allem im Produktivsystem!). In Transaktion swel kann man sich das Log des Ereignis-Trace ansehen. Zum Testen habe ich nacheinander zwei Feldänderungen durchgeführt. Das Log zeigt, dass jeweils das Ereignis ausgelöst und der Verbraucher gemäss der Kopplung MARA_FIELDSET_CHANGED identifiziert und korrekt gestartet wurde.

Eine minimalistische JavaScript-Bibliothek

2011-02-16T21:18:00.078+01:00

HTML ist, wie Stefan Münz es so schön sagte, die lingua franca des Web: HTML bleibt die Sprache, in der man als Server mit einem Browser reden sollte – flankiert von CSS-Code für die kompakte und wiederverwendbare Notation von Stil, und JavaScript-Code für die Implementierung von clientseitigem Verhalten. Manche errichten allerdings prächtige Gebäude, in Form von Web Application Frameworks und denken sich lustige Namen für diese aus, nur um ihre Verwender vor dem direkten Kontakt mit dieser vermeintlich schlimmen Trias zu bewahren: Als würden Entwickler beim Anblick von HTML-, CSS- und JavaScript-Code zu Stein erstarren.

Aber diese prächtigen Gebäude setzen sich alle nicht so richtig durch. Das Interesse, Overhead durch zusätzliche, oft nicht wirklich benötigte Indirektionsebenen zu vermeiden, ist höher als die Angst, aus Versehen doch wirklich einmal eine HTML-Notation zu verwenden, die doch tatsächlich vom Netscape Navigator 4.0 nicht mehr korrekt interpretiert wird. Und da HTML, CSS und selbst JavaScript leicht zu erlernen sind, schreckt die Zielgruppe, an die sich die prächtigen Gebäude eigentlich wenden, nicht davor zurück, statt mit abstrahierenden Frameworks direkt auf der HTML-Ebene zu arbeiten. Dazu kommt, dass es für Content Management und Webanwendungen eine Menge konkurrierende Lösungen gibt, so dass man sich bei Verwendung eines bestimmten Frameworks in eine Abhängigkeit begibt.

Wer also zu der grossen Gruppe der Webanwendungsentwickler gehört, die ihre Anwendungen direkt mit HTML, CSS und JavaScript formulieren, ohne dabei so schreckliche Dinge wie WYSIWYG-Editoren mit automatischer HTML-Codegenerierung zu verwenden, der wird zwar kein Framework benötigen, wohl aber eine Bibliothek von JavaScript-Funktionen. Und zwar aus drei Gründen:

weil er gewisse Funktionen immer wieder benötigt und sie daher nur einmal programmieren möchte (Don't Repeat Yourself),

um auf browserspezifisch unterschiedlich implementierte Features mit einer Abstraktion zugreifen zu können,

um den konkreten JavaScript-Code der Webanwendung flüssig lesbar und doch kompakt formulieren zu können.

Nun gibt es eine Reihe von JavaScript-Bibliotheken für solche Zwecke. Aber jede Bibliothek möchte natürlich besonders gut und umfassend werden, die Konkurrenz in allen obigen Punkten um Längen schlagen. Da erwacht der Ehrgeiz der Bibliotheksentwickler, und die Bibliotheken werden wirklich besser und umfassender - aber auch immer grösser. Dojo 1.5 hat unkomprimiert 370 KB (komprimiert immer noch 88), jQuery 1.5 hat 207 KB (komprimiert 82), und Prototype 1.7 hat unkomprimiert 169 KB (und bietet keine komprimierte Version an; wenn ich aber Frank Marcias JS Minifier verwende, reduziert sich Prototype 1.7 auf 120 KB). Das ist immerhin bedenklich: Braucht man wirklich so grosse Bibliotheken?

Man könnte einwenden, dass die Parsezeiten für Bibliotheken dieser Grössenordnung schon heute vernachlässigbar sind, während die JavaScript-Interpreter immer noch beständig weiter optimiert werden (vom IE9 hört man über traumhafte Performanceergebnisse, die selbst Google Chromes Wunderwaffe V8 noch in den Schatten stellen sollen). Bei Anwendungen, die mit den klassischen Form-Submit-Zyklen arbeiten, schlägt diese Parsezeit allerdings bei jedem Dialogschritt zu Buche. Es empfiehlt sich in jedem Fall das Ökonomieprinzip: Warum soll man etwas laden, das man zu grossen Teilen gar nicht benötigt oder verwendet? Später lässt sich nicht mehr genau sagen, welche Funktionen in welchen Teilen der Anwendung wirklich verwendet werden.

Daher stellt sich die Frage: Welche Funktionen werden besonders häufig benötigt oder ergeben einen besonders grossen Nutzen?

Da sind sicher einmal einfache DOM-Zugriffsfunktionen. Die Funktionen $() und $$() in Prototype und jQuery verwenden die Syntax von CSS-Selektoren, um Knotenmengen aus dem HTML-DOM zu extrahieren. Das ist eine kompakte Syntax, die gut ankommt und von der Zielgruppe verstanden und gelesen wird. Eine gute Wahl. Aber der Parser für die Selektorstrings will erstmal geschrieben werden. Schon eine reine Abkürzung für das geschwätzige document.getElementById macht den Code lesbarer:

// Shortcut für document.getElementById
function byId(id) {
  return document.getElementById(id);
  }

Mit Iteratorfunktionen füllen die Bibliotheken eine weitere Lücke im JavaScript-Sprachumfang. Diese wird zwar mit JavaScript 1.6 durch Methoden wie forEach geschlossen. Bis dahin aber mag ich nicht warten. Mit wenigen Codezeilen lässt sich die Lücke füllen, indem ich dem Array-Objekt des JavaScript-Standards eine neue each-Methode unterschiebe. Die in der Implementierung verwendete, "ausprogrammierte" indexbasierte (also zwangsläufig hässliche) Schleife hilft, viele indexbasierte Schleifen im Applikations-Code durch besser lesbare each()-Konstrukte zu ersetzen.[1]

// --- Array-Iteration mit each()
// Die Callbackfunktion erhält den Wert des Array-Elements als "this"
// Als Argument wird der aktuelle Array-Index übergeben
var _break = {};  // Spezielle Exception, um aus each() auszubrechen
Array.prototype.each = function(f,context) {
  var i,n=this.length;
  if (typeof f != "function") { 
    alert( "Programmfehler: each-Argument muss eine Funktion sein"); 
    return; 
    }
  try {
    for (i=0;i<n;++i) {
      f.call(context||this[i],this[i],i);
      }
    }
    catch(e) {
      if (e!=_break) {throw e; } 
      }
  };

Weitere Iteratorfunktionen wie etwa any() und all(), die feststellen, ob ein oder jedes Element des Arrays eine Bedingungsfunktion erfüllt, halte ich für nicht so wichtig. Eine Filter- oder Subset-Funktion dagegen ist hilfreich, um verkettete Methodenaufrufe zu ermöglichen:

// --- subset(filter)
// Die Teilmenge aller Arrayelemente bilden, 
// für die die filter-Funktion true ergibt
Array.prototype.subset = function(filter) {
  var result = [];
  this.each( function() {
    if (filter.call(this)) { result.push(this); }
    });
  return result;  
  };

Nun können auch weitere DOM-Zugriffsfunktionen geschrieben werden wie byName(name,parentNode) und byTagName(tagname,parentNode) und byClass(classname,parentNode) (wobei der zweite Parameter parentNode optional ist, um nicht das ganze Dokument durchsuchen zu müssen, sondern nur alle Knoten, die unterhalb von parentNode liegen). Zu beachten ist, dass die native Implementierung des Rückgabewertes einer DOM-Funktion wie getElementsByTagName kein Array sein muss, sondern gemäss DOM-Spezifikation nur eine NodeList. Die Implementierung dieser NodeList ist browserspezifisch und nicht in jedem Browser erweiterbar. Um also den Rückgabewert mit each() iterieren zu können, muss das Ergebnis leider in einen Array abgebildet werden:

// Shortcut für getElementsByTagName
function byTagName(tagname,theParent) {
  var i,n,result=[];
  var nodeList = (theParent||document).getElementsByTagName(tagname);
  for (i=0,n=nodeList.length;i<n;++i) { result.push(nodeList[i]); }
  return result;
  }

Ein Verwendungsbeispiel dieser Funktionen: Um alle Eingabefelder eines mit der ID adressdaten bezeichneten Formulars als Name/Wert-Paare in einem Hash einzusammeln, muss ich folgendes schreiben:

var fields = {};
byTagName( "input", byId("adressdaten") ).each( function() { 
  fields[this.name] = this.value;
  });

Komplexere und geschachtelte Bedingungen kann man mit der Funktion byCondition(condition,parentNode) realisieren, die den Baum ab dem angegebenen Element traversiert und alle Elemente einsammelt, für die die Funktion condition zu true evaluiert (auch hier ist, weil NodeList kein Array und nicht erweiterbar sein muss, wieder eine indexbasierte Schleife nötig. Je mehr notwendige indexbasierte Schleifen wir aber in eine Bibliothek extrahieren können, umso weniger hat sie der Anwendungscode nötig):

// --- Alle Elemente, die eine Bedingung erfüllen
function byCondition( condition, theParent) {
  var children, n, i, result = [];
  children = (theParent || document).childNodes;
  n = children.length;
  for (i=0;i<n;++i) {
    if (children[i].nodeType==1) {
      if (condition.call(children[i])) { result.push( children[i] ); }
      Array.prototype.push.apply( result, 
        byCondition( condition, children[i] ) );
      }
    }
  return result;
  }

Man kann die in byCondition enthaltene Traversierung des DOM auch isoliert benutzen: Wer über byCondition verfügt, hat keine Notwendigkeit mehr, selbst an irgendeiner Stelle noch einmal das rekursive Durchlaufen aller Elemente des DOM zu programmieren.

Was man sicher braucht, ist eine Funktion doRequest(url,callback,data,contentType), die HTTP-Zugriffe durchführt (wobei nur die ersten beiden Argumente obligatorisch sind) und die angegebene callback-Funktion in einen Wrapper aufnimmt, um sie bei readyState = 4 aufzurufen. Für die meisten Browser, auch für IE ab Version 7, kann dabei auf das Objekt XMLHttpRequest zugegriffen werden. Für frühere IE-Versionen kann man Fallback-Objekte verwenden. Diesen Code zur Instanzbeschaffung, verpackt in der Funktion getRequestor(), zeige ich hier nicht. Er ist direkt aus dem Wikipedia-Artikel zu XMLHttpRequest übernommen.

// --- Browserübergreifender HTTP-Request
// callback,data,action,headerFields sind optional
function doRequest(url,callback,data,action,headerFields) {
  var field,value,
      theData   = data || null,
      requestor =  getRequestor();
  requestor.open(action||"GET",url,!!callback);  
  if (callback) { requestor.onreadystatechange = function() {
     if (requestor.readyState ==4) {
       callback.call(requestor);  // Mit requestor = this aufrufen
       }
     };
    }
  if (headerFields) {
    for (field in headerFields) {
       requestor.setRequestHeader(field,headerFields[field]);
       }
    }
  requestor.send(theData);
  return callback ? requestor : requestor.responseText;
}

Weiter gibt es je nach Browser verschiedene Arten, einen Ereignisbehandler zu registrieren:

// --- Browserübergreifende Registrierung einer Funktion
function registerFor( theElement, theEvent, theHandler ) {
  var eventNormalized;
  if (typeof theHandler != "function") {
    alert( "Programmfehler: Nur Funktionen können registriert werden");
    return;
    }
  var f = function(e) { theHandler.call(getSource(e),e); };
  if (window.addEventListener) {
    eventNormalized = theEvent.replace(/^on/,""); // immer ohne "on"
    theElement.addEventListener(eventNormalized, f, false);
    }
  else {
    eventNormalized = theEvent.replace(/^(?!on)/,"on"); // immer mit "on"
    theElement.attachEvent(eventNormalized, f );
    }
  }

Die Validierung, dass der übergebene Behandler wirklich eine Funktion ist, ist sehr nützlich, denn viele Entwickler schreiben aus Gewohnheit

registerFor(window,"load",doOnLoad());  // falsch!!!

was natürlich grundfalsch ist (sie machen es, weil sie es seit DOM Level 0 gewohnt sind, Ereignisbehandler direkt im HTML zu notieren). Die Klammern nach doOnLoad sind hier falsch: es soll ja nicht die Behandlerfunktion zum Zeitpunkt des Aufrufs von registerFor evaluiert und das Ergebnis dieses Aufrufs registriert werden (das meistens undefined oder false ist), sondern die Funktion doOnLoad für die spätere Ausführung zum Zeitpunkt load vorgemerkt werden.

Ein Ereignisbehandler muss auf das Element zugreifen können, von welchem aus das Ereignis ausgelöst wurde. Am einfachsten geht das, wenn dieses Element der Funktion bereits als this-Argument bereitsteht, wie es z.B. in Prototype gelöst ist. Das macht auch meine Registrierungsfunktion registerFor: Wie zu sehen ist, wird nicht die übergebene Funktion (theHandler) selbst, sondern ein Wrapper f registriert, der bei Ereignisauslösung zunächst die Ereignisquelle ermittelt und das this-Argument mit diesem Element belegt. Die dafür verwendete browserübergreifende Funktion getSource(event) ist im Grunde ein Einzeiler, aber solche Dinge soll man nur einmal hinschreiben müssen – die Benennung als Source (wie bei Microsoft) finde ich übrigens besser als Target (wie bei Mozilla):

// Browserübergreifende Ermittlung einer Event-Source
function getSource( event ) {
  return event && event.target || window.event.srcElement;
  }

// Browserübergreifende Ermittlung eines key-Codes
function getKeyCode(event) {
  var e = event || window.event;
  return e.keyCode || e.which;
  }

Weitere Funktionen: setText() und getText() setzen und lesen Texte beliebiger Elemente (in <input>-Elementen wird der value verwendet, für andere Elemente der erste textförmige Kindknoten, der ggf. erst anzulegen ist). gotoURL(url, fields) erstellt und versendet ein adhoc-Formular, damit die URL nicht mit Get-Parametern verschmutzt wird.

Zusammen mit einigen weiteren kleinen Funktionen dieser Art habe ich eine minimalistische JavaScript-Bibliothek erstellt, die unkomprimiert nur rund 8 KB umfasst und die ich nicht mehr nennenswert erweitern werde:

http://ruediger-plantiko.net/minlib/

minlib.js ist eigentlich bei der Refaktorisierung meiner MVC-JavaScript-Bibliothek global.js entstanden. Interessanterweise war die Datei vor wie nach der Refaktorisierung ungefähr gleich gross (nämlich 20KB), obwohl sie hinterher die minlib-Funktionen enthielt! Das heisst, die 8KB habe ich bei der Refaktorisierung des restlichen, MVC-spezifischen Teils wieder herausgeholt, indem ich den Code nun kompakter formulieren konnte! Das Ergebnis war eine besser lesbare Datei, die um einige nützliche wiederverwendbare Funktionen angewachsen war.

[1] Die each-Funktion ist so geschrieben, dass sie funktionsidentisch mit der each()-Funktion des Prototype-Frameworks abläuft. Das ist mit Absicht so gemacht, damit im Bedarfsfall prototype und minlib.js gleichzeitig verwendet werden können.

Allahs ist nicht der Okzident!

2011-02-13T13:46:00.082+01:00

11. September 2001 - ich war gerade dabei, einen normalen Arbeitstag bei SAP in Walldorf zu beenden. Auf dem Weg nach Hause fiel mein Blick auf den grossen, am Haupteingang angebrachten Monitor, über den normalerweise SAP-Infos und Marketingfilme ausgestrahlt wurden. An diesem Abend zeigte er in einer Sondersendung die schockierenden Bilder von den im Namen Allahs verübten Mordtaten. Eine Traube von Kollegen hatte sich schon darum gebildet, die kopfschüttelnd und sichtlich entsetzt die Bilder verfolgten. Auch ich war fassungslos. Für mich war dieser Tag ein Wendepunkt und eine grausame Offenbarung. Ich fühlte, wie ich innerlich Partei nahm. Alle Differenzen, die es im Westen gibt, sei es zwischen Konservativen und Liberalen, zwischen Bürgerlichen, Sozialisten oder Kommunisten, sei es zwischen Christen und Juden, Agnostikern und Atheisten, all diese Differenzen wurden plötzlich unbedeutend angesichts des Krieges der Barbarei gegen die Zivilisation (Wafa Sultan) [1], der sich hier manifestierte. Alle Unvollkommenheiten oder Ungerechtigkeiten der westlichen Systeme wurden klein und unwichtig angesichts dieses Einbruchs der rohen Gewalt.

Die Somalierin Ayaan Hirsi Ali war genauso entsetzt und fassungslos wie viele im Westen aufgewachsene Menschen. Sie sah sich damals noch selbst als Muslimin. Wieder und wieder las sie die Argumente Osama bin Ladens, mit denen dieser die Taten rechtfertigte. Sie prüfte die Koranstellen und stellte fest, dass es stimmte: Der Koran verlangt wirklich die Tötung Ungläubiger, daran lässt sich nichts herumdeuten.[2] Damit stand ihre Entscheidung fest, dass sie dem Islam den Rücken kehren musste. Auch für sie war dieser Tag demnach ein Wendepunkt. Sie schreibt, dass es ihr nicht leicht fiel, sich von der Angst vor Höllenstrafen loszusagen. Noch lange nach ihrer Abwendung vom muslimischen Glauben ertappte sie sich bei Schuldgefühlen vor Allah. Im Ganzen ist ihre Bilanz aber positiv - sie konnte endlich in einer zivilisierten Gesellschaft ihren Drang nach Freiheit leben. Noch schöner wäre es natürlich, wenn sie dies nicht unter ständigem Polizeischutz tun müsste, denn aus den Reihen ihrer früheren Glaubensgemeinschaft droht man ihr mit Mord – wie jeder "Apostat" (dramatisierend für: Ausgetretene) nach islamischem Recht des Todes ist: Und wenn sie sich abwenden, dann greift sie und tötet sie, wo immer ihr sie findet, und nehmt euch niemand von ihnen zum Freund oder Helfer! (Sure 4,89 - mehr dazu unter [3]). Die Polizei fand einen Zettel mit einer gegen Ayaan Hirsi Ali gerichteten Morddrohung auf dem Leichnam des von einem Muslim ermordeten holländischen Regisseurs Theo van Gogh (mit dem zusammen sie einen islamkritischen Film gedreht hatte). Seine Tat selbst hatte der Mörder aus der Sure 5,33 abgeleitet: Siehe, der Lohn derer, welche Allah und seinen Gesandten befehden und Verderben auf der Erde betreiben, ist nur der, dass sie getötet oder gekreuzigt oder an den Händen und Füßen wechselseitig verstümmelt oder aus dem Lande vertrieben werden. Das ist ihr Lohn hienieden, und im Jenseits wird ihnen schmerzliche Strafe.[4]

Die Todesdrohung gegen Menschen, die sich vom Islam lossagen, wird nämlich nicht nur gegen prominente Islamkritiker wie Ayaan Hirsi Ali ausgesprochen; auch ist sie keineswegs ein altertümliches Relikt, das nur noch in einigen fernen barbarischen Gesellschaften praktiziert wird. Wir können uns mit keinen Ausreden vor der harten Tatsache schützen, dass die Todesdrohung gegen "Apostaten" inmitten unserer westlichen Gesellschaften lebendig und wirksam ist, wie es zum Beispiel André Glasmacher über in Berlin lebende, zum Christentum konvertierte Iraner und Türken berichtet: Diese Christen müssen entgegen der staatlich zugesicherten Religionsfreiheit ihren Glauben im Verborgenen leben (ähnlich den Urchristen Roms, die sich in den Katakomben trafen) um sich vor ihren ehemaligen muslimischen Glaubensgenossen zu schützen.[5]

Ayaan Hirsi Alis beeindruckendes Buch Ich bin eine Nomadin [2] gibt Zeugnis vom Leben und vom Freiheitsdurst einer Persönlichkeit, die sich aus eigener Kraft die Werte der Aufklärung erarbeitet hat. Eindringlich appelliert sie an die Menschen im Westen, nicht leichtfertig diese Werte preiszugeben, die für unter der Scharia lebende Menschen meist unerreichbar sind – wie die Religionsfreiheit (inclusive der Freiheit, sich von der Religion abzuwenden, in die man hineingeboren ist), die freie Meinungsäusserung, den Grundsatz der Gleichbehandlung vor dem Gesetz, das aktive und passive Wahlrecht. Dies alles sind in Wahrheit kostbare Dinge, auch wenn wir das durch Gewöhnung oft nicht mehr wahrnehmen. Ihr Buch ist aber auch als Denkanstoss an die im Westen lebenden Muslime gerichtet, deren Probleme sie aus erster Hand kennt. Das Hauptproblem ist demnach die Inschallah-Mentalität ("so Allah will"): die mangelnde Eigenverantwortung. Statt das Leben mit all den Chancen, die es bietet, aktiv zu ergreifen und die eigene Freiheit zu leben, herrscht eine Versorgungs- und Opfermentalität; es wird ein bequemes generelles Beleidigtsein gepflegt, und die fremden Freiheiten werden dazu genutzt, um Sonderrechte für die Muslime einzufordern. Einwanderern aus islamischen Ländern machen laut Ayaan Hirsi Ali vor allem drei Problemfelder zu schaffen: Geld, Sexualität und Gewalt. In allen drei Bereichen werden auf eine anachronistische und mittlerweile oft selbstzerstörerische Weise Normen der Herkunftsländer gelebt - häufig verbunden mit einer Verachtung der Gastländer: Es war und ist in der islamischen Welt üblich, auf die "Dhimmis", d.h. Christen, Juden und Zoroastrier als Bürger zweiter Klasse herabzuschauen, zu deren Pflichten es gehört, z.B. durch hohe Steuerabgaben, den Muslimen einen höheren Lebensstandard zu ermöglichen.[5a] Ayaan Hirsi Ali fordert die Muslime auf, sich von dieser simplen, aber eingefleischten Mentalität zu trennen, den Westen nicht mehr als Dar al-Harb (Haus des Krieges) zu betrachten und als Wohnung der Kuffar (Ungläubigen) geringzuschätzen, sondern die Freiheitsrechte als einen elementaren Grundbestandteil einer modernen Gesellschaft und als Aufforderung an jeden hier lebenden Menschen zu betrachten – es gilt das ungeheure Potential zu entdecken, das eine freie Gesellschaft für die Entwicklung jedes einzelnen bereithält.

Besonders beeindruckend fand ich die Leserbriefe, die Ayaan Hirsi Ali von hier lebenden Muslimen und Musliminnen erhält, wie zum Beispiel den folgenden [6, Hervorhebung von mir]:

Eine Frau aus dem Sudan, die in Virginia lebt, schickte mir eine E-Mail: "Ich dachte, als muslimische Frau ist es meine Pflicht, Ihr Buch zu hassen, doch dann habe ich es gelesen und mich mit Ihnen identifiziert. Jedes Gefühl, das Sie in diesem Buch in Worte zu fassen suchten, habe auch ich schon erlebt. Jeden geistigen Konflikt, den Sie mit sich austrugen, habe auch ich schon gespürt... Ich merke, dass ich den Islam verstehen will und es einfach nicht kann. Was hat der Islam an sich, dass er für meine Eltern so verlockend und pefekt ist, für mich aber so falsch erscheint? ... Ich verurteile den Islam nicht, weil ich glaube, dass er eine gewisse Wahrheit in sich birgt – und wenn ich ihn verurteilen würde, wohin sollte ich dann gehen?"

Das wirft ein Licht auf einen geistigen Gärungs- und Umdenkprozess, der sicher schon bei vielen hier lebenden Muslimen im Gange ist. Die hervorgehobene Stelle zeigt nebenbei die Situation der Erpressung durch die Verhältnisse, in denen die Muslimin lebt: So strafbewehrt wie der Glaubensabfall in ihrem sozialen System ist, würde es einen ungeheuren Ruck erfordern, sich vom Islam loszusagen – denn dieser Schritt bedeutet, alle bestehenden Sicherheiten des Lebens zu verlieren: von der eigenen Familie, insbesondere den Kindern entfremdet zu werden und darüberhinaus für seine Existenz selbst sorgen zu müssen. Da ist es verständlich, wie wenige sich zu dem aufraffen, was sie mit der Vernunft bereits als den besseren Weg erkennen.-

Auf viele Menschen wirkte der Anschlag vom 11. September 2001 so wie auf Ayaan Hirsi Ali: als ein Augenöffner über die wahre, unverhüllte Natur des Islam, über seinen totalitäten politischen Kern. Leider muss ich auch über eine andere Form der Reaktion reden: Die Leichen des Anschlags waren noch nicht kalt, da versuchte man schon, den Islam als Souffleur dieser Morde aus der Schusslinie zu nehmen, zu verschweigen, zu verharmlosen, ja die Akteure selbst als Opfer darzustellen. Da hiess es etwa: Die USA seien aufgrund ihrere Aussenpolitik, zum Beispiel ihrer Israel- und Afghanistanpolitik, selbst schuld an dieser Tat. Man müsse Verständnis mit den Tätern haben, die in einer Notlage radikalen Elementen auf den Leim gegangen seien. Oder, besonders in Europa beliebt: Diese Morde seien einer fehlgegangenen, nicht fürsorglich genug durchgeführten Integrationspolitik zuzuschreiben. All dies sind aber, nüchtern betrachtet, nichts als Verdrehungen der tatsächlichen Verhältnisse – nach dem Motto: Nicht der Mörder, sondern der Ermordete ist schuld!

Die Entschuldigung der Täter, das Verschweigen der von diesen selbst angeführten Motive, die Beschwichtigungsformeln, die Ablenkung von den tatsächlichen Verhältnissen, sind psychologisch verständlich. Sie erklären sich durch einen Mechanismus, den die Psychologen als Identifikation mit dem Aggressor oder als Stockholm-Syndrom bezeichnen. Die Polizei kennt dieses Verhalten sehr gut von Geiselnahmen. Amerikaner erinnern sich an den Fall von Patty Hearst, einem jungen Mädchen aus reichem Hause, die 1974 von einer wirren Terrorgruppe entführt wurde. Im Laufe ihrer Geiselhaft wurde sie selbst zu einer überzeugten Anhängerin dieser Gruppe und führte später Raubüberfälle für sie durch. Durch das blosse Erlebnis der Gewalt wurde sie gewissermassen umgepolt, nahm den Standpunkt ihrer Entführer an. Die Identifikation mit dem Aggressor ist aber nicht auf Geiselnahme beschränkt, sondern wird bei allen Formen von angedrohter oder tatsächlich ausgeübter Gewalt wirksam, und vor allem geht sie über ein bloss erpresstes Verhalten weit hinaus. Das gewünschte Verhalten wird nicht bloss widerwillig ausgeführt, sondern begeistert, von ganzem Herzen und voller Faszination. Dank des Mechanismus der Identifikation mit dem Aggressor wird gewissermassen die ganze Individualität erobert.

Dies ist nur ein Sonderfall der leider allgemeingültigen Regel: Gewalt ist sexy. Immer wieder fühlen sich Frauen zu verurteilten Schwerverbrechern hingezogen, schreiben Liebesbriefe an Mörder, Vergewaltiger oder Bankräuber. In deutschen Gefängnissen gehört dieses Psycho-Phänomen zum Alltag. [6a] Dies gilt in besonderem Masse und gerade für Jugendliche, wenn die Gewalt mit einer Opposition zu den tragenden Werten der Gesellschaft verknüpft ist. Das bedeutet: Gerade die Blutspur des Islam, die mit seiner Praxis verknüpfte Gewalt, nicht nur in Form von einzelnen Terroranschlägen, sondern auch als institutionalisierter Terror in Ländern wie Saudi-Arabien, Afghanistan, Iran, der einem freiheitsliebenden Menschen im Westen das Blut in den Adern gefrieren lässt, wirkt nicht allein durch die implizit vorhandene Drohung, indem vorauseilend Freiheitsrechte beschnitten werden, sobald als Folge ihrer Ausübung muslimischer Terror zu erwarten ist; darüber noch hinausgehend ist es gerade die Gewalt, die den Islam für viele Menschen im Westen attraktiv macht. Vielen jungen Menschen, die heute im Westen zum Islam konvertieren, wird allerdings ein böses Erwachen blühen. Denn der Weg zurück ist versperrt: auf die Konversion zur nächsten Modereligion in einigen Jahren steht die Todesstrafe! Den Konvertiten zum Islam steht eine ähnlich harte Landung bevor wie den westlichen Frauen, die sich in eine Beziehung mit einem Muslim begeben haben und deren erschütternde Geschichten auf der Website des Bezness Forums gesammelt wurden.

Der amerikanische Islamkritiker Robert Spencer macht sich die Mühe, die im Auftrag des Islam seit dem 11. September begangenen Terroranschläge laufend zu dokumentieren. Er kommt (Stand Februar 2011) auf die gewaltige Zahl von 16.800 tödlichen Anschlägen seit dem 11. September 2001. Das heisst, der Islam forderte in einem Zeitraum von knapp zehn Jahren weit über zehnmal mehr Tote als die spanische Inquisition in ihrer gesamten unseligen 260jährigen Geschichte.[7] Wer diese Zahl bezweifelt, möge die Aufstellungen von Robert Spencer untersuchen, sie unterschätzen meines Erachtens eher die tatsächliche Zahl der Opfer des islamischen Terrors. Angesichts solcher Zahlen kann man nicht mehr, wie es häufig getan wird, von verwirrten Einzeltätern sprechen, von einer Handvoll Geisteskranker, sondern muss sich der Tatsache stellen, dass es sich bei diesen Morden um ein strukturelles, dem Islam inhärentes Phänomen handelt. Auch kann man nicht sagen, dass die Täter den Koran nur falsch interpretieren, denn die im Koran enthaltenen Aufrufe zur Ermordung von Nichtgläubigen und Andersgläubigen lassen praktisch keinen Spielraum für unterschiedliche Deutungen.[8]

Ein üblicher Verschleierungsversuch ist es, die im Namen des Islam begangenen hässlichen Praktiken nicht dem Islam selbst, sondern den sogenannten Islamisten zuzuschreiben. Der Islamist sei der Schlimme, der die an sich friedliche Religion des Islam in ihr Gegenteil verkehre und zu einem Mordinstrument mache. Der Islam habe mit diesen schrecklichen Dingen überhaupt nichts zu tun, sei er doch in Wahrheit die "Religion des Friedens" (wofür die Ähnlichkeit der Wörter salam, Frieden, und islam, das Sich-Unterwerfen, herangezogen wird). Wenn das stimmt, ginge es nur darum, die kleine Gruppe der "Islamisten", die den Islam pervertieren, ausfindig und unschädlich zu machen – eine Aufgabe, die man bequem an Geheimdienste und Sicherheitsorgane delegieren kann, ohne dass ein eigener persönlicher Einsatz nötig wäre. Eine schöne Lösung.

Das Problem dabei ist nur: Die Trennung von Islam und Islamismus oder "islamischem Fundamentalismus" ist eine künstliche. Selbst Muslime wie der türkische Ministerpräsident Recep Tyyip Erdogan (der im Westen ironischerweise selbst als "moderater Muslim" geführt wird) verwahren sich dagegen [9]:

Diese Bezeichnungen [moderater Islam / Islamismus, RP] sind sehr hässlich, es ist anstössig und eine Beleidigung unserer Religion. Es gibt keinen moderaten oder nicht-moderaten Islam. Islam ist Islam, und damit hat es sich... Unsere Religion ist ohne Fehler.

In der Tat kann der Fundamentalismus an sich niemals das Problem sein, sondern nur dasjenige, auf das der Fundamentalismus angewendet wird. Ein Fundamentalist ist bloss jemand, der seinen Glauben besonders ernst nimmt, ihn besonders genau und streng anwendet und kein anderes Kriterium als seinen Glauben gelten lassen möchte. Der Fundamentalist ist demnach nicht an sich gefährlich: Es kommt darauf an, an was er glaubt! Ein fundamentalistischer Buddhist mag sich in die Berge zurückziehen und radikal nach Erleuchtung streben. Eine Gefahr für die Gesellschaft geht von ihm sicher nicht aus. Ein fundamentalistischer Muslim dagegen strebt danach, das "Haus des Islam" zu vergrössern und im religiösen Kampf (Dschihad) möglichst viele Ungläubige zu töten. Das Problem liegt folglich nicht im Fundamentalismus an sich, sondern in dessen Bezugsobjekt - hier also: im Islam selbst. Es wird durch die Menschen offenbar, die den Islam ernstnehmen, weil diese die Inhalte ihrer Religion am deutlichsten zum Ausdruck bringen.

An dieser Stelle folgt meist der Hinweis auf die 1.6 Milliarden Muslime, die allein aufgrund ihrer hohen Zahl doch nicht alle Terroristen sein können! Das ist ohne Zweifel wahr: Es gibt Muslime, die darauf verzichten, den bewaffneten Kampf gegen die Ungläubigen auszuüben. Es gibt Muslime, die für sich privat nur Teile des Korans und der Überlieferung gelten lassen. Es gibt auch Muslime, die den Koran schlechter kennen als ein durchschnittlicher Islamkritiker – so wie es Christen gibt, die nicht wissen, was eigentlich zu Ostern gefeiert wird. Es gibt Muslime, die nur qua Geburt Muslime sind und sich eigentlich überhaupt nicht um ihren Glauben scheren. Es gibt Muslime, die nur ein paar ihrer religiösen Pflichten einhalten, ihren Glauben äusserst lax praktizieren. Gott sei Dank ist das so.

Aber, umgekehrt gefragt: Warum sind alle Selbstmordattentäter, mit denen wir heute konfrontiert sind, muslimischen Glaubens? Wenn uns die vielen, aus Hass, Rache und Clandenken verübten Gewalttaten von Muslimen immer als Taten von verirrten Einzeltätern präsentiert werden, die den Koran nur falsch verstanden haben: Wo sind dann die Selbstmordattentate, Ehrenmorde, Genitalverstümmlungen, Zwangsverheiratungen von Buddhisten, von Christen, von Baha'i, von Atheisten, die ihren Glauben nur falsch verstanden haben? Warum gibt es sie fast ausschliesslich unter Muslimen, die "wirren Einzeltäter", die "Den-Glauben-bloss-falsch-Versteher"? Diese Frage bleibt beim Erklärungsmuster des "wirren Einzeltäters" rätselhaft, ja unlogisch.

Manfred Kleine-Hartlage hat diesen Umkehrschluss einmal durchdekliniert (Hervorhebungen von mir). Zwar ist die grosse Mehrheit der Muslime friedlich, das ist unbestritten – aber [10]:

Wenn eine junge Frau auf offener Strasse von ihrem eigenen Bruder erschossen wird, darf man getrost hohe Summen darauf verwetten, dass beide aus einer muslimischen Familie stammen. Wenn einer Geisel vor laufender Kamera die Kehle durchgeschnitten wird, wird der Täter Muslim sein. Wer von "deutschen (englischen, schwedischen) Schlampen" redet, ist Muslim. Wer "mehr Respekt" für sich und seine Gemeinschaft einfordert, ist Muslim. Wer sich und andere mit einem Dynamitgürtel in die Luft sprengt, einen solchen Mörder zum "Märtyrer" erklärt, das Wort "Ungläubige" benutzt, seine Tochter nicht schwimmen lernen lässt, sie stattdessen lehrt, Gott befehle die Tötung von Juden, ist Muslim. Länder, in denen vergewaltigte Frauen wegen "Ehebruchs" ins Gefängnis geworfen werden, sind islamisch. Länder, in denen die Bibel nicht verkauft werden darf, wohl aber die "Protokolle der Weisen vom Zion", sind islamisch. Länder, in denen Homosexuelle an Baukränen aufgehängt werden, sind islamisch. Länder, in denen gesteinigt wird, sind islamisch.

"Wirre Einzeltäter" müssten nach den Gesetzen der Wahrscheinlichkeit unter allen möglichen Glaubensgemeinschaften auftreten. De facto aber konzentrieren sich die aufgeführten Praktiken auf Muslime. Die m.E. einzig logische Erklärung ist: Diese Praktiken leiten sich aus den Lehren des Islam ab, und nicht etwa aus denen der Baha'i, Christen, Buddhisten etc. Es ist also etwas Besonderes um den Islam, das ihn von anderen Bekenntnissen unterscheidet. Diesen Unterschied gilt es wahrzunehmen und herauszuarbeiten, statt ihn zu verschleiern oder wegzudiskutieren.

Im Westen besteht allerdings ein politisches, praktisches Interesse daran, den Unterschied des Islam von anderen Religionen wegzudiskutieren und alle konkreten Glaubensbekenntnisse einander gleichzumachen. Man tut niemandem weh, wenn man die Religionen alle als gleich behandelt und diese Unterschiede ignoriert, und man muss sich nicht Konsequenzen stellen, die gerade aus den Unterschieden der Religionen resultieren könnten.

Eines sollte aber klar sein: Durch Wegschauen dient man einem faulen Frieden und arbeitet selbst an der Zementierung der Ungerechtigkeiten mit, macht sich mitschuldig. Vielmehr ist es nötig, die problematischen Sachverhalte klar auszusprechen: Genau so kann man das Denken öffnen: Durch ehrlichen, offenen Dialog. Vielleicht fliessen Tränen dabei, aber kein Blut (Ayaan Hirsi Ali, [11]). Das Verschweigen unangenehmer Tatsachen kann sich nicht auf die Toleranz berufen, sondern ist genau besehen nichts als Feigheit: Furcht vor den praktischen Konsequenzen, die aus diesen unangenehmen Tatsachen abzuleiten wären. Das Ideal der Toleranz würde es in Wahrheit erfordern, gerade besonders genau hinzusehen. Toleranz hat keine Augenbinde auf, sondern nimmt die Verschiedenheiten wahr.

Auch kann Toleranz niemals gegenüber der Intoleranz geübt werden, auf Strafe ihres Untergangs. Toleranz kann nur dann wirken, wenn das nackte Recht des Stärkeren ausgehebelt ist, wenn die Ausübung bürgerlicher Grundrechte wie der freien Meinungsäusserung nicht durch Gewalt oder die blosse Drohung von Gewalt verhindert werden kann. Dies ist nicht erst seit Sir Karl R. Poppers "Die offene Gesellschaft und ihre Feinde" Gemeingut, sondern seit dem 18. Jahrhundert, seit dem Bestehen moderner, aufgeklärter, demokratischer Gesellschaften.[12] Sie könnten gar nicht bis heute bestanden haben, ohne sich gegen ihre äusseren und inneren Feinde zu wehren.

In Gesprächen höre ich oft: Judentum und Christentum seien doch grundsätzlich dem Islam ähnlich. Das glauben Westeuropäer, die alle Kulturen als grundsätzlich gleichwertig betrachten wollen und dafür bereit sind, schmerzhafte Unterschiede zu ignorieren oder mit leicht durchschaubaren Argumenten zu verleugnen. Den Frieden der Religionen, den sie sich so sehnlich wünschen, versuchen sie also dadurch herzustellen, dass sie vor den Tatsachen, die diesen Frieden bedrohen oder verhindern, die Augen verschliessen. Das Problem mit den Leuten aus dem Westen ist nicht, dass sie den Islam nicht verstehen. Ihr Problem ist, dass sie den Islam nicht verstehen wollen, klagte schon Wafa Sultan.[13]

Muslime selbst kennen dagegen den wesentlichen Unterschied ihrer Religion zum Christentum und Judentum sehr genau. Schon im 14. Jahrhundert präzisierte der islamische Gelehrte Ibn Khaldun (1332 – 1406) in seiner "Muqaddima" [14],

das Judentum sei zwar fähig, sich politisch im Diesseits zu behaupten, doch es habe keinen universalen Anspruch, umgekehrt habe das Christentum zwar einen universalen Anspruch, doch es verfolge ihn nicht mit politischen und militärischen Mitteln. Der Islam sei beiden Religionen überlegen, weil er beides vereine: "Im Islam ist der Djihad (der Heilige Krieg) gesetzlich vorgeschrieben, weil er einen universalen Auftrag hat und gehalten ist, die gesamte Menschheit freiwillig oder gezwungen zur Religion des Islams zu bekehren".

Ibn Khaldun weist hiermit auf einen ganz wesentlichen Unterschied des Islam zum Christentum und zum Judentum hin: Der Islam verlangt, die ganze Welt unter sein Gesetz zu stellen, freiwillig oder gezwungen – und das bedeutet natürlich: nur gezwungen, denn eine Entscheidung kann nicht frei sein, wenn sie von der Drohung des Zwangs begleitet ist. Die Endperspektive ist die totale islamische Herrschaft: Und kämpft gegen sie, damit keine Verführung mehr stattfinden kann, und kämpft, bis sämtliche Verehrung auf Allah allein gerichtet ist. Stehen sie jedoch vom Unglauben ab, dann, wahrlich, sieht Allah sehr wohl, was sie tun. (Sure 8,39). Dies ist offensichtlich kein theologischer Lehrsatz, sondern eine konkrete, ganz weltlich zu nehmende Handlungsaufforderung. Hierzu wird die Welt von Muslimen in zwei Reiche aufgeteilt: Das Dar al-Islam, das Haus des Islam, in dem dieser bereits Staatsreligion und die Scharia gültiges Recht ist, und das Dar al-Harb, das Haus des Krieges, d.h. die noch nicht vom Islam beherrschten Teile der Welt. Zu den Verhaltensregeln für Muslime gehört es eigentlich, sich nicht im Haus des Krieges niederzulassen. Wenn sie sich doch ins Haus des Krieges begeben, so ist ihre Aufgabe, dort den Djihad (wörtlich: Anstrengung - dazu gehören nicht nur kriegerische Akte, sondern alle Arten des Einsatzes für den Islam) zu führen, also der Sache des Islam zum Siege zu verhelfen. Durch diese Normen erweist sich der Islam als eine totalitäre, nach dem globalen Kalifat, also der Weltherrschaft strebende Ideologie.

Ibn Khaldun anerkennt dagegen, durchaus im Einklang mit dem Koran, dass die Juden sehr wohl auch diesseitig denken und handeln und ihre Religion auch militärisch zu verteidigen wissen. Der universale Anspruch, wie ihn der Islam hegt, die eigene Religion zur Religion der ganzen Welt zu machen, ist dem Judentum dagegen fremd. Man könnte hinzufügen, dass es in der Geschichte auch Kriege gab, die den Juden gemäss der Bibel von Gott befohlen wurden, etwa den Eroberungszug gegen die Kanaaniten (Dtn 20,16-18 und Jos 10,40). Dies waren aber zeitlich und räumlich begrenzte Kriege. Der universale Anspruch fehlt – und das ist ein wichtiger Unterschied, wie schon Ibn Khaldun erkannte und woraus er die Überlegenheit des Islam ableitete.

Das Christentum dagegen hat sehr wohl den universalen Anspruch: Darum gehet hin und lehret alle Völker und taufet sie im Namen des Vaters und des Sohnes und des Heiligen Geistes! Und lehret sie halten alles, was ich euch befohlen habe! Und siehe, ich bin bei euch alle Tage bis an der Welt Ende. (Mt 28,19-20). Es ist aber ein Anspruch der Mission, der Verkündigung. Ibn Khaldun weiss richtig, dass das Christentum nicht gebietet, diesen Anspruch mit politischen und militärischen Mitteln zu verfolgen. Das Christentum trennt nämlich die weltlichen und geistlichen Dinge: So gebet dem Kaiser, was des Kaisers ist, und Gott, was Gottes ist (Mt 22,21), und gerade der Kerngehalt der christlichen Lehre hat keine konkreten weltlichen Implikationen, sondern betrifft den Menschen als spirituelles Wesen und eine transzendente, wenn auch in diese Welt hineinleuchtende Ordnung (das "Reich Gottes" oder Himmelreich). Als Religion hätte das Christentum allerdings nicht überlebt, wenn sich die Gemeinschaft der an Christus Glaubenden, also die Kirche, nicht auch weltlich formiert hätte, zu einer Institution dieser Welt geworden wäre. Diese Institution befindet sich in einem permanenten Spannungsverhältnis zu der Botschaft, zu deren Schutz, Erhaltung und Verbreitung sie angetreten ist. Das kann gar nicht anders sein, denn eine Institution, die dem Bösen keinen Widerstand (Mt 5,39) leistete, bedingungslos ihre Feinde liebte (Mt 5,44) und nicht richtete, auf dass sie nicht gerichtet werde (Mt 7,1), könnte in dieser Welt nicht lange bestehen.

Der fundamentale Unterschied des Christentums zum Islam wird in einem "Exkurs" von Manfred Kleine-Hartlage sehr schön herausgearbeitet.[15] Schon das Welt- und Menschenbild unterscheidet sich grundlegend. Der Islam bejaht die Welt in der Form, wie sie vorgefunden wird. Für ihn ist der gläubige Mensch so, wie er ist, ein Instrument Allahs. Es gibt keine grundlegende Kritik an dieser Welt. Diese Welt ist Gottes Schöpfung, die gesamte vorgefundene Welt- und Geselllschaftsordnung ist Teil von Gottes Wille. Das macht den Islam extrem konservativ: Zur Zeit Mohammeds gab es Sklaverei, Polygamie, Beschneidung von Frauen, beduinische Raubzüge, Clan- und Gewaltherrschaft an Stelle garantierter Rechte für alle. Allah/Mohammed bejaht und legitimiert all diese Praktiken, er hat an keiner etwas auszusetzen, solange sie im Rahmen der Umma, der muslimischen Gemeinschaft ausgeübt wird. Der Islam ist dieser Welt gegenüber affirmativ eingestellt. Zwar kennt auch der Islam die jenseitige Welt, den Himmel. Aber bereits das Diesseits ist von Gott in seiner Grundstruktur genau so gewollt, wie es ist. Der Muslim kann sich in dieser Welt als verlängerter Arm Gottes fühlen. Mit dem Koran hat er eine göttliche Wegleitung in der Hand, die einfach formuliert und nicht interpretationsbedürftig ist. Indem sich der Muslim Allah unterwirft (was der Wortsinn von "Islam" ist), wird er zum Teil der Gemeinschaft der Gläubigen in dieser Welt, der besten Gemeinde, die je für die Menschen entstand. Ihr gebietet das, was Rechtens ist, und ihr verbietet das Unrecht. (Sure 3,110). Er darf sich also durch seine Teilhabe an der Umma dem Rest der Menschheit überlegen fühlen und geniesst gegenüber den beiden anderen Klassen von Menschen, den Dhimmis und den Ungläubigen, dank der Scharia Sonderrechte (eingeschlossen das Recht, Gewalt gegenüber diesen auszuüben).

Das Christentum ist grundsätzlich anders: Der Christ leidet an der Welt und in ihr. Für das Christentum ist die Welt, wie sie ist, aus der Ordnung Gottes herausgefallen. Sie ist nicht mehr in ihrem ursprünglichen, heiligen, ganzen Zustand – sondern krank. Zwar deutet alles in ihr noch auf den reinen, unverfälschten Ursprung. Aber dieser Ursprung ging durch eine Art historischer, universal-menschheitlicher Katastrophe verloren: den "Sündenfall". Der Mensch kennt nur noch die Sehnsucht nach dem "verlorenen Paradies", und die Dinge dieser Welt erinnern ihn daran. Aber in ihrer konkreten Gestalt enthalten sie so viel Ungöttliches, ja Widergöttliches, dass sich eine affirmative Haltung zur Welt für den Christen verbietet. Das Reich Gottes ist nicht von dieser Welt (Jo 18:36), und alle Weisheit dieser Welt ist Torheit vor Gott (1. Kor. 1,20). Der Mensch hat durch die Nachfolge Christi eine metaphysische Perspektive auf die Wiederherstellung einer ursprünglichen göttlichen Ordnung, denn Christus ist das Licht (Jo 8,12), das in diese Welt hineinleuchtet, um sie in der von Gott gewollten Ordnung auferstehen zu lassen – und Christus ist als neuer Adam der erste, der diesen Weg gegangen ist (Röm 5,12-15). Der Christ kann daher in seinem Handeln nie ganz in dieser Welt aufgehen – es bleibt immer ein Rest, ein Vorbehalt. In der Konsequenz bejaht das Christentum seinem ganzen Wesen nach das Säkularitätsprinzip, die Trennung der weltlichen von der göttlichen Ordnung. Für den Christen gilt der bereits zitierte, wichtige Grundsatz: Gebt dem Kaiser, was des Kaisers ist und Gott, was Gottes ist (Mk 12,13). Weder das Aufbegehren gegen die gesellschaftliche Ordnung um einer besseren Ordnung willen [15a], noch die vollständige Eingliederung in ein gesellschaftliches System, können Sache des Christen sein. Er lebt in der Welt, ist aber als Geistwesen zugleich dieser Welt enthoben. Partei nehmen für eine weltliche Sache – das ist etwas, worin er nie ganz aufgehen kann. Jesus, der Sohn Gottes und zugleich irdischer Mensch, vereinte in sich die beiden Ordnungen. Aber sein ganzes Leben zeigt, welche Präferenzen er setzte: Er lebte in den niederen, wenig geachteten Gesellschaftsschichten und starb - aus Liebe zu den Menschen - den schmählichen Tod am Kreuz, den Tod eines Verbrechers – und dies, obwohl er niemals zur Gewalt aufgerufen hatte. Da dies muslimischem Welt- und Religionsverständnis fundamental entgegenläuft, verleugnet Mohammed/Allah in Sure 4,157 den Kreuzestod Jesu und hängt stattdessen der gnostischen Lehre an, "ein anderer" sei an Jesu Stelle gekreuzigt worden.

Nun ist aber gerade der Kreuzestod Jesu eines der zentralen Elemente des christlichen Glaubens, ohne den auch die Perspektive der Heilung, des wiederhergestellten Lebens in der Auferstehung undenkbar wäre. Der Bischof Melito von Sardes – er lebte im 2. Jahrhundert, als auch die heidnischen Mysterien noch verbreitet waren – beschreibt dieses "neue Mysterium" [16]:

Die Natur erschauderte und sprach erstaunt:
Was ist dies für ein neues Mysterium?

Der Richter wird gerichtet und verhält sich ruhig,
Der Unsichtbare wird geschaut und scheut sich nicht,
Der Unfassbare wird erfasst und entrüstet sich nicht,
Der Unmessbare wird gemessen und widerstrebt nicht,
Der Leidlose leidet und rächt sich nicht,
Der Unsterbliche stirbt und weigert es nicht.

Was ist dies für ein neues Mysterium?

Wenn Gott sich nach Ansicht der Christen in Gestalt eines in dieser Welt absolut ohnmächtigen Menschen offenbart hat, so kann der Glaube nicht mit Gewalt verbreitet werden, sondern nur auf freier Entscheidung jedes einzelnen basieren. Der Mensch wird durch die Glaubensentscheidung zum Kind Gottes, statt nur ein ausführender Sklave des Gotteswillens zu sein: Denn alle, die sich vom Geist Gottes leiten lassen, sind Söhne Gottes. Denn ihr habt nicht einen Geist empfangen, der euch zu Sklaven macht, so dass ihr euch immer fürchten müsstet, sondern ihr habt den Geist empfangen, der euch zu Söhnen macht, den Geist, in dem wir rufen: Abba, Vater! So bezeugt der Geist selber unserem Geist, dass wir Kinder Gottes sind (Röm 8,14-15). Das ist der Grund, warum gerade die Freiheit ein wichtiges Fundament des christlichen Glaubens ist.

Die Kirche als durchaus weltliche Institution steht, wie erwähnt, in einem Spannungsverhältnis zu der radikal unpolitischen Botschaft Jesu, zu deren Schutz und Überlieferung sie ja eigentlich existiert. Als weltliche Gemeinschaft wird die Kirche angreifbar, fehlerhaft, irdisch und kann natürlich auch von Christen im Namen der christlichen Botschaft angegriffen werden. Wie viel weltliche Macht gerade noch ausgeübt werden darf und kann, um die christliche Botschaft und Gemeinschaft vor dem Untergang zu bewahren, der aus einer konsequenten Realisierung der zentralen christlichen Lehren resultieren würde, war Gegenstand eines lang andauernden Kampfes zwischen kirchlicher und weltlicher Macht. So ist die Geschichte der Kirche auch eine Geschichte von Glaubensspaltungen und Schismen, die in der Reformation als einem vorläufigen Höhepunkt gipfelten.

Es ist eine verbreitete, aber falsche Auffassung, dass die Aufklärung eine reine Gegenbewegung zum Christentum war. Auf einer oberflächlichen Ebene ist das richtig, denn einige Aufklärer stellten sich energisch gegen Kirche und Christentum, und unbestritten gab es auch von kirchlicher Seite heftigen Widerstand gegen die Aufklärung. Das ist aber nicht entscheidend. In ihrem Kern sind die Grundwerte der Aufklärung nämlich nichts anderes als transformierte, säkularisierte christliche Werte. Die Aufklärung hat auf keinem anderen Boden entstehen können als dem des christlichen Abendlandes. Werte, mit denen ein moderner Atheist oder Agnostiker lebt, leiten sich teilweise direkt aus christlichen Normen ab. Zu solchen, direkt aus dem Christentum hervorgehenden Normen zählen: das soziale Element der Hinwendung zu den Schwachen, das Verbot zu richten, das Liebesgebot inclusive der Feindesliebe, sowie rückbezügliche Normen in Form einer für alle Menschen, nicht nur für die Angehörigen des eigenen Glaubens, gültigen Goldenen Regel: Alles nun, was ihr wollet, das euch die Leute tun sollen, das tut ihr ihnen (Mt 7,12).[17]

Ob wir wollen oder nicht, ob wir uns als Christen verstehen oder nicht: Die rückbezüglichen Normen des Christentums sind uns in Fleisch und Blut übergegangen, wir können gar nicht mehr (oder nur mit grösster Mühe) aus ihnen heraustreten. Beispielsweise sind aktuelle Ideologien wie der Kulturrelativismus nichts anderes als die verinnerlichte christliche Norm: Richtet nicht, auf dass ihr nicht gerichtet werdet (Mt 7,1). Die Kritik an jemand anderem oder an einer Gruppe, der wir nicht angehören, verursacht dem Abendländer einen inneren Schmerz. Er ist darauf abgerichtet, Kritik sofort mit Selbstkritik zu relativieren und das, was er dem anderen aufgeben will, zuerst einmal und besonders streng sich selbst aufzugeben.

Das ist eine wunderbare Norm – die jedoch nur solange funktionieren kann, wie auch das Gegenüber sie verinnerlicht hat. Jemand, der diese Norm nicht kennt, erlebt die radikal auf sich selbst zurückgeworfene Kritik als Selbsterniedrigung, als Zugeständnis der eigenen Minderwertigkeit. Im Falle des Islam wirkt also unser ständiges reflektierendes Zaudern, unser skrupulöses Haften an der Rechtsstaatlichkeit, die permanente Selbstkritik, die laute Anprangerung selbst geringfügiger Vergehen gegen garantierte Grundrechte, das Zulassen radikaler Kritik um der Meinungsfreiheit willen, das schonungslose Aussprechen von eigenen Misständen, nur in einem Sinne: Als Selbsteingeständnis der Minderwertigkeit unserer Kultur. Da dies vollständig mit dem Bild konform ist, das der Islam sowieso von der christlich-jüdischen Kultur zeichnet, so dass Muslime sich ermuntert sehen, für ihre eigene Kultur offensiver einzutreten, erweisen sich genau die Normen mit relativierendem Rückbezug, deren Umsetzung in Form von freiheitlichen Gesellschaftsordnungen die bislang grösste Errungenschaft der Menschheit darstellt, als die eigentliche Achillesferse unserer gesamten abendländischen Zivilisation.

[1] Wafa Sultan: In ihrer glasklaren, auf Al-Jazira ausgestrahlten Stellungnahme die mittlerweile zu einem Klassiker avanciert ist, begründet sie, dass der Konflikt nicht, wie Samuel P. Huntington meint, ein "Kampf der Zivilisationen" sei: denn Zivilisation kämpfen nicht, sie wetteifern. Vielmehr seien wir Zeugen eines Kampfes der Barbarei gegen die Zivilisation.
[2] Ayaan Hirsi Ali, Ich bin eine Nomadin, Piper Verlag, München 2010, S. 13. Zur Ableitung von Gewalt und Mord gegen Ungläubige siehe auch Fussnoten [4] und [8].
[3] Die Apostasie ist laut Koran das Allerschlimmste, was ein Muslim tun kann, und er wird dafür für immer verflucht sein (Sure 4, 137). Siehe auch Sure 16,106 und Sure 4,36ff. sowie 9,68. Ein informatives Gutachten hierzu liefert Christine Schirrmacher auf http://www.igfm.de/Wenn-Muslime-Christen-werden-Glaubensabfall-und-Todesstrafe-im.466.0.html
[4] Auch dieses Koranzitat fand sich auf dem an das Opfer gehefteten Zettel, siehe http://widerworte.wordpress.com/2010/09/17/gewaltaufrufe-im-koran/.
[5] André Glasmacher, Angst vor dem strafenden Islam, Tagesspiegel vom 21.4.2007, http://www.tagesspiegel.de/berlin/angst-vor-dem-strafenden-islam/v_default,837238.html
[5a] Bat Ye'or, Der Niedergang des orientalischen Christentums unter dem Islam, Resch Verlag, Gräfelfing 2005.
[6] Ayaan Hirsi Ali, a.a.O., S. 277.
[6a] Die Faszination des Abscheulichen, Bild online vom 14.4.2010. Die sogenannten Serial Killer Groupies (SKG) sind Gegenstand kriminalpsychologischer Untersuchungen (siehe http://www.trutv.com/library/crime/criminal_mind/psychology/s_k_groupies/4.html).
[7] Robert Spencer, Anschläge im Namen Allahs seit dem 11. September 2001, http://therelegionofpeace.com. Zu den Todesopfern der spanischen Inquisition, siehe http://en.wikipedia.org/wiki/Spanish_Inquisition#Death_tolls
[8] Es genügt, wenn - im Rahmen einer Arbeitsteilung - auch nur ein Teil der Muslime sich für die konkrete Umsetzung der insgesamt 206 Koranstellen zuständig fühlt, die explizit zur Gewalt gegen Ungläubige aufrufen (eine Auflistung dieser Stellen enthält z.B. die Webseite http://www.koran.terror.ms/) – solange sie von der restlichen Umma nicht klar bekämpft werden, wird so ein Klima der Angst geschaffen, des Appeasement und der Erpressung, wie es sich vor unseren Augen tatsächlich entfaltet. Seine "Fatwa" von 1998 zur Rechtfertigung des Terrorismus gegen Amerika gründet Bin Laden unter anderem auf Sure 9,5: "Und wenn die heiligen Monate abgelaufen sind, dann tötet die Götzendiener, wo immer ihr sie findet, und ergreift sie und lauert ihnen aus jedem Hinterhalt auf." (http://www.mideastweb.org/osamabinladen2.htm).
[9] Erdogan, zitiert in der Zeitung Milliyet vom 21.8.2007. Siehe http://www.politik.de/forum/religion/212757-ministerpraesident.html
[10] Manfred Kleine-Hartlage, Das Dschihad-System. Wie der Islam funktioniert. S.9.
[11] Ayaan Hirsi Ali, a.a.O., S. 268.
[12] Karl R. Popper, Die offene Gesellschaft und ihre Feinde, Zwei Bände, Francke Verlag, Tübingen 1980.
[13] Wafa Sultan, Interview in der Helen Glover Show vom 12.3.09.
[14] Ibn Khaldun, Muqaddima. Zitiert aus http://koptisch.wordpress.com/2010/09/17/die-grunde-fur-die-christlichen-kreuzzuge/
[15] Manfred Kleine-Hartlage, a.a.O. Exkurs: Warum das Christentum mit der Moderne vereinbar ist, der Islam aber nicht, S.135-146.
[15a] Der Umsturz der Ordnung, in der er lebt, ist nicht Sache des Christen - wohl aber der Kampf gegen Unrecht. Beispielsweise bekämpften Christen schon in den ersten nachchristlichen Jahrhunderten die Sklaverei, weil sie ihrem Grundsatz der Gleichheit der Menschen vor Gott widerspricht (während es im Islam nie einen nennenswerten Widerstand gegen die Sklaverei gab und in vielen islamischen Ländern die Sklaverei erst durch die Kolonialherren abgeschafft wurde). Siehe hierzu Egon Flaig, Weltgeschichte der Sklaverei, Beck Verlag, München 2009, S. 199ff.
[16] Melito von Sardes, zitiert aus http://www.kathsurf.at/gebete/vorfahren/vorfahren.html#Ein neues Mysterium
[17] Im Gegensatz zum Christentum kennt der Islam keine universale, für alle Menschen gültige Goldene Regel. Im Koran kommt eine Goldene Regel überhaupt nicht vor. Im Gegenteil ist die Aufteilung der Menschen in Höherwertige (Muslime) und Minderwertige (Dhimmis, Ungläubige) ein klarer Verstoss gegen die Goldene Regel, die sich durch den ganzen Koran und natürlich die Scharia zieht, die sich als Recht der Ungleichbehandlung erweist. Auch die Hadithstelle 1,2,13 lässt sich nicht als Gegenbeweis heranziehen, denn die (saudische) Übersetzung lässt keinen Zweifel, dass diese Regel auf die eigene Glaubensgemeinschaft beschränkt ist, womit ihr gerade das wesentliche Kriterium der universellen Anwendbarkeit fehlt, das die Goldene Regel ausmacht. Die Goldene Regel würde dem Koran und der islamischen Wirklichkeit widersprechen.

Eine Mohammedstudie von Johannes Kepler

2011-02-11T22:04:00.033+01:00

In einer kleinen, 1604 erschienen Schrift Judicium Kepleri de Prognostico P. Sutorii setzt sich der Astronom und kaiserliche Hofmathematiker Johannes Kepler mit einer Untersuchung des Astrologen Paulus Sutorius über Mohammed und die Zukunft des Islam auseinander. Dieser hatte laut Kepler prognostiziert, die Christenheit werde in den Jahren von 1604 bis 1644 besonders schweren Wirrnissen ausgesetzt, die als Strafe für ihre halsstarrigen Sünden[1] anzusehen seien. Die Schrift von Sutorius gipfelte in der Vorhersage, dass für das Jahr 1700 die von allen wahrhaftigen Christen sehnlich erwartete letzte Wiederkunft unseres himmlischen Königs und Heilands Jesu Christi sich herzu nahe und diese Welt hiermit ihr Ende nehmen werde.[1] Kepler nimmt zu der Schrift von Sutorius Stellung und diskutiert ihre astrologischen, politischen und historischen Argumente sehr ausführlich.

Für Astrologen ist es eine interessante Frage, welche Horoskope damals einer Untersuchung über den Islam zugrundegelegt wurden - denn um dessen Heimsuchungen handelt es sich bei den prophezeiten schrecklichen Wirrnissen.

Da Mohammed nicht fürstlicher Abstammung war, waren seine genauen Geburtsdaten unbekannt. Es scheint auch im Islam keine Quelle zu geben, in der eine Art zweifelsfreier, offizieller Geburtszeit mitgeteilt wurde (wohl aber gab es eine, dem Koran beigegebene Zeittafel mit einem Geburtsdatum, die er Chronicum ad Alcoranum nennt). Kepler fasst zusammen:

Mercator will, er sei geboren Anno Christi 569, Chronicum ad Alcoranum 571, 21. Sept., alii 596. 23. April, Sutorius 594, 23. April.

Kepler findet das Geburtsjahr 594 unplausibel. Denn damit wäre Mohammed zum Zeitpunkt der Hedschra erst 28 Jahre gewesen – zu jung für ein Unterfangen, das mehr im verborgenen Rat bestand als in blosser Kühnheit. Kepler wusste um die Hedschra als ein sicheres Datum: Denn gewiss, dass er anno 622, da er schon lange zuvor gepredigt gehabt, hat fliehen müssen und in solcher seiner Flucht sich zum weltlichen Haupt aufgeworfen. Später dazu: Er muss ohne Zweifel schon viele Jahre vorher mit seiner Lehre, für die ein rechtes Alter nötig ist, umhergezogen sein, bis er sich so viel Gefahr und Feindschaft auf den Hals geladen hatte, dass er entweichen musste.

Er geht nun auf die Deutung des Horoskops durch Sutorius ein, wobei er die Gelegenheit nicht auslässt, das Glücksrad (pars fortunae) als einen fiktiven Punkt zu erklären, dem man wie allen arabischen Punkten keine Bedeutung beizumessen habe.

Im Mohammed-Horoskop nach Sutorius ist der Mond eleviert und steht in den Fischen in seiner Erhöhung, ist demnach stark gestellt. Er bildet ein Sextil zu einer Merkur/Venus-Konjunktion und steht in Opposition zu Mars. Hierzu schreibt Kepler, dass die Vermischung Mercurii et Veneri in sextili Lunae zu allerhand Wollust neige. Welches sich wohl auf des Mahomet Lehre reimt, der die Polygamie zulässt; und weil aus der Geschichte bekannt ist, dass Kepler durch Heirat aufgestiegen ist, ist der Erfahrungssatz zu zitieren: wenn der Mond vornehm gestellt und von vielen Planeten durch Aspekte bestrahlt wird, wie hier, so bedeutet dies vornehme, reiche Heirat.

Obwohl er also das Horoskop von Sutorius in vielen Punkten für passend befindet, lehnt er es ab, weil der Geburtstermin nach seiner Ansicht zu spät sei. Er hält sich lieber an ein Chronicon Arabicum, das dem Koran beigefügt sei und als Geburtstermin den 21. September 571 mittags angibt. Da er den Mond dann mit 10° Widder angibt, muss er sich um einen Tag verrechnet haben, denn dort stand der Mond bereits am 20. September. Um der Nachvollziehbarkeit des Textes folgt hier die Geburtsfigur für den 20. September 571:

Alle Planeten ausser Mond innerhalb 45 Grad. Sonne Mond, Mars und Merkur sowie Drachenkopf und Drachenschwanz in der Nähe der Äquinoktialpunkte bedeuten eine herausragende Person, weil auch die Finsternisse dieses und des darauffolgenden Jahres in Widder und Waage stattfinden. Dazu führt Bodinus aus Plutarch an, dass die Finsternis in der Nähe von Äquinoktialpunkten immer grosse Veränderungenm gebracht habe. Saturn und Jupiter vereinigt am Anfang des Skorpions, unweit davon die Venus. Dies ist bedeutsamer, als wenn sie nur durch ein Sextil, und noch ausserhalb der wässrigen Zeichen, verbunden wären. Sonne und Mars vereinigt bringen eine mutige, vorwärtspreschende Natur. Mars und Merkur in einer fast gradgenauen Konjunktion bei Spica Virginis, [...] bedeuten einen Aufrührer, Räuber und Mörder, Betrüger [falsarium] und alles andere, was Röslin oben aus der blossen Triangulation beider Planeten deduziert.- Cardanus will, dass Spica Virginis in Zusammenhang mit der christlichen Religion steht. Hier würde nun der christlichen Religion grosser Schaden bedeutet, durch Mord und Lügen, propter Martem et Mercurium conjunctos Spicae. Dort aber, und wenn 594 das richtige Jahr wäre, stünde der gütige Jupiter bei Spica. Nun hat Mahomet der christlichen Religion nicht so gütlich getan, dass es dieser Bedeutung bedürfte.- Mond in Opposition Merkur bedeutet den grossen Geist, aber auch Verwirrtheit, Konfusion. Ebenso bedeutet der Vollmond nahe der Opposition des Mars Jähzorn. Diese beiden Deutungen sind übliche astrologische Regeln. [2]

Sutorius ist laut Kepler nun so vorgegangen, dass er aus Mohammeds Radixhoroskop gleichsam eine Allegorie macht und daraus durch Direktionen mit acht Signifikatoren die achtmal acht wichtigsten Änderungen im Türkischen Reich zwingend herleiten will. Kepler hält es dagegen für besser, mit einem Horoskop der Hedschra zu arbeiten, denn dieses würde gewissermassen der Krönung Mohammeds entsprechen: Es soll einen an diesen grossen Astrologen Röslin und Sutorios schon Wunder nehmen, dass sie die Inthronisation so gar nicht beachten, von der unsere astrologischen Autoritäten sonst so viel halten... es ist aus der Geschichte wohlbekannt, der erste Muharram [arabischer Monatsname], von welchem die Araber ihre Hedschra anfangen, sei der Tag, an welchem Mohammed ausgezogen und von seiner Banditenrotte zum Haupt gewählt worden war. Denn Hedschra heisst gemäss Scaliger so viel wie Verfolgung wegen des Glaubens, oder Exil. Dieser erste Muharram der Hedschra fängt nach jüdischer Art am Abend des 15. Juli an und fällt in den 16. Juli, einen Freitag, im Jahre Christi 622, und am Himmel ist folgende Figur gestanden:

Es folgt eine Deutung, die Kepler (wie so oft) nach den Regeln der Astrologen vornimmt, die nicht seine eigenen sind:

Ohne Zweifel haben Sutorius und Röslin diese Figur ignoriert, weil sie ihnen nicht sonderlich getaugt hat: Denn nach astrologischer Lehre findet sich hier nichts besonders Wichtiges, und Jupiter und Mars sind in entgegengesetzten Zeichen, Mars steht verworfen im achten Haus, Jupiter ist rückläufig, Glückspunkt mit Drachenschwanz im gegenüberliegenden Domizil des Saturn [in Wassermann], dieser selbst in seinem Fall [nämlich auch in Löwe], im Quadrat zur Himmelsmitte. Das wären schlechte Bedeutungen. Doch hätten sie auch manches gefunden, was zu loben gewesen wäre: Jupiter steht in seinem Domizil, im Trigon zum MC, Sonne und Mond in Rezeption, der Mond mit Drachenkopf, Regulus und Venus, dass also auch hier der Mond wieder trefflich passt. Ausserdem ist das Medium Coeli am Ort der grossen Konjunktion der Jahre 571 und 630 [nämlich am Anfang des Skorpion.] Auch der Jupiter, der den Ort der Grossen Konjunktion von 631 günstig bestrahlt [aus den Fischen], während die Sonne im dritten der Wasserzeichen steht [im Krebs]. Weil das Medium Coeli die Herrschaft bedeutet, könnten diese Konstellationen den Grossen Konjunktionen subsumiert werden, was die Argumentation Röslins weiter stützt, das wässrige Trigon würde die Mohammedaner begünstigen. Aber das Feuer kann er dann nicht verwerfen [als für die Mohammedaner irrelevant betrachten], weil der Mond darinnen so trefflich wohl steht. Auch würde die in diesem Reich herrschende Polygamie gut zu dieser Stellung des Mondes passen, weil wieder Venus und Merkur sich mit ihm mischen. Mars als Herrscher des Aszendenten [durch Erhöhung] und des Medium Coeli [durch Domizil], im Sextil zur Sonne und im Trigon zum Aszendenten bedeutet kriegerische, streitbare Regenten, im Haus des Merkur [Jungfrau] betrügerisch und treulos. Jupiter, Herrscher von Sonne und Mond [nämlich via Dekanat?], bedeutet aus religiösen Dingen abgeleitete Ehre und Herrschaft, und dass König und Priester eine Person sind. Saturn mit Mondknoten zwischen den Lichtern [also in der hier kurzen Strecke zwischen Sonne und Mond] steht für tyrannische Regenten und Zerstörer, für starke Polizei und Ordnung.

Dies alles habe ich nach den Lehren der Astrologen abgeleitet, um zu zeigen, dass es Sutorius gar nicht nötig gehabt hätte, in neuer, unpassender Weise aus der Nativität Mohammeds Direktionen zu berechnen, statt, wie es die Astrologen lehren, das Horoskop der Inthronisation für die Direktionen zu verwenden, das das Reich mehr betreffen wird als das persönliche Horoskop Mohammeds.

Vermutlich sind die hier aufgeführten Horoskope Mohammeds konstruiert. Auch die Araber waren der Astrologie mächtig und dürften ihren Propheten zu einer astrologisch passenden Zeit in die Welt treten lassen. Anders steht es um die Hedschra: Da mit der Hedschra tatsächlich eine neue Zeitzählung begann, ist dieses Datum vermutlich korrekt. Das Horoskop wird auch anderwärts in der astrologischen Literatur verwendet.[3] Ob die Geschichte des Islams wirklich in Konkordanz mit den Direktionen dieses Horoskops verläuft, wäre einmal zu untersuchen.

Der immer wieder hervorgehobene Zusammenhang mit der Mutation der Grossen Konjunktionen ins Wasserelement (Konjunktion vom 29.8.571 jul. auf 3°31' Skorpion) ist jedenfalls bedenkenswert. Interessant ist auch die Zuordnung des Wasserelements zum Islam und des Feuerelements zum Christentum (weil das Leben Jesu mit der Mutation ins Feuerelement begann), worin Kepler offenbar mit Röslin und Sutorius übereinstimmt.

[1] Kepler, Judicium de Prognostici P. Sutorii (1604), in: Opera Omnia, ed. C. Frisch, Band VIII, S. 302. Siehe http://books.google.de/ebooks/reader?id=-pcqAAAAYAAJ&printsec=frontcover&output=reader, das Gutachten beginnt auf S. 300. Alle im Text folgenden Zitate stammen aus diesem Gutachten Keplers. Die Wörter habe ich teilweise um der besseren Verständlichkeit in heutiges Deutsch übertragen. Kommentare in eckigen Klammern sind von mir hinzugefügt.
[2] Kepler findet einige dieser Konstellationen verwandt mit denen des ihm vorliegenden Lutherhoroskops für den 10. November 1483, 11. Stunde - und bemerkt an dieser Stelle, dass es einen Streit um das richtige Geburtsjahr Luthers gibt.
[3] So in José Luis San Miguel de Pablos, Uranus-Neptun-Konjunktionen, Verlag Hier und Jetzt, Hamburg 1993, S. 35. Ihm geht es um die Uranus-Neptun-Konjunktion vom 18.9.623 jul., die sich im Hedschra-Horoskop bereits anbahnt.

Domänenspezifische Programmierung in ABAP

2011-01-06T19:01:00.039+01:00

Mit dem Thema domänenspezifischer Sprachen (DSL) habe ich mich hier schon beschäftigt und werde es noch häufiger tun, da ich es für ein zukunftsweisendes Feld in der Programmierung halte.

Die einfachste und dem ABAP-Entwickler geläufigste Form der domänenspezifischen Programmierung ist es sicher, Customizingtabellen zu definieren und für die Steuerung des Systems zu verwenden [1]: In einer gut definierten Customizingtabelle sind z.B. die möglichen Festwerte einer (DDIC-)Domäne unmittelbar in der Fachsprache der Anwendung nachvollziehbar.

Manchmal ist der Rahmen einer Datenbanktabelle für die gewünschte Form der Steuerbarkeit des Systems unzureichend: Man möchte z.B. flexibler sein. Vielleicht ist das relationale Datenmodell, das ausschliesslich Schlüssel/Wert-Beziehungen ableitet, für die Abbildung der gewünschten Steuerung unpassend. Oder man möchte die Steuerung des Programms im Quelltext der Klasse hinterlegen, die die Logik ausführt, um sie nahe beim Code selbst zu haben.

Eine Lösung ist es dann, die Logik so in einer Methode zu programmieren, dass der Quelltext dieser Methode radikal auf den Anwendungskontext beschränkt ist - die Programmierung selbst läuft gewissermassen hinter den Kulissen. Das kann man in ABAP mit Macros und der Doppelpunkt/Komma-Syntax erreichen.[2]

Ein Beispiel. In einer Klasse namens ZCL_GDBW_SELECTOR hatte ich die Aufgabe implementiert, Selektionen von verschiedenen externen Datenbanktabellen auszuführen, die im wesentlichen ähnlich strukturiert sind. Die Details, in denen sie voneinander abweichen, habe ich in einer statischen Hashtabelle festgehalten, die beim Laden der Klasse aufgebaut wird. Das Auffüllen dieser Tabelle ist programmiertechnisch ein harmloser, geradezu langweiliger Vorgang. Die insert-Anweisungen sowie die Zuweisungen an die Felder des Arbeitsbereichs gehören zum "Rauschen" der Sprache (syntactic noise): Notwendig zwar für die Maschine, für den Menschen aber erschweren sie den Blick auf das Wesentliche. In diesem Fall habe ich diese Anweisungen in Macros verborgen, so dass nur die wesentlichen, die steuernden Parameter im Quelltext der Methode stehenbleiben:

method build_info_on_tables_and_conns.
  data: ls_table_data type ty_table_data,
        ls_con_data   type ty_con_data.

  _add_table_data
*  Connection     Node          Zusatz
*                 Databox       Tabellenname
   'GDBW'         'gdnf1bw'     ' '      :
                  'INBOX'       'V_INFO_DATEN_RECV',
                  'OUTBOX'      'V_INFO_DATEN_SEND',
                  'ALL'         'V_INFO_DATEN_ALL',
                  'ARCH'        'V_INFO_DATEN_SEND_ARCH'.

  _add_table_data
    'MVN'         'gdnf2bw'      'X'      :
                  'INBOX'        'V_INFO_DATEN_RECV_NF',
                  'OUTBOX'       'V_INFO_DATEN_SEND_NF',
                  'ARCH'         'V_INFO_DATEN_SEND_ARCHIV'.

* ...

* Q-Verbindungen
  _copy_table_data_from_to :
                   'MVN'   'QMVN',
                   'KMVN'  'KQMVN',
*                   ...

Der "Domänenexperte" ist in diesem Fall jemand, der sich mit den externen Datenbanken und ihren Verbindungen zum SAP-System auskennt.

Man beachte in diesem Beispiel auch die Verwendung der Doppelpunkt/Komma-Notation: Der vor dem Doppelpunkt stehende Teil des Statements wird der Reihe nach als immer gleicher Vordersatz für alle durch Komma getrennten, nach dem Doppelpunkt stehenden Hintersätze verwendet. Auch dies erleichtert den Blick auf das Wesentliche. Alternativ hätte ich auch die Vordersätze n-mal hinschreiben müssen. Die Doppelpunkt/Komma-Notation und Macros haben mir in diesem Beispiel zu einer radikalen Durchsetzung von Don't repeat yourself verholfen. Keine Information muss mehrfach hingeschrieben werden, auch keine Programmzeile.

Ein anderes Beispiel aus meinem BSP-Thread Eingabebereitschaft in deklarativer Syntax zeigt den Einsatz dieser Technik, um zu steuern, wann welche Buttons in einer Anwendung aktiv, inaktiv und wann sie unsichtbar sind - abhängig vom Transaktionsmodus (Anzeigen, Ändern, Anlegen). Auch hier wieder die Reduktion auf das Wesentliche. Die tatsächliche Manipulation des Feldstatus erfolgt hinter den Kulissen, verborgen im Macro:

     _set_button_state_per_mode : 
*      FCODE    \  CREATE     CHANGE     DISPLAY 
       'ACTU'      active     active     disabled, 
       'SAVE'      active     active     disabled, 
       'UNDO'      active     invisible  invisible, 
       'CANCEL'    invisible  active     disabled, 
       'PRINT'     invisible  active     active.

Wieder erlaubt es die Anwendung, die Steuerung in Tabellenform zu notieren. Das bedeutet, für diese Art von Steuerungen wäre es im Prinzip auch möglich, kleine Customizingtabellen zu definieren, die dasselbe leisten.[3]

In beiden Fällen habe ich bewusst keine Customizingtabelle gewählt, schon aus Gründen der Sparsamkeit: Wenn ich alle Fallentscheidungen und Steuerungen dieser Art in Customizingtabellen ausprägen würde, würde ich das System mit Customizingtabellen geradezu fluten.

Ausserdem hätte ich dann nicht nur einen Ort, sondern zwei, die für die Steuerung zuständig sind: Um später in Problemfällen zu verstehen, warum ein bestimmter Status gewählt wird, muss ich mir die Einträge der Customizingtabelle und das Programm ansehen, das sie auswertet.

In der Macro-Notation habe ich dagegen alles an einem Ort, im selben Programmobjekt. Das Macro dient mir nur dazu, die Programmlogik innerhalb des Objekts von den eigentlich wichtigen steuernden Werten zu trennen, denn diese sind das Wesentliche. Die hinter den Kulissen laufende Programmlogik ist für alle Buttons die gleiche. Einmal programmiert - und mit einem Unit Test abgesichert - wird man in der Wartung nie mehr mit dem Code zu tun haben. Wohl aber mit den steuernden Werten: Es kann zum Beispiel ein neuer Button dazukommen. Oder ein neuer Auftraggeber findet es geschmackvoller als sein Vorgänger, Buttons grundsätzlich auf invisible zu schalten, wenn sie nicht verwendbar sind. Das sind typische Fälle von Änderungen - und immer müssen nur die Werte im obigen Codeabschnitt angepasst oder erweitert werden.

Macros und die Doppelpunkt/Komma-Syntax verhelfen also in ABAP zur Erstellung von internen DSLs, also Sprachen, die eingebettet in den normalen ABAP-Kontext verarbeitet werden.

Weitere Möglichkeiten ergeben sich durch die in ABAP integrierten XSLT- und JavaScript-Prozessoren. In meinem BSP-Framework stellt die in der Datei config.xml ausgeprägte Flow Logic eine DSL für die Ablaufsteuerung der Views in einer BSP-Applikation dar. Sie wird mit einer einzigen ABAP-Anweisung in ein Set von internen Tabellen gewandelt (siehe den Konstruktor der Klasse zcl_mvc_framework):

* config.xml in ABAP-Daten wandeln
  call transformation (config_to_abap) source xml lv_sxml
         result application = ls_application
                tree        = tree
                controller  = controllers
                model       = models.

In anderen Fällen kann es sinnvoller sein, statt XML die JavaScript-Objektnotation (JSON) zu verwenden. Denn XML produziert auch selbst wieder einen beachtlichen syntactic noise. Die JavaScript-Daten, die man z.B. in einem Standardtext (SO10) ablegen könnte, können entweder mit dem von mir in diesem Blog vorgestellten JSON-Parser oder mit dem in ABAP zugänglichen JavaScript-Interpreter cl_java_script eingelesen werden. Steuernde, sitzungsübergreifend relevante Informationen sollten, nachdem sie in ABAP-Daten gewandelt wurden, auf jeden Fall auf dem Application Server gepuffert werden.[4]

Aber auch JSON ist nicht ganz frei von syntactic noise. Der Anwender - und der DSL-Programmierer - will ja nicht die vielen geschweiften Klammern und Anführungszeichen sehen, sondern auf den ersten Blick bereits die wesentlichen Informationen. Dann kommen wir allmählich in die Gefilde einer "echten", externen DSL. Die Notation der Daten wird für ein bestimmtes spezifisches Problem ad hoc entworfen. Ein typisches Beispiel einer solchen DSL ist ein CSS-Sheet. Die CSS-Notation ist optimal auf genau einen Zweck zugeschnitten: Das Erscheinungsbild von HTML-Elementen zu steuern.

Eine externe DSL muss in ein semantisches Modell übersetzt werden. Für jede Notation wird ein eigener Übersetzer benötigt. Das klingt nach einem beträchtlichen Extraaufwand, da mit einem solchen Übersetzer ja eine weitere Softwarekomponente benötigt wird. Der Aufwand, einen Parser für DSLs oder an einen Parser angekoppelte Übersetzer zu schreiben, wird aber tendenziell überschätzt. Je eingeschränkter die Verwendung der DSL ist – und ein eingeschränkter Sprachumfang gehört zu den Charakteristika einer DSL – umso einfacher wird es auch, sie zu parsen, vor allem wenn man mit testgetriebener Entwicklung arbeitet (siehe zu diesem Thema den schönen Bliki ParserFear von Martin Fowler). Parser sind geradezu ein Paradebeispiel für die Effizienz testgetriebener Entwicklung, da sie so wenig Abhängigkeiten haben: Sie wandeln nur einen textförmigen Input in einen Syntaxbaum oder irgendein semantisches Modell um. Es bestehen keine weiteren Abhängigkeiten, etwa von Datenbanktabellen. Auch müssen ausser Basisfunktionen - etwa im Bereich der Stringverarbeitung - keine weiteren API's aufgerufen werden.

Für die Arbeit auf der Stringebene stehen uns in ABAP darüberhinaus die mächtigen regulären Ausdrücke zur Verfügung. Das dem eigentlichen Parsen oft vorangestellte Tokenizing lässt sich häufig bereits durch eine Folge von einfachen replace regex-Konstrukten realisieren.

Zur Illustration mag eine DSL zur Formulierung von sogenannten Verpackungsregeln dienen. Mit einer Verpackungsregel kann gesteuert werden, wie der Inhalt von mehreren SAP-Lieferungen auf einzelne Paletten aufzuteilen oder zu gruppieren ist. Ich habe für solche Verpackungsregeln einen kleinen Editor gebaut. Die Regeln werden von unserem SAP CC zum Test verschiedener Prozessfälle gepflegt und verwendet. Hier ein Beispiel:

1. Palette ( 
  2. Palette ( 
    1. Lieferung, 1. Pos.
      )
  3.Palette ( 
    1. Lieferung, Rest
      )
  4.Palette ( 
    2. Lieferung, 1. Pos.
    2. Lieferung, 2. Pos., 50%
      )
  5.Palette ( 
    2. Lieferung, Rest
     )
   )

Hier wird also eine hierarchische Handling Unit mit dem Inhalt von zwei Lieferungen bestückt, wobei eine Gruppenbildung von Lieferpositionen oder Teilmengen von Lieferpositionen möglich ist. Eine solche Regel kann mit einem Namen versehen und zur Laufzeit in einem Testfall zum automatischen Verpacken herangezogen werden. Ein Parser validiert die syntaktische Richtigkeit der Regel bereits zur Designzeit und erstellt ein semantisches Modell in Form von internen Tabellen. Dieses semantische Modell wird dann zur Laufzeit auf die real vorliegenden Lieferungen angewendet.

Zur Illustration folgt hier der Tokenizer für diese DSL, der vollständig mit regulären Ausdrücken notiert ist. Er erzeugt aus den vom Benutzer eingegebenen Regeln eine Folge von wohldefinierten, normalisierten Tokens in Form einer stringtab:

  lv_norm = iv_code.

  translate lv_norm to upper case.
  replace all occurrences of regex :

* Komma wird wie ein Trenner behandelt
    ','                          
          in lv_norm with gc_space,

* Normierung der Schlüsselwörter
    '\bLIEF(\.|ER\.|ERUNG)?'       
          in lv_norm with ' LIEF ',
    '\bPOS(\.|ITION)?'             
          in lv_norm with ' POS ',
    '\bPAL(\.|ETTE)?'              
          in lv_norm with ' PAL ',
    '\b(ALLES|REST)'               
          in lv_norm with ' REST ',

* Mehrfache Leerzeichen, Zeilenumbrüche etc. auf je 1 Space normieren
    '\s+'                        
          in lv_norm with gc_space,

* Menge mit Postfix MG
    '([\d.]+) ?(CU|%)'         
          in lv_norm with '$1 MG $2',

* Keywort folgt nach Nummer
    '(\d+)\. ?(LIEF|POS|PAL)'  
          in lv_norm with '$1 $2',

* 2x, da Tokens aneinanderhängen können: "(REST)"
    '([\d.]+|\(|\)|REST|LIEF|POS|PAL)(\(|\)|REST|LIEF|POS|PAL)'  
          in lv_norm with '$1 $2',
    '([\d.]+|\(|\)|REST|LIEF|POS|PAL)(\(|\)|REST|LIEF|POS|PAL)'  
          in lv_norm with '$1 $2'.

  shift lv_norm left deleting leading space.
  split lv_norm at space into table et_code.

Die Tokentabelle wird nun in einem folgenden Schritt in eine Tabelle von Tokens gewandelt; diese Tabelle enthält für jeden Token ein allfällig erfordertes numerisches Argument.

  loop at lt_code into lv_token.
    case lv_token.
      when '('.
        _add_token ct_tokens bra space.
      when ')'.
        _add_token ct_tokens ket space.
      when 'REST'.
        _add_token ct_tokens rest space.
      when 'PAL'.
        _add_token ct_tokens pal lv_number.
      when 'LIEF'.
        _add_token ct_tokens lief lv_number.
      when 'POS'.
        _add_token ct_tokens pos lv_number.
      when 'MG'.
        _add_token ct_tokens meng lv_number.
      when 'CU' or '%'.
        _add_token ct_tokens einh lv_token.
      when others.
        find regex '(\d+)' in lv_token submatches lv_number.
        if sy-subrc ne 0.
* Fehlermeldung - unbekanntes Token lv_token
          _raise_syntax lv_token text-003.
        else.
* Kein clear lv_number!
          continue.
        endif.
    endcase.
    clear lv_number.
  endloop.

In dieser Form kann sie nun vom Builder Befehl für Befehl abgearbeitet werden, um das gewünschte semantische Modell zu erzeugen.

Wenn wir in ABAP einen Parsergenerator aus der mächtigen Familie der Parsing Expression Grammars (PEG) zur Verfügung hätten, etwa OMeta, so liesse sich ein Parser für diese DSL mit wesentlich weniger Codezeilen notieren. Das folgende OMeta-Objekt dient zugleich als Parser, als Builder des semantischen Modells (hier in Form eines AST mit verschachtelten JavaScript-Arrays) wie auch zur Definition der verwendeten Grammatik. Darüberhinaus ist es auch lesbarer als die oben ausprogrammierte Folge von regulären Ausdrücken, die demselben Zweck dient.

ometa HandlingUnitDefinition <: Parser { 
  ordnum = digit+:ds '.'            -> parseInt(ds.join('')),
// Vollständige Lieferung mit allen Pos. bekommt Posnr 0:
  dlv  = ordnum:n ( "Lieferung" | "Lief" | "LF"  )     -> ["DLV", n, 0],
// Eine SSCC (Serial Shipment Container Code = ID einer Handling Unit)
  sscc = ordnum:n ( "Palette"   | "Pal" | "SSCC" )     -> ["SSCC", n], 
// Ausdruck für eine Position
  item = ordnum:n ( "Position"  | "Pos" | "POS"  )     -> ["POS", n], 
// Lieferposition
  dlvItem      = dlv:d "," spaces item:p       -> ["DLV",d[1],p[1]], 
// Rekursiver Aufbau einer HU in beliebige Tiefe:
  contentPart = dlvItem | dlv | hu | sscc,
// Regel für den Inhalt einer HU
  content = contentPart:x (spaces contentPart)*:xs 
          -> [x].concat(xs),
  hu      = sscc:s spaces "(" spaces content:c spaces ")"   
          ->  ["HU", s[1],c],
// expr definiert die gesamte Regel und damit die DSL:
  expr    = spaces hu:first (spaces hu)*:more      
          -> [first].concat(more)              
}

Diese OMeta-Grammatik ist fast vollständig äquivalent zu dem von mir ausprogrammierten ABAP-Code, von dem ich oben einen Auszug gezeigt habe! Das zeigt Perspektiven, in die man gehen könnte, um DSLs noch schneller und einfacher zu formulieren und zu definieren. Da es eine JavaScript-Implementierung von OMeta gibt, könnten sich Grammatiken auch in der ABAP-Welt verwendet werden - denn es gibt ja den in der Klasse CL_JAVA_SCRIPT verschalten JavaScript-Interpreter. Die sogenannten semantischen Aktionen, die nach jeder Regel hinter dem Pfeil-Operator -> folgen, könnten darüberhinaus Callbacks in ABAP enthalten. Dass der CL_JAVA_SCRIPT ressourcenintensiv ist und dass eine interpretierte Sprache nicht besonders schnell ist, gibt auch keinen Grund zur Beunruhigung. Denn das Ergebnis des Parse-Vorgangs wird man sowieso auf dem Application Server puffern, da es normalerweise für alle Benutzer identisch ist.

Statt ein semantisches Modell in Form von internen Tabellen zu füllen, kann ein DSL-Parser natürlich auch verwendet werden, um ABAP-Programmcode zu erzeugen. Auch hierfür halten unsere SAP-Systeme eine Reihe von Beispielen bereit. Diese gedenke ich in künftigen Blogs zu dokumentieren.

[1] Dass die Einträge von Customizingtabellen als ein "DSL-Programm" aufgefasst werden können, mag Verwunderung oder gar Befremden hervorrufen: Ich hatte diesen Standpunkt bereits in meinem Blog Software-Steinzeit erläutert.

[2] Macros werden im Debugger wie eine Ausführung behandelt, man kann nicht in ein Macro hineindebuggen. Daher empfiehlt es sich, das Macro ausser in den einfachsten Fällen nur zum Aufruf von Methoden zu verwenden und die Logik des Macros in diesen Methoden zu programmieren. Das Macro hilft dann, die beabsichtigte Steuerung in einer besser lesbaren Form hinzuschreiben.

[3] Um Tippfehler zu vermeiden, habe ich in diesem Fall die möglichen Zustände eines Buttons in Form von Konstanten ausgeprägt. Hinter den Kulissen gibt es Konstanten gc_state-active, gc_state-invisible usw. So hält mich bereits der ABAP Syntaxchecker davon ab, ungültige Zustandswerte einzugeben.

[4] Nur in Entwicklungssystemen sind Pufferungen normalerweise lästig: Der Entwickler ist mehr daran interessiert, bei seinen Entwicklertests stets die aktuellsten Daten zu sehen, die er für seine Tests auch ständig ändert. Im Entwicklungssystem zu puffern, kann lästige Debuggingsitzungen verursachen. Dagegen ändern sich die steuernden Daten im Produktivsystem eher selten, während andererseits die höchstmögliche Performance angestrebt werden sollte: Dort also unbedingt puffern! Schliesslich sollen nicht hunderte von Benutzern in ihren Sitzungen alle dieselbe Konfigurationsdatei von der Datenbank oder vom Dateisystem einlesen müssen. Aus demselben Grund sind Customizingtabellen im DDIC mit einem Click - ohne zusätzlichen Programmieraufwand - auf dem Applikationsserver pufferbar.

Micro-Versionierung

2011-01-04T22:23:00.017+01:00

Vor kurzem wäre ich beinahe Opfer eines schlimmen Datenverlustes geworden [1]: Durch den Upload eines falschen JavaScript-Files hätte ich die Frucht von fast zwei Tagen intensiver Programmierarbeit verloren. Zwar ist es meine Erfahrung, dass das erneute Schreiben des Programms in solchen Fällen ein besseres Ergebnis liefert, auch wenn das erste Produkt doch wieder auftaucht oder wiederhergestellt werden kann. Auch Briefe gewinnen deutlich an Qualität, wenn man sie nach Abfassung zerreisst und komplett neu schreibt!

Dennoch versuche ich natürlich vernünftigerweise, Datenverlust möglichst zu vermeiden. Im SAP-System gelingt mir dies durch häufige Freigabe meiner Änderungen ins Testsystem. Dadurch entstehen zwar viele kleine Transporte - aber die Arbeit wird dadurch besser dokumentiert und nachvollziehbar. Die Kurztexte der Transporte kann ich darüberhinaus zur Dokumentation der kleinen Änderungen nutzen, die ich jeweils vorgenommen habe. So enthält die Versionsverwaltung schliesslich eine Dokumentation der an einem Quelltext vorgenommenen Arbeitsschritte.

Nur für Arbeiten an "Wegwerfprototypen" verzichte ich auf Transporte und verwende lokale Pakete. Genau daher bekam ich mein Problem. Dabei haben Prototypen in der Entwicklungsarbeit durchaus einen hohen Stellenwert: sie können - wie in diesem Fall - als Proof Of Concept die Vergabe eines Entwicklungsprojekts legitimieren.

Für Entwicklungen in JavaScript, Perl, C/C++ und Java benutze ich häufig den Editor UltraEdit. Dieser erlaubt es zwar, automatisch numerierte Backups der letzten Änderungen zu erstellen. Diese Einstellung ist aber pauschal, gilt dann für jedes File, das ich im Editor überhaupt ändere. Mir ist es lieber, die Versionierung gezielt selbst anstossen zu können. Ausserdem gefällt mir die Verschwendung nicht, jede dieser Versionen als Vollversion zu speichern (statt nur die Differenzen).

Daher habe ich UltraEdit mit einem Versionierungswerkzeug auf Basis von CVS ausgestattet (CVS ist zwar ein bisschen aus der Mode gekommen, aber zweifellos "gut abgehangen"). Wer CVS nicht mag, sondern lieber mit GIT oder SVN arbeitet, kann meine Lösung leicht abändern, da die Kommandozeilenbefehle für das Ein- und Auschecken in allen diesen Systemen ähnlich sind.

Wie funktioniert es? Wenn ich eine Version der aktuell bearbeiteten Datei ziehen möchte, wähle ich mein neues Werkzeug "Versionieren":

Die Versionen, ihre Diffs und Patches kann ich mir nachher mit einem GUI für CVS ansehen, z.B. TortoiseCVS oder wincvs.

Der Vollständigkeit halbe füge ich hier noch das Batchfile an, das die Versionierung ausführt. Es bekommt von Ultraedit zwei Argumente, den Verzeichnisnamen und den Dateinamen (im Werkzeugkommando durch die Symbole %p und %n%e bezeichnet). Die Definition des Werkzeugs lautet also

makeVersion.bat "%p" %n%e

Das Batchfile muss mit seiner mittelalterlichen Stringverarbeitung diese Anführungszeichen wieder entfernen, um Name und Pfad in eigenen Kommandos verwenden zu können. Es richtet dann ein temporäres Arbeitsverzeichnis ein, checkt die Datei gleichen Namens aus einem lokalen Repository aus, kopiert den aktuellen Stand in das Arbeitsverzeichnis und führt schliesslich den commit aus. Auf Dokumentationen der Änderungen mit dem -m Parameter verzichte ich. Denn es geht mir ja nur um Microversionen - die viele kleinsten Versionen, die während der Arbeit an einem Programm entstehen. Aus dem gleichen Grunde reicht es mir, die Versionierung nur anhand des Dateinamens auszuführen. Wenn ich vor vielen Monaten schon einmal eine ganz andere Datei desselben Namens bearbeitet hatte, stören mich die von dieser Zeit noch vorliegenden Versionen nicht: Ich schaue ja gar nicht so weit zurück, mir geht es um Änderungen in einem Zeitrahmen von Minuten oder Stunden.

In meiner IDE der Zukunft sind all diese Dinge in den Editor integriert. Für die Fehlersuche steht mir dann eine Zeitlinie zur Verfügung, in der auch bei der gleichzeitigen Arbeit an mehreren Dateien die letzten konsistenten Codestände testhalber wiederhergestellt können, so dass ich ohne aufwendige Analyse direkt ermitteln kann, ab welcher Änderung sich das Fehlerchen eingeschlichen hat.

@ECHO OFF

rem SYNTAX:
rem makeVersion  
rem Versioniert die angegebene Datei, wobei für jeden Dateinamen
rem ein neuer Modul im Wurzelverzeichnis ue32work angelegt wird.

set CVSWORKDIR=\UltraEdit-32\cvswork
set WTEMP=\Temp
set UE32WORK=%WTEMP%\ue32work
set CVSCMD=\cvsnt\cvs -d %CVSWORKDIR%
set FILEPATH=%1%
for /f "useback tokens=*" %%a in ('%FILEPATH%') do set FILEPATH=%%~a
set FILENAME=%2%
for /f "useback tokens=*" %%a in ('%FILENAME%') do set FILENAME=%%~a
set FULLFILENAME="%FILEPATH%%FILENAME%"

rmdir /S /Q %UE32WORK%
mkdir %UE32WORK%
if exist %CVSWORKDIR%\ue32work\%FILENAME% ( 
@ECHO ON
cd %WTEMP%
%CVSCMD% co ue32work\%FILENAME%
copy /Y %FULLFILENAME% %UE32WORK%\%FILENAME%
cd %UE32WORK%\%FILENAME% 
%CVSCMD% commit -m "Dummy" %FILENAME%
) else (
@ECHO ON
mkdir %UE32WORK%\%FILENAME%
copy /Y %FULLFILENAME% %UE32WORK%\%FILENAME% 
cd %UE32WORK%\%FILENAME%
%CVSCMD% import -m "Dummy" ue32work\%FILENAME% "UE32WORK" "r1" 
)

[1] Wieso wurde ich nur beinahe ein Datenverlust-Opfer? Dank eines wahnsinnigen Zufalls hatte mein Kollege eine Version des Files in seinem Browser-Cache, die immerhin nur eine halbe Stunde alt war. Das genügte.

Ein JSON-Parser in ABAP

2010-12-21T20:27:00.015+01:00

Wenn es darum geht, strukturierte Daten zwischen verschiedenen Systemen auszutauschen, bietet sich das JSON-Datenformat an. Es unterstützt Arrays, Hashs, einige elementare Datentypen für Zahlen, Strings und Wahrheitswerte und erlaubt es, Datenobjekte beliebig tief ineinander zu schachteln.

Die Notation ist einfach und Programmierern der verschiedensten Sprachen (C, C++, C#, Java, JavaScript) in dieser oder ähnlicher Form geläufig. Im Vergleich zu XML gibt es weniger Overhead zur Definition der Struktur, so dass das Wesentliche, der eigentliche Dateninhalt, besser ins Auge fällt.

Hier einige einfache Beispiele:

[ "rot", "grün", "blau" ]

ist ein Array von Strings. Der folgende Hash definiert beispielhaft einige Name/Wert-Paare:

{ 
  "Alter":42, 
  "Beruf":"Stenotypistin", 
  "Raucher":true 
}

Natürlich lassen sich Arrays und Hashs beliebig kombinieren, zum Beispiel zu einem Hash of Arrays (HoA):

{
  "Adam" : ["Kain", "Abel", "Seth"],
  "Abraham" : ["Ismael", "Isaak"],
  "Isaak" : ["Jakob", "Esau"]
}

Da JSON im wesentlichen der Notation von Daten in JavaScript entspricht, wird es häufig in Webanwendungen für die Kommunikation mit dem Server verwendet. Das Parsen im JavaScript-Layer einer Webanwendung kann einfach mit der Anweisung eval erfolgen.[1]

Um die Benutzeroberfläche portabel entwickeln und ohne grossen Aufwand zwischen verschiedenen Backends wählen zu können, empfiehlt sich ein standardisiertes Datenformat wie JSON für beide Richtungen des Datentransports, für das Senden wie das Empfangen der Daten.

Da ich seit kurzem an einer Webanwendung arbeite, die Ajax-Requests mit JSON-Daten an ein SAP-System sendet und von diesem empfängt, benötigte ich im ABAP-Stack einen JSON-Parser. Da es einen solchen anscheinend im SAP-System bisher nicht gibt, habe ich ihn selbst programmiert: Die Klasse ZCL_JSON_PARSER kann eine JSON-Eingabe in ein allgemein typisiertes ABAP-Datenobjekt umwandeln, das dann im Client Code durchsucht oder auf die anwendungsspezifischen Datenstrukturen abgebildet werden kann.

Bei Mappingaufgaben wie dieser ist das testgetriebene Entwickeln besonders effizient: Das liegt daran, dass wir nicht wie sonst mit Seiteneffekten zu tun haben - es gibt praktisch keine API-Aufrufe, die so oder so ausgehen können, und keine Abhängigkeit von den Inhalten irgendwelcher Datenbanktabellen. Wir haben ein Input und ein nur von diesem abhängendes Ouput. Das ruft geradezu danach, die Funktionalitäten Schritt für Schritt als Erfüllung von Testerwartungen zu implementieren. [3]

Bevor wir aber auch nur einen syntaktisch korrekten Test hinschreiben können, muss wenigstens die Schnittstelle der zu testenden Methode festgelegt sein. In unserem Fall werden wir eine öffentliche Methode parse haben, die sicher folgendermassen aussieht:

methods parse
  importing
    iv_json type string
  returning
    value(es_data) type zut_data
  raising
    zcx_parse_error.

Eingabe ist sicher ein String. Ausgabe ist ein Datenobjekt, das mit ABAP-Mitteln ausgewertet werden kann und beliebig tiefe Verschachtelungen zulässt. Hierzu benötigen wir einen generischen Datentyp, der beliebige Datenobjekte fassen kann. Der Datentyp any kann leider nicht verwendet werden, da er nur eine Abstraktion aller bestehenden Datentypen darstellt und dem Compiler nicht sagen kann, wieviele Bytes für diesen Typ alloziert werden sollen. Der Typ ref to data hat dieses Problem nicht. Er ist "ein Zeiger auf irgendetwas" und benötigt eine bekannte Anzahl von Bytes: Die Länge einer Speicheradresse, üblicherweise vier Bytes.

Der obige Rückgabetyp ist im Data Dictionary definiert. In ABAP würde man ihn äquivalent wie folgt notieren:

types: begin of zut_data,
  type type c length 1,
  data type ref to data,
end of zut_data.

Der Typschlüssel type spezifiert den Typ des Datenobjekts, auf das der Zeiger data zeigt. Das können elementare Datentypen wie String (S), Number (N), Boolean (B) sein, aber auch zusammengesetzte Typen wie Hash (h) oder Array (a).

Man beachte, dass die so typisierte Schnittstelle schon eine wichtige Designentscheidung enthält: Das Ziel unseres Mappings wird ein Datenobjekt, nicht die Instanz einer Klasse. In der Hierarchie der ABAP-Objekte haben Datenobjekte und Instanzen von Klassen keinen gemeinsamen Oberbegriff.

Man hätte alternativ eine Klasse zur Definition des Zieltyps in ABAP verwenden können. Das hätte gewisse Vorteile gebracht, zum Beispiel hätte der Typschlüssel eliminiert werden können [2] – aber um den Preis beträchtlicher Performanceeinbussen: Der create data Befehl hat wesentlich bessere Ausführungszeiten als create object.

Für die einfachen Datentypen können wir nun schon einige Tests hinschreiben:

* --- Zahlen erkennen
  method test_42.

    data: ls_data type zut_data.
    ls_data = go_ref->parse( '42' ).

* Parser erkennt '42' als Zahl:
    assert_equals( act = ls_data-type
                   exp = 'N' ).

* Wert 42 wurde korrekt ermittelt
    _assert_equals( act = ls_data-data
                    exp = 42 ).

  endmethod.

* --- Einen String erkennen
  method test_string.
    data: ls_data type zut_data.
    ls_data = go_ref->parse( '"Abc"' ).

* Typ String wird erkannt
    assert_equals( act = ls_data-type
                   exp = 'S' ).

* String wird richtig gelesen
    _assert_equals( act = ls_data-data
                    exp = 'Abc' ).

  endmethod.                    "test_string

Hierbei ist _assert_equals eine Hilfsmethode, die im wesentlichen wie assert_equals funktioniert; wenn aber act ein Zeiger ist, wird er vor dem Vergleich mit exp dereferenziert.

Wenn ein leerer Input hereingereicht wird, soll auch eine leere Struktur zurückgegeben werden:

* --- Keine Eingabe -> Keine Ausgabe
  method test_nothing.
    data: ls_data type zut_data.

    ls_data = go_ref->parse( '' ).

* Leerer String ergibt leeres Ergebnis (keine Ausnahme)
    assert_initial( ls_data ).

  endmethod.                    "test_nothing

Wie ist es nun mit zusammengesetzten Typen - hier Hashs und Arrays? Es liegt nahe, Hashs und Arrays in ABAP durch interne Tabellen mit Hash- bzw. Standardzugriff abzubilden. Für Arrays ist dies relativ einfach:

types: zut_array_tab 
  type standard table of zut_data.

leistet das Gewünschte: Denn jedes Arrayelement kann ja wieder ein beliebiges Datenobjekt enthalten. Also ist der Zeilentyp des Arrays wieder zut_data.

Hashs sind Mengen von Schlüssel/Wert-Paaren. Der Schlüssel ist ein String, der Wert ist wieder ein beliebiges Datenobjekt. Ein Hash-Element sieht also folgendermassen aus:

types: begin of zut_hash_element,
  key type string.
  include type zut_data as value.
types: end of zut_hash_element.

Der Hash selbst ist nun im ABAP-Sinne eine Hash-Tabelle mit Zeilentyp zut_hash_element und Schlüsselspalte key:

types: zut_hash_tab type hashed table of zut_hash_element 
  with unique key key.

Nun können wir auch Tests für Hashs und Arrays formulieren, mit dem einfachsten Fall beginnend:

Es soll sicher der leere Array erkannt werden (go_ref ist das Object Under Test, also die zu testende Instanz von ZCL_JSON_PARSER):

* --- Der leere Array []
  method test_empty_array.

    data: ls_data type zut_data.

    field-symbols: <lt_array> type zut_array_tab.

    ls_data = go_ref->parse( ' [   ]  ' ).

* Typ array wird erkannt
    assert_equals( act = ls_data-type
                   exp = 'a' ).

    assert_bound( ls_data-data ).

    assign ls_data-data->* to <lt_array>.
    assert_subrc( act = sy-subrc
                  msg = 'Datenobjekt hat nicht den korrekten Typ' ).

* Es wurde der leere array ermittelt
    assert_initial( <lt_array> ).

  endmethod.                    "test_empty_array

Der letzte und komplizierte Testfall, das Parsen einer verschachtelten komplexen Struktur soll zugleich zeigen, wie die resultierende Struktur in ABAP ausgewertet werden kann, um die in der Anwendung gewünschten Daten zu extrahieren:

* --- Verschachtelte Struktur
  method test_complex_nested.

    data: ls_data type zut_data,
          lv_array_length type i.

    field-symbols: <lt_array> type zut_array_tab,
                   <lt_hash>  type zut_hash_tab,
                   <lt_hash2>  type zut_hash_tab,
                   <ls_line>  type zut_data,
                   <ls_element> type zut_hash_element,
                   <ls_element2> type zut_hash_element.


    ls_data = go_ref->parse( 
      ' [ 1, { x:[1,2,3],y:{"c":1} }, "a" , true ]  ' 
      ).

* Basistyp Array wird erkannt
    assert_equals( act = ls_data-type
                   exp = 'a' ).

* Äusseren Array anschauen
    assign ls_data-data->* to <lt_array>.

* Er hat vier Elemente
    describe table <lt_array> lines lv_array_length.
    assert_equals( act = lv_array_length
                   exp = 4 ).

* Auf zweites Element positionieren
    read table <lt_array> assigning <ls_line> 
      index 2.
    assert_equals( act = <ls_line>-type exp = 'h' ).
    assign <ls_line>-data->* to <lt_hash>.

* Den Hash (das zweite Element des äusseren Arrays) anschauen
* Auf Element zum Schlüssel 'y' positionieren
    read table <lt_hash> assigning <ls_element> 
      with table key key = 'y'.
    assert_subrc( sy-subrc ).

* Das Element zum Schlüssel 'y' ist wieder ein Hash
    assert_equals( act = <ls_element>-type exp = 'h' ).
    assign <ls_element>-data->* to <lt_hash2>.

* Dieser innerste Hash enthält zum Schlüssel 'c' die Zahl 1:
    read table <lt_hash2> assigning <ls_element2> 
         with table key key = 'c'.
    assert_subrc( sy-subrc ).
    assert_equals( act = <ls_element2>-type exp = 'N' ).
    _assert_equals( act = <ls_element2>-data exp = 1 ).

  endmethod.

Zum Entwurf der Klasse ZCL_JSON_PARSER noch einige Anmerkungen:

Kernstück ist die Methode get_any, die ein beliebiges JavaScript-Datenobjekt einliest. Sie wird nicht nur von der einzigen öffentlichen Methode parse für das Top-Datenobjekt aufgerufen, sondern auch an den dafür vorgesehenen Plätzen in Arrays und Hashs, was zu rekursiven Aufrufen führt.

Es gefiel mir, die Klasse vollständig von globalen Variablen freizuhalten: Sie besitzt überhaupt keine Attribute. Der Preis dafür war lediglich, alle Teilmethoden mit einem Parameter cv_pos zu versehen, der die aktuelle Position im String angibt und von den Teilmethoden bei erfolgreichem Lesen eines Ausdrucks erhöht werden kann. Die Aufrufe der Teilmethoden werden dadurch etwas unhandlicher als sie sein könnten: Jede Methode übergibt per Referenz den vollständigen zu parsenden String und die Position im String als Changing-Parameter. Dazu gibt es meist den Exportparameter ev_found, ein Flag, das angibt, ob das gesuchte Teilobjekt gefunden wurde.

Die Klasse kann ein bisschen mehr als das JSON-Format: Schlüssel von Hashes können wie in JavaScript ohne Anführungszeichen hingeschrieben werden, wenn sie einen gültigen Variablennamen darstellen. Und Strings können auch durch einfache Hochkommata begrenzt werden. Einzige Einschränkung für Strings: Unicode-Zeichen in der Notation \uXXXX sind nicht unterstützt.

[1] Wegen der theoretischen Möglichkeit von Code Injection-Angriffen wird für Anwendungen, die im Public Internet laufen, allerdings empfohlen, auch in JavaScript einen ausprogrammierten Parser zu verwenden, der wirklich nur Datenobjekte evaluiert und keine JavaScript-Anweisungen ausführt. Die bekannteren JavaScript-Frameworks wie Prototype oder jQuery enthalten einen JSON-Parser.
[2] Das ist Martin Fowlers Refactoringmuster: "Typschlüssel durch Unterklassen ersetzen".
[3] Das ist auch der Grund, warum in TDD-Einführungen häufig Mappingaufgaben als Beispiel verwendet werden, etwa ein Konverter von Ganzzahlen in römische Zahlwerte.

Keine Message-Befehle in Geschäftslogik!

2010-11-25T22:21:00.022+01:00

Vor kurzem erhielt ich per Mail die Anfrage eines Entwicklers, wie er denn mit ABAP Units testen könne, ob eine bestimmte Fehlermeldung, die er in seiner Geschäftslogik durchläuft, gesendet oder nicht gesendet wird. Er hatte das schon auf verschiedene Weisen probiert, kam an dieser Stelle aber nicht weiter.

Wenn etwas sich als kompliziert testbar erweist, liegt es oft nicht am Unit Test oder gar, wie hier indirekt geargwöhnt wurde, am Unit Test Framework (zwischen den Zeilen lese ich "Pah! Mit ABAP Unit kann man nicht mal eine Errormeldung abfangen bzw. abfragen"), sondern meistens liegt das Problem im zu testenden Code selbst. So auch hier.

Nehmen wir an, es sei eine Plausibilitätsprüfung gefordert, dass ein vom Benutzer einzugebender Preis einen bestimmten Maximalbetrag nicht überschreiten darf. In der an die Transaktion gebundenen Klasse, die die Eingabewerte überprüft, finden wir vielleicht den folgenden Code:

if iv_input_price > gv_max_price.
* Der eingegebene Preis &1 ist zu hoch (Maximum: &2)
  message e100 with iv_input_price gv_max_price.
endif.

Das funktioniert im GUI alles ganz wunderbar. Aber beim automatischen Testen des Codes ergeben sich Schwierigkeiten. Der Unit Test, der eine Überschreitung des Maximalbetrags simuliert, lässt sich nicht bis zu Ende ausführen. Wenn er auf die Fehlermeldung stösst, übergibt der Unit Test die Kontrolle zwangsläufig an den GUI zur Anzeige des Fehlers. Das bedeutet aber: Die Ausführung des Unit Tests stoppt an dieser Stelle. Beides - die Anzeige des Fehlers und die Unmöglichkeit, den Unit Test korrekt zu Ende zu führen - ist natürlich unerwünscht.

Wo liegt hier das Problem?

Auch wenn der produktive Code anscheinend ja korrekt funktioniert und das Problem nur beim Unit Test auftritt, liegt das Problem nicht beim Unit Test und schon gar nicht beim Unit Test Framework. Das Problem besteht darin, dass obiger Code die Prüflogik an die Existenz eines GUI bindet: Der message-Befehl ist eine Anweisung, die an den GUI zur Ausführung übergeben wird. Es ist nicht möglich, die Prüfung unabhängig vom GUI auszuführen. Das ist in vieler Hinsicht schädlich:

Der Code kann nicht im Hintergrund ausgeführt werden, z.B. in einem Job: Eine Errormeldung führt zum sofortigen Abbruch des Jobs. Wenn aber z.B. eine ganze Reihe von Belegen im Hintergrund verbucht werden sollen, ist dies nicht das erwünschte Verhalten: Dann soll normalerweise nur die Bearbeitung des aktuellen Belegs abgebrochen und mit dem nächsten Beleg fortgefahren werden.

Es ist nicht möglich, die Klasse mit dieser Prüfung in einer Web-Anwendung oder mit einem ganz anderen User Interface einzusetzen: Da die message-Anweisung nicht ausgeführt werden kann, kommt es zu einem Abbruch des Prozesses mit einem Kurzdump - im Web also zu einem "internen Serverfehler" (HTTP 500).

Es ist nicht möglich, die Logik dieser Klasse als API-Funktion anzubieten, da der Fehlerfall zu einer Situation führt, die nicht durch die Schnittstelle kontrolliert ist.

Alle Probleme der Informatik können durch Einführung einer neuen Indirektionsebene gelöst werden, lautet ein berühmtes Zitat von Butler Lampson.[1] Das ist auch in diesem Fall so. Genau um die Behandlung eines Fehlers von dessen Erkennung zu trennen, hat man die Exception erfunden. Statt eine Fehlersituation direkt im GUI zu melden, sollte das Programm eine Ausnahme auslösen, und zwar am besten gleich eine klassenbasierte. Diese Ausnahme wird in der Schnittstelle der Prüfmethode deklariert. Der Konsument dieser Methode kann dann mit einem try... catch... Block selbst entscheiden, was er im Ausnahmefall machen möchte. Nach Einführung einer solchen Ausnahme kann der Code beispielsweise folgendermassen aussehen:

if iv_input_price > gv_max_price.
  raise exception type zcx_price_exceeds_bound
    exporting 
      price = iv_input_price
      bound = gv_max_price.
endif.

Der Unit Test einer solchen Logik gestaltet sich entsprechend einfach — und einfache Unit Tests sind meist ein Zeichen, dass der produktive Code ganz gut geraten ist. Hier der Test, dass die Prüfung eine Grenzwertüberschreitung erkennt und die erwartete Ausnahme auslöst:

method test_bound_detected.
  try.
      go_validator->check_price( gc_very_high_price ).
* Nicht OK - Ausnahme wurde nicht ausgelöst:
      fail( 'Zu hoher Preis soll Ausnahme auslösen!').
    catch zcx_price_exceeds_bound into lo_ex.
* OK - optional noch die Ausnahmeparameter prüfen:
      assert_equals( 
        act = lo_ex->price
        exp = gc_very_high_price
        msg = 'Ausnahmeobjekt falsch parametrisiert' ).    
      assert_equals( 
        act = lo_ex->bound
        exp = go_validator->gv_max_price
        msg = 'Ausnahmeobjekt falsch parametrisiert' ).    
  endtry.      
endmethod.

Auch der umgekehrte Test ist sinnvoll: Wenn ein hinreichend kleiner Preis (z.B. 1) eingegeben wird, soll keine Ausnahme ausgelöst werden:

method test_no_ex_for_price_in_range.
  go_validator->check_price( 1 ).
endmethod.

Fehlt hier nicht noch etwas? Nein! Denn das Abfangen einer Ausnahme können wir getrost dem Unit Test Framework überlassen: Wenn es zu einer Ausnahme kommt, ist das ja ein Fehler im Programm. Also reagiert das Unit Test Framework bereits korrekt, indem es den Test test_no_exc_for_price_in_range in der Übersicht als fehlerhaft markieren wird. Siehe hierzu auch meinen Blog Unbehandelte Ausnahmen als Zusicherung.

Damit könnten wir den Fall als erledigt betrachten: Error Messages in der Prüflogik sollen unbedingt vermieden werden. Ende der Durchsage.

Trotzdem bleibt der unterschwellige Vorwurf bestehen, das Unit Test Framework könnte keine Error Messages abfangen (unabhängig davon, ob dies sinnvoll ist oder nicht). Die Antwort ist: Es kann - wenn wir bereit sind, eine weitere Indirektionsebene einzuführen! Indem ich ausführe, wie das geht, will ich keineswegs zur Verwendung von Error Messages raten. Es könnte aber sein, dass das Wissen um diese Möglichkeit in irgendwelchen Fällen einmal nützlich ist.

Tatsächlich bietet ABAP eine Möglichkeit, Fehlermeldungen abzufangen: Funktionsbausteine haben stets die eingebaute Ausnahme error_message. Wenn diese Ausnahme bei Aufruf eines Funktionsbausteins explizit abgefangen wird, so wird sie beim Auftreten einer Error Message innerhalb des vom Funktionsbaustein durchlaufenen oder aufgerufenen Codes ausgelöst. Man kann also nach Aufruf des Funktionsbausteins wie üblich den sy-subrc abfragen, um zu erkennen, dass eine Error Message ausgelöst wurde.

Nun gibt es für Methoden aus gutem Grund (s.o.) keinen solchen Mechanismus. Wir können jedoch einen Funktionsbaustein einführen, der dynamisch Methoden eines zur Laufzeit gegebenen Objekts mit einer zur Laufzeit gegebenen Parameterliste aufruft:

FUNCTION Z_TEST_E_MESSAGE.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     REFERENCE(IO_OBJECT) TYPE REF TO  OBJECT
*"     REFERENCE(IV_METHOD) TYPE  CSEQUENCE
*"     REFERENCE(IT_PARAMETERS) TYPE  ABAP_PARMBIND_TAB
*"----------------------------------------------------------------------

  call method io_object->(iv_method)
    parameter-table it_parameters.

ENDFUNCTION.

Das folgende Beispielprogramm zeigt dann mithilfe eines Miniobjekts lcl_testee,
das auf Wunsch Error Messages erzeugt, wie das Auftreten oder Nichtauftreten einer
Error Message im Unit Test geprüft werden kann:

* ---
report  z_test_e_message.

* --- How to test for error messages within unit tests

* ---
class lcl_testee definition.
  public section.
    methods unwise_check 
      importing iv_error type flag.
endclass.                    "lcl_testee DEFINITION

* ---
class lcl_testee implementation.
  method unwise_check.
    if iv_error eq 'X'.
      message e001(bl) 
        with 'Never issue E-message in a validator'.
    endif.
  endmethod.                    "unwise_check
endclass.                    "lcl_testee IMPLEMENTATION

* ---
class lcl_test definition 
      for testing  " #AU Risk_Level Harmless
      inheriting from cl_aunit_assert. " #AU Duration Short

  private section.
    data go_testee type ref to lcl_testee.
    methods:
      setup,
      prepare_parameters 
        importing iv_error type flag
        exporting et_parameters type abap_parmbind_tab,
      test_error for testing,
      test_no_error for testing.


endclass.                    "lcl_test DEFINITION

*
class lcl_test implementation.
*
  method setup.
    create object go_testee.
  endmethod.                    "setup
*
  method test_error.
    data: lt_parameters type abap_parmbind_tab,
          lv_subrc type i.
    call method prepare_parameters
      exporting iv_error = 'X'
      importing et_parameters = lt_parameters.
    call function 'Z_TEST_E_MESSAGE'
      exporting
        io_object     = go_testee
        iv_method     = 'UNWISE_CHECK'
        it_parameters = lt_parameters
      exceptions
        error_message = 1.
    lv_subrc = sy-subrc.
    assert_not_initial( 
      act = lv_subrc
      msg = 'Method should issue an error message' ).
  endmethod.                    "test
*
  method test_no_error.
    data: lt_parameters type abap_parmbind_tab.
    call method prepare_parameters
      exporting iv_error = space
      importing et_parameters = lt_parameters.
    call function 'Z_TEST_E_MESSAGE'
      exporting
        io_object     = go_testee
        iv_method     = 'UNWISE_CHECK'
        it_parameters = lt_parameters
      exceptions
        error_message = 1.
    assert_subrc( sy-subrc ).
  endmethod.               "test_no_error
*
  method prepare_parameters.
    data: ls_parameter type abap_parmbind,
          lv_error type ref to flag.

    clear et_parameters.

    create data lv_error.
    lv_error->* = iv_error.
    ls_parameter-name  = 'IV_ERROR'.
    ls_parameter-kind  = cl_abap_objectdescr=>exporting.
    ls_parameter-value = lv_error.

    insert ls_parameter into table et_parameters.

  endmethod.

endclass.                    "lcl_test IMPLEMENTATION

Dieses Programm beweist, dass es durchaus möglich ist, Error Messages in Unit Tests abzufangen. Der beträchtliche Umfang dieses Testcodes für eine so einfache Sache wie das Auslösen einer Fehlermeldung ist allerdings ein untrüglicher "Code Smell" – in diesem Fall dafür, dass der message-Befehl an einem ungeeigneten Ort verwendet wird.

[1] Zitiert aus Greg Wilson, Andy Oram [Hg.]: Beautiful Code, O'Reilly, Sebastopol (CA), Juni 2007, S.279.

Eine objektorientierte Metasprache

2010-11-23T23:29:00.023+01:00

In Computerzeitschriften und Büchern über modellgetriebene Softwareentwicklung wird in jüngster Zeit häufig das Framework Xtext beschrieben und gepriesen — was vor allem dem Umstand zu verdanken ist, dass es für die Integration von Programmiersprachen in die Eclipse IDE verwendet wird.[1] Xtext (bzw. dessen zugrundeliegender Parsergenerator Antlr) ist ein leicht zu erlernendes Tool, um die Grundzüge der Entwicklung domänenspezifischer Sprachen kennenzulernen — gerade deshalb eignet es sich auch gut für den Einstieg in dieses Gebiet. Es gibt aber interessante Alternativen, die man zumindest kennen sollte.

Eine interessantere Option für zur Laufzeit pflegbare Modelle, für Codegenerierung wie auch für die Entwicklung von DSLs stellen in meinen Augen die sogenannten Parsing Expression Grammars (PEG) dar, insbesondere die von Alessandro Warth entwickelte objektorientierte Metasprache OMeta. Der Grundgedanke aller PEGs ist ein verallgemeinerter Begriff des Pattern Matching, wie es z.B. in regulären Ausdrücken verwendet wird. PEGs nutzen die Erkenntnis, dass alle üblicherweise mit dem Bau von Compilern und Interpretern verbundenen Aufgaben in gewisser Weise nur Varianten eines gemeinsamen Mechanismus sind - der Mustererkennung: [2]

Der Tokenizer (auch Lexer oder Scanner genannt) transformiert einen Array von Zeichen (die Eingabe, den Quelltext) in eine Folge von syntaktischen Grundeinheiten, die Tokens. Klassisch verwendet man hierzu ein Werkzeug wie lex oder dessen Weiterentwicklung Flex. Im Prinzip stellt ein Lex- oder Flexfile eine Liste von regulären Ausdrücken dar, die der Reihe nach auf die Eingabe angewendet werden, bis ein passender Ausdruck gefunden wird. Jedem regulären Ausdruck ist eine "Aktion" in Form von C-Code zugeordnet, die schliesslich mit der Rückgabe eines wohldefinierten Tokens mitsamt eines etwaigen Token-Arguments enden muss. Zur Illustration, wie ein solches Flexfile notiert wird, mag mein Flex-Definitionsfile apc_lexer.lex im Projekt astropatterns dienen.
Der Parser operiert auf dem Array von Tokens, um eine interne Datenstruktur zu erzeugen, die für die effiziente maschinelle Abarbeitung besonders gut geeignet ist. In der Regel ist das Ergebnis des Parsings ein abstrakter Syntaxbaum (AST). Auch das Parsing ist im Grunde Mustererkennung, nur auf einer höheren Ebene: Er arbeitet mit einer anderer Art "Alphabet", das aus terminalen und nichtterminalen Symbolen besteht, und die Muster sind die Syntaxregeln, die sogenannten Produktionsregeln. Parsergeneratoren haben eine lange Geschichte, in denen yacc (yet another compiler compiler) einen ersten Meilenstein darstellte. yacc, obwohl vor über 30 Jahren entwickelt, wird bis heute für den Entwurf von Programmiersprachen verwendet. Ich habe mit Bison, dem Nachfolger von yacc, eine astrologische DSL implementiert, die hier ebenfalls der Veranschaulichung dienen soll. Die Bison-Grammatik dieser DSL zeigt als strukturelle Ähnlichkeit, dass auch hier die Eingabe mit einer Reihe sogenannter Produktionsregeln verglichen wird. Wenn eine passende Regel gefunden wird, wird die zugeordnete semantische Aktion ausgeführt.
Type Checker und Optimierer sind Transformationen des AST, die bestimmte Muster erkennen und durch spezifischere oder effizientere Konstruktionen ersetzen. Da das Produkt des Parsers in der Regel ein Syntaxbaum ist, verwendet man häufig das Besucher-Entwurfsmuster, um den Baum zu traversieren und dabei je nach Anwendungsfall spezifische Operationen auszuführen.[3]
Das Gleiche gilt schliesslich für den Code Generator, der den AST in Programmquelltext oder Binärcode für einen Prozessor oder eine virtuelle Maschine transformiert. Auch hierfür werden an das Besuchermuster angelehnte Methoden verwendet, obwohl sich auch diese Aufgabe in Form einer Grammatik mit Produktionsregeln formulieren liesse.

Die Programmiersprache OMeta bietet einen Mechanismus, um all diese Aufgaben in Form einer PEG-Grammatik zu formulieren und zu lösen. Das Konzept ist so allgemein gehalten, dass im Prinzip beliebige Transformationen von Quelltexten und Datenstrukturen in andere Zielstrukturen möglich sind. Die OMeta-Syntax kann in verschiedene Hostsprachen eingebettet werden, es gibt z.B. OMeta-Implementierungen für Squeak, COLA (der ersten verwendeten Hostsprache – einer Mischung aus Scheme und Smalltalk), C#, JavaScript, Ruby u.v.a.m. – die Zahl der Implementierungen steigt. Besonders attraktiv finde ich dabei die Kooperation mit dynamischen Hostsprachen wie JavaScript oder Python. Denn die interpretierten Sprachen sind offenbar besonders gut gerüstet für die Vision der modellgetriebenen Softwareentwicklung, zur Laufzeit in einer domänenspezifischen Sprache das Systemverhalten steuern zu können. Die Sprache JavaScript hat darüberhinaus den zusätzlichen Vorteil, dass sie als "Standardsprache der Webbrowser" ohne Extrakosten in Webanwendungen verfügbar ist. Weil ich die Sprache OMeta so wichtig finde, habe ich auf meiner Homepage eine Oberfläche zum Experimentieren unter dem Link

http://ruediger-plantiko.net/ometa/

bereitgestellt. Sie ist ähnlich der auf http://tinlizzie.org bereitgestellten Seite, trennt jedoch klarer den Grammatik-Definitionsteil von der Ausführung des daraus generierten Parsers.

OMeta ist, wie es der Name sagt, eine objektorientierte Metasprache, die viele interessante Features aufweist:

Die Eingabe von OMeta muss nicht als Quelltext oder überhaupt als Zeichenfolge vorliegen, sondern kann ein Array von beliebigen Objekten der Hostsprache sein. Das ermöglicht z.B. auch die Transformation von abstrakten Syntaxbäumen. Denn jeder Syntaxbaum ist i.w. als eventuell verschachtelte Folge von Arrays, Tokens und Objekten darstellbar. Das JavaScript-Statement
```
document.getElementById("btnSave").click();
```
könnte z.B. durch folgenden AST dargestellt werden:
```
[ APPLY, 
    [ APPLY, document, "getElementById", ["btnSave" ] ], 
    "click", [] ]
```
Das ist, formal gesehen, ein Array, der aus Objekten besteht - nämlich wiederum aus Arrays, aus Symbolen wie APPLY (die z.B. auch als Strings realisierbar wären), aus gewöhnlichen JavaScript-Objekten der Hostsprache, wie hier dem DOM-Objekt document, und Datentypen wie Strings, Zahlen, usw.[4] In dieser Form könnte der AST wiederum einem OMeta-Programm zur Verarbeitung vorgelegt werden.

Objektorientierung erlaubt die Trennung von Produktionsregeln in verschiedenen Namensräumen. So ist jede Grammatik frei in ihrer Namenswahl für die verwendeten Symbole, unbeeinflusst durch eventuell bereits im selben Prozess bestehende Grammatiken. Ausnahme ist natürlich der explizit gewünschte Bezug auf eine bestehende Grammatik durch den Vererbungsmechanismus. Es ist möglich, eine OMeta-Grammatik von einer anderen erben zu lassen und sich in der Formulierung der Produktionsregeln auf die Regeln der Superklasse zu beziehen. Das erlaubt es, bestehende Parser, z.B. den notwendigerweise existierenden Parser der Hostsprache, mit wenigen Codezeilen um eigene Konstrukte zu erweitern. Dadurch ist OMeta ein ideales Werkzeug für Entwickler von Programmiersprachen, um neue syntaktische Idiome auszuprobieren.

Im Gegensatz zu kontextfreien Grammatiken (CFG) ist der Auswahloperator | in einer PEG nichtdeterministisch: Es ist ein priorisierter, "kurzschliessender" Operator, dessen Evaluation bei der ersten passenden Alternative abgebrochen wird. Das kann als Nachteil angesehen werden, da die "veroderten" Operanden dadurch nicht mehr gleichberechtigt sind. Andererseits ist es auch ein Vorteil, da die Interpretation eines priosierten Auswahloperators keine Mehrdeutigkeiten produziert, wodurch die PEGs einfacher nachvollziehbar werden.

Das letztgenannte Feature des priorisierten Auswahloperators bringt üblicherweise das Problem von Endlosschleifen für linksrekursive Regeln mit sich. Die Regel
```
expr = expr "-" number | number
```
zur Definition von Subtraktions-Ausdrücken kann in einer herkömmlichen PEG nicht ausgewertet werden: Um diese Regel zu erkennen, wird zuerst der linke Teil der Alternative ausprobiert; hierzu muss wiederum die Erkennung von expr ausgeführt werden usw. Das führt zu einem unendlichen Abstieg. In komplizierteren Fällen bildet sich ein geschlossener Zykel aus mehreren voneinander abhängigen Regeln, die sogenannte indirekte Linksrekursion.

Nun lassen sich alle Regeln, die auf das Problem der Linksrekursion stossen, von Hand so umschreiben, dass die Linksrekursion nicht mehr auftritt. Aber die Ausdrücke werden dadurch umständlicher und sind nicht mehr so leicht nachvollziehen. Aus Sicht eines Grammatik-Entwicklers ist es eine unnötige Komplikation, in seiner Grammatik Linksrekursionen vermeiden zu müssen.

Nun ist es Alessandro Warth mit OMeta gelungen, dieses Problem zu lösen. In OMeta kann man auch linksrekursive Regeln wie die obige notieren. Die Effizienz leidet darunter nicht wesentlich - die Parsezeiten hängen in der Regel weiterhin linear von der Länge des Inputs ab. Die Möglichkeit rekursiver Regeldefinitionen erhöht die Ausdruckskraft von OMeta in der Verwendung als alternative PEG-Implementierungen.

OMeta erlaubt die Definition sogenannter parametrisierter Regeln. Das sind, wie der Name sagt, Regeln, die von Parametern abhängen. Warth erläutert dieses Idiom anhand einer Regel für Zeichenmengen. Zeichenmengen kann man traditionell durch den Auswahloperator definieren. Wenn es die eingebaute Regel digit für die Erkennung von Ziffern in OMeta nicht schon gäbe, könnte man sie so definieren:
```
digit = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 
```
Solche Regeln sind fehleranfällig und langsam in der Ausführung. Hier helfen parametrisierte Regeln wie die folgende (die überdies zeigt, dass auch in parametrisierten Regeln sogenannte semantische Aktionen angegeben werden können, wie hier die Rückgabe des erkannten Zeichens):
```
charRange :x :y = char:c ?(x <= c && c <= y) -> c
```
Ist die Regel charRange einmal erklärt, kann sie in weiteren "konkreten" Regeln wiederverwendet werden:
```
digit     = charRange('0','9'),
lowerCase = charRange('a','z'),
upperCase = charRange('A','Z')
```
Das Beispiel lässt erkennen, dass die parametrisierten Regeln eine höhere Abstraktionsebene einführen. Wie Vererbung erlauben sie eine "Oben-Unten-Trennung", eine Trennung des Allgemeinen vom Konkreten.

Wie um dies noch zu überbieten, unterstützt OMeta sogar Regeln höherer Ordnung: Das sind Regeln, die andere Regeln als Argument haben! Dieses Feature wird möglich durch eine Kombination der parametrisierten Regeln mit einer speziellen eingebauten Regel namens apply. apply nimmt den Namen einer Regel entgegen und führt diese aus. Als sinnvolles, praktisches Beispiel gibt Warth folgende OMeta-Regel:
```
listOf :p = apply(p) ( "," apply(p) )*
```
Diese Regel erkennt ein oder mehrere, durch Komma getrennte Vorkommen von "etwas, das der Regel p genügt". Beispielsweise erkennt der Term
```
listOf('expression')
```
eine mit Kommas getrennte Liste von Ausdrücken (die einer früher definierten Regel expression genügen), während
```
listOf('name')
```
auf eine Liste von Namen (die der früher definierten Regel name genügen) passt.

Ich kann hier nicht die gesamte Sprache OMeta erläutern, sondern nur zu ihrem Studium anregen. Die obigen Erklärungen fassen wesentliche Teile von Warths Dissertation zusammen. Wer mehr erfahren will, sei auf http://www.tinlizzie.org/ometa/ verwiesen.

Immerhin will ich noch ein kleines, in der Szene der "Compilerbauer" beliebtes Beispiel vorführen: einen "Tischrechner". Dieser konkrete Tischrechner kann sogar mit Variablen arbeiten, was nebenbei beweist, dass man mit OMeta auch zustandsbehaftete Parser bauen kann. Auf meiner Testseite erreicht man seine Definition durch Auswahl von Calculator in der Liste der verfügbaren Grammatiken. Auch dieses Beispiel ist der Dissertation von Warth entnommen. Ich will es hier kurz diskutieren.

Mit der ersten Zeile

ometa Calc <: Parser {

wird eine neue Grammatik (eine neue Transformation, ein neuer Parser, ein neues OMeta-Objekt) deklariert. In diesem Fall soll es von der eingebauten Grammatik Parser erben. Diese eingebaute Klasse enthält aktuell nur eine einzige grundlegende Parser-Funktionalität – nämlich eine token-Regel, mit der durch Leerzeichen getrennte Strings erkannt werden können. Diese token-Regel wird in allen von Parser erbenden Grammatikdefinitionen automatisch den in Doppelhochkommata eingeschlossenen Strings unterlegt. Mehr bekommt man durch diese Vererbung nicht.

Die nächste Zeile

var           = spaces letter:x             -> x,

zeigt die typische Syntax einer Produktionsregel in OMeta. Dem Namen der Regel folgt nach einem Gleichheitszeichen ihre Definition, und nach der Definition kann, mit einem Pfeil -> abgetrennt, eine semantische Aktion angegeben werden. Eine semantische Aktion ist im Code der Hostsprache notiert und wird für ein erkanntes Muster evaluiert. Das Ergebnis der Evaluation ist auch der Rückgabewert der sogenannten matchAll()-Methode, mit der man schliesslich den Parser aufrufen kann.

In diesem Fall haben wir eine Regel var zur Erkennung von Variablennamen. Zunächst wird festgelegt, dass Leerzeichen unmittelbar vor einem Variablennamen ignoriert werden sollen. Dies erreicht man mit der eingebauten Regel spaces, die "Null oder mehr Leerzeichen" erkennt. Danach folgt die eigentliche Festlegung, was als Variable erkannt werden soll: Variablen sollen in unserem Tischrechner einbuchstabig sein. Hierzu benutzen wir die eingebaute OMeta-Basisregel letter. Nach dem Doppelpunkt folgt nun ein Variablenname, der bei erfolgreicher Anwendung der Regel das Evaluationsergebnis der semantischen Aktion enthält (oder, wenn keine semantische Aktion ist, den als passend erkannten Teil der Eingabe). Auf diese Variablen, die während des Parsens zugewiesen werden, kann man dann in der semantischen Aktion zurückgreifen – wie hier. Wir legen fest, dass der Rückgabewert der Regel genau der erkannte Buchstabe ist.

Eine einfachere, völlig äquivalente Formulierung wäre übrigens

var           = spaces letter

Aber wir wollen ja schliesslich lernen, wie OMeta funktioniert, und dafür ist die erste Variante besser geeignet.

Nach den Variablen legt die folgende Regel die erlaubten Zahlen fest - positive, ganze Zahlen:

num           = num:n digit:d        -> (n*10 + d*1)
              | digit:d              -> (d*1),

Hier ist neu der Gebrauch des Auswahloperators | für die Deklaration der Alternativen. Ausserdem lernen wir, dass auch Teilen einer Regel bereits eine semantische Aktion zugeordnet werden darf. Der erste Teil der Regel enthält darüberhinaus die bereits besprochene Linksrekursion.

Diese Regel hätte man äquivalent auch so schreiben können:

num           = digit+:d        -> (1*d.join('')),

Neu ist hier der Quantifier + mit derselben Semantik wie in regulären Ausdrücken. Ein mit dem Quantifier + oder * angereicherter Ausdrucks evaluiert immer zu einem Array mit den einzelnen Treffern als Elementen. Den Array können wir in der semantischen Aktion mittels der Methode join() der JavaScript-Klasse Array zu einem String zusammenspleissen und schliesslich durch Multiplikation mit 1 (type coercion) die Umwandlung in den numerischen Datentyp erzwingen. Auch diese Variante der Regel num ist sicher lehrreich.

Es folgen nun die primären Ausdrücke: Die Eingabe eines Variablennamens soll deren Inhalt zurückliefern, die Eingabe eines Zahlenstrings soll ebendiese Zahl zur Antwort haben, und komplexere Ausdrücke sollen geklammert werden können:

primaryExpr   = spaces var:x         -> self.vars[x]
              | spaces num:n         -> n
              | "(" expr:r ")"       -> r,

Neu ist hier der Zugriff auf die Variable self.vars, die in einer speziellen, bei der Parserinstanziierung aufgerufenen sogenannten initialize()-Methode als leerer Hash definiert wird und uns als Container (genauer: als Symboltabelle) für die im Tischrechner eingegebenen Variableninhalte dient.

Es kommen nun die Multiplikations- und Additionsregeln:

mulExpr       = mulExpr:x "*" primaryExpr:y -> ( x * y )
              | mulExpr:x "/" primaryExpr:y -> ( x / y )
              | primaryExpr,
addExpr       = addExpr:x "+" mulExpr:y     -> ( x + y )
              | addExpr:x "-" mulExpr:y     -> ( x - y )
              | mulExpr,

Wir benutzen hierbei die Eigenschaft, dass der Auswahloperator priorisierend ist, um der Punktrechnung vor der Strichrechnung den Vorzug zu geben: Es werden immer zuerst die mulExpr erkannt (und evaluiert), bevor ein addExpr erkannt wird. Nicht ganz dem entsprechend, was der Name suggeriert, subsumiert die Regel addExpr insbesondere auch den mulExpr (dritte Alternation der Regel für additive Ausdrücke). Auf der rechten Seite stehen wieder die semantische Aktionen - in den Klammern kann beliebiger JavaScript-Code codiert sein.

Die addExpr ist somit allgemeiner als mulExpr und allgemeiner als die primaryExpr. Sie enthält letztere als Spezialfälle. Mit der folgenden Regel

expr          = var:x  "=" expr:r           -> (self.vars[x] = r)
                | addExpr,

umfassen wir somit alle für den Tischrechner gültigen Ausdrücke. Variablenzuweisungen ebenso wie arithmetische Ausdrücke (die auch wieder Variablen enthalten dürfen).

Die letzte Regel doit legt fest, dass soviele Ausdrücke wie möglich evaluiert werden sollen, und schliesslich das Ergebnis des letzten gültigen Ausdrucks ausgegeben werden soll.

doit          = (expr:r)* spaces end        -> r

Hier folgt noch - ausserhalb der OMeta-Grammatik, die bereits erwähnte initialize()-Methode, mit der der Rechner in den Startzustand versetzt wird:

Calc.initialize = function() {  this.vars = {}; }

In meiner "Workbench" kann ich nun die Regel doit auf die Eingabe

x=1 y=2 x+y

anwenden und erhalte die Ausgabe 3. Das liegt daran, dass die doit-Regel mehrere, durch Leerraum getrennte Ausdrücke erkennt und auswertet. Ich hätte aber auch drei Eingaben nacheinander tätigen können: Zuerst

x=1

danach

y=2

und schliesslich

x+y

Auch dann hätte ich die Ausgabe 3 erhalten. Der Grund ist, dass meine "Workbench" in jedem Dialogschritt mit derselben Parserinstanz arbeitet und sich daher alle bereits erfolgten Variablenzuweisungen in der Symboltabelle vars gemerkt hat. Es ist eben ein stateful parser – und mit dieser Eigenschaft ist OMeta auch für REPL Shells verwendbar (read-evaluate-print loops).

Wer mag, kann sich auf meiner OMeta-Workbench auch meinen in OMeta implementierten XML-Parser anschauen: Ein meiner Ansicht nach durchaus lesbarer Quelltext von nur 42 Zeilen erlaubt die Transformation eines XML-Dokuments in einen in JavaScript modellierten Objektbaum. Das sind die Grössen, mit denen man in OMeta arbeiten kann; es ist auch eine der Fragestellungen, mit denen das Viewpoints Research Institute angetreten ist, unter dessen Dach auch OMeta entwickelt wurde: Um wieviele Zehnerpotenzen kann bestehender Programmquelltext bei Einsatz geeigneter, möglichst ausdrucksstarker Programmierumgebungen gekürzt werden, um dennoch das zu erreichen, wozu man heute Computer einsetzt (Textverarbeitung, Graphik, Internet usw.)?

Dies möge als ein erster Einblick in einen hochinteressanten Parsergenerator genügen, den ich zum näheren Studium nur empfehlen kann. Die Einsatzfelder, rund um den Bereich domänenspezifischer Sprachen (DSL) scheinen mir sehr vielversprechend zu sein. Die Sprache ist kompakt und ausdrucksstark. Ihren mächtigen Features, wie etwa der Objektorientierung, den parametrisierten Regeln und der Rekursion, ist es zu verdanken, dass Grammatiken wesentlich eleganter notiert werden können als in früheren Werkzeuge dieser Art.

[1] So in Thomas Stahl, Markus Völter, Sven Efftinge, Arno Haase: Modellgetriebene Software-Entwicklung, 2. Auflage, dpunkt Verlag, Heidelberg 2007.
Jan Köhnlein und Sebastian Zarnekow, Xtext-Praxis, eclipse-Magazin 1.2010, S. 50.
[2] Die folgenden Ideen sind der Dissertation von Alessandro Warth Experimenting with Programming Languages entnommen.
[3] Es geht jedoch auch ohne das Besucher-Entwurfsmuster, das leider intrusiv ist und dem in der Umsetzung eine gewisse Schwerfälligkeit anhaftet (wie ich in meinem Blog gezeigt habe).
[4] Dabei wird die Anwendung einer Methode m des Objekts o mit dem Argument-Array [args...] durch das Konstrukt [APPLY, o, m, [args...]] modelliert.

Eine Erfolgsgeschichte mit Simple Transformations

2010-10-28T07:45:00.021+01:00

Simple Transformations (ST) sind eine wunderbare und effiziente Möglichkeit, ABAP-Daten in XML-Dokumente und zurück zu transformieren. Sie sind vom Konzept her bidirektional, somit ideal für die Serialisierung und Deserialisierung geeignet – und ausserdem sind sie, wie wir beobachten konnten, hocheffizient. Wenn man sich einmal in das Konzept eingearbeitet hat, sind sie darüberhinaus wirklich simple, wie es der Name verheisst, also einfach in der Implementierung.

Dank der Simple Transformations ist es uns gelungen, eine unzuverlässige Komponente unseres XI-Systems (den JDBC-Adapter) durch einen stabil laufenden, in ABAP programmierten Adapter zu ersetzen, der über seine Arbeit im Joblog genau Rechenschaft gibt und obendrein einen deutlich besseren Durchsatz hat als die bisherige Lösung.

Wir haben eine entfernte Datenbank, in die im Laufe des Tages aus verschiedenen Quellen immer wieder neue "Meldungen" eingespeist werden (Wert- und Warenflüsse). Um diese einzulesen und den Java-Mappingklassen zur weiteren Verarbeitung zuzuführen, haben wir bislang den von SAP mitgelieferten sogenannten JDBC-Adapter verwendet, der gemäss Beschreibung genau für eine solche Aufgabe geeignet wäre. Leider hat dieser Adapter (in unserem System) eine Schwachstelle, die sich trotz intensiver Bemühungen nicht beheben liess – er leidet gewissermassen unter Narkolepsie: Ganz unvermittelt stellt er immer wieder mal seine Arbeit komplett ein – ohne noch irgendein Lebenszeichen von sich zu geben, aber auch ohne dass der Prozess abbricht, geschieht mitten in einer Verarbeitung einfach nichts mehr.

Da die eingehenden Meldungen zeitkritisch sind, führte dies immer wieder zu extra Wartungsaufwand. Es mussten Überwachungsprogramme geschrieben werden, um die fristgerechte Abarbeitung der Meldungen zu garantieren. Zur Unzeit (so etwas passiert immer zur Unzeit!) wurde unser Support mit Alarm-SMS aus dem Bett geholt, weil es wieder einmal passiert war. Der manuelle Workaround, um den JDBC-Adapter wieder zum Laufen zu bekommen, bestand dann darin, einen zweiten, identisch konfigurierten Kanal zu definieren und auf diesen zu wechseln.

Der JDBC-Adapter ist für uns leider eine "Black Box". Das ist das Problematische an den von SAP ausgelieferten Java-Komponenten (nicht an der Sprache Java selbst – die Sprache Java ist grossartig). Wir können die SAP-Java-Komponenten nicht wie ein ABAP-Programm studieren, um unsere eigenen Schlussfolgerungen zu ziehen.[1] Wir können auch keine Fangschaltung einbauen, um diesen spontan auftretenden Fehler näher zu lokalisieren. Wir sind gezwungen, jedes Problem an den Support von SAP zu addressieren. SAP selbst hatte keine Antwort auf unser Problem und musste die OSS-Meldungen schliessen, da das Problem ja nicht reproduzierbar ist.

Wir haben uns daher dazu entschlossen, diesen JDBC-Adapter aus dem XI-Eingangsprozess zu eliminieren und durch eine in ABAP programmierte Komponente zu ersetzen, die letztlich den sogenannten Plain Adapter verwendet. Das ist ein vom ABAP-seitigen ICF angesprochener REST-artiger HTTP-Service (zu erreichen unter /sap/xi/adapter_plain). Im Body der HTTP-Anfrage erwartet der Plain Adapter das XML-Dokument in der Form, wie es schliesslich vom XI-Mapping verarbeitet wird. Er reicht dieses Dokument dann an die XI-Mappingschicht weiter.

Die eigenprogrammierte Komponente ist ein in regelmässigen Abständen gestarteter Job, der

die Daten aus der entfernten Datenbank in interne Tabellen einliest,
die ABAP-Daten in ein XML-Dokument transformiert – dies ist der Ort, an dem die Simple Transformations zum Einsatz kommen – und
das XML-Dokument schliesslich über einen "internen" HTTP-Request an den Plain Adapter weiterleitet.[2]

In einem (typischen) Joblauf wurden 403 Meldungen mit insgesamt 125.254 Meldungspositionen in 123 Sekunden verarbeitet. Das bedeutet einen Durchsatz von rund 1 Millisekunde pro Position. Hierin enthalten ist das Lesen der Position von der Datenbank, die Abbildung der Meldungen in ein XML-Dokument und schliesslich die Verarbeitung im "Plain Adapter". Das sind wunderbare Laufzeiten!

Die folgende Graphik zeigt, wie sich die Laufzeit für einen typischen Joblauf auf diese Schritte verteilt:

Für das Marshalling, also die Konvertierung der ABAP-Daten in ein XML-Dokument, wurden nur 12 der 125 Sekunden benötigt. Die XML-Konvertierung, einschliesslich eines Prepare-Schritts in ABAP, in dem die Daten für die Transformation passend aufbereitet werden, schafft also 10 Detailsätze pro Millisekunde. Das ist mehr als zufriedenstellend.

Es ist sinnvoll, vor dem eigentlichen Aufruf der ST einen vorbereitenden Schritt zu implementieren, in dem die Daten für den Zugriff der ST passend aufbereitet werden. Simple Transformations sind nicht nur einfach zu verstehen, sie sollten auch einfach konzipiert werden. Denn je simpler eine Simple Transformation gerät, desto effizienter wird sie auch. Im vorliegenden Fall erzeugt die ST eine Sequenz von Elementen ("Zeilen"), die jeweils Daten aus Kopf und Position enthalten. Die passende Datenstruktur hierfür ist eine interne Tabelle mit einem tiefen Zeilentyp: Jede Zeile steht für eine Meldung, und die Komponente detail der Zeile ist selbst eine interene Tabelle, die die Positionen enthält. Bei geschachtelten Strukturen ist auf den erhöhten Speicherbedarf zu achten. Eine überschlägige Rechnung zeigte uns aber, dass der Hauptspeicher für das benötigte Datenvolumen auch für sehr grosse Meldungen noch ausreicht. Ausserdem handelt es sich ja nur um eine Hilfstabelle mit extrem kurzer Lebensdauer - sie lebt als lokales Feld "auf dem Stack" und wird genau in der Methode auf- und abgebaut, die die Simple Transformation durchführt: [3]

* Header/Detail in Tabelle mit tiefer Zeilenstruktur abbilden
  loop at it_header assigning <ls_header>.

    clear ls_meldung.
    move-corresponding <ls_header> to ls_meldung.

    loop at it_detail assigning <ls_detail>
         where  absender            = <ls_header>-absender and
                meldungs_id         = <ls_header>-meldungs_id and
                meldungs_datum      = <ls_header>-meldungs_datum and
                partition_knoten    = <ls_header>-partition_knoten and
                partition_tag       = <ls_header>-partition_tag.
      insert <ls_detail> into table ls_meldung-detail.
    endloop.

    insert ls_meldung into table lt_meldungen.

  endloop.

Der Aufruf der Transformation ist dann sehr einfach:

* Meldungsspezifisch in XML transformieren
  call transformation (gv_transformation)
    source meldungen = lt_meldungen
    result xml ev_xml.

Die Transformation wird dynamisch aufgerufen, wir haben für jeden Meldungstyp eine andere Simple Transformation. Die zuvor aufbereitete Meldungstabelle wird nun als source übergeben - das Resultatdokument wird im Parameter ev_xml vom Typ xstring entgegengenommen (es könnte auch ein string oder ein Objekt vom Typ if_ixml_document sein - die Transformation erkennt selbständig den erwarteten Typ).

Die Simple Transformation selbst ist nun wirklich einfach: Nach Festlegung des Referenz-Datenobjekts mittels <tt:root> werden die Meldungen mit einer geschachtelten <tt:loop> abgearbeitet. In der inneren Loop wird schliesslich die Ergebniszeile hergestellt, indem die entsprechenden Quellfelder aus Meldungskopf oder Meldungsposition in das durch das Mapping gewünschte Zielfeld übernommen werden.

Hier ein typisches Beispiel (wir haben rund ein Dutzend solcher Transformationen, und sie sehen alle ähnlich aus):

<?sap.transform.simple?>
<!-- Automatisch generierte Transformation. 
     Bitte Anpassungen nur an der Vorlage machen 
     (XSLT-Transformation ZGDBW_TO_XI_CREATE)-->
<tt:transform xmlns:tt="http://www.sap.com/transformation-templates">
  <tt:root name="MELDUNGEN"/>
  <tt:template>
    <ns:MT_MVN_DESADV2500 xmlns:ns="http://migros.ch/xi/DESADV2500">
      <tt:loop ref=".MELDUNGEN" name="header">
        <tt:loop ref="DETAIL">
          <row>
            <ABSENDER>
            <tt:value ref="$header.ABSENDER"/>
            </ABSENDER>
            <MELDUNGS_ID>
            <tt:value ref="$header.MELDUNGS_ID"/>
            </MELDUNGS_ID>
            (... weitere Kopffelder ...)
            <FELD_1 >
              <tt:value ref="FELD_1 "/>
            </FELD_1 >
            (... weitere Detailfelder ...)
          </row>
        </tt:loop>
      </tt:loop>
    </ns:MT_MVN_DESADV2500>
  </tt:template>
</tt:transform>

Was heisst hier "automatisch generiert"? Ein weiterer starker Vorteil der Simple Transformations (ebenso wie der XSLT-Transformationen) ist, dass es ein einfach zu bedienendes API zum Erstellen einer Transformation im Repository gibt - die Klasse CL_O2_API_XSLTDESC. Dies kam uns in unserer Situation sehr entgegen: Dinge wie der Namensraum des Zieldokuments und die tatsächlich zu extrahierenden Felder variieren nämlich je nach Meldungstyp. Wir haben daher eine simple Customizingtabelle vorgesehen, in der wir pro Meldungstyp diese Unterschiede festlegen. Ein Report Z_REGENERATE_ST baut aus dieser Customizingtabelle alle vorgesehenen ST-Transformationen auf (wobei er sich selbst einer XSLT-Transformation bedient). Diese werden dann dynamisch aufgerufen. Dieses Vorgehen hat den Vorteil, dass die Transformationen möglichst einfach und sehr schnell werden. Ausserdem hat eine im Repository gepflegte Transformation den Vorteil, dass sie bei Gebrauch im Hauptspeicher des Servers gepuffert wird - was ihre Ausführung noch mehr beschleunigt.

[1] Zwar gibt es neben dem Disassembler javap hervorragende Java-Decompiler mit begeisternden Benutzerschnittstellen, wie z.B. jd-gui. Es ist aber umständlich, ein Programm erst decompilieren zu müssen, um seine Logik zu verstehen und ggf. zu modifizieren. Bei der in der Branche zunehmenden Kleingeistigkeit ist ausserdem vermehrt mit dem Einsatz von Bytecode-Verdunklern (Obfuskatoren) zu rechnen, die die Lesbarkeit des decompilierten Codes weiter erschweren.

[2] Das geschieht mittels eines internen HTTP-Requests - d.h. der Baustein HTTP_DISPATCH_REQUEST erscheint im eigenen Callstack, der Request wird nicht in einem separaten Task bearbeitet. Insbesondere ist die Verarbeitung der Requests somit notwendigerweise synchron: Wenn der Job durchgelaufen ist, haben sämtliche Meldungen den Plain Adapter passiert.

[3] Wir haben hier eine Loop über eine Tabelle mit N Eintragen, die eine Loop über eine zweite Tabelle mit N*M Einträgen enthält. Das könnte ein Problem ergeben. Damit hier keine quadratischen Effekte auftreten, darf die Positionstabelle keine Standardtabelle sein. In unserem Fall sind beide Tabellen sortiert. Die innere Loop mit Where-Bedingung nutzt implizit die Sortierordnung gemäss Tabellenschlüssel aus, so dass kein Performanceproblem entsteht. Eine - noch etwas effizientere - Alternative wäre gewesen, mit der loop at it_detail zu beginnen (ohne Where-Bedingung) und mittels at new die Kopfdaten beim Wechsel zu einer neuen Meldung nachzulesen. Aber, wie man an den Laufzeiten sieht, ist der "Marshalling Prepare" Schritt auch in dieser Form unkritisch.

Tabellenpflege als Webanwendung

2010-10-09T23:06:00.006+01:00

Die Situation ist elementar und kommt häufig vor: Irgendwelche tabellenförmigen Daten – zum Beispiel die Buchungen eines Kontos – sollen mit Hilfe eine Webanwendung gepflegt werden. Trotzdem habe ich nach einer ersten Sichtung keine passende Software für diesen allereinfachsten Anwendungsfall gefunden.[1]

Hier zeige ich eine Implementierung für die Pflegeoberfläche mit JavaScript, die die gesamte Änderungsverwaltung auf dem Client übernimmt. Die Applikation besteht aus einer einzigen Webseite, die weder verlassen noch neu geladen wird. Sie kommuniziert intern über Ajax-Requests mit dem Server, der die Daten anliefert und Änderungen fortschreibt.

Im einzelnen muss eine Anwendung zur Tabellenpflege

die Tabellendaten vom Server lesen,
dem Benutzer zur Ansicht und Pflege anbieten,
der Zellen verändern, ganze Zeilen löschen oder neue Zeilen hinzufügen kann
und schliesslich diese Änderungen sichern kann,
wodurch sie auf den Server zurückgeschrieben werden.

Wie ist eine solche Anwendung zu entwerfen? Sicher einmal benötigt man ein physisches Bild der Tabelle, das irgendwo im Filesystem hinterlegt sein muss. Auf der anderen Seite bedarf es einer Präsentationsschicht (GUI), um die Tabelle dem Benutzer anzuzeigen und ihm Änderungen anzubieten. Für Webanwendungen besteht die Präsentationsschicht in der Regel aus HTML-Seiten.

Zwischen diesen beiden Endpunkten – GUI und Filesystem – liegen im wesentlichen zwei Softwarekomponenten, die bei einer solchen Anwendung zusammenarbeiten: Eine Persistenzkomponente, die dafür zuständig ist, dass die Daten über die Sitzung des Benutzers hinaus existieren. Und eine Änderungsverwaltung, die die Änderungen des Benutzers protokolliert und zu einem vom Benutzer gewählten Zeitpunkt an die Persistenzkomponente übergibt.

An den Jargon der Datenbankprogrammierer angelehnt, liegt die Tabelle in der Anwendung in zwei Formen vor: Als Before-Image repräsentiert sie den Stand der Daten, bevor der Benutzer sie zu Gesicht bekommt und manipulieren kann (mit dem Image ist das Pflegebild gemeint, auf dem der Benutzer die Daten ändern kann). Das After-Image modelliert folglich die Änderungen, die der Benutzer an den Daten vorgenommen hat. Aus dem Vergleich des Before-Image mit dem After-Image ist eine Reihe von insert-, update- und delete-Operationen ableitbar, die an der Tabelle vorgenommen werden müssen.

Wenn die Tabelle vom Server kommt, stellt sie das Before-Image dar. Diese Daten muss der Client in einer Form präsentieren, die dem Benutzer leicht Änderungen ermöglicht. Neben der Präsentation verwaltet der Client auch die vom Benutzer getätigten Änderungen. Der Client weiss jederzeit, ob und welche Änderungen vorgenommen wurden. Nur wenn wirklich Änderungen vorgenommen wurden, braucht man dem Benutzer einen Sichern-Button anzubieten, mit dem er die gerade getätigten Änderungen "committen", das heisst in der Persistenzschicht fortschreiben kann.

Hier meine Beispiel-Implementierung [2]:

http://www.ruediger-plantiko.net/konto

Die Anwendung besteht aus einer einzigen HTML-Seite. Clientseitige Logik ist mit JavaScript abgebildet. Die Kommunikation mit dem Server erfolgt über Ajax, wobei als Struktur für den Datenaustausch in beide Richtungen das JavaScript-Datenformat JSON verwendet wird. Die HTML-Seite wird mittels JavaScript dynamisch manipuliert. Auf Serverseite nimmt ein Perl-Programm unter CGI die Anfrage entgegen, wobei ein Query-Parameter names action dem Server mitteilt, was er machen soll. Beispielsweise teilt die URL

/cgi-bin/konto.pl?action=get_all

dem Programm konto.pl mit, dass es alle Buchungszeilen aus der Kontodatei einlesen und dem Client im JSON-Format senden soll. Dagegen teilt eine zweite action namens save

/cgi-bin/konto.pl?action=save

dem Server mit, dass sich im Bauch des HTTP-Requests ein JSON-Hash mit Zeilendaten befindet, die in der Kontodatei aktualisiert werden sollen. Er verbucht diese Änderungen und sendet dann dem Client wie bei get_all das aktualisierte Bild der Datei (wieder im JSON-Format). Nur diese beiden actions werden übrigens benötigt.

Die beiden Schichten kommunizieren nur über diese Schnittstelle und sind ansonsten völlig unabhängig voneinander. Das heisst beispielsweise: Statt mit Perl unter CGI könnte man den Request auch mit einer beliebigen anderen Technologie behandeln. In meiner Implementierung ist der Schnitt zwischen den Systemen zugleich auch der Schnitt zwischen den beiden erwähnten Softwarekomponenten: Der Server verwaltet die Persistenzschicht, während die Verwaltung der Änderungen auf dem Client erfolgt.

Zu den Besonderheiten dieser Implementierung gehört, dass die Daten auf dem Client nur in der dynamischen Tabelle buchungen gehalten werden - das ist genau die Tabelle, die der Benutzer sieht. Es gibt kein Extrabild dieser Daten, etwa in Form eines globalen Arrays. Ähnlich ist es mit der Änderungsverwaltung: Es gibt kein globales Flag dataLoss. Wenn der Benutzer Änderungen vornimmt, werden diese für ihn sichtbar in der Tabelle als geändert markiert. Es gibt kein globales Flag, wohl aber eine Funktion dataLoss(), die einfach schaut, ob Zellen als geändert markiert sind.

Aber fangen wir mit dem Datenformat an. Ich habe mir der Einfachheit ein CSV-artiges Format ausgedacht. Man kann Kommentarzeilen und Leerzeilen verwenden. Diese bleiben bei Updates erhalten und werden im übrigen ignoriert. Kommentarzeilen beginnen wie in Perl mit dem Doppelkreuz (#). Ausserdem soll es neben den Buchungszeilen noch andere Zeilen in der Datei geben, die manuell oder von einem anderen Programm eingefügt werden könnten. Beispielsweise könnte ein Cron-Job regelmässig den Kontostand abfragen und als realen Saldo in die Datei einfügen. Unser Programm soll all diese Zeilen reproduzieren, aber für die eigene Verarbeitung ignorieren.

Das lässt sich so einrichten, dass die erste Spalte im CSV-Format eine ID des Satzes darstellt. Diese ID kann für die allein zu berücksichtigenden Buchungszeilen das Präfix buch haben, während andere Zeilen andere Präfixe haben. Saldozeilen zum Beispiel könnten mit dem Präfix saldo eingeleitete ID's haben. Die Datei kann also etwa folgendermassen aussehen:

# Abhebungen
buch1;1.09.2010;150.00;Norbert;Kursgebühr "Modernes JavaScript"
buch2;10.9.2010;605.00;Petra;Flug nach Florenz, Mietauto, Übernachtung 
buch3;23.9.2010;200.00;Norbert;Spende an Wikipedia
saldo1;30.9.2010;15362.00
buch4;3.10.2010;350.00;Petra;Neues Smartphone

Wenn die Tabellenpflege nach Anmeldung im Web aufgerufen wird, erhält die zuständige Perl-Klasse CsvTableMaintainer den Befehl zum Laden aller Buchungszeilen (action=get_all). Die obige Beispieldatei wird dabei in folgendes JSON-Objekt transformiert:

{ buchungen:[
    ["buch1","1.09.2010","150.00","Norbert","Kursgebühr \"Modernes JavaScript\""],
    ["buch2","10.9.2010","605.00","Petra","Flug nach Florenz, Mietauto, Übernachtung "],
    ["buch3","23.9.2010","200.00","Norbert","Spende an Wikipedia"],
    ["buch4","3.10.2010","350.00","Petra","Neues Smartphone"]
    ], 
    user:"petra", 
    msg:"" 
    }

Dieser Hash wird nun im Browser von der JavaScript-Funktion updatePage() entgegengenommen. Diese überträgt zunächst den User, unter dem die Anmeldung erfolgte, in ein dafür vorgesehenes Feld (wenn es nicht angezeigt werden soll, kann man dieses Feld auf unsichtbar setzen). Für jedes weitere Element des Hashs wird eine Funktion <key>_update(<value>) aufgerufen, wobei <key> den Schlüssel und <value> den Wert zu diesem Eintrag bedeutet — falls eine Funktion dieses Namens existiert. Wenn nicht, wird <key> einfach als ID eines Elements im HTML-DOM betrachtet, dessen Inhalt durch <value> zu ersetzen ist. Schliesslich wird noch die Sanduhr-Graphik auf unsichtbar geschaltet, die dem Benutzer die Server-Aktivität anzeigte:

// --- Nach Rückkehr eines Ajax-Requests: Seitenteile aktualisieren
function updatePage(transport) { 
// Parameter transport ist das Ajax-Objekt (letztlich XMLHttpRequest)
  var id, newCode;
  newCode = transport.responseText.evalJSON();
  
// Den User zuerst aktualisieren  
  if (newCode.user) {
    user_update( newCode.user );
    delete newCode.user;
    }

  for (id in newCode) {
// Entweder mit spezieller Methode, falls implementiert ...    
    if (typeof self[id+"_update"] == "function") {
      self[id+"_update"](newCode[id]);
      }
// ... oder einfach durch Austausch des HTML-Contents       
    else {
      $(id).update( newCode[id] );
      }
    }
// Ladezustand zurücksetzen    
  $("loading").hide();
  }

Für den Schlüssel buchungen gibt es eine designierte Funktion buchungen_update(), die demnach mit dem Array der Buchungszeilen aufgerufen wird. Sie bekommt einen Array of Arrays übergeben (AoA), kann also auf jede Zelle jeder Zeile zugreifen. Sie durchläuft die anzuzeigenden Zellen in einer geschachtelten each()-Schleife und baut dabei die einzelnen <tr>- und <td>-Elemente der HTML-Tabelle auf. Die vom Anmeldeuser getätigten Buchungen bekommen darüberhinaus noch eine weitere Zelle, die controlCell, mit Ikonen zum Ändern und Löschen von Zeilen. Diese müssen dann noch alle klicksensitiv gemacht werden, indem der doOnClick() für das Event click registriert wird. Schliesslich wird der Button zum Sichern verborgen: Denn immer wenn diese Funktion durchlaufen wird, enthält die Tabelle den reinen Datenbankstand. Ein Sichern ist also unnötig:

// --- Vom Server als Array of Array (AoA) gesendete Buchungszeilen 
//     ins HTML übernehmen
function buchungen_update( rows ) {
  
  var tbody = $("buchungen").down("tbody");
  var user = $("user").innerHTML;
  
  tbody.update("");
  
  var controlCellCode = controlCell(); 
  
  rows.each( function(cells) {
    var rowid = cells.shift();
    var row = new Element( "tr", {id:rowid} );    
    cells.each( function(cellData, index) {    
      row.appendChild( 
        new Element( "td", 
          {className:"c"+(index+1)})
          .update(cellData) );
      });
    row.appendChild( 
      new Element( "td", 
        {className:"c5"} ).update(
      (cells[2] == user) ? controlCellCode : "" ) );
    tbody.appendChild(row);  
    });
    
  $("buchungen").show();  

// Alle Bilder in der Buchungstabelle sind clicksensitiv  
  $$("#buchungen img").each( function( img ) {
    img.observe("click", doOnClick );    
    });
    
// Datenbankstand - Sichern ist unnötig    
  $("save").hide();  
  
  }

Wenn der Benutzer nun "Ändern" oder "Neuer Eintrag" klickt, öffnet sich ein Formularbereich zum Pflegen einer einzelnen Tabellenzeile. Dieses Formular dient wirklich nur zum Editieren, es wird niemals verschickt. Zum Abschliessen drückt der Benutzer im Formularbereich auf den Button "Übernehmen". Dann schliesst sich das Formular, und die geänderten oder neuen Zellinhalte werden in der Tabelle eingetragen und erhalten eine markierung in Form der CSS-Klasse changed. Diese Markierung zeigt dem User ebenso wie dem Programm, dass diese Felder sich vom Datenbankstand unterscheiden.

Da die Funktion dataLoss() nun anspricht, wird auch der Button zum Sichern angeboten. Hierfür ist die Funktion checkDataLoss() zuständig, die nach allen Operationen, die potentiell zu Datenänderungen führen, aufgerufen wird. Diese ruft ihrerseits die schon erwähnte Funktion dataLoss() auf, um den Änderungsstatus durch Inspektion der Tabelle zu ermitteln. Das kann man mit dem Prototype-Framework sehr kompakt formulieren. Die vier Terme der Funktion lesen sich so: Schaue nach, ob es irgendeine echte Datenzeile der Buchungstabelle gibt, die entweder auf Zeilenebene die CSS-Klasse deleted besitzt oder irgendeine Zelle mit der CSS-Klasse changed enthält. Da die verwendeten Funktionen any() und down() kurzschliessen, d.h. die Iteration nach dem ersten Fund abbrechen, ist die Implementierung der Methode dataLoss() nicht nur kurz, sondern auch effizient:

// --- Save-Button nur anbieten, wenn sich Daten geändert haben
function checkDataLoss() {
  $("save").style.display = dataLoss() ? "inline" : "none";
  }
  
// --- Feststellen, ob Daten geändert wurden  
function dataLoss() {
  return $("buchungen").down("tbody").
    select("tr").any( function(row) {
      return row.hasClassName("deleted") ||
             row.down("td[class~=changed]");  
      });
  }

Irgendwann drückt der Benutzer "Sichern". Dann werden die Änderungen in der Funktion extractChanges() ermittelt und in Form eines JSON-Hashs an den Server übergeben. Neu angelegte Zeilen (die dadurch zu erkennen sind, dass ihre (vorläufige) ID mit dem Präfix new beginnt) werden hierbei gleich behandelt wie geänderte Zeilen: Die Zeilendaten werden als Datenteil zur ID in den Hash eingefügt. Für gelöschte Zeilen das spezielle Schlüsselwort deleted als Datenteil übergeben. Wenn die Benutzerin Petra in obigem Beispiel die Zeile buch2 löscht, den Betrag der Zeile buch4 von 350.00 CHF auf 400.00 CHF ändert und eine neue Zeile einfügt, um ihre Hannoversche Hotelrechnung zu erfassen, sieht der an den Server übergebene Hash folgendermassen aus:

{
  buch2:"deleted",
  buch4:"3.10.2010;400.00;Petra;Neues Smartphone",
  new1:"9.10.2010;100.00;Übernachtung Hannover"
  }

Der Server erhält diesen JSON-Hash im Body des HTTP-Requests, zusammen mit dem Wert save für den URL-Parameter action. Er wertet den Hash aus und übersetzt ihn in Anweisungen zur Änderung des Datenfiles. Auch wird für neu angelegte Zeilen eine endgültige ID vergeben. Schliesslich gibt er — wie das Kommando get_all — den aktuellen Stand der Buchungszeilen an den Client zurück.[3]

Der Einstiegspunkt für alle internen, von der Webseite mittels Ajax abgesetzten CGI-Anfragen ist das Perl-Programm konto.pl. Es wertet den URL-Parameter action aus. Wie macht es das? Der CGI-Mechanismus ist sehr einfach: Der Query-Teil einer URL wird dem aufgerufenen Programm in Form einer Umgebungsvariablen zur Verfügung gestellt. Der Body des Requests kann aus der Standardeingabe eingelesen werden, und alle Ausgaben an die Standardausgabe bilden den Body der HTTP-Antwort. Das Programm konto.pl extrahiert daher den Wert von action aus dem Query-String der URL und ruft dann dynamisch das Unterprogramm dieses Namens auf. Das geht so:

#!W:/perl/bin/perl.exe

# CGI Perl-Requesthandler, der mit der Kontopflegeseite kommuniziert

use strict;
use warnings;
no strict 'refs';

use CsvTableMaintainer;  # Tabellenpflegeklasse
use MiniJSON;            # Benötigte Perl-JSON-Konvertierungen

# URL-Querystring
my $queryString = $ENV{"QUERY_STRING"} 
   || "action=get_all";  # Für standalone Testausführungen   
my ($action) = ($queryString =~ /action=(\w+)/);

# Instanz der Tabellenpflegeklasse bilden
my $tableMaintainer = CsvTableMaintainer::new( file=>"konto.dat" );

# Erste Zeile der HTTP-Antwort
print "Content-Type:text/plain\n\n";

# Im Queryparameter übergebene Aktion ausführen
print &$action() if $action;

sub get_all {
...
  }

sub save {
...
  }

Wie man sieht, ist konto.pl nur der Dispatcher, der die Anfragen entgegennimmt und die entsprechenden Subroutinen aufruft. konto.pl ist schmal und hat nur wenige Subroutinen — normalerweise nur die den actions entsprechenden Unterprogramme. Bemerkenswert ist, dass für einfache Aufgaben wie diese auch kein use CGI::<irgendwas> notwendig ist: Query-Parameter auslesen und auf Payloads der ein- und ausgehenden HTTP-Nachrichten zuzugreifen, ist unter CGI so einfach, dass keine weiteren Hilfspakete dafür nötig sind.

konto.pl ist natürlich auch deshalb so schmal, weil es die eigentlichen Aufgaben an die Klasse CsvTableMaintainer und zu einem kleineren Teil an das Paket MiniJSON delegiert. Diese Programmteile befinden sich - wie auch alle anderen, für dieses Beispiel benötigten Programmteile - in meinem github-Reposoritory konto. Wer sich die Beispielapplikation daher noch genauer ansehen will, sei auf dieses Repository verwiesen.

[1] Vielleicht habe ich nicht gründlich genug gesucht oder war mit den gefundenen Objekten nicht zufrieden.
[2] Neben dem JavaScript-Framework Prototype von Sam Stephenso, das mich dabei unterstützt, lesbares JavaScript zu schreiben, verwende ich den Datepicker von Hugo Ortega Fernandez. Und - ja, ich mag die SAP-Ikonen!
[3] Um Codeduplizierung zu vermeiden, ruft er dafür nach Ausführung des Sicherns schlicht die Aktion get_all auf.

Das schriftliche Wurzelziehen

2010-09-30T20:26:00.017+01:00

Vor ein paar Tagen brachte mein Sohn interessante Rechenaufgaben aus der Schule mit: Der Mathematiklehrer hatte den Kindern das gute alte schriftliche Wurzelziehen beigebracht — ein Verfahren, bei dem die erste binomische Formel ausgenutzt wird, um sukzessive die Stellen der Wurzel zu ermitteln. Das Verfahren ist heute fast völlig in Vergessenheit geraten, wird jedoch an den Waldorfschulen noch in Ehren gehalten — ihrem ausgeprägten Konservatismus sei Dank.

Für mich war es eine nette Erfahrung, das Verfahren in Form von JavaScript-Code nachzubilden — und zwar so, dass es zum Üben benutzt werden kann. Statt die gesamte Rechnung auf einen Schlag anzuzeigen, sollten auf Knopfdruck die einzelnen Schritte ausgeführt werden. So kann man auf dem Papier das Verfahren selbst probieren und sich bei jedem Schritt vergewissern, keinen Fehler gemacht zu haben.

Das Programm soll die Rechnung, wie sie auf dem Papier entsteht, erzeugen, die Schritte sollen mit Kommentaren versehen werden, und in einem eigenen Bereich sollen kleine Nebenrechnungen ausgeführt werden — analog dem Schmierpapier, das man bei der schriftlichen Rechnung braucht.

Ich setzte mir ein Zeitlimit von drei Stunden, das ich gerade so einhalten konnte — in nostalgischer Erinnerung an die guten alten Zeiten, als ich mich noch in Prüfungen bewähren musste: "Sie haben drei Stunden — die Zeit läuft." Allerdings habe ich später noch eine weitere Stunde für ein paar Refaktorisierungen aufgewendet. Die Webseite

http://ruediger-plantiko.net/wurzeln/

zeigt das Ergebnis. Es folgen ein paar Anmerkungen zum Programmentwurf.

Die HTML-Seite zeigt nichts anderes als das Seitenlayout. Sie ist vollständig von JavaScript freigehalten. Auch Clickbehandler, onload-Behandler usw. sind in die Scriptdatei ausgelagert.

Um lesbares und dennoch kurzes JavaScript zu produzieren, verwende ich das Framework Prototype.

Der Unterbruch zwischen den einzelnen Rechenschritten erfordert es leider, dass Zwischenergebnisse in globalen Variablen mitgeführt werden müssen. Wenigstens werden diese globalen Variablen alle an einem Ort deklariert und an einem zweiten Ort, in einer reset()-Funktion wieder gelöscht.

Der Algorithmus besteht aus insgesamt neun Schritten. Die ersten drei Schritte werden nur einmal ausgeführt. Die nachfolgenden sechs Schritte werden so lange ausgeführt, bis keine weiteren Ziffern vom Radikanden mehr heruntergeholt werden können. Dann ist das Verfahren beendet.

Mein Entwurf packt diese neun Schritte als anonyme Funktionen in einen Array execute[], so dass sie dynamisch über einen Index angesprochen und ausgeführt werden können. Die Methode executeNextStep(), die bei Click auf den Weiter-Button aufgerufen wird, kann die Schleife dann ohne umständliche switch...case Konstrukte realisieren, indem der Schrittzähler step kontinuierlich erhöht wird, der Divisionsrest modulo 6 aber als Index für den Zugriff auf den execute-Array fungiert.[1]

Um aus der Schleife auszubrechen, empfiehlt sich eine Exception - im simpelsten Fall, wie hier, einfach in Form eines Stringobjekts, das dann angezeigt wird.

function executeNextStep() {

  try {

// Schrittzähler erhöhen
    incrementStepCounter( );

// Nächsten Schritt ausführen
    if (step <= 2)
// Schritte 0 bis 2 nur einmal
      execute[step]();
    else
// Ab Schritt 3 wird es periodisch
      execute[3+((step-3)%6)]();

    } catch (e) {

// Ausnahme (z.B. STOP) melden und Verfahren beenden
      commentOhneSchritt( "<b>" + e + "</b>");
      verfahrenBeenden();
      }
  }

// Hier folgen die Schritte:
execute = [
  function() {
    comment("Zahl nach links in Zweiergruppen aufteilen");  
    var r = radikand+"",i;
    for (i=r.length-2;i>=-1;i-=2) {
      if (i>=0) 
        groups.unshift( r.substring(i,i+2) );
      else 
        groups.unshift( r.substring(0,1) ); 
      }    
    s = "";
    groups.each( function(g) {
      s+='<span class="group">' + g + '</span>';
      }); 
    write(s);
    },  
  function() {
    ...
    },
  ... 
];

Diese Art, das Problem zu lösen, lässt sich sicher auch in anderen Kontexten einsetzen: Nämlich immer dann, wenn ein Algorithmus stückweise auszuführen ist, etwa wie hier in einer Schleife mit Abbruchbedingung. Der Zugriff auf Funktionen als Arrayelemente ist für eine Abfolge von Schritten naheliegender als der Zugriff über den Funktionsnamen, etwa self["schritt2"](), der ja alternativ auch möglich wäre. Die Lösung ist aber vor allem kompakter als eine switch...case...-Konstruktion, ohne an Lesbarkeit einzubüssen. Im Gegenteil, gerade die mühsam abzuhandelnden case's, die in C-artigen Sprachen (wie JavaScript) auch noch jeden case mit einem break beenden müssen, erschweren nach meiner Ansicht die Lesbarkeit von Code.

Im Rückblick fand ich es unbefriedigend, dass ich für mein geradezu spartanisches UI-Design relativ viel Zeit aufwenden musste. Für die eigentlichen Logik des Wurzelziehens brauchte ich nur knapp die Hälfte der Zeit, die ich mir vorgegeben hatte. Zu erwarten wäre eigentlich, dass man für die Problem Domain die meiste Zeit aufwenden muss, nicht für das User Interface. Das hat bei mir sicher auch damit zu tun, dass ich nicht wie ein hauptberuflicher Webdesigner ständig neue HTML/CSS-Oberflächen kreiere, sondern an einmal geschaffenen Entwürfen sehr lange und sehr genügsam festhalte, denn auch beruflich programmiere ich hauptsächlich Geschäftslogik und modifziere meist nur bestehende Entwürfe von Benutzeroberflächen. Insgesamt muss ich jedoch meine Kritik aus dem bösen Tabellenlayout wiederholen, dass ich CSS in der jetzigen Form für die Gestaltung der Präsentationsschicht einfach noch nicht griffig genug finde.

[1] Auf den Namen execute für den Funktions-Array bin ich übrigens erst nach einigem Versuchen gekommen: Ausdrücke wie execute[step]() gewinnen durch ihn an Lesbarkeit.