Willkommen zu Teil #5 unserer verblüffenden Blogpost- und Webinar-Serie! In unserer Serie helfen wir Ihnen, alle Ihre Domino-Anwendungen zu analysieren.

Der Titel des Webinars für diesen Blogpost lautete „Landen Sie nicht im Graben, weil Sie sich der Hindernisse in Ihrem Quellcode nicht bewusst waren“.

Diesmal berichten wir über das Warum, was und wie man in Ihren Domino-Anwendungen analysieren sollte.

Bitte Marketing-Cookies akzeptieren um dieses Video anzusehen.

Ein Vorwort für Nicht-Entwickler

Wenn Sie kein Entwickler sind: Die folgende Einführung hilft Ihnen vielleicht, den Rest dieses Beitrags besser zu verstehen.

Jede Datenbank in Ihrer Umgebung enthält Designelemente und Code. Damit können Sie alle darin enthaltenen Dokumente anzeigen. Sei es zum Erstellen, Bearbeiten oder Lesen.

Ansichten zeigen Ihre Dokumente im Listenformat an. Diese können sortiert und/oder kategorisiert werden. Zum Beispiel nach Datum, Benutzername oder was immer zur jeweiligen Anwendung und Ansicht passt.

Neben den Ansichten sind zwei weitere Designelemente hervorzuheben. Diese unterstützen Sie dabei, Dokumente in Ihren Datenbanken zu erstellen, zu bearbeiten oder zu lesen:

  • Aktionen in Ansichten (in der Regel über Schaltflächen oder Menüoptionen am oberen Rand der Ansichten verfügbar)
  • und Formulare, sowie Felder in Formularen

Eine Datenbank kann aus vielen weiteren Arten von Designelementen bestehen. Jeder von ihnen kann eine oder mehrere der folgenden Programmiersprachen verwenden:
@Formeln, LotusScript, JavaScript und Java.

Dieser Code kann wiederum eine Vielzahl von Schnittstellen und Abhängigkeiten haben:

  • andere Notes/Domino-Datenbanken,
  • andere Anwendungen, wie Microsoft Excel oder SAP,
  • das Dateisystem – sei es auf Clients oder Servern -,
  • das Betriebssystem,
  • und viele, viele andere Abhängigkeiten.

Eine Anwendung kann aus einer oder mehreren Datenbanken bestehen und auf einem oder mehreren Servern verfügbar sein. Bei der Replikation werden dieselben Datenbanken auf verschiedenen Servern synchronisiert. Das Ergebnis ist eine hervorragende Leistung, Lastverteilung und hohe Verfügbarkeit über verschiedene Standorte/Netzwerke hinweg.

Wenn Sie eine Anwendung optimieren, modernisieren oder migrieren wollen, müssen Sie das wissen:

  • wie komplex eine Anwendung ist (denken Sie an die Art und Anzahl der Designelemente sowie an die Codezeilen),
  • was der ganze Code macht,
  • und ob der Code in Ihrem jeweiligen Projekt leicht zu verarbeiten sein wird.

Lassen Sie uns also mit dem Warum beginnen

Die meisten Entwickler haben nicht alle Anwendungen selbst entwickelt. Selbst wenn sie es getan haben (Chapeau!), ist es wahrscheinlich nicht „gestern“ passiert, sondern über ein paar Jahre hinweg. Erinnern Sie sich noch gut genug an den Code in all Ihren Anwendungen?

Außerdem haben einige Unternehmen nicht einmal mehr einen Domino-Entwickler. Ganz zu schweigen von all denen, die im Laufe der Jahre zum Aufbau der heutigen Anwendungslandschaft beigetragen haben.

Außerdem ist die Kenntnis des Quellcodes einer Anwendung von großem Vorteil, um sie unverändert unter Domino laufen zu lassen bzw. zu pflegen.

Schließlich wollen Sie alle Hindernisse sowie hilfreichen Code finden, wenn nicht sogar generell das Gute, das Schlechte und das Hässliche.

