Codegenerator ausführen

Sie verwenden den Codegenerator, um die API-Services und den zugehörigen Code für die Implementierung der empfohlenen Partitionen zu generieren.

Vorbereitende Schritte

Stellen Sie sicher, dass die Systemvoraussetzungen und die folgenden Codegeneratorvoraussetzungen erfüllt sind.

Der Codegenerator muss Zugriff auf Folgendes haben:
- Das Verzeichnis cardinal , das im Verzeichnis mono2micro-output erstellt wurde (siehe AI-Engine zum Analysieren erfasster Daten ausführen). Dieses Verzeichnis enthält Partitionsinformationsdateien und andere Dateien, die der Codegenerator verwendet, einschließlich einer Konfigurationsdatei mit zwei anpassbaren Parametern.
- Der Quellcode der Monolith-Anwendung. Stellen Sie sicher, dass der Anwendungsquellcode exakt mit dem identisch ist, der verwendet wurde, um die Binärdatei während der Codeanalyse zu generieren, oder mit dem Code-Analyseprogramm während der Quellcodeanalyse. Der Codegenerator kopiert relevante Abschnitte aus dem Monolithen, um den refaktorierten Code zu generieren.
Der Benutzer, der den Codegenerator ausführt, muss Lese-und Schreibzugriff auf das gewünschte Ausgabeverzeichnis haben.

Passen Sie außerdem den Codegenerierungsprozess nach Bedarf an. Die Datei app.config.txt im Verzeichnis cardinal enthält zwei anpassbare Parameter.

ApplicationName: Der Name der Anwendung, für die ein Refactoring ausgeführt wurde Der Wert wird als Präfix für den generierten Code, die URL und die Annotationen verwendet.
CardinalOut-Pfad: Die Position in der Quellcodestruktur, an der Dienstprogrammklassencode generiert wird.

Vorgehensweise

Führen Sie den Codegenerator aus, um Refactoring-Code für die empfohlenen Partitionen zu generieren.

Prüfen Sie das Verzeichnis cardinal .
Ein Beispiel, das die Anwendung 'Daytrader' verwendet, wird angezeigt. Das Verzeichnis cardinal wird aus dem Verzeichnis mono2micro-output kopiert, das zuvor erstellt wurde (siehe AI-Engine zum Analysieren erfasster Daten ausführen), während für dieses Beispiel das Verzeichnis daytrader7-source aus https://github.com/WASdev/sample.daytrader7.gitgeklont wird.
```
transform-input
    ├── cardinal
    │   ├── app_config.txt
    │   ├── cardinal_graph.json
    │   ├── class_run.json
    │   ├── partition.txt
    │   ├── refTable.json
    │   └── symTable.json
    └── daytrader7-source
```
Führen Sie den Codegeneratorbefehl aus.
```
mono2micro transform -s <src-dir-path> -p <partition-info-dir-path>
```
In diesem Befehl ist <src-dir-path> der Pfadname für das Anwendungsquellcodeverzeichnis und <partition-info-dir-path> der Pfadname für das Verzeichnis cardinal , das von der KI-Engine erstellt wird.

Führen Sie den Befehl mono2micro transform --help aus, um weitere Informationen zum Befehl und seinen Optionen abzurufen.
Hinweise:
- Der Benutzer, der den Codegenerator ausführt, hat Lese-und Schreibzugriff auf das Verzeichnis <src-dir-path> , da der Codegenerator Berichte und Quellcode in Unterverzeichnissen des Verzeichnisses <src-dir-path> erstellt.
- Wenn Sie die Abbildung verwenden, in der das Monolith-Verzeichnis den Namen daytrader7-sourcehat, und wenn sich das von der KI-Engine generierte Verzeichnis cardinal im Pfad <dir-path> befindet, führen Sie den Codegenerator mit dem folgenden Befehl aus:
```
mono2micro transform -s <dir-path>/daytrader7-source -p <dir-path>/cardinal
```
Überwachen Sie den Fortschritt der Ausführung.

