Ejecución del generador de código

Utilice el generador de código para generar los servicios de API y el código relacionado necesario para implementar las particiones recomendadas.

Antes de empezar

Asegúrese de cumplir los requisitos del sistema y los siguientes requisitos de generador de código.

El generador de código debe tener acceso a:
- El directorio cardinal creado bajo el directorio mono2micro-output (consulte Ejecución del motor de IA para analizar los datos recopilados). Este directorio contiene archivos de información de partición y otros archivos que utiliza el generador de código, incluido un archivo de configuración con dos parámetros personalizables.
- El código fuente de la aplicación monolito. Asegúrese de que el código fuente de la aplicación sea exactamente el mismo que se ha utilizado para generar el archivo binario durante el análisis de código o el que se ha utilizado al ejecutar el analizador de código durante el análisis de código fuente. El generador de código copia las partes relevantes del monolito para generar el código refactorizado.
El usuario que ejecuta el generador de código debe tener acceso de lectura y escritura al directorio de salida deseado.

Además, personalice el proceso de generación de código según sea necesario. El archivo app.config.txt del directorio cardinal tiene dos parámetros personalizables.

ApplicationName: El nombre de la aplicación refactorizada. El valor se utiliza como prefijo para el código generado, el URL y las anotaciones.
CardinalOutPath: La ubicación en el árbol de código fuente donde se genera el código de clase de programa de utilidad.

Procedimiento

Ejecute el generador de código para generar código de refactorización para las particiones recomendadas.

Examine el directorio cardinal .
Se muestra un ejemplo que utiliza la aplicación Daytrader. El directorio cardinal se copia del directorio mono2micro-output que se creó anteriormente (véase Ejecución del motor de IA para analizar los datos recopilados ), mientras que para este ejemplo el directorio daytrader7-source se clona de https://github.com/WASdev/sample.daytrader7.git.
```
transform-input
├── cardenal
    │   ├── app_config.txt
    │   ├── cardinal_graph.json
    │   ├── class_run.json
    │   ├── partition.txt
│├── refTable.json
│ └── symTable.json
    └── daytrader7-source
```
Ejecute el mandato de generador de código.
```
mono2micro transform -s <src-dir-path> -p <partition-info-dir-path>
```
En este mandato, <src-dir-path> es el nombre de vía de acceso para el directorio de código fuente de la aplicación y <partition-info-dir-path> es el nombre de vía de acceso para el directorio cardinal creado por el motor de IA.

Para obtener más información sobre el mandato y sus opciones, ejecute el mandato mono2micro transform --help .
Consideraciones:
- El usuario que ejecuta el generador de código tiene acceso de lectura y escritura al directorio <src-dir-path> , porque el generador de código creará informes y código fuente en subdirectorios bajo el directorio <src-dir-path> .
- Utilizando la figura en la que el directorio de monolito se denomina daytrader7-source, y si el directorio cardinal que ha generado el motor de IA se encuentra en la vía de acceso <dir-path> , ejecute el generador de código con el mandato siguiente:
```
mono2micro transform -s <dir-path>/daytrader7-source -p <dir-path>/cardinal
```
Supervise el progreso de la ejecución.

Dependiendo del número de particiones y del tamaño del monolito, el tiempo para completar la tarea del generador de código varía.

La ejecución del generador de código genera una gran cantidad de mensajes informativos. En la mayoría de los casos, los mensajes no necesitan ninguna atención especial. Sin embargo, para los posibles problemas de configuración y para la comprensión general, sería prudente redirigir los mensajes a un archivo para un escrutinio más detallado.

Si el generador de código se completa correctamente, se crea un directorio cardinal-codegen dentro del directorio <partition-info-dir-path> que contiene varios informes. Para cada partición, el generador de código crea un directorio que contiene la mayor parte del código necesario para su realización como un microservicio potencial. El generador de código anuncia su finalización y la creación de un directorio de informes.

Resultados

Una finalización satisfactoria del generador de códigos da como resultado una estructura de directorios similar a la siguiente estructura de directorios de Daytrader.

transform-input
├── cardenal
    │   ├── 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