Wenn Sie Ihre Anwendungen optimieren, modernisieren oder migrieren möchten:

Alles in allem: Wäre es nicht toll, wenn Sie sich wertvolle Zeit, Frustration und Fallstricke ersparen könnten? Die Stakeholder Ihrer Anwendungen zu kennen, ist viel wirkungsvoller, wenn man es mit der Analyse des Designs und des Codes Ihrer Anwendungen kombiniert.

Wenn Sie Ihre Stakeholder kennen, wissen Sie auch, woran Sie sind:

  • Wer ist von den Änderungen betroffen, die Sie an einer Anwendung vornehmen?
  • Wie werden sie davon betroffen sein?
  • Wen sollten Sie konsultieren, bevor Sie mit den Änderungen beginnen?
  • Wer profitiert von der Arbeit, die Sie leisten?

Das bringt uns zu dem Thema Was

Bevor wir uns mit dem Thema „Was von Ihrem Code sollten Sie analysieren“ befassen, sollten Sie sich daran erinnern:

Es gibt noch viele andere wichtige Daten, die Sie berücksichtigen sollten, bevor Sie den Code analysieren:

  • Welche sind Ihre meistgenutzten und am wenigsten komplexen Anwendungen?
    Diese zahlen sich schnell aus. Und Sie sollten keine Zeit mit Anwendungen verbringen, die niemand benutzt! Weitere Einzelheiten finden Sie auch hier und hier.
  • Welche Endbenutzer benötigen aus Gründen der Leistung oder der Offline-Nutzung lokale Replikate?
  • Welche Anwendungen nutzen Ihre VIPs oder Ihre wichtigsten Profitcenter?

Dies sind nur einige Beispiele, die Sie im Hinterkopf behalten sollten – weitere finden Sie hier (siehe Folien 17-21).

Welchen Code sollten Sie nun analysieren, und wonach sollten Sie darin suchen?

Alles davon. Zeitraum. In *allen* Ihren Anwendungen. Und für jeden von ihnen bedeutet das

  • Der gesamte Code: @Formeln, Java, JavaScript und LotusScript
  • Alle Designelemente (denken Sie an „Code-Container“). Dies können Formulare, Unterformulare, Ansichten, Spalten, Aktionen, Agenten, Schaltflächen, Skriptbibliotheken usw. sein.
  • Die folgenden Gestaltungselemente verdienen oft besondere Aufmerksamkeit:
    XPages, Java-Klassen, Applets, Jar-Dateien, Webdienste, Funktionen für zusammengesetzte Anwendungen und ähnliches

Eine ordnungsgemäße Analyse sowohl der Designelemente als auch des Codes einer Anwendung beantwortet zwei wesentliche Fragen:

  1. Wo befindet sich Ihr gesamter Code? Wie viel ist wo? Und um welche Art von Code handelt es sich?
  2. Was bewirkt dieser Code?

Die folgenden zwei Beispiele zeigen, wie wichtig es ist, sowohl das Design als auch den Code zu analysieren:

a) Je mehr Formulare, Felder und Code eine Anwendung hat, desto zeitaufwändiger ist die Modernisierung oder Migration der Anwendung.

b) Eine Anwendung, die Java-Code verwendet, ist kein idealer Kandidat für die Migration zu SharePoint. Ja, das hängt zum Teil davon ab, was der entsprechende Code tut. Dennoch hilft es Ihnen, Ihre Bewerbungen zu bewerten und Fallstricke zu vermeiden.

WAS Sie in Ihrem Code suchen sollten

Die Suche in Codes kann sowohl lustig als auch frustrierend sein.

