Executando o gerador de código

Você usa o gerador de código para gerar os serviços da API e o código relacionado necessário para implementar as partições recomendadas.

Antes de iniciar

Certise-se de atender aos requisitos do sistema e aos seguintes requisitos de gerador de código.

O gerador de código deve ter acesso a:
- O diretório cardinal criado sob o diretório mono2micro-output (consulte Running the AI engine para analisar dados coletados). Este diretório contém arquivos de informações de partição e outros arquivos que o gerador de código utiliza, incluindo um arquivo de configuração com dois parâmetros personalizáveis.
- O código-fonte do aplicativo monolith. Certifica-se de que o código-fonte do aplicativo é o exato mesmo que foi usado para gerar o arquivo binário durante a análise de código ou o usado ao executar o analisador de código durante análise de código-fonte. O gerador de código copia porções relevantes do monólito para gerar o código refatorado.
O usuário que executa o gerador de código deve ter acesso de leitura e gravação ao diretório de saída desejado.

Além disso, personalize o processo de geração de código conforme necessário. O arquivo app.config.txt no diretório cardinal tem dois parâmetros personalizáveis.

ApplicationName: O nome do aplicativo refatorado. O valor é usado como o prefixo para o código gerado, URL e anotações.
CardinalOutPath: O local na árvore de código-fonte onde o código de classe utilitário é gerado.

Procedimento

Execute o gerador de código para gerar código de refatoração para as partições recomendadas.

Examine o diretório cardinal .
Um exemplo que usa o aplicativo Daytrader é mostrado. O diretório cardinal é copiado do diretório mono2micro-output que foi criado anteriormente (consulte Executando o mecanismo de IA para analisar os dados coletados ), enquanto que, neste exemplo, o diretório daytrader7-source é clonado de https://github.com/WASdev/sample.daytrader7.git.
```
transformar-entrada
├── cardeal
    │   ├── app_config.txt
    │   ├── cardinal_graph.json
    │   ├── class_run.json
    │   ├── partition.txt
│ ├── refTable.json
│ └── symTable.json
    └── daytrader7-source
```
Executar o comando gerador de código.
```
mono2micro transform -s <src-dir-path> -p <partition-info-dir-path>
```
Neste comando, <src-dir-path> é o nome do caminho para o diretório de código-fonte do aplicativo e <partition-info-dir-path> é o nome do caminho para o diretório cardinal que é criado pelo motor AI.

Para obter mais informações sobre o comando e suas opções, execute o comando mono2micro transform --help .
Considerações sobre o :
- O usuário que executa o gerador de código tem acesso de leitura e gravação ao diretório <src-dir-path> , pois o gerador de código criará relatórios e código-fonte em subdiretórios sob o diretório <src-dir-path> .
- Usando a figura onde o diretório monolith é denominado daytrader7-source, e se o diretório cardinal que o motor AI gerou estão ambos localizados no caminho <dir-path> , você executa o gerador de código com o seguinte comando:
```
mono2micro transform -s <dir-path>/daytrader7-source -p <dir-path>/cardinal
```
Monitore o progresso da execução.

Dependendo do número de partições e do tamanho do monolito, o tempo para concluir a tarefa do gerador de código varia.

A execução do gerador de código produz uma grande quantidade de mensagens informativas. Na maioria das instâncias, as mensagens não precisam de atenção especial. No entanto, para possíveis problemas de configuração e para entendimento geral, é prudente redirecionar as mensagens para um arquivo para um exame mais detalhado.

Se o gerador de código for concluído com sucesso, um diretório cardinal-codegen será criado dentro do diretório <partition-info-dir-path> que contém vários relatórios. Para cada partição, o gerador de código cria um diretório contendo a maior parte do código necessário para a sua realização como um microserviço em potencial. O gerador de código anuncia sua conclusão e a criação de um diretório de relatórios.

Resultados

Uma conclusão bem-sucedida do gerador de código resulta em uma estrutura de diretórios semelhante à estrutura de diretórios Daytrader a seguir.

transformar-entrada
├── cardeal
    │   ├── 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

