• Holm Gehre
• 13.09.2017
• DE

XSLT 2.0 mit dem DeliveryServer

XT ist schnell, unterstützt aber nicht alle XSLT 1.0 Funktionen und schon gar nicht XSLT 2.0 bzw. XSLT 3.0. Wie schnell und einfach ein anderer Parser "installiert" und eingerichtet ist und was es bei der Umstellung zu beachten gilt, möchte ich in diesem Artikel aufzeigen.

Schritt 1: Download eines geeigneten XSLT Prozessor

Die gängisten XSTL-Prozessoren sind Saxon und Xalan. Ich habe mich für die "Saxon-HE 9.8" entschieden und die benötigten Java-Bibliotheken unter "https://sourceforge.net/projects/saxon/files/Saxon-HE/9.8/" heruntergeladen.

Schritt 2: Ablage jar(s) im tomcat/lib - Verzeichnis

Die "saxon9he.jar" aus dem heruntergeladenen zip-Archiv ganz einfach in das tomcat/lib - Verzeichnis auf dem OTWSM DeliveryServer kopieren.

Schritt 3: Konfigurieren und DS neu starten

Die Nutzung des neuen XSLT-Prozessors ist über die OTWSM DeliveryServer - Oberfläche zu konfigurieren. Die beiden nachfolgenden Screens zeigen die Originaleinstellung (xt) und die von mir durchgeführte Änderung (standard).

Anschließend muss der OTWSM DeliveryServer neu gestartet werden.

Schritt 4: Projektänderungen

Während die ersten 3 Schritte recht schnell von der Hand gehen, kommt in diesem Schritt die "Fummelei".

Zunächst sind alle Inhalte vom Typ "XSL" (irgendwo geistert zumindest in den alten Projekten immer eine "hs.xsl" rum :-)) zu editieren und die Stylesheet-Version 1.0 auf 2.0 umzustellen.

 XSLT 1.0 
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0">
  <xsl:template match="*">
    <xsl:apply-templates />
  </xsl:template>
</xsl:stylesheet>

 XSLT 2.0 
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0">
  <xsl:template match="*">
    <xsl:apply-templates />
  </xsl:template>
</xsl:stylesheet>

Im "rde.log" finden sich meisten schon die ersten Hinweise darauf, dass etwas nicht umgestellt wurde.

Anschließend heißt es "Testen, Testen und nochmals Testen!!!".  In dem von mir umgestellten Projekt, zeigte sich sehr häufig die nachfolgende Fehlermeldung im "rde.log".

Ursuche hierfür ist die striktere Auslegung von Variablen-Typen bei Saxon als es bei XT der Fall war.
So muss beispielweise beim Aufruf der XSLT - Funktionen "format-number($var, '0')" oder "round($var)" die Variable $var explizit über "number($var)" in eine Zahl konvertiert werden (s. nachfolgende Code-Beispiele).

 XSLT 1.0 
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0">
  <xsl:template match="/dynament">
    <xsl:variable name="var" select="50142"/>
    <xsl:value-of select="format-number($var, '0')" />
  </xsl:template>
</xsl:stylesheet>

 XSLT 2.0 
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0">
  <xsl:template match="/dynament">
    <xsl:variable name="var" select="50142"/>
    <xsl:value-of select="format-number(number($var), '0')" />
  </xsl:template>
</xsl:stylesheet>

Hinweis: Funktionsaufrufe, wie "format-number(number($var), '0')" läufen auch unter XSLT 1.0 und es hat sich bei meiner Umstellung gezeigt, dass es sich lohnt solche Änderungen im Vorfeld einer Umstellung auf XSLT 2.0 in den bestehenden Projekten (Software für die Versionsverwaltung nicht vergessen!) durchzuführen.

Sind alle Fehler behoben und das Projekt läuft wieder wie am Schnürchen, können die bisher nicht unterstützen Funktionen aus XSL 1.0 (z.B. key()) und die mit XSLT 2.0 zur Verfügung stehenden Funktionen (z.B. distinct-values()) genutzt werden.

Fazit

Zusammenfassend kann gesagt werden, dass eine systemseitige Umstellung des XSLT-Prozessors schnell und problemlos durchzuführen ist.
Da diese Umstellung systemweit erfolgt, sollten alle DeliveryServer - Projekte entsprechend im Vorfeld (auf einer Testumgebung) auf XSLT 2.0 und/oder XSLT 3.0 Konformität geprüft werden. Je nach Anzahl der eingesetzten XSL - Inhalte kann dies einige Zeit (bei mir waren es mit 87 zu Teil sehr umfangreichen XSL-Inhalte rund 2 Tage debugging - in Anspruch nehmen.

Wird der DeliveryServer neu eingeführt oder ist die Projekt- und XSL-Anzahl überschaubar kann ich, falls der Wunsch bzw. die Notwendigkeit einer Umstellung besteht, nur dazu raten.

Wer eine Umstellung des XSTL-Prozessors durchführt, tut dies "auf eigene Gefahr". Unter Umständen ist es möglich, dass der OT-Support bei der Eröffnung neuer Supporttickets erst nach Ausschluß der Fehlerquelle "XSLT-Prozessor" die Bearbeitung aufnimmt. 

---

Über den Autor: