AWS Estructura de Blu Age de una aplicación modernizada

Este documento proporciona detalles sobre la estructura de las aplicaciones modernizadas (mediante las herramientas de refactorización de la modernización del AWS mainframe), de modo que los desarrolladores puedan realizar diversas tareas, como:

• Navegar por las aplicaciones sin problemas.

• Desarrollar programas personalizados a los que se pueda acceder desde las aplicaciones modernizadas.

• Refactorizar de forma segura las aplicaciones modernizadas.

Damos por supuesto que ya tiene conocimientos básicos sobre lo siguiente:

• conceptos de codificación comunes heredados, como los registros, los conjuntos de datos y sus modos de acceso a los registros (indexados, secuenciales), unidades de ejecuciónVSAM, scripts jcl, conceptos, etc. CICS

• codificación Java utilizando el marco de Spring

• A lo largo del documento, utilizamos short class names para facilitar la lectura. Para obtener más información, consulte AWS Asignaciones de nombres totalmente calificadas de Blu Age Recuperar los nombres completos correspondientes a los elementos de tiempo de ejecución de AWS Blu Age y recuperar los nombres completos correspondientes Asignaciones de nombres totalmente cualificadas de terceros a los elementos de terceros.

• Todos los artefactos y muestras se toman de los resultados del proceso de modernización de la COBOL CICS CardDemo muestra/aplicación.

Organización de artefactos

AWS Las aplicaciones modernizadas de Blu Age se empaquetan como aplicaciones web java (.war), que se pueden implementar en un JEE servidor. Normalmente, el servidor es una instancia de Tomcat que incorpora el tiempo de ejecución de AWS Blu Age, que actualmente se basa en los marcos Springboot y Angular (para la parte de la interfaz de usuario).

La aplicación war agrega varios artefactos de componentes (.jar). Cada artefacto jar es el resultado de la compilación (con la herramienta maven) de un proyecto Java específico cuyos elementos son el resultado del proceso de modernización.

La organización básica se basa en la siguiente estructura:

• Proyecto de entidades: contiene elementos del modelo de negocio y del contexto. El nombre del proyecto generalmente termina con “-entities”. Por lo general, para un COBOL programa heredado determinado, esto corresponde a la modernización de la sección de E/S (conjuntos de datos) y la división de datos. Puede tener más de un proyecto de entidades.

• Proyecto de servicio: contiene elementos de modernización de la lógica empresarial heredados. Normalmente, la división de procedimientos de un COBOL programa. Puede tener más de un proyecto de servicio.

• Proyecto de utilidad: contiene herramientas y utilidades comunes compartidas, utilizadas por otros proyectos.

• Proyecto web: contiene la modernización de los elementos relacionados con la interfaz de usuario cuando corresponde. No se utiliza para proyectos de modernización únicamente por lotes. Estos elementos de la interfaz de usuario pueden provenir de CICS BMS mapas, IMS MFS componentes y otras fuentes de interfaz de usuario de mainframe. Puede tener más de un proyecto web.

Contenido de proyecto de entidades

nota

Las siguientes descripciones solo se aplican a los resultados de COBOL modernización de PL/I. RPGlos resultados de la modernización se basan en un diseño diferente.

Antes de cualquier refactorización, la organización de los paquetes en el proyecto de la entidad está vinculada a los programas modernizados. Puede lograr esto de dos maneras diferentes. La forma preferida es utilizar la caja de herramientas de refactorización, que funciona antes de activar el mecanismo de generación de código. Se trata de una operación avanzada, que se explica en las BluAge capacitaciones. Para obtener más información, consulte el taller Refactorings. Este enfoque le permite conservar la capacidad de volver a generar el código Java más adelante, para beneficiarse de nuevas mejoras en el futuro, por ejemplo). La otra forma es realizar una refactorización de Java regular, directamente sobre el código fuente generado, utilizando cualquier enfoque de refactorización de Java que desee aplicar, bajo su propia responsabilidad.

Clases relacionadas con el programa

Cada programa modernizado está relacionado con dos paquetes, un paquete business.context y un paquete business.model.

• base package.program.business.context

  El subpaquete business.context contiene dos clases, una clase de configuración y una clase de contexto.

  • Una clase de configuración para el programa, que contiene detalles de configuración específicos para el programa en cuestión, como el juego de caracteres que se utilizará para representar los elementos de datos basados en caracteres, el valor de bytes predeterminado para rellenar los elementos de la estructura de datos, etc. El nombre de la clase termina con “Configuration”. Está marcado con la anotación @org.springframework.context.annotation.Configuration y contiene un único método que debe devolver un objeto Configuration configurado correctamente.

    

  • Una clase de contexto, que sirve de puente entre las clases de servicios del programa (véase más abajo) y las estructuras de datos (Record) y los conjuntos de datos (File) del subpaquete del modelo (véase más abajo). El nombre de la clase termina con "Context" y es una subclase de la clase RuntimeContext.

    

• base package.program.business.model

  El subpaquete del modelo contiene todas las estructuras de datos que puede utilizar el programa en cuestión. Por ejemplo, cualquier estructura de COBOL datos de nivel 01 corresponde a una clase del subpaquete del modelo (las estructuras de datos de nivel inferior son propiedades de la estructura de nivel 01 que la poseen). Para obtener más información sobre cómo modernizamos estructuras de datos 01, consulte ¿Qué son los simplificadores de datos en AWS Blu Age?.

  

Todas las clases amplían la clase RecordEntity, que representa el acceso a una representación de un registro empresarial. Algunos de los registros tienen un propósito especial, ya que están vinculados a un File. El enlace entre a Record y a File se realiza en los FileHandler métodos * correspondientes que se encuentran en la clase de contexto al crear el objeto de archivo. Por ejemplo, en la siguiente lista se muestra cómo TransactfileFile File se vincula a transactFile Record (del subpaquete modelo).

Contenido del proyecto de servicio

Cada proyecto de servicio incluye una aplicación Springboot dedicada, que se utiliza como columna vertebral de la arquitectura. Esto se materializa a través de la clase denominada SpringBootLauncher, ubicada en el paquete base de los orígenes Java del servicio:

Esta clase es, en particular, responsable de:

• Hacer de enlace entre las clases de programas y los recursos administrados (orígenes de datos / administradores de transacciones / asignaciones de conjuntos de datos / etc...).

• Proporcionar un ConfigurableApplicationContext a los programas.

• Descubrir todas las clases marcadas como componentes de Spring (@Component).

• Garantizar que los programas están registrados correctamente en el ProgramRegistry. Consulte el método de inicialización responsable de este registro.

Artefactos relacionados con el programa

Sin necesidad de una refactorización previa, las salidas de la modernización de la lógica empresarial se organizan en dos o tres paquetes por programa tradicional:

El caso más exhaustivo constará de tres paquetes:

• base package.program.service: contiene una interfaz denominada ProgramProcess, que cuenta con métodos empresariales para gestionar la lógica empresarial y preservar el flujo de control de ejecución tradicional.

• base package.program.service.impl: contiene una clase denominada ProgramProcessImpl, que es la implementación de la interfaz de proceso descrita anteriormente. Aquí es donde las declaraciones heredadas se «traducen» a declaraciones de Java, basándose en el marco de AWS Blu Age:

  

• base package.program.statemachine: es posible que este paquete no esté siempre presente. Es necesaria cuando la modernización del flujo de control heredado tiene que utilizar un enfoque de máquina de estados (es decir, utilizar el StateMachine marco Spring) para cubrir adecuadamente el flujo de ejecución heredado.

  En ese caso, el subpaquete statemachine contiene dos clases:

  • ProgramProcedureDivisionStateMachineController: una clase que amplía una clase que implementa las interfaces StateMachineController (define las operaciones necesarias para controlar la ejecución de una máquina de estados) y StateMachineRunner (define las operaciones necesarias para ejecutar una máquina de estados), utilizadas para controlar la mecánica de la máquina de estados de Spring; por ejemplo, SimpleStateMachineController como en el caso de muestra.

    

    El controlador de la máquina de estados define los diferentes estados posibles y las transiciones entre ellos, lo que reproduce el flujo de control de ejecución heredado para el programa dado.

    Al crear la máquina de estados, el controlador hace referencia a los métodos que se definen en la clase de servicio asociada ubicada en el paquete de la máquina de estados y que se describen a continuación:

    
    subConfigurer.state(States._0000_MAIN, buildAction(() -> {stateProcess._0000Main(lctx, ctrl);}), null);
    subConfigurer.state(States.ABEND_ROUTINE, buildAction(() -> {stateProcess.abendRoutine(lctx, ctrl);}), null);
            

  • ProgramProcedureDivisionStateMachineService: esta clase de servicio representa una parte de la lógica empresarial que debe estar vinculada a la máquina de estados que crea el controlador de la máquina de estados, como se describió anteriormente.

    El código de los métodos de esta clase utiliza los eventos definidos en el controlador de la máquina de estados:

    
    

    El servicio statemachine también realiza llamadas a la implementación del servicio de procesos descrita anteriormente:

    

Además, un paquete base package.program desempeña un papel importante, ya que reúne una clase por programa, que servirá como punto de entrada al programa (más detalles sobre esto más adelante). Cada clase implementa la interfaz de Program, marcador del punto de entrada del programa.

Otros artefactos

• BMSMAPsacompañantes

  Además de los artefactos relacionados con el programa, el proyecto de servicio puede contener otros artefactos para diversos fines. En el caso de la modernización de una aplicación CICS en línea, el proceso de modernización genera un archivo json y lo coloca en la carpeta de mapas de la carpeta /src/main/resources:

  

  El motor de ejecución de Blu Age consume esos archivos json para vincular los registros utilizados por la SEND MAP declaración con los campos de la pantalla.

• Scripts groovy

  Si la aplicación antigua tenía JCL scripts, estos se han modernizado como scripts geniales y se guardan en la carpeta /src/main/resources/scripts (hablaremos de esa ubicación específica más adelante):

  

  Estos scripts se utilizan para lanzar trabajos por lotes (cargas de trabajo de procesamiento de datos dedicadas, no interactivas y con un uso intensivo de la CPU).

• SQLarchivos

  Si la aplicación antigua utilizaba SQL consultas, las consultas modernizadas correspondientes se recopilaron en archivos de propiedades dedicados, con el programa de patrones de nomenclatura .sql, donde program es el nombre del programa que utiliza esas SQL consultas.

  

  El contenido de esos archivos sql es una colección de entradas (clave=consulta), donde cada consulta está asociada a una clave única, que el programa modernizado utiliza para ejecutar la consulta en cuestión:

  

  Por ejemplo, el programa COSGN 00C ejecuta la consulta con la clave "COSGN00C_1" (la primera entrada del archivo sql):

  

Contenido de proyecto de utilidades

El proyecto de utilidades, cuyo nombre termina con "-tools", contiene un conjunto de utilidades técnicas que podrían ser utilizadas por todos los demás proyectos.

Contenido de los proyectos web

El proyecto web solo está presente al modernizar los elementos de la interfaz de usuario heredados. Los elementos de la interfaz de usuario moderna que se utilizan para crear la interfaz de usuario modernizada de la aplicación se basan en Angular. La aplicación de ejemplo que se utiliza para mostrar los artefactos de modernización es una CICS aplicaciónCOBOL/, que se ejecuta en un ordenador central. El CICS sistema se utiliza MAPs para representar las pantallas de la interfaz de usuario. Los elementos modernos correspondientes serán, para cada mapa, un archivo html acompañado de archivos TypeScript:

El proyecto web solo se ocupa del aspecto inicial de la aplicación. El proyecto de servicio, que se basa en los proyectos de utilidades y entidades, proporciona los servicios de backend. El enlace entre el front-end y el backend se realiza a través de la aplicación web llamada Gapwalk-Application, que forma parte de la distribución estándar de tiempo de ejecución de Blu Age. AWS

Ejecutar y llamar a programas

En los sistemas heredados, los programas se compilan como ejecutables independientes que pueden ejecutarse a sí mismos mediante un CALL mecanismo, como una sentencia, pasando argumentos cuando es necesario. COBOL CALL Las aplicaciones modernizadas ofrecen la misma capacidad, pero utilizan un enfoque diferente, ya que la naturaleza de los artefactos involucrados difiere de la de los antiguos.

Desde el punto de vista modernizado, los puntos de entrada de los programas son clases específicas que implementan la interfaz de Program, son componentes de Spring (@Component) y se encuentran en proyectos de servicio, en un paquete denominado base package.program.