Neste exemplo, a partição daytrader-source-Utility contém classes de aplicativos monolíticos Java identificadas como possíveis classes de utilitários. Você pode tratar essa partição como qualquer outra partição junto com o IBM Mono2Micro código gerado, ou pode empacotar essas classes de aplicativo como um arquivo .jar utilitário com todas as outras partições que dependem das classes.

Os diretórios destacados são criados pelo gerador de código. O diretório cardinal-codegen contém vários relatórios, e várias partições são escritas nos diretórios xxx-partition_n , onde xxx é o valor ApplicationName e n é o número da partição. Para o exemplo, as partições são nomeadas daytrader7-source-partition_n (onde 0 < = n < = 4). Para obter mais informações, consulte Criando visualizações customizadas

Cada um desses diretórios xxx-partition_n contém as partes apropriadas do código-fonte extraído do monolítico em consideração. A saída inclui, mas não está limitada a, wrappers transformacionais, serviços de API, código para gerenciamento de objetos distribuídos e coleta de lixo. Toda a movimentação e a geração de códigos são feitas automaticamente pelo componente de geração de códigos do Mono2Micro No momento, o gerador de código considera apenas os arquivos de origem .java ; ele não copia ou gera nenhuma informação de configuração ou de implementação do monolito. Para a implementação real das partições como microsserviços, deve-se fornecer as informações de configuração apropriadas.

O conteúdo da pasta cardinal-codegen interna gerada são vários relatórios. Os arquivos Cardinal-partition_n-report.txt (onde 0 <= n <= 4) são os relatórios de análise de invocação Java para partições individuais em formato de texto, conforme mostrado na figura para o partition_3 partition. Você pode especificar a opção html enquanto executa o gerador de código para gerar uma versão HTML consolidada do relatório. Para obter mais informações, consulte Relatório Cardinal.

Relatório Cardinal-partition_1-report.txt

O componente de geração de código do Mono2Micro gera o arquivo CardinalFileSummary.txt , que detalha todas as etapas executadas para gerar o código.. Você usa o relatório para depuração, para uma compreensão mais profunda do processo de geração de código, e para olhar o código gerado. O relatório é apenas para uso de referência e não é usado por nenhum componente de Mono2Micro

Para cada partição, há cinco categorias de relatórios no relatório CardinalFileSummary.txt. Um relatório de amostra abreviado é mostrado na figura ao lado.

Exemplo de relatório CardinalFileSummary.txt abreviado

As cinco categorias de relatórios são:

Proxy: Um relatório que contém aulas de stub para cada partição que precisa acessar objetos que não são locais e pertencem a outras partições.
Service: Um relatório que contém as APIs criadas para os objetos das partições que são acessadas de fora da partição.
Original: Um relatório que contém os arquivos Java intactos originais de monolith. Esses arquivos são acessados apenas localmente dentro da partição.
Dummy: Um relatório que contém os arquivos captados durante análise de código-fonte estática que não são usados em tempo de execução. Cardinal Exceptions são adicionados a esses arquivos para garantir que exceções de tempo de execução apropriadas sejam geradas se forem executadas. Esta categoria de relatório também informa os desenvolvedores sobre potenciais dependências nesses arquivos.
Helper: Um relatório que contém código gerado que manipula tais funções como serialização e exceções para as partições recomendadas e suas interfaces correspondentes.

O relatório também tem uma categoria global:

Copied: Um relatório que contém classes que não possuem lógica de programação mas são necessárias para compilar as partições, como interfaces e classes abstratas.

O relatório final no diretório cardinal-codegen é CardinalSings.json. Este arquivo é destinado ao uso por desenvolvedores. Este relatório lista o seguinte conteúdo:

Lista os locais em que o código precisa ser alterado ou onde a inspeção detalhada é necessária para implementar partições como potenciais microserviços.
Lista itens de ação para desenvolvedores, chaveados como CARDINAL_TODO_T<number>, que devem ser abordados, ou que são da variedade WARN. Esses avisos aconselham os desenvolvedores a inspecionar e atualizar o código conforme necessário. As tarefas são agrupadas em níveis de classe e de arquivo. O relatório a seguir mostra o WARN TODOs enquanto refatora a aplicação Daytrader de amostra. Comentários detalhados e autoexplicativos são fornecidos pelo gerador de código para cada tarefa do CARDINAL_TODO_T<number> .