Home
Über mich
Blog
Veröffentlichungen
IT-Trainings
Impressum


Änderungen der XML-Input-Dokumentstruktur

Idealerweise stellt der Datenlieferant an einer klar definierten Adresse Daten bereit, die einer ebenso klar definierten XML Schema-Struktur (Elemente, Attribute, Namespaces, Typen) entsprechen. Was der Daten-Consumer damit macht, steht nicht unter seiner Kontrolle. Der Daten-Consumer baut auf diesen klar definierten Informationen mitunter sehr zahlreiche und/oder komplexe Verarbeitungslogiken auf.

Es kommt gar nicht selten vor, daß irgendwann eine Änderung der XML Dokumentstruktur unvermeidlich ist. Komplexe Systeme leben nun einmal, Änderungen müssen möglich sein. Dann muß das XML Schema geändert werden:

Jede Änderung der definierten Datenstruktur erfordert eine entsprechende Anpassung sämtlicher Verarbeitungslogiken, die von dieser Änderung betroffen sind, und zwar auf beiden Seiten: der Datenlieferant muß seine Prozesse anpassen, um die geänderten Daten-Strukturen zu generieren. Jeder Daten Consumer muss seine Programmlogiken zur Verarbeitung des geänderten Inputs ebenso anpassen.

Eine Änderung der vereinbarten Datenstruktur dürfte mit einiger Wahrscheinlichkeit Anpassungen in der Programmlogik auf beiden Seiten nach sich ziehen. Daher ist es sinnvoll, die Notwendigkeit derartige Änderungen sorgfältig abzuwägen. Das ist mehr als "mal eben" ein Feld, das bisher klein geschrieben wurde (<lastname>), nun plötzlich groß zu schreiben (<LASTNAME>), weil der Developer, der das XSD betreut, das so schick findet. Der Anpassungsaufwand für sämtliche betroffenen Änderungen auf Seiten der Datenlieferanten wie auch auf Seiten der Daten Consumer kann erheblich sein.

Schwierig wird es, wenn jene Seite, die die XSD's ändert (z.B. Datenlieferant), die jeweils andere Seite (hier: Data Consumer) über die Änderungen nicht rechtzeitig informiert. Dann können die Anpassungen nicht rechtzeitig erfolgen, besonders wenn Daten-Consumer auf die Input-Validierung verzichten und stunden-, tage- oder wochenlang nicht bemerken, daß wichtige Informationen fehlen. Das kann teuer werden: die Folgekosten aufgrund entgangener Umsätze, Konventional- oder anderer Strafen können erheblich bis ruinös sein.

Dabei ist es möglich, daß lediglich die Namespaces (die oft Versionsänderungen dokumentieren) betroffen sind, die Adressierbarkeit der Felder jedoch unverändert bleibt. In anderen Fällen ist zusätzlich die Dokumentstruktur betroffen. Sind lediglich die Namespaces betroffen, so ist die Versuchung groß, die Programmlogik von der engen Bindung an die Namespaces zu entkoppeln und eine namespace-unabhängige Programmierung zu verfolgen. In diesen Fällen ist es möglich, auf die vorgeschaltete XSD-Validierung völlig zu verzichten und statt dessen eine angepasste XSD-Validierung in XSLT 2.0 vorzunehmen, die sich lediglich auf die tatsächich verwendeten Felder bezieht, verbunden mit einer individuellen Fehlerbehandlungsroutine, die Namespace-Änderungen als Warnmeldungen reportet.

qrpic/XSD2_3.jpg

wg / 30. September 2017




Fragen? Anmerkungen? Tips?

Bitte nehmen Sie Kontakt zu mir auf (info10@wilfried-grupe.de).



Vielen Dank für Ihr Interesse an meiner Arbeit.


V.i.S.d.P.: Wilfried Grupe * Klus 6 * 37643 Negenborn

Mobil: 0151. 750 360 61 * eMail: info10@wilfried-grupe.de