in Blog, iDNA, Noch mehr, Produkte

Lesezeit: 14 Minuten

Über die vielen Hindernisse in Ihrem Quellcode

Weg #5 aus 7 neue Wege zur Überwindung Ihrer Herausforderungen bei der Domino Anwendungsmigration

Willkommen zu Teil #5 unserer erstaunlich populären Blogpost– und Webinar-Reihe! In dieser Folge helfen wir Ihnen bei der Analyse all Ihrer Domino-Anwendungen.

Dieses Mal beantworten wir die Fragen „Warum, Was und Wie“ man Domino Anwendungen am besten analysiert (bzw. analysieren sollte).

Ein Vorwort für Nicht-Entwickler

Falls Sie kein Entwickler sind: Die folgende Einführung könnte Ihnen helfen, den Rest dieses Beitrags besser zu verstehen.

Jede Datenbank in Ihrer Umgebung enthält Designelemente und Code. Dies dient dazu, alle darin enthaltenen Dokumente anzuzeigen. Sei es, um sie zu erstellen, zu bearbeiten oder zu lesen.

Views zeigen Ihre Dokumente in Listenform an. Diese können sortiert und/oder kategorisiert sein. Zum Beispiel nach Datum, Benutzername oder was immer zur jeweiligen Anwendung und Ansicht passt.

Neben den Ansichten sind zwei weitere Gestaltungselemente hervorzuheben. Diese unterstützen Sie beim Erstellen, Bearbeiten oder Lesen von Dokumenten in Ihren Datenbanken:

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

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

Auch dieser Code kann eine Vielzahl von Schnittstellen und Abhängigkeiten haben:

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

Eine Anwendung kann eine oder mehrere Datenbanken umfassen und auf einem oder mehreren Servern verfügbar sein. Bei der Replikation werden dieselben Datenbanken auf allen Servern synchron gehalten. Dies führt zu bester Leistung, Lastausgleich und Hochverfügbarkeit über Geographien und Netzwerke hinweg.

Wenn es um die Optimierung, Modernisierung oder Migration einer Anwendung geht, wollen und müssen Sie Folgendes wissen:

  • wie komplex eine Anwendung ist (denken Sie an Typen und Anzahl der Gestaltungselemente sowie an Codezeilen),
  • was der ganze Code bewirkt,
  • und ob der Code in Ihrem jeweiligen Projekt leicht zu handhaben ist.

Beginnen wir also mit dem Warum

Die meisten Entwickler haben nicht alle Anwendungen selbst entwickelt. Und falls doch (Hut ab!), so geschah es höchstwahrscheinlich nicht „alles gestern“, sondern über mehrere Jahre hinweg. Erinnern Sie sich noch gut genug an den Code in all Ihren Anwendungen?

Außerdem haben einige Firmen nicht einmal mehr einen Domino-Entwickler. Ganz zu schweigen von all denjenigen, die im Laufe der Jahre beim Aufbau der heutigen Anwendungslandschaft mitgeholfen haben.

Als nächstes ist die Kenntnis des Quellcodes einer Anwendung großartig, um sie so wie sie ist auf Domino laufen zu lassen und zu pflegen.

Schließlich möchte man alle Hindernisse sowie hilfreichen Code finden, bzw. ganz allgemein alles Gute, Schlechte und Hässliche.

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

Wäre es nicht großartig, wenn Sie sich wertvolle Zeit, Frustration und Fallstricke einfach ersparen könnten?

Das Wissen wer die Benutzer Ihrer Anwendungen sind wird noch nützlicher, wenn sie mit der Analyse von Design und Code Ihrer Anwendungen kombiniert wird.

Sobald Sie Ihre Interessensgruppen/Stakeholder kennen, werden Sie auch wissen:

  • Wer wird von Änderungen, die Sie an einer Anwendung vornehmen, betroffen sein?
  • Wie werden sie betroffen sein?
  • Wen sollten Sie konsultieren, bevor Sie Änderungen vornehmen?
  • Wem kommt die Arbeit, die Sie leisten, zugute?

Dies bringt uns zu der Frage „Was“

Bevor wir tiefer in das „Was Sie von Ihrem Code analysieren sollten“ eintauchen, denken Sie bitte daran:

Es gibt viele andere wichtige Datenpunkte, die vor der Analyse von Code zu berücksichtigen sind.

  • 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! Für weitere Details siehe auch hier und hier.
  • Welche Endbenutzer benötigen lokale Repliken aus Performance- oder Offline-Nutzungsgründen?
  • Welche Anwendungen nutzen Ihre VIPs und wichtigsten Profitcenter?

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

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

Nach allem, was drin ist. Punkt. In *allen* Ihren Anwendungen. Und für jede von ihnen bedeutet das

  • Allen Code: @Formeln, Java, JavaScript und LotusScript
  • Alle Gestaltungselemente (man denke an „Code-Container“). Dies können Masken, Untermasken, Ansichten, Spalten, Aktionen, Agenten, Schaltflächen, Skript-Bibliotheken usw. sein.
  • Die folgenden Designelemente verdienen oft besondere Aufmerksamkeit: XPages, Java-Klassen, Applets, Jar-Dateien, Webdienste, Funktionen von Composite Applications und ähnliches.

Eine ordnungsgemäße Analyse, sowohl der Elemente des Anwendungsdesigns, als auch des Codes beantwortet zwei wesentliche Fragen:

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

Die folgenden zwei Beispiele zeigen den Wert der Analyse von Design und Code:

a) Je mehr Masken, Felder und Code eine Anwendung hat, desto zeitaufwendiger ist die Modernisierung oder Migration der Anwendung

b) Eine Anwendung, die Java-Code verwendet, ist kein idealer Kandidat für eine Migration zu SharePoint. Ja, es hängt teilweise davon ab, was der entsprechende Code bewirkt. Dennoch hilft es Ihnen, Ihre Anwendungen zu kategorisieren und Fallstricke zu vermeiden.

Wonach Sie in Ihrem Code suchen sollten

Das Durchsuchen von Code kann gleichermaßen frustrierend und erheiternd sein – gemeinsam wollen wir für letzteres sorgen.

Nachdem Sie das Design Ihrer Anwendungen in DXL (Domino XML Language) exportiert haben, finden Sie hier drei Tipps, die Ihnen den Einstieg erleichtern:

  1. Starten Sie Notepad oder ähnliches und erkunden Sie das Ergebnis. Um ein erstes Gefühl zu bekommen, versuchen Sie, einen Teil Ihres Codes zu finden, indem Sie nach Teilen davon suchen. Suchen Sie auch nach Benutzernamen, Servernamen und Ähnlichem.
  2. Versuchen Sie es mit dem LotusScript Manager oder Source Sniffer von OpenNTF (verwenden Sie *nicht* Lotus Analyzer! Er wartet mit verborgenem Design auf und telefoniert nach Hause.)
  3. Pro-Challenge: Legen Sie die einzelnen Code-Blöcke aus dem 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, haben Sie vielleicht einige Mängel auf dem Weg dorthin bemerkt:

a) Ihre Suchergebnisse beinhalten ebenfalls Treffer aus Kommentaren/Bemerkungen in Ihrem Code.

b) Kombinierte Suchen wie @Db(Column OR Lookup) erfordern, dass die oben genannte Pro-Herausforderung zuerst angegangen wird. (= Speichern der Code-Blöcke in Notes/Domino-Dokumenten oder einer SQL-Datenbank). Getrennte Suchvorgänge führen zu doppelten Ergebnissen. Dies wiederum läuft Ihrem Ziel, so wenig Code wie möglich zu überprüfen, sehr zuwider.

c) Ihre Suchanfragen finden auch Code, nach dem Sie nicht gesucht haben. Zum Beispiel:

  • Die Suche nach „Open“ findet NotesDatabase[Objekt].Open und NotesStream[Objekt].Open
  • Die Suche nach „@DbLookup“ schließt Lookups in derselben Datenbank ein, in welcher der Code lebt. Möglicherweise möchten Sie jedoch nur nach @DbLookups suchen, die auf andere/externe Datenbanken zugreifen. Oder Ihr Ergebnis enthält auch Nicht-Notes-Lookups, wie z.B. ODBC. Vielleicht möchten Sie aber auch nur Notes-Lookups suchen.

Bevor wir also unsere Suche fortsetzen, müssen wir den Code optimieren

Für gute Suchergebnisse müssen wir alle Kommentare aus dem gesamten Code entfernen. Ja, es ist gut, Kommentare in Ihrem Code zu haben, um ihn später wieder besser verstehen zu können. 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 beliebig vielen Leerzeichen (=Leerzeichen oder Tabulatoren). Als nächstes folgt der eigentliche Kommentar, der entweder von doppelten Anführungszeichen oder geschwungenen Klammern umgeben ist.

Wir haben das bereits für Sie vorbereitet, damit Sie es KOSTENLOS testen können

Dieser gesamte Artikel hilft Ihnen, Ihre eigene, unabhängige Anwendungsanalyse zu verstehen und durchzuführen. Dennoch möchten Sie sich vielleicht wertvolle Zeit sparen und schneller vorankommen. Alles, was Sie tun müssen, ist sich für unsere Sandbox für iDNA Applications zu registrieren. Sobald Sie sich registriert haben, müssen Sie sich nur noch anmelden und zu unserer vorgefertigten Code-Sofort-Suche navigieren. Zugegeben, sie zeigt nicht Ihre eigenen Anwendungen, aber sie gibt Ihnen eine gute Vorstellung davon, wie Code-Suche funktionieren sollte.

Verwenden Sie zum Testen der Textsuche z.B. die folgenden Suchbegriffe: „florian“, „vogler“, „server“, „/acme“, „/O=acme“ und „workflow“. Versuchen Sie auch eine Suche mit regulären Ausdrücken wie z.B. „(?iw)@db(lookup|column)“.

Lassen Sie uns jetzt direkt in das WAS eintauchen, um *im gesamten* (Design und) Code Ihrer Anwendungen zu suchen:

Wenn Sie optimieren wollen:

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

Wenn Sie modernisieren wollen

  • Prüfen Sie, ob eine Anwendung stark auf NotesUI*-Klassen angewiesen ist. Das funktioniert nicht in Web-Browsern und muss überarbeitet werden.
    Suchen Sie nach Code, der in Browsern nicht unterstützt wird. Tipp: Suchen Sie in der Designer-Hilfe nach „Diese Funktion funktioniert nicht in Web-Anwendungen.“.
  • Gibt es bereits eine Menge Code, der auf Browser-Unterstützung hindeutet?
    z.B. @WebDbName, @BrowserInfo, @ClientType, Domino @DbCommands, …
  • Ist Ihre Anwendung/Ihr Code auf das Drucken von Dokumenten angewiesen? Das kann eine Herausforderung im Browser sein.
  • Analysieren Sie Ihren Code daraufhin, ob er in HCL Nomad (=Notes auf Smartphones und Tablets) funktioniert
    • Benötigt die Anwendung XPages, Java oder ODBC? Dies funktioniert nicht auf HCL Nomad.
    • Verwendet die Anwendung C-API-Aufrufe? Wenn ja, funktioniert der Code auch unter iOS und Android?

    Benötigt Ihre Anwendung irgendwelche Client-Erweiterungen von Drittanbietern?

  • Unabhängig vom Code: Finden Sie Ihre meistgenutzten/beliebtesten Datenbanken und geben Sie ihnen ein wenig Liebe. Machen Sie sie hübscher und moderner!

Wenn Sie migrieren möchten:

  • Wie viele Masken, Felder, Ansichten usw. hat eine Anwendung? Wählen Sie nicht zuerst die komplexesten.
  • Hängt Ihre Anwendung von Code- oder Designelementen ab, die auf Ihrer jeweiligen Zielplattform nicht gut funktionieren?
    Zum Beispiel: Java <> SharePoint, zu viele Ordner <> SharePoint. C-API. Privates oder öffentliches Adressbuch, Mail (Senden und) Verschlüsseln. , 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 (die also beispielsweise nicht „“:““ als server:filename Parameter verwenden). Dasselbe gilt für New NotesDatabase, GetDatabase, .Open, .OpenWithFailover, .OpenIfModified, .OpenByReplicaID, [FileOpenDatabase], [Compose] usw.
  • Unabhängig von Code und Migration: Schenken Sie einer Ihrer verbliebenen Datenbanken ein wenig Liebe, machen Sie sie hübscher und moderner!

Zum Schluss sehen wir uns an, WIE Sie Ihren Code am besten durchsuchen

Das Folgende ist wirklich, wirklich gruseliges Zeug. Wenn Sie kein Entwickler sind, können Sie diesen Abschnitt gerne überspringen!

Zu einem Teil haben wir bereits ausgeführt, warum die Suche nach Code mit einfachen (Teil-)Begriffen nicht allzu weit führt. In zu vielen Fällen finden Sie zu viel oder zu wenig. Wir haben auch dargelegt, warum es notwendig ist, alle Kommentare zu entfernen, bevor Sie Ihren Code durchsuchen.

Mehr Erfahren...

Auch das Folgende ist bei der Suche nach Code sehr, sehr, sehr wichtig:
Suchen Sie NICHT nach Code, indem Sie daran denken, wie Sie ihn entwickelt hätten. Denken Sie weiter und Sie werden ziemlich überrascht sein zu erfahren, wie andere Leute Code entwickeln.

Was also sind nun bessere Ansätze für die Suche nach Code, als nur einfach Teil-Begriffe?

Ein Volltext-Index, der Wildcards wie „*“ (Stern) unterstützt, bringt Sie etwas weiter. Zum Beispiel bei der Suche nach „@dbcolumn* OR @dblookup*“ – aber es fehlt die Unterstützung für eine präzise Negation. Die genaue Verneinung von Codeteilen ist wichtig, um z.B. nur @DbLookups zu finden, die nicht auf dieselbe Datenbank zeigen.

Das folgende @DbLookup liest Daten aus derselben Datenbank, in welcher der Code ausgeführt wird. Dies geschieht durch das „“:““ als zweiten Parameter:

Das nächste @DbLookup liest Daten aus dem „lokalen“ Adressbuch (Client oder Server, je nachdem, wo es läuft):

Sie sehen also, die Suche nach allen @DbLookups, die Daten im Adressbuch („names.nsf“) nachschlagen, ist also ziemlich einfach. Auch mit Platzhaltern, wie z.B.  @dblookup(*: „names.nsf „*). Jedenfalls so lange, bis Sie auf Code wie diesen hier stoßen:

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

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

Der obige Code liest Daten aus derselben Datenbank. Die Variable ht_filename ist das Ergebnis von @Subset(@DbName;-1). Daraus ergibt sich wiederum der Dateiname der Datenbank, in welcher der Code ausgeführt wird.

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

Die beste Lösung für die Suche nach Code wäre, wenn man den Code parsen (also Variablen auflösen) könnte. Dies würde uns erlauben, 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 Regular Expressions.

Die folgende Regular Expression ist ein großer Schritt nach vorn. Er erlaubt es uns, nach jedem @DbLookup zu suchen, dass Daten nicht aus derselben Datenbank ausliest, in welcher es ausgeführt wird:

@dblookup\([^;]*;(?!““(:““)?).*

@dblookup(Die offene Klammer muss in Regular Expressions maskiert werden, daher die \(
[^;]*;gefolgt von „alles außer einem Semikolon“ bis zum nächsten Semikolon. Die Suche nach „.*;“ wäre falsch, da dieser Ausdruck gierig wäre. Es würde bis zum letzten Semikolon gesucht werden.
(?!““(:““)?)gefolgt von einem verneinten „“, gefolgt von einem weiteren optionalen :““ – der zweite Parameter kann entweder „“ oder „“:““ sein
.*bis zum Ende der Zeile

Dieses Beispiel erfordert noch einige Feinabstimmung, um

  • auch jede Menge optionaler Leerzeichen zu unterstützen,
  • und für Situationen sorgen, in denen @dbname oder @subset(@dbname;1):@subset(@dbname;-1) die gleiche Datenbank verwenden
  • und nur diejenigen @DbLookups finden, für welche die Klasse „“ oder „Notes“ ist (unabhängig von Groß-/Kleinschreibung)

Als Bonuspunkte können Sie auch @dblookups finden, die in LotusScript-Auswertungen verwendet werden. Häufig müssen dann auch Anführungszeichen in dort verwendeten Formeln ausgenommen werden.

Die Regular Expression, die alle oben genannten Anforderungen (mit Ausnahme des Code-Parsings) erfüllt, ist … möglicherweise das hässlichste, was Sie heute zu sehen bekommen:

Related Posts

Ich könnte stundenlang so weitermachen

Wenn Sie das wirklich gruselige Zeug oben überstanden haben: Ich ziehe meinen Hut vor Ihnen! Sie sind ein Superheld-Entwickler und Überlebender der Regular Expressions.

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

Wenn Sie einen Blick in unsere Sandbox für iDNA Applications werfen, finden Sie dort mehr als 70 fertige Regular Expressions. Diese suchen nach über 300 verschiedenen Code-Vorkommen. Sie können all diese Muster KOSTENLOS in Ihrer ganz eigenen Code-Suchlösung verwenden.

Und nur für den Fall, dass Sie eine bessere Idee als die Verwendung Regular Expressions haben oder mit einigen neuen oder verbesserten Regular Expressions aufwarten können: Bitte lassen Sie es uns wissen, und wir werden es wiederum mit der Gemeinschaft teilen.

Für den Fall, dass Sie nicht die Zeit haben, Ihre eigene Code-Suchlösung zu entwickeln:

Es gibt eine Reihe von Drittanbieter-Lösungen, die helfen können. Einige von ihnen sind auf OpenNTF verfügbar. Einige von ihnen sind kommerzielle Lösungen wie unser panagenda iDNA Applications.

Zusammenfassung

Die ordnungsgemäße Analyse Ihrer Anträge dient drei Hauptzielen:

  • Einsparung von (viel) Zeit, Frustration und Geld
  • Sich auf die richtigen Dinge konzentrieren und im Bilde sein
  • Die erfolgreiche Transformation Ihrer Domino-Landschaft

Optimierung, Modernisierung oder Migration

  • Was auch immer Sie tun, vergessen Sie nicht, mindestens einer Ihrer Domino Anwendung etwas Liebe zu schenken. Sie wird es Ihnen zurückzahlen. Vielmals!

Next in our series

Scheuen Sie nicht davor, Ihren Erfolg zu teilen

Fortschrittsberichte. Sie sind Teil jedes Projekts und sie zu erstellen macht keinen besonderen Spaß. Es ist nicht nur Ihr Fortschritt, den Sie teilen müssen. Sie müssen den Projektteams auch die Daten zur Verfügung stellen, die sie für ihre Arbeit benötigen. Es ist schwer zu koordinieren und es endet scheinbar nie. Aber Fortschrittsberichte können Ihr Freund sein, wenn Sie Erfolg melden!

Fakten nutzen, damit es auch realistisch bleibt. Wissen Sie im Voraus Bescheid.

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 Ihr Projekt vor dem Scheitern bewahren? Manchmal kann man es nicht. Manche Projekte sind zum Scheitern verurteilt, bevor sie überhaupt begonnen haben. Erkennen Sie was Sie wissen sollten, bevor Sie loslegen.

Webinar: Don’t be afraid to share your success

Von nun an wird es eine kontinuierliche Erweiterung des Anwendungskreises sein, an dem wir arbeiten. Jeder Schritt wird kostenintensiver, und eine umsichtige Planung wird immer größere Vorteile bringen.

Click to access series overview!

Über diese Serie:

Unzählige Unternehmen weltweit setzen seit Jahrzehnten auf Notes/Domino*. Diese mächtige Applikations- und Kollaborationsplattform hat sich in vielen Unternehmen Zug um Zug als Fundament von Arbeitsweisen und etlichen Prozessen etabliert. Trotz alledem beginnen IT-Entscheidungsträger, sich eine Zukunft vorzustellen, in der Notes/Domino möglicherweise eine geringere oder gar keine Rolle mehr spielen könnte.

*formerly IBM Notes/Domino

Related Posts


Kommentar hinterlassen

Start typing and press Enter to search

Seeking application owners? Find its stakeholders first!People searching new team member