Registro de programas

Cada vez que se inicia el servidor Tomcat que aloja las aplicaciones modernizadas, también se inicia la aplicación Springboot del servicio, lo que desencadena el registro del programa. Un nombre de registro específico ProgramRegistry se rellena con entradas de programa, y cada programa se registra con sus identificadores, una entrada por cada identificador de programa conocido, lo que significa que si un programa es conocido por varios identificadores diferentes, el registro contiene tantas entradas como identificadores.

El registro de un programa determinado se basa en la colección de identificadores devueltos por el método getProgramIdentifiers ():

En este ejemplo, el programa se registra una vez, con el nombre 'CBACT04C' (fíjese en el contenido de la programIdentifiers colección). Los registros tomcat muestran todos los registros del programa. El registro del programa solo depende de los identificadores del programa declarados y no del nombre de la clase del programa en sí (aunque normalmente los identificadores y los nombres de las clases del programa se corresponden).

El mismo mecanismo de registro se aplica a los programas utilitarios incluidos en las distintas aplicaciones web de utilidad AWS Blu Age, que forman parte de la distribución en tiempo de ejecución de AWS Blu Age. Por ejemplo, la aplicación web Gapwalk-Utility-Pgm proporciona los equivalentes funcionales de las utilidades del sistema z/OS (IDCAMS,, ICEGENERSORT, etc.) y puede invocarse mediante programas o scripts modernizados. Todos los programas de utilidades disponibles que se registran al iniciar Tomcat se registran en los registros de Tomcat.

Registro de scripts y daemons

En el momento de iniciar Tomcat, se produce un proceso de registro similar para los scripts groovy que se encuentran en la jerarquía de carpetas /src/main/resources/scripts. Se recorre la jerarquía de carpetas de scripts y todos los scripts groovy que se descubren (excepto el script reservado functions.groovy especial) se registran en el ScriptRegistry, utilizando su nombre abreviado (la parte del nombre del archivo de script que aparece antes del primer punto) como clave para la recuperación.

nota

• Si varios scripts tienen nombres de archivo que dan como resultado la misma clave de registro, solo se registra la última, lo que sobrescribe cualquier registro que se haya encontrado anteriormente para esa clave determinada.

• Teniendo en cuenta lo anterior, preste atención al utilizar subcarpetas, ya que el mecanismo de registro aplana la jerarquía y podría provocar sobrescrituras inesperadas. La jerarquía no se tiene en cuenta en el proceso de registro: lo normal es que /scripts/A/myscript.groovy y /scripts/B/myscript.groovy provoquen que /scripts/B/myscript.groovy sobrescriba /scripts/A/myscript.groovy.

Los scripts groovy de la carpeta /src/main/resources/daemons se gestionan de forma un poco diferente. Se siguen registrando como scripts normales, pero además, se lanzan una vez, directamente al iniciar Tomcat, de forma asíncrona.

Una vez registrados los scripts en, se puede iniciar una REST llamada utilizando los puntos finales ScriptRegistry específicos que expone la aplicación Gapwalk. Para obtener más información, consulte la documentación correspondiente.

Programas que llaman a programas

Un programa puede llamar a otro programa como subprograma, pasándole parámetros. Para ello, los programas utilizan una implementación de la ExecutionController interfaz (la mayoría de las veces, se trata de una ExecutionControllerImpl instancia), junto con un API mecanismo fluido denominado el para crear los argumentos de las llamadas CallBuilder al programa.

Todos los métodos de los programas utilizan RuntimeContext y ExecutionController como argumentos de método, por lo que ExecutionController siempre está disponible para llamar a otros programas.

Véase, por ejemplo, el siguiente diagrama, que muestra cómo el programa CBST 03A llama al programa CBST 03B como un subprograma y le pasa los parámetros:

• El primer argumento de ExecutionController.callSubProgram es un identificador del programa al que se va a llamar (es decir, uno de los identificadores utilizados para el registro del programa; consulte los párrafos anteriores).

• El segundo argumento, que es el resultado de la creación de CallBuilder, es una matriz de Record, que corresponde a los datos que se transmiten del programa que hace la llamada al programa que recibe la llamada.