Nachdem Sie das Design Ihrer Anwendungen in DXL (Domino XML Language) exportiert haben, finden Sie hier drei Tipps für den Anfang:

  1. Starten Sie Notepad oder ein ähnliches Programm und sehen Sie sich das Ergebnis an. Um ein erstes Gefühl zu bekommen, versuchen Sie, Teile Ihres Codes zu finden, indem Sie nach Teilen davon suchen. Suchen Sie auch nach Benutzernamen, Servernamen und ähnlichem
  2. Versuchen Sie LotusScript Manager oder Source Sniffer von OpenNTF
    (verwenden Sie *nicht* Lotus Analyzer! Es hat ein verstecktes Design und telefoniert nach Hause)
  3. Pro-Herausforderung: Schneiden Sie den Code aus der DXL in Dokumente in einer Notes-Datenbank. Dies erleichtert die Kategorisierung, Suche und Nachbearbeitung (z.B. zum Zählen von Designelementen).

Wenn Sie eine der oben genannten Möglichkeiten ausprobiert haben, sind Ihnen vielleicht ein paar Unzulänglichkeiten aufgefallen:

a) Ihre Suchanfragen entsprechen auch den Kommentaren/Bemerkungen in Ihrem Code

b) Kombinierte Suchen wie @Db(Column OR Lookup) erfordern, dass Sie die obige Pro-Herausforderung zuerst angehen
(=Aufteilung des Codes in Notes/Domino-Dokumente oder eine SQL-Datenbank). Getrennte Suchen führen zu doppelten Ergebnissen. Das wiederum steht Ihrem Ziel, so wenig Code wie möglich zu überprüfen, sehr entgegen.

c) Ihre Suche führt auch zu einem Code, nach dem Sie nicht gesucht haben. Zum Beispiel:

  • Die Suche nach „Open“ findet NotesDatabase[Object].Open und NotesStream[Object].Open
  • Die Suche nach „@DbLookup“ umfasst Nachforschungen in derselben Datenbank, in der sich der Code befindet. Vielleicht möchten Sie aber auch nur Abfragen in anderen/externen Datenbanken. Oder Ihr Ergebnis enthält auch nicht-Notes-Lookups, wie ODBC. Vielleicht suchen Sie aber auch nur nach Notizen.

Bevor wir alsoBevor wir unsere Suche fortsetzen, müssen wir den den Code

Für gute Suchergebnisse müssen wir alle Kommentare aus dem Code entfernen. Ja, Kommentare sind gut für Ihren Code, um ihn später besser zu verstehen. Aber sie verzerren unsere Suchergebnisse.

Die folgenden Bilder veranschaulichen, wie ein Entwickler in LotusScript und @Formeln kommentieren kann:

In @Formeln beginnen Kommentare mit einem REM, gefolgt von einer beliebigen Anzahl von Leerzeichen (=Leerzeichen oder Tabulatoren). Dann folgt der eigentliche Kommentar, der entweder von doppelten Anführungszeichen oder geschweiften Klammern umgeben ist.

Wir haben die oben genannten Produkte bereits für Sie vorbereitet, die Sie KOSTENLOS testen können.

Dieser ganze Artikel hilft Ihnen, Ihre eigenen, unabhängigen Anwendungsanalysen zu verstehen und durchzuführen. Aber vielleicht möchten Sie sich wertvolle Zeit sparen und schnell handeln. Alles, was Sie tun müssen, ist, sich für unsere spielfertige iDNA Applications Sandbox zu registrieren. Sobald Sie sich registriert haben, brauchen Sie sich nur noch einzuloggen und zu unserer vorgefertigten Sofortcode-Suche zu navigieren. Zugegeben, es zeigt nicht Ihre eigenen Anwendungen, aber es gibt Ihnen eine gute Vorstellung davon, wie die Codesuche funktionieren sollte.

Verwenden Sie zum Testen die Textsuche mit „florian“, „vogler“, „server“, „/acme“, „/O=acme“ und „workflow“. Versuchen Sie auch eine Suche mit einem regulären Ausdruck wie „(?iw)@db(lookup|column)“.

Lassen Sie uns nun darauf eingehen, wonach Sie *im* gesamten (Design und) Code Ihrer Anwendungen suchen müssen:

Wenn Sie optimieren möchten

  • Suchen Sie nach GetNthDocument – es ist langsamer als GetFirst/GetNextDocument
  • Suchen Sie nach hartkodierten Servernamen, Benutzernamen, Datenbankdateinamen, IP-Adressen, E-Mail-Adressen, Replikat-IDs usw.
  • Suche nach altem Code (@V2If, @V3Username, @V4UserAccess, @UserPrivileges, @IfError)
  • Unabhängig vom Code: Finden Sie Ihre meistgenutzten/beliebten Datenbanken und geben Sie ihnen ein wenig Liebe. Machen Sie sie hübscher und moderner!

Wenn Sie modernisieren möchten

  • Prüfen Sie, ob eine Anwendung stark auf NotesUI*-Klassen angewiesen ist. Das funktioniert in Webbrowsern nicht und muss überarbeitet werden
    Suchen Sie nach Code, der von Browsern nicht unterstützt wird. Tipp: Suchen Sie in der Designer-Hilfe nach „Sie können diese Funktion nicht in Webanwendungen verwenden.“
  • Gibt es bereits eine Menge Code, der auf eine Browser-Unterstützung hindeutet?
    d.h. @WebDbName, @BrowserInfo, @ClientType, Domino @DbCommands, …
  • Ist Ihre Anwendung/Ihr Code auf das Drucken angewiesen? Das kann von einem Browser aus eine Herausforderung sein
  • Analysieren Sie Ihren Code, ob er auf HCL Nomad funktioniert
    • Ist die Anwendung abhängig von XPages, Java oder ODBC? Dies funktioniert nicht auf HCL Nomad.
    • Verwendet die Anwendung C-API-Aufrufe? Wenn ja, funktioniert der Code auch auf iOS und Android?
    Benötigt Ihre Anwendung irgendwelche Client-Erweiterungen von Drittanbietern?
  • Unabhängig vom Code: Finden Sie Ihre meistgenutzten/beliebten Datenbanken und geben Sie ihnen ein wenig Liebe. Machen Sie sie hübscher und moderner!

Wenn Sie migrieren möchten

  • Wie viele Formulare, Felder, Ansichten usw. hat eine Anwendung? Wählen Sie nicht das komplexeste zuerst.
  • Ist Ihre Anwendung von Code- oder Designelementen abhängig, die auf der jeweiligen Zielplattform nicht gut funktionieren?
    Zum Beispiel: Java <> SharePoint, zu viele Ordner <> SharePoint. C-API. Privates oder öffentliches Adressbuch, Mail (Senden und) Verschlüsseln. Verwenden SieLSX, ODBC, DB2, DOS/cmd, OLE, Dateien, Verzeichnisse, MIME, Dokumentverknüpfungen, usw.
  • Hängt eine Anwendung von anderen Datenbanken ab?
    Denken Sie an @DbLookups, die eine Verbindung zu anderen Datenbanken herstellen (und z.B. nicht „“:““ als server:filename verwenden). Dasselbe gilt für New NotesDatabase, GetDatabase, .Open, .OpenWithFailover, .OpenIfModified, .OpenByReplicaID, [FileOpenDatabase], [Compose] usw.
  • Unabhängig von Code und Migration: Geben Sie einer Ihrer übrig gebliebenen Datenbanken ein wenig Liebe, machen Sie sie hübscher und moderner.

Zum Schluss wollen wir uns ansehen, WIE Sie Ihren Code am besten durchsuchen

Das Folgende ist wirklich sehr gruselig. Wenn Sie kein Entwickler sind, können Sie diesen Abschnitt überspringen!

Zum Teil haben wir bereits erklärt, warum die Suche nach Code mit (Unter-)Zeichenketten nicht allzu weit führt. In zu vielen Fällen passt er zu viel oder zu wenig. Wir haben uns auch angesehen, warum es notwendig ist, alle Kommentare zu entfernen, bevor Sie Ihren Code durchsuchen.

