Legacy-JavaScript erkennen

Bevor man über die Risiken von altem Formular-Code sprechen kann steht eine Handwerksfrage: Woran erkennt man Legacy-Code überhaupt wenn ein Ordner voller Web-Ressourcen vor einem liegt? Das Gute an Legacy-Mustern ist, dass sie sich wörtlich suchen lassen. Eine kommentierte Suchliste.

Die eindeutigen Treffer

Diese Zeichenketten sind für sich genommen schon ein Befund ohne dass man den umgebenden Code verstehen muss.

• "Xrm.Page": der alte Formularzugriff, seit Version 9 abgelöst durch den formContext aus dem Ausführungskontext. Der mit Abstand häufigste Fund.
• "/XRMServices/2011/": der alte SOAP- beziehungsweise OData-v2-Endpunkt. Datenzugriffe gehören heute auf die Web API.
• "Xrm.Page.context", "Xrm.Utility.openEntityForm" und "Xrm.Utility.openQuickCreate": abgekündigte Vorgänger von "Xrm.Utility.getGlobalContext()" und der heutigen Navigations-API "Xrm.Navigation" (Liste der abgekündigten Client-APIs bei Microsoft).
• "window.parent.Xrm": der Griff aus einer HTML-Web-Ressource ins Eltern-Fenster. Funktioniert je nach Einbettung mal, mal nicht und war nie der vorgesehene Weg.
• "crmForm": wer das findet hat Code aus der 4.0-Ära vor sich. Kommt seltener vor aber es kommt vor.

Die Verhaltensmuster

Andere Merkmale erkennt man nicht an einem Schlüsselwort sondern an der Bauart.

Synchrone Serveraufrufe erkennt man am dritten Parameter "false" in "xhr.open(...)". Sie frieren das Formular während des Aufrufs ein und sind im Browser abgekündigt. Manche Skripte pflegen handgebaute Feldnamenslisten im Code statt sie aus dem Formular zu holen. Solche Listen brechen bei der nächsten Umbenennung. Und eingebettete Fremdbibliotheken mit Versionsnummer im Dateinamen (etwa eine jQuery 1.x) datieren ein Skript zuverlässiger als jeder Kommentar.

Ein Wort noch zu HTML-Web-Ressourcen: Sie sind eine eigene Fundgrube. Dort liegen komplette Seiten aus früheren Projektphasen mit eingebettetem Skript und den ältesten Zugriffsmustern des ganzen Bestands. Wer nur die js-Dateien durchsucht übersieht sie.

Ebenfalls ein Hinweis auf Alter: Verweise auf "ClientGlobalContext.js.aspx" in HTML-Ressourcen. Der Weg funktioniert noch stammt aber aus der Zeit vor "Xrm.Utility.getGlobalContext()". Meist steckt er tief in alten Hilfsseiten welche Modernisierungsrunden gern unbemerkt überleben. Kein Befund für sich aber ein guter Anlass die Seite genauer anzusehen.

Vom Fund zur Einschätzung

Nicht jeder Treffer ist gleich dringend. Für die Priorisierung hat sich eine einfache Zweiteilung bewährt. Alles was auf abgekündigten Endpunkten oder synchronen Aufrufen basiert kann bei einem Plattform-Update tatsächlich aufhören zu funktionieren. Das gehört auf die aktive Liste. Der reine "Xrm.Page"-Bestand funktioniert bis auf Weiteres und kann geplant wandern, am besten dann wenn das jeweilige Formular ohnehin angefasst wird.

Wichtig ist noch die Gegenrichtung: Ein Skript kann frei von allen diesen Mustern sein und trotzdem tot, weil kein Formular und keine Schaltfläche es mehr aufruft. Die Modernität des Codes und seine Verwendung sind zwei getrennte Fragen und beide gehören in die Bestandsaufnahme.

Die ganze Suchliste läuft mit einem beliebigen Editor über den entpackten WebResources-Ordner in wenigen Minuten. Es gibt wenige Prüfungen mit einem besseren Verhältnis von Aufwand zu Erkenntnis.

Zur Einordnung, weil ich mit D365 Audit selbst ein Prüfwerkzeug baue: Es erkennt aus dieser Liste "Xrm.Page", eingebettete jQuery-Versionen, "eval" und synchrone Aufrufe automatisch. "/XRMServices/2011/", "crmForm", "openEntityForm" und "window.parent.Xrm" gehören nicht dazu - für sie bleibt die Textsuche der richtige Weg.