Esecuzione del generatore di codice

Utilizzare il generatore di codice per generare i servizi API e il relativo codice necessario per implementare le partizioni consigliate.

Prima di iniziare

Accertarsi di soddisfare i requisiti di sistema e i seguenti requisiti di generatore di codice.

Il generatore di codice deve avere accesso a:
- La directory cardinal creata nella directory mono2micro-output (consultare Esecuzione del motore AI per analizzare i dati raccolti). Questa directory contiene file di informazioni sulla partizione e altri file utilizzati dal programma di creazione del codice, incluso un file di configurazione con due parametri personalizzabili.
- Il codice sorgente dell'applicazione monolitica. Verificare che il codice sorgente dell'applicazione sia esattamente lo stesso utilizzato per generare il file binario durante l'analisi del codice o quello utilizzato durante l'esecuzione del programma di analisi del codice durante l'analisi del codice sorgente. Il generatore di codice copia le parti rilevanti dal monolite per creare il codice di cui è stato eseguito il refactoring.
L'utente che esegue il generatore di codice deve disporre dell'accesso in lettura e scrittura alla directory di output desiderata.

Inoltre, personalizzare il processo di generazione del codice in base alle necessità. Il file app.config.txt nella directory cardinal ha due parametri personalizzabili.

ApplicationName: Il nome dell'applicazione di cui è stato eseguito il refactoring. Il valore viene utilizzato come prefisso per codice generato, URL e annotazioni.
CardinalOutPath: La posizione nella struttura ad albero del codice di origine in cui viene generato il codice della classe del programma di utilità.

Procedura

Eseguire il generatore di codice per generare il codice di refactoring per le partizioni consigliate.

Esaminare la directory cardinal
Viene mostrato un esempio che utilizza l'applicazione Daytrader. La directory cardinal viene copiata dalla directory mono2micro-output creata in precedenza (vedere Esecuzione del motore AI per analizzare i dati raccolti ), mentre per questo esempio la directory daytrader7-source viene clonata da https://github.com/WASdev/sample.daytrader7.git.
```
trasformare l'ingresso
├─── cardinale
    │   ├── app_config.txt
    │   ├── cardinal_graph.json
    │   ├── class_run.json
    │   ├── partition.txt
│ ├── refTable.json
│ └── symTable.json
    └── daytrader7-source
```
Eseguire il comando generatore di codice.
```
mono2micro transform -s <src-dir-path> -p <partition-info-dir-path>
```
In questo comando, <src-dir-path> è il nome percorso per la directory del codice sorgente dell'applicazione e <partition-info-dir-path> è il nome percorso per la directory cardinal creata dal motore AI.

Per ottenere ulteriori informazioni sul comando e le relative opzioni, eseguire il comando mono2micro transform --help .
Considerazioni:
- L'utente che esegue il generatore di codice ha accesso in lettura e scrittura alla directory <src-dir-path> , poiché il generatore di codice creerà i report e il codice sorgente nelle sottodirectory nella directory <src-dir-path> .
- Utilizzando la figura in cui la directory monolith è denominata daytrader7-sourcee se la directory cardinal generata dal motore AI si trova entrambe nel percorso <dir-path> , si esegue il generatore di codice con il seguente comando:
```
mono2micro transform -s <dir-path>/daytrader7-source -p <dir-path>/cardinal
```
Monitorare i progressi dell'esecuzione.

A seconda del numero di partizioni e della dimensione del monolite, il tempo per completare l'attività del generatore di codice varia.

L'esecuzione del generatore di codice produce una grande quantità di messaggi informativi. Nella maggior parte dei casi, i messaggi non richiedono attenzione particolare. Tuttavia, per eventuali problemi di configurazione e per conoscenza generale, è consigliabile reindirizzare i messaggi ad un file per un esame più attento.

Se il generatore di codice viene completato correttamente, viene creata una directory cardinal-codegen all'interno della directory <partition-info-dir-path> che contiene diversi report. Per ogni partizione, il generatore di codice crea una directory che contiene la maggior parte del codice necessario per la sua realizzazione come un potenziale microservizio. Il generatore di codice annuncia il suo completamento e la creazione di una directory di report.

Risultati

Un corretto completamento del generatore di codice determina una struttura di directory simile alla seguente struttura di directory Daytrader.

trasformare l'ingresso
├─── cardinale
    │   ├── app_config.txt
│ ├─── cardinale-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 questo esempio, la partizione daytrader-source-Utility contiene classi di applicazioni monolitiche Java identificate come potenziali classi di utilità. È possibile trattare questa partizione come qualsiasi altra partizione insieme al codice IBM Mono2Micro generato, oppure si possono impacchettare queste classi applicative come un file di utilità .jar con tutte le altre partizioni che dipendono dalle classi.

Le directory evidenziate vengono create dal generatore di codice. La directory cardinal-codegen contiene diversi report e diverse partizioni vengono scritte nelle directory xxx-partition_n , dove xxx è il valore ApplicationName e n è il numero di partizione. Per l'esempio, le partizioni sono denominate daytrader7-source-partition_n (dove 0 < = n < = 4). Per ulteriori informazioni, consultare Creazione di viste personalizzate.

Ognuna di queste directory xxx-partition_n contiene le porzioni del codice sorgente appropriate prese dal monolite in esame. L'output include, ma non è limitato a, wrapper di trasformazione, servizi API, codice per la gestione degli oggetti distribuiti e la raccolta di dati inutilizzati. Tutto lo spostamento e la generazione del codice vengono eseguiti automaticamente dal componente di generazione del codice di Mono2Micro. Al momento il generatore di codice considera solo i file di origine .java ; non copia né genera alcuna informazione di configurazione o distribuzione dal monolite. Per la distribuzione effettiva delle partizioni come microservizi, è necessario fornire le informazioni di configurazione appropriate.

Il contenuto della cartella cardinal-codegen interna generata è costituito da vari report. I file Cardinal-partition_n-report.txt (dove 0 <= n <= 4) sono i rapporti di analisi delle invocazioni Java per le singole partizioni in forma di testo, come mostrato in figura per il file partition_3 partition. È possibile specificare l'opzione html durante l'esecuzione del generatore di codice per generare una versione HTML consolidata del report. Per ulteriori informazioni, consultare Cardinal-Report.

Report Cardinal-partition_1-report.txt di esempio

Il componente di creazione del codice di Mono2Micro genera il file CardinalFileSummary.txt , che descrive in dettaglio tutte le operazioni eseguite per generare il codice. Il report viene utilizzato per il debug, per una comprensione più profonda del processo di generazione del codice e per la ricerca del codice generato. Il report è solo per uso di riferimento e non è utilizzato da alcun componente di Mono2Micro.

Per ogni partizione sono disponibili cinque categorie di report nel report CardinalFileSummary.txt. Un breve report di esempio viene mostrato nella figura successiva.

Esempio di report abbreviato CardinalFileSummary.txt

Le cinque categorie di report sono:

Proxy: Un prospetto che contiene le classi stub per ogni partizione che deve accedere agli oggetti non locali e che appartengono ad altre partizioni.
Service: Un report che contiene le API create per gli oggetti delle partizioni a cui si accede dall'esterno della partizione.
Original: Un prospetto che contiene i file Java originali intatti dal monolite. A questi file si accede solo localmente all'interno della partizione.
Dummy: Un report che contiene i file raccolti durante l'analisi del codice sorgente statico non utilizzati in runtime. Cardinal Exceptions vengono aggiunti a questi file per garantire che le eccezioni di runtime appropriate vengano generate se vengono eseguite. Questa categoria di report informa anche gli sviluppatori sulle dipendenze potenziali su questi file.
Helper: Un prospetto che contiene il codice generato che gestisce funzioni quali la serializzazione e le eccezioni per le partizioni consigliate e le interfacce corrispondenti.

Il report ha anche una categoria globale:

Copied: Un prospetto che contiene classi che non hanno una logica di programmazione ma sono necessarie per la compilazione delle partizioni, come le interfacce e le classi astratte.

Il report finale nella directory cardinal-codegen è CardinalSings.json. Questo file è destinato all'utilizzo da parte degli sviluppatori. Questo report elenca il contenuto seguente:

Elenca le ubicazioni in cui è necessario modificare il codice o in cui è necessaria un'ispezione dettagliata per implementare le partizioni come potenziali microservizi.
Elenca gli elementi di azione per gli sviluppatori, con chiave CARDINAL_TODO_T<number>, che devono essere indirizzati o che sono della varietà WARN . Queste avvertenze danno indicazioni agli sviluppatori per l'ispezione e l'aggiornamento del codice, come necessario. Le attività sono raggruppate in livelli di classe e file. Il seguente report mostra WARN TODOs durante il refactoring dell'applicazione Daytrader di esempio. Il generatore di codice fornisce commenti dettagliati e autoesplicativi per ogni task di CARDINAL_TODO_T<number> .