• El tercer y último argumento es la instancia RuntimeContext del programa que hace la llamada.

Los tres argumentos son obligatorios y no pueden ser nulos, pero el segundo argumento puede ser una matriz vacía.

El programa que llama solo podrá procesar los parámetros transmitidos si se ha diseñado originalmente para ello. Para un COBOL programa heredado, eso significa tener una LINKAGE sección y una USING cláusula para que la división de procedimientos haga uso de los elementos. LINKAGE

Por ejemplo, consulte la CBSTM03B correspondiente. CBLCOBOLarchivo fuente:

Por lo tanto, el programa CBSTM 03B toma un single Record como parámetro (una matriz de tamaño 1). Esto es lo que CallBuilder está creando, usando el encadenamiento de los métodos byReference getArguments () y ().

La API clase CallBuilder fluent tiene varios métodos disponibles para rellenar la matriz de argumentos que se van a pasar a la persona que llama:

• asPointer(RecordAdaptable): agrega un argumento tipo puntero, como referencia. El puntero representa la dirección de una estructura de datos de destino.

• byReference(RecordAdaptable): agrega un argumento por referencia. El programa que hace la llamada verá las modificaciones que realiza el programa que recibe la llamada.

• byReference(RecordAdaptable): variante varargs del método anterior.

• byValue(Objeto): agrega un argumento, transformado en unRecord, por valor. El programa que hace la llamada no verá las modificaciones que realiza el programa que recibe la llamada.

• byValue(RecordAdaptable): igual que el método anterior, pero el argumento está disponible directamente comoRecordAdaptable.

• byValueWithLímites (Object, int, int): agrega un argumento, transformado en aRecord, extrayendo la parte de la matriz de bytes definida por los límites dados, por valor.

Por último, el getArguments método recopilará todos los argumentos agregados y los devolverá como una matriz de. Record

nota

Es responsabilidad del programa que hace la llamada asegurarse de que la matriz de argumentos tenga el tamaño requerido, que los elementos estén ordenados correctamente y que sean compatibles, en términos de diseño de memoria, con los diseños esperados para los elementos de enlace.

Scripts que llaman a programas

Para llamar a programas registrados desde scripts groovy, es necesario usar una instancia de clase que implemente la interfaz de MainProgramRunner. Por lo general, obtener una instancia de este tipo se logra mediante el ApplicationContext uso de Spring:

Cuando haya una MainProgramRunner interfaz disponible, utilice el runProgram método para llamar a un programa y pase el identificador del programa de destino como parámetro:

En el ejemplo anterior, se llama a un paso de trabajo IDCAMS (programa utilitario de manejo de archivos), lo que proporciona un mapeo entre las definiciones reales de los conjuntos de datos y sus identificadores lógicos.

Cuando se trata de conjuntos de datos, los programas antiguos utilizan principalmente nombres lógicos para identificar los conjuntos de datos. Cuando se llama al programa desde un script, el script debe hacer corresponder los nombres lógicos con los conjuntos de datos físicos reales. Estos conjuntos de datos podrían estar en el sistema de archivos, en un almacenamiento de Blusam o incluso estar definidos por un flujo en línea, la concatenación de varios conjuntos de datos o la generación de un. GDG

Utilice el withFileConfiguration método para crear un mapa lógico a físico de conjuntos de datos y ponerlo a disposición del programa llamado.

Escriba su propio programa

Escribir un programa propio para ejecutar scripts u otros programas modernizados es una tarea habitual. Por lo general, en los proyectos de modernización, se escriben programas propios cuando un programa ejecutable antiguo está escrito en un lenguaje que el proceso de modernización no admite, o cuando los orígenes se han perdido (sí, eso puede suceder), o cuando el programa es una utilidad cuyos orígenes no están disponibles.

En ese caso, puede que tenga que escribir el programa que falta, en Java, usted mismo (suponiendo que tenga suficiente conocimiento sobre cuál debería ser el comportamiento esperado del programa, el diseño de memoria de los argumentos del programa, si los hubiera, etc.) Su programa Java debe cumplir con la mecánica del programa descrita en este documento, de modo que otros programas y scripts puedan ejecutarlo.

Para asegurarse de que el programa se puede utilizar, debe completar dos pasos obligatorios:

• Escriba una clase que implemente la interfaz de Program correctamente, de modo que se pueda registrar y llamar a ella.

• Asegúrese de que el programa esté registrado correctamente, de modo que sea visible desde otros programas/scripts.

Escribir la implementación del programa

Utilice el suyo IDE para crear una nueva clase java que implemente la Program interfaz:

La siguiente imagen muestra el EclipseIDE, que se encarga de crear todos los métodos obligatorios que deben implementarse:

Integración con Spring

En primer lugar, la clase debe declararse como un componente de Spring. Anote la clase con la anotación @Component:

A continuación, implemente los métodos requeridos correctamente. En el contexto de este ejemplo, añadimos el paquete MyUtilityProgram que ya contiene todos los programas modernizados. Esa ubicación permite al programa usar la aplicación Springboot existente para proporcionar lo necesario ConfigurableApplicationContext para la implementación del getSpringApplication método:

Puede elegir una ubicación diferente para su programa. Por ejemplo, puede ubicar el programa en otro proyecto de servicio dedicado. Asegúrese de que el proyecto de servicio en cuestión tenga su propia aplicación Springboot, que permita recuperar el ApplicationContext (que debería ser unConfigurableApplicationContext).

Dar una identidad al programa

Para que otros programas y scripts puedan invocarlo, el programa debe tener al menos un identificador, que no debe colisionar con ningún otro programa registrado existente en el sistema. La elección del identificador puede deberse a la necesidad de sustituir un programa antiguo existente; en ese caso, tendrás que usar el identificador esperado, tal y como CALL ocurre en los programas antiguos. La mayoría de los identificadores del programa tienen una longitud de 8 caracteres en los sistemas antiguos.

Crear un conjunto de identificadores no modificables en el programa es una forma de hacerlo. En el siguiente ejemplo, se muestra la elección de MYUTILPG "» como identificador único:

Asocie el programa a un contexto

El programa necesita una instancia de RuntimeContext complementaria. Para los programas modernizados, AWS Blu Age genera automáticamente el contexto complementario, utilizando las estructuras de datos que forman parte del programa anterior.

Si está escribiendo su propio programa, también debe escribir el contexto complementario.

Consulte Clases relacionadas con el programa para ver que un programa requiere al menos dos clases complementarias:

• una clase de configuración

• una clase de contexto que usa la configuración

Si el programa de utilidades usa alguna estructura de datos adicional, también debería escribirse y usarse según el contexto.

Esas clases deben estar en un paquete que forme parte de una jerarquía de paquetes que se escaneará al iniciar la aplicación, para garantizar que el marco de Spring gestione el componente de contexto y la configuración.

A continuación, escribamos una configuración y un contexto mínimos en el paquete de base package.myutilityprogram.business.context recién creado en el proyecto de entidades:

Este es el contenido de la configuración: Utiliza una compilación de configuración similar a la de otros programas (modernizados) cercanos. Probablemente tengas que personalizarlo para que se adapte a tus necesidades específicas.

Notas:

• La convención de nomenclatura general es ProgramNameConfiguración.

• Debe usar las anotaciones @org.springframework.context.annotation.Configuration y @Lazy

• El nombre del bean suele seguir la ProgramNameContextConfiguration convención, pero no es obligatorio. Asegúrese de evitar conflictos de nombres de beans en todo el proyecto.

• El único método a implementar debe devolver un objeto Configuration. Usa el ConfigurationBuilder lenguaje fluido API para ayudarte a construir uno.

Y el contexto asociado:

Notas

• La clase context debe ampliar una implementación de Context interfaz existente (RuntimeContexto bienJicsRuntimeContext, mejorada RuntimeContext con elementos JICS específicos).

• La convención de nomenclatura general es ProgramNameContext.

• Debe declararlo como un componente de Prototype y utilizar la anotación @Lazy.

• El constructor hace referencia a la configuración asociada y utiliza la anotación @Qualifier para dirigirse a la clase de configuración adecuada.

• Si el programa de utilidades utiliza algunas estructuras de datos adicionales, deberían ser:

  • escritas y añadidas al paquete base package.business.model

  • referenciadas en el contexto. Eche un vistazo a otras clases de contexto existentes para ver cómo hacer referencia a las clases de estructuras de datos y adaptar los métodos de contexto (constructor, limpieza o restablecimiento) según sea necesario.