Je nach Anzahl der Partitionen und Größe des Monolithen variiert die Zeit für die Ausführung der Codegeneratortask.

Die Ausführung des Codegenerators erzeugt eine große Menge an Informationsnachrichten. In den meisten Fällen benötigen die Nachrichten keine besondere Aufmerksamkeit. Für mögliche Konfigurationsprobleme und für die allgemeine Verständigung ist jedoch eine Weiterleitung der Nachrichten in eine Datei für eine genauere Prüfung eine umsichtige Vorsichtsmaßnahme.

Wenn der Codegenerator erfolgreich ausgeführt wird, wird ein Verzeichnis cardinal-codegen im Verzeichnis <partition-info-dir-path> erstellt, das verschiedene Berichte enthält. Für jede Partition erstellt der Codegenerator ein Verzeichnis, das den Großteil des Codes enthält, der für seine Realisierung als potenzieller Mikroservice benötigt wird. Der Codegenerator kündigt die Fertigstellung und Erstellung eines Berichtsverzeichnisses an.

Ergebnisse

Eine erfolgreiche Beendigung des Codegenerators führt zu einer Verzeichnisstruktur, die der folgenden Daytrader-Verzeichnisstruktur ähnelt.

transform-input
    ├── cardinal
    │   ├── app_config.txt
    │   ├── cardinal-codegen
    │   │   ├── Cardinal-Utility-report.txt
    │   │   ├── Cardinal-partition0-report.txt
    │   │   ├── Cardinal-partition1-report.txt
    │   │   ├── Cardinal-partition2-report.txt
    │   │   ├── Cardinal-partition3-report.txt
    │   │   ├── Cardinal-partition4-report.txt
    │   │   ├── CardinalFileSummary.json
    │   │   ├── CardinalFileSummary.txt
    │   │   └── CardinalSings.json
    │   ├── cardinal_graph.json
    │   ├── class_run.json
    │   ├── instrumenter-config.json
    │   ├── partition.txt
    │   ├── refTable.json
    │   └── symTable.json
    ├── daytrader7-source
    ├── daytrader7-source-Utility
    ├── daytrader7-source-partition0
    ├── daytrader7-source-partition1
    ├── daytrader7-source-partition2
    ├── daytrader7-source-partition3
    └── daytrader7-source-partition4

In diesem Beispiel enthält die Partition daytrader-source-Utility Java ® monolithische Anwendungsklassen, die als potenzielle Dienstprogrammklassen identifiziert werden. Sie können diese Partition wie jede andere Partition zusammen mit dem von IBM Mono2Micro™ generierten Code behandeln oder Sie können diese Anwendungsklassen als .jar -Dienstprogrammdatei mit allen anderen Partitionen packen, die von den Klassen abhängig sind.

Die hervorgehobenen Verzeichnisse werden vom Codegenerator erstellt. Das Verzeichnis cardinal-codegen enthält verschiedene Berichte und verschiedene Partitionen werden in die Verzeichnisse xxx-partition_n geschrieben, wobei xxx für den Wert ApplicationName und n für die Partitionsnummer steht. Im Beispiel haben die Partitionen den Namen daytrader7-source-partition_n (wobei 0 < = n < = 4). Weitere Informationen finden Sie unter Angepasste Ansichten erstellen.

Jedes dieser xxx-partition_n-Verzeichnisse enthält die entsprechenden Teile des Quellcodes, der dem betrachteten Monolith entnommen wird. Die Ausgabe enthält, ist aber nicht beschränkt auf, transformationelle Zeilenumbrüche, API-Services, Code für verteilte Objektverwaltung und Aufräumfunktion. Das gesamte Verschieben und Generieren von Code erfolgt automatisch durch die Codegenerierungskomponente von Mono2Micro. Derzeit berücksichtigt der Codegenerator nur .java -Quellendateien; er kopiert oder generiert keine Konfigurations-oder Implementierungsinformationen aus dem Monolith. Für die tatsächliche Implementierung der Partitionen als Mikroservices müssen Sie die entsprechenden Konfigurationsinformationen angeben.

Der Inhalt des generierten inneren Ordners cardinal-codegen besteht aus verschiedenen Berichten. Die Cardinal-partition_n-report.txt -Dateien (0 < = n < = 4) sind die Java ® -Aufrufanalyseberichte für einzelne Partitionen im Textformat, wie in der Abbildung für partition_3 partitiondargestellt. Sie können die Option html beim Ausführen des Codegenerators angeben, um eine konsolidierte HTML-Version des Berichts zu generieren. Weitere Informationen finden Sie unter Cardinal-Bericht.

Beispielbericht Cardinal-partition_1-report.txt

Die Codegenerierungskomponente von Mono2Micro generiert die Datei CardinalFileSummary.txt , in der alle Schritte zum Generieren des Codes aufgeführt sind. Sie verwenden den Bericht für das Debugging, für ein tieferes Verständnis des Codegenerierungsprozesses und für die Suche nach dem generierten Code. Der Bericht dient nur zu Referenzzwecken und wird von keiner Komponente von Mono2Microverwendet.

Für jede Partition gibt es fünf Berichtskategorien im Bericht CardinalFileSummary.txt. In der nächsten Abbildung wird ein abgekürzter Beispielbericht angezeigt.

Beispiel für abgekürzten Bericht CardinalFileSummary.txt

Die fünf Kategorien von Berichten sind:

Proxy: Ein Bericht, der Stubklassen für jede Partition enthält, die auf Objekte zugreifen muss, die nicht lokal sind und zu anderen Partitionen gehören.
Service: Ein Bericht, der die APIs enthält, die für die Objekte der Partitionen erstellt wurden, auf die von außerhalb der Partition zugegriffen wird.
Original: Ein Bericht, der die ursprünglichen intakten Java-Dateien aus Monolith enthält. Auf diese Dateien wird nur lokal innerhalb der Partition zugegriffen.
Dummy: Ein Bericht, der die Dateien enthält, die bei der Analyse des statischen Quellcodes berücksichtigt wurden und nicht zur Laufzeit verwendet werden. Cardinal Exceptions werden zu diesen Dateien hinzugefügt, um sicherzustellen, dass geeignete Laufzeitausnahmebedingungen generiert werden, wenn sie ausgeführt werden. Diese Berichtskategorie informiert die Entwickler darüber hinaus über mögliche Abhängigkeiten zu diesen Dateien.
Helper: Ein Bericht, der generierten Code enthält, der Funktionen wie Serialisierung und Ausnahmen für die empfohlenen Partitionen und ihre entsprechenden Schnittstellen verarbeitet.

Der Bericht hat auch eine globale Kategorie:

Copied: Ein Bericht, der Klassen enthält, die keine Programmierlogik haben, aber für die Kompilierung der Partitionen erforderlich sind (z. B. Schnittstellen und abstrakte Klassen)

Der letzte Bericht im Verzeichnis cardinal-codegen ist CardinalSings.json. Diese Datei ist für die Verwendung durch Entwickler bestimmt. Dieser Bericht enthält die folgenden Inhalte:

Listet die Positionen auf, an denen Code geändert werden muss oder an denen eine detaillierte Inspektion erforderlich ist, um Partitionen als potenzielle Mikroservices zu implementieren
Listet Aktionselemente für Entwickler mit dem Schlüssel CARDINAL_TODO_T<number> auf, die entweder adressiert werden müssen oder die zur WARN-Variante gehören. Diese Warnungen weisen darauf hin, dass Entwickler Code bei Bedarf überprüfen und aktualisieren können. Tasks werden in Klassen- und Dateiebenen gruppiert. Der folgende Bericht zeigt die WARN TODOs beim Refactoring der Daytrader-Beispielanwendung. Detaillierte selbsterklärende Kommentare werden vom Codegenerator für jede CARDINAL_TODO_T<number> -Task bereitgestellt.