Außerdem ist das Folgende sehr, sehr, sehr wichtig, wenn Sie nach Code suchen:
Suchen Sie NICHT nach Code und denken Sie dabei daran, wie Sie ihn entwickelt hätten. Denken Sie breiter und Sie werden überrascht sein, wie andere Menschen coden.

Was sind also bessere Ansätze für die Suche nach Code als nur Teilstring-Treffer?

Ein Volltext-Index, der Wildcards wie „*“ (Sternchen) unterstützt, bringt Sie ein Stück weiter. Z.B. bei der Suche nach „@dbcolumn* OR @dblookup*“ – aber es fehlt der Support für präzise Negationen. Die genaue Negierung von Codeteilen ist wichtig, um z.B. nur @DbLookups zu finden, die nicht auf dieselbe Datenbank verweisen.

Das folgende @DbLookup sucht nach Daten aus derselben Datenbank, in der der Code ausgeführt wird. Dies geschieht durch die Angabe „“:““ als zweiten Parameter:

Das nächste @DbLookup sucht nach Daten aus dem „lokalen“ Adressbuch (Client oder Server, je nachdem, wo es ausgeführt wird):

Die Suche nach einem @DbLookup, das Daten aus „names.nsf“ nachschlägt, ist ziemlich einfach. Auch mit einfachen Platzhaltern: @dblookup(: „names.nsf“). Bis Sie auf einen Code wie diesen stoßen:

Jetzt müssen wir plötzlich über mehrere Zeilen hinweg nach Code suchen – ja, wir haben solchen Code schon gesehen.

Noch schlimmer wird es, wenn Variablen, geschweige denn @Funktionen, als Parameter ins Spiel kommen:

Der obige Code ruft Daten aus der gleichen Datenbank ab. Die Variable ht_filename ist das Ergebnis von @Subset(@DbName;-1). Das Ergebnis ist wiederum der Dateiname der Datenbank, in der der Code läuft.

In ähnlicher Weise sucht das folgende Codebeispiel nach Daten aus dem lokalen Adressbuch:

Die beste Lösung für die Suche nach Code wäre, wenn man den Code analysieren könnte. Dies würde es uns ermöglichen, den Wert von ht_filename in den obigen Beispielen aufzulösen. Wir haben jedoch keine intelligente Lösung dafür gefunden.

Wofür wir eine intelligente Lösung gefunden haben, ist die Suche nach Code mit präziser Negation:

Wir verwenden reguläre Ausdrücke.

Der folgende reguläre Ausdruck ist ein großer Schritt nach vorn. Damit können wir nach jedem @DbLookup suchen, das nicht in derselben Datenbank nachschlägt, aus der es ausgeführt wird:

@dblookup([^;];(?!””(:””)?).*
@dblookup(Die offene Klammer muss in regulären Ausdrücken ausgeklammert werden, daher das \(
[^;]*;gefolgt von „alles außer einem Semikolon“ bis zum nächsten Semikolon.

Die Suche nach „.*;“ wäre falsch, da dieser Ausdruck zu gierig wäre. Er würde bis zum letzten Semikolon suchen.
(?!””(:””)?)Anschließend negieren Sie „“, gefolgt von einem weiteren optionalen :““ – der zweite Parameter kann entweder „“ oder „“ sein:““
.*bis zum Ende der Zeile

Dieses Beispiel erfordert noch etwas Feinabstimmung, um

  • unterstützen auch so gut wie überall eine beliebige Menge an Leerzeichen,
  • und für Situationen sorgen, in denen @dbname oder @subset(@dbname;1):@subset(@dbname;-1) die gleiche Datenbank verwenden
  • und finden Sie nur die @DbLookups, für die die Klasse „“ oder „Notes“ ist (Groß- und Kleinschreibung wird nicht berücksichtigt)

Als Bonuspunkte können Sie auch @dblookups finden, das in LotusScript Evaluates verwendet wird. Oftmals müssen dann auch die Zitate entfallen.

Der reguläre Ausdruck, der alle oben genannten Anforderungen erfüllt (mit Ausnahme des Code-Parsing), ist … möglicherweise das Hässlichste, was Sie heute zu sehen bekommen:

Ich könnte stundenlang weitermachen

Wenn Sie es bis zu dem wirklich gruseligen Zeug oben geschafft haben: Ich ziehe meinen Hut vor Ihnen! Sie sind ein Superhelden-Entwickler und ein Überlebenskünstler in Sachen reguläre Ausdrücke.

Die gute Nachricht für alle Leser ist: Wir von panagenda haben bereits einen großen Teil der schweren Arbeit erledigt. Und wir teilen gerne.

In unserer iDNA Applications Sandbox finden Sie mehr als 70 vorgefertigte reguläre Ausdrücke. Diese suchen nach über 300 verschiedenen Codefunden. Sie können all diese Muster KOSTENLOS in Ihrer eigenen Code-Suchlösung verwenden.

Und nur für den Fall, dass Sie eine klügere Idee als die Verwendung regulärer Ausdrücke haben oder Ihnen neue oder verbesserte reguläre Ausdrücke einfallen: Lassen Sie es uns bitte wissen, und wir werden es mit der Community teilen.

Falls Sie keine Zeit haben, Ihre eigene Lösung für die Codesuche zu entwickeln:

Es gibt eine Reihe von Drittanbieterlösungen, die Ihnen dabei helfen können. Einige von ihnen sind auf OpenNTF verfügbar. Einige davon sind kommerzielle Lösungen wie unsere eigene panagenda iDNA Applications.

Zusammenfassend

Die ordnungsgemäße Analyse Ihrer Anwendungen dient drei Hauptzielen:

  • Sparen Sie (viel) Zeit, Frust und Geld
  • Sich auf die richtigen Dinge konzentrieren und auf dem Laufenden sein
  • Ermöglicht die erfolgreiche Transformation Ihrer Domino-Landschaft

Optimierung, Modernisierung oder Migration

  • Was auch immer Sie tun, vergessen Sie nicht, mindestens einer Ihrer Domino-Anwendungen etwas Liebe zukommen zu lassen. Es wird sich für Sie auszahlen. Viele ti

Nächster Teil unserer Serie

Fortschrittsberichte. Sie sind Teil eines jeden Projekts und es macht keinen Spaß, sie zu produzieren. Es sind nicht nur Ihre Fortschritte, die Sie teilen müssen. Außerdem müssen Sie die Projektteams mit den Daten versorgen, die sie für ihre Arbeit benötigen. Es ist schwer zu koordinieren und es hört nie auf. Aber Fortschrittsberichte können Ihr Freund sein, wenn Sie über den Erfolg berichten!

Migrations- und Modernisierungsprojekte sind enorm teuer und sehr öffentlichkeitswirksam. Von Anfang an werden viele Augen auf Sie gerichtet sein. Die Erwartungen werden hoch sein. Wie können Sie verhindern, dass Ihr Projekt scheitert? Manchmal können Sie das nicht. Manche Projekte sind zum Scheitern verurteilt, bevor sie überhaupt begonnen haben. Das sollten Sie wissen, bevor Sie gehen.

Von nun an wird sich der Kreis der Anwendungen, an denen wir arbeiten, ständig erweitern. Jeder Schritt wird kostenintensiver sein, und eine umsichtige Planung wird einen immer größeren Nutzen bringen.

Über diese Serie:

Viele Unternehmen in aller Welt setzen seit Jahren auf HCL Notes/Domino*. Sie kennen die vielen Vorteile, die sich aus dieser Beziehung ergeben. Außerdem steht Notes/Domino im Mittelpunkt ihrer Prozesse und ihrer Arbeitsweise. Trotz alledem beginnen IT-Entscheidungsträger auf der ganzen Welt, sich eine Zukunft vorzustellen, in der Notes/Domino eine geringere oder gar keine Rolle mehr spielen könnte.

*ehemals IBM Notes/Domino