Ahora que hay un contexto específico disponible, deje que el nuevo programa lo use:

Notas:

• El getContext método debe implementarse estrictamente como se muestra, utilizando una delegación al getOrCreate método de la ProgramContextStore clase y al Spring cableado automáticamenteBeanFactory. Se utiliza un único identificador de programa para almacenar el contexto del programa en el ProgramContextStore; este identificador se denomina “identificador principal del programa”.

• Se debe hacer referencia a las clases complementarias de configuración y contexto mediante la anotación @Import de Spring.

Implementación de la lógica empresarial

Cuando el esquema del programa esté completo, implemente la lógica empresarial para el nuevo programa de utilidades.

Hágalo según el método run del programa. Este método se ejecutará cada vez que se llame al programa, ya sea mediante otro programa o mediante un script.

¡Feliz programación!

Gestionar el registro del programa

Por último, asegúrese de que el nuevo programa esté registrado correctamente en el ProgramRegistry. Si ha agregado el nuevo programa al paquete que ya contiene otros programas, no hay nada más que hacer. El nuevo programa se selecciona y se registra en todos sus programas vecinos al iniciar la aplicación.

Si elige otra ubicación para el programa, debe asegurarse de que el programa esté registrado correctamente al iniciar Tomcat. Para inspirarse sobre cómo hacerlo, consulte el método de inicialización de las SpringbootLauncher clases generadas en los proyectos de servicio (consulteContenido del proyecto de servicio).

Compruebe los registros de inicio de Tomcat. Se registran todos los registros de programas. Si el programa se ha registrado correctamente, encontrará la entrada de registro correspondiente.

Cuando esté seguro de que su programa está registrado correctamente, puede empezar a iterar con la codificación de la lógica empresarial.

Asignaciones de nombres totalmente cualificadas

Esta sección contiene listas de la era AWS azul y de mapeos de nombres totalmente cualificados de terceros para utilizarlos en sus aplicaciones modernizadas.

AWS Asignaciones de nombres totalmente calificadas de Blu Age

Nombre corto	Nombre completo cualificado
CallBuilder	com.netfective.bluage.gapwalk.runtime.statements.CallBuilder
Configuration	com.netfective.bluage.gapwalk.datasimplifier.configuration.Configuration
ConfigurationBuilder	com.netfective.bluage.gapwalk.datasimplifier.configuration.ConfigurationBuilder
ExecutionController	com.netfective.bluage.gapwalk.rt.call.ExecutionController
ExecutionControllerImpl	com.netfective.bluage.gapwalk.rt.call.internal.ExecutionControllerImpl
File	com.netfective.bluage.gapwalk.rt.io.File
MainProgramRunner	com.netfective.bluage.gapwalk.rt.call.MainProgramRunner
Program	com.netfective.bluage.gapwalk.rt.provider.Program
ProgramContextStore	com.netfective.bluage.gapwalk.rt.context.ProgramContextStore
ProgramRegistry	com.netfective.bluage.gapwalk.rt.provider.ProgramRegistry
Record	com.netfective.bluage.gapwalk.datasimplifier.data.Record
RecordEntity	com.netfective.bluage.gapwalk.datasimplifier.entity.RecordEntity
RuntimeContext	com.netfective.bluage.gapwalk.rt.context.RuntimeContext
SimpleStateMachineController	com.netfective.bluage.gapwalk.rt.statemachine.SimpleStateMachineController
StateMachineController	com.netfective.bluage.gapwalk.rt.statemachine.StateMachineController
StateMachineRunner	com.netfective.bluage.gapwalk.rt.statemachine.StateMachineRunner

Asignaciones de nombres totalmente cualificadas de terceros

Nombre corto	Nombre completo cualificado
@Autowired	org.springframework.beans.factory.annotation.Autowired
@Bean	org.springframework.context.annotation.Bean
BeanFactory	org.springframework.beans.factory.BeanFactory
@Component	org.springframework.stereotype.Component
ConfigurableApplicationContext	org.springframework.context.ConfigurableApplicationContext
@Import	org.springframework.context.annotation.Import
@Lazy	org.springframework.context.annotation.Lazy