En este ejemplo, la partición daytrader-source-Utility contiene clases de aplicaciones monolíticas Java identificadas como posibles clases de utilidad. Puede tratar esta partición como cualquier otra partición junto con el IBM Mono2Micro código generado, o puede empaquetar estas clases de aplicación como un archivo de utilidad .jar con todas las demás particiones que dependen de las clases.

El generador de códigos crea los directorios resaltados. El directorio cardinal-codegen contiene varios informes y varias particiones se escriben en los directorios xxx-partition_n , donde xxx es el valor ApplicationName y n es el número de partición. Para el ejemplo, las particiones se denominan daytrader7-source-partition_n (donde 0 < = n < = 4). Para obtener más información, consulte Creación de vistas personalizadas.

Cada uno de estos directorios xxx-partition_n contiene las partes correspondientes del código fuente que se toma del monolito bajo consideración. La salida incluye, pero no se limita a, derivadores transformacionales, servicios de API, código para la gestión de objetos distribuidos y recogida de basura. Todo el movimiento y generación de código lo realiza automáticamente el componente de generación de código de Mono2Micro. Actualmente, el generador de código sólo tiene en cuenta los archivos de origen .java ; no copia ni genera ninguna información de configuración o despliegue del monolito. Para el despliegue real de las particiones como microservicios, debe proporcionar la información de configuración adecuada.

El contenido de la carpeta cardinal-codegen interna generada son varios informes. Los archivos Cardinal-partition_n-report.txt (donde 0 <= n <= 4) son los informes de análisis de invocación Java para particiones individuales en forma de texto, como se muestra en la figura para el partition_3 partition. Puede especificar la opción html mientras ejecuta el generador de código para generar una versión HTML consolidada del informe. Para obtener más información, consulte Cardinal-Report.

Ejemplo de informe Cardinal-partition_1-report.txt

El componente de generación de código de Mono2Micro genera el archivo CardinalFileSummary.txt , que detalla todos los pasos realizados para generar el código. Puede utilizar el informe para la depuración, para una comprensión más profunda del proceso de generación de código y para ver el código generado. El informe es sólo para uso de referencia y no lo utiliza ningún componente de Mono2Micro.

Para cada partición, hay cinco categorías de informes en el informe CardinalFileSummary.txt. En la siguiente figura se muestra un informe de ejemplo abreviado.

Ejemplo de informe abreviado CardinalFileSummary.txt

Las cinco categorías de informes son:

Proxy: Informe que contiene clases de apéndice para cada partición que necesita acceder a objetos que no son locales y pertenecen a otras particiones.
Service: Informe que contiene las API creadas para los objetos de las particiones a las que se accede desde fuera de la partición.
Original: Un informe que contiene los archivos Java intactos originales de monolito. A estos archivos solo se accede localmente dentro de la partición.
Dummy: Informe que contiene los archivos recogidos durante el análisis de código fuente estático que no se utilizan en tiempo de ejecución. Cardinal Exceptions se añaden a estos archivos para asegurarse de que se generan las excepciones de tiempo de ejecución adecuadas si se ejecutan. Esta categoría de informe también informa a los desarrolladores sobre las posibles dependencias de estos archivos.
Helper: Informe que contiene código generado que maneja funciones como la serialización y excepciones para las particiones recomendadas y sus interfaces correspondientes.

El informe también tiene una categoría global:

Copied: Informe que contiene clases que no tienen lógica de programación pero que son necesarias para compilar las particiones, como por ejemplo interfaces y clases abstractas.

El informe final bajo el directorio cardinal-codegen es CardinalSings.json. Este archivo está destinado a ser utilizado por los desarrolladores. Este informe lista el contenido siguiente:

Lista las ubicaciones en las que es necesario modificar el código o en las que es necesaria una inspección detallada para implementar particiones como microservicios potenciales.
Lista los elementos de acción de los desarrolladores, por clave como CARDINAL_TODO_T<number>, que deben abordarse o que son de la variedad WARN. Estos avisos aconsejan a los desarrolladores que inspeccionen y actualicen el código según sea necesario. Las tareas se agrupan en niveles de clase y de archivo. El informe siguiente muestra el WARN TODOs al refactorizar la aplicación Daytrader de ejemplo. El generador de código proporciona comentarios autoexplicativos detallados para cada tarea de CARDINAL_TODO_T<number> .