AWS Structure Blu Age d'une application modernisée

Ce document fournit des détails sur la structure des applications modernisées (à l'aide des outils de refactoring de modernisation du AWS mainframe), afin que les développeurs puissent accomplir diverses tâches, telles que :

• navigation fluide dans les applications.

• développer des programmes personnalisés qui peuvent être appelés à partir des applications modernisées.

• refactoriser en toute sécurité des applications modernisées.

Nous supposons que vous possédez déjà des connaissances de base dans les domaines suivants :

• anciens concepts de codage courants, tels que les enregistrements, les ensembles de données et leurs modes d'accès aux enregistrements (indexés, séquentiels)VSAM, les unités d'exécution, les scripts jcl, CICS les concepts, etc.

• codage Java à l'aide du framework Spring.

• Tout au long du document, nous l'utilisons short class names pour des raisons de lisibilité. Pour plus d'informations, voir AWS Mappages de noms entièrement qualifiés Blu Age pour récupérer les noms complets correspondants pour les éléments d'exécution de AWS Blu Age et Mappages de noms entièrement qualifiés par des tiers pour récupérer les noms complets correspondants pour les éléments tiers.

• Tous les artefacts et échantillons sont extraits des résultats du processus de modernisation de l'COBOLéchantillon/de CICS CardDemo l'application.

Organisation des artefacts

AWS Les applications modernisées de Blu Age sont regroupées sous forme d'applications Web Java (.war), que vous pouvez déployer sur un JEE serveur. Généralement, le serveur est une instance Tomcat qui intègre le AWS Blu Age Runtime, qui est actuellement basé sur les frameworks Springboot et Angular (pour la partie interface utilisateur).

La guerre regroupe plusieurs artefacts de composants (.jar). Chaque fichier jar est le résultat de la compilation (à l'aide de l'outil maven) d'un projet Java dédié dont les éléments sont le résultat du processus de modernisation.

L'organisation de base repose sur la structure suivante :

• Projet Entities : contient des éléments de modèle commercial et de contexte. Le nom du projet se termine généralement par « -entities ». Généralement, pour un COBOL programme existant donné, cela correspond à la modernisation de la section E/S (ensembles de données) et de la division des données. Vous pouvez avoir plusieurs projets d'entités.

• Projet de service : contient des éléments de modernisation de la logique métier héritée. Il s'agit généralement de la division procédurale d'un COBOL programme. Vous pouvez avoir plusieurs projets de service.

• Projet utilitaire : contient des outils et utilitaires communs partagés, utilisés par d'autres projets.

• Projet Web : contient la modernisation des éléments liés à l'interface utilisateur, le cas échéant. Non utilisé pour les projets de modernisation par lots uniquement. Ces éléments d'interface utilisateur peuvent provenir de CICS BMS cartes, de IMS MFS composants et d'autres sources d'interface utilisateur du mainframe. Vous pouvez avoir plusieurs projets Web.

Entités, contenu du projet

Note

Les descriptions suivantes s'appliquent uniquement aux résultats COBOL de modernisation PL/I. RPGles résultats de modernisation sont basés sur une disposition différente.

Avant toute refactorisation, l'organisation des packages dans le projet d'entités est liée aux programmes modernisés. Vous pouvez y parvenir de différentes manières. La méthode préférée consiste à utiliser la boîte à outils Refactoring, qui fonctionne avant que vous ne déclenchiez le mécanisme de génération de code. Il s'agit d'une opération avancée, qui est expliquée dans les BluAge formations. Pour plus d'informations, consultez la section Atelier de refactorisation. Cette approche vous permet de conserver la possibilité de régénérer le code Java ultérieurement, afin de bénéficier de nouvelles améliorations dans le futur, par exemple). L'autre méthode consiste à effectuer une refactorisation Java régulière, directement sur le code source généré, en utilisant n'importe quelle approche de refactorisation Java que vous souhaiteriez appliquer, à vos risques et périls.

Cours liés au programme

Chaque programme modernisé est associé à deux packages, un package business.context et un package business.model.

• base package.program.business.context

  Le sous-package business.context contient deux classes, une classe de configuration et une classe de contexte.

  • Une classe de configuration pour le programme, qui contient les détails de configuration spécifiques au programme donné, tels que le jeu de caractères à utiliser pour représenter les éléments de données basés sur des caractères, la valeur d'octet par défaut pour le remplissage des éléments de structure de données, etc. Le nom de la classe se termine par « Configuration ». Il est marqué par l'@org.springframework.context.annotation.Configurationannotation et contient une méthode unique qui doit renvoyer un Configuration objet correctement configuré.

    

  • Une classe de contexte, qui sert de pont entre les classes de service du programme (voir ci-dessous) et les structures de données (Record) et les ensembles de données (File) du sous-package du modèle (voir ci-dessous). Le nom de classe se termine par « Context » et est une sous-classe de la RuntimeContext classe.

    

• base package.program.business.model

  Le sous-package du modèle contient toutes les structures de données que le programme donné peut utiliser. Par exemple, toute structure de COBOL données de niveau 01 correspond à une classe du sous-package du modèle (les structures de données de niveau inférieur sont les propriétés de leur propre structure de niveau 01). Pour plus d'informations sur la façon dont nous modernisons les structures de données 01, consultezQue sont les simplificateurs de données dans AWS Blu Age.

  

Toutes les classes étendent la RecordEntity classe, qui représente l'accès à une représentation d'enregistrement commercial. Certains enregistrements ont un objectif spécial, car ils sont liés à unFile. La liaison entre a Record et a File est établie dans les FileHandler méthodes * correspondantes trouvées dans la classe de contexte lors de la création de l'objet fichier. Par exemple, la liste suivante montre comment le TransactfileFile File est lié au transactFile Record (à partir du sous-package du modèle).

Contenu du projet de service

Chaque projet de service est accompagné d'une application Springboot dédiée, qui est utilisée comme colonne vertébrale de l'architecture. Cela se matérialise par le biais de la classe nomméeSpringBootLauncher, située dans le package de base des sources Java du service :

Cette classe est notamment chargée de :

• faire le lien entre les classes du programme et les ressources gérées (sources de données/gestionnaires de transactions/mappages d'ensembles de données/etc...).

• fournissant un ou ConfigurableApplicationContext deux programmes.

• découvrir toutes les classes marquées comme spring components (@Component).

• s'assurer que les programmes sont correctement enregistrés dans le ProgramRegistry -- voir la méthode d'initialisation chargée de cet enregistrement.

Artefacts liés au programme

Sans refactorisation préalable, les résultats de la modernisation de la logique métier sont organisés en deux ou trois packages par programme existant :

Le cas le plus exhaustif comportera trois packages :

• base package.program.service: contient une interface nommée Program Process, qui dispose de méthodes métier pour gérer la logique métier, en préservant le flux de contrôle d'exécution existant.

• base package.program.service.impl: contient une classe nommée ProgramProcessImpl, qui est l'implémentation de l'interface Process décrite précédemment. C'est ici que les anciennes instructions sont « traduites » en instructions Java, en s'appuyant sur le framework AWS Blu Age :

  

• base package.program.statemachine: ce package n'est peut-être pas toujours présent. Cela est nécessaire lorsque la modernisation de l'ancien flux de contrôle doit utiliser une approche basée sur une machine à états (notamment en utilisant le StateMachine framework Spring) pour couvrir correctement le flux d'exécution existant.

  Dans ce cas, le sous-package statemachine contient deux classes :

  • ProgramProcedureDivisionStateMachineController: une classe qui étend une classe implémentant les interfaces StateMachineController (définition des opérations nécessaires pour contrôler l'exécution d'une machine à états) et StateMachineRunner (définition des opérations requises pour exécuter une machine à états), utilisées pour piloter la mécanique des machines à états Spring ; par exemple, SimpleStateMachineController comme dans le cas d'exemple.

    

    Le contrôleur de machine à états définit les différents états possibles et les transitions entre eux, qui reproduisent le flux de contrôle d'exécution existant pour le programme donné.

    Lors de la création de la machine à états, le contrôleur fait référence aux méthodes définies dans la classe de service associée située dans le package de machine à états et décrite ci-dessous :

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

  • ProgramProcedureDivisionStateMachineService: cette classe de service représente une certaine logique métier qui doit être liée à la machine d'état créée par le contrôleur de machine d'état, comme décrit précédemment.

    Le code des méthodes de cette classe utilise les événements définis dans le contrôleur State Machine :

    
    

    Le service statemachine appelle également l'implémentation du service de processus décrite précédemment :

    

De plus, un package nommé base package.program joue un rôle important, car il regroupe une classe par programme, qui servira de point d'entrée au programme (plus de détails à ce sujet ultérieurement). Chaque classe implémente l'Programinterface, marqueur d'un point d'entrée du programme.

Autres artéfacts

• BMSMAPscompagnons

  Outre les artefacts liés au programme, le projet de service peut contenir d'autres artefacts à des fins diverses. Dans le cas de la modernisation d'une application CICS en ligne, le processus de modernisation produit un fichier json et place dans le dossier map du dossier /src/main/resources :

  

  Le moteur d'exécution Blu Age utilise ces fichiers json pour lier les enregistrements utilisés par l'SENDMAPinstruction aux champs d'écran.

• Scripts géniaux

  Si l'ancienne application comportait JCL des scripts, ceux-ci ont été modernisés en tant que scripts groovy, stockés dans le dossier /src/main/resources/scripts (nous reviendrons sur cet emplacement spécifique ultérieurement) :

  

  Ces scripts sont utilisés pour lancer des tâches par lots (charges de travail de traitement de données dédiées, non interactives et gourmandes en ressources processeur).

• SQLfichiers

  Si l'ancienne application utilisait des SQL requêtes, les SQL requêtes modernisées correspondantes ont été rassemblées dans des fichiers de propriétés dédiés, avec le modèle de dénomination program .sql, où program est le nom du programme utilisant ces requêtes.

  

  Le contenu de ces fichiers SQL est une collection d'entrées (clé=requête), où chaque requête est associée à une clé unique, que le programme modernisé utilise pour exécuter la requête donnée :

  

  Par exemple, le programme COSGN 00C exécute la requête avec la clé « COSGN 00C_1" (la première entrée du fichier SQL) :

  

Contenu du projet Utilities

Le projet d'utilitaires, dont le nom se termine par « -tools », contient un ensemble d'utilitaires techniques qui peuvent être utilisés par tous les autres projets.

Contenu du (des) projet (s) Web

Le projet Web n'est présent que lors de la modernisation des anciens éléments de l'interface utilisateur. Les éléments d'interface utilisateur modernes utilisés pour créer le front-end d'application modernisé sont basés sur Angular. L'exemple d'application utilisé pour montrer les artefacts de modernisation est une CICS applicationCOBOL/, exécutée sur un mainframe. Le CICS système utilise MAPs pour représenter les écrans de l'interface utilisateur. Les éléments modernes correspondants seront, pour chaque carte, un fichier html accompagné de fichiers Typescript :

Le projet Web ne prend en charge que l'aspect frontal de l'application. Le projet de service, qui repose sur les projets d'utilitaires et d'entités, fournit les services principaux. Le lien entre le front-end et le backend est établi via l'application Web nommée Gapwalk-Application, qui fait partie de la distribution d'exécution standard AWS de Blu Age.

Programmes en cours d'exécution et d'appel

Sur les anciens systèmes, les programmes sont compilés sous forme d'exécutables autonomes qui peuvent s'appeler eux-mêmes par le biais d'un CALL mécanisme, tel que l'COBOLCALLinstruction, en transmettant des arguments lorsque cela est nécessaire. Les applications modernisées offrent les mêmes fonctionnalités mais utilisent une approche différente, car la nature des artefacts concernés est différente de celle des anciens artefacts.

Du côté modernisé, les points d'entrée du programme sont des classes spécifiques qui implémentent l'Programinterface, sont des composants Spring (@Component) et sont situés dans des projets de service, dans un package nommébase package.program.

Inscription aux programmes

Chaque fois que le serveur Tomcat hébergeant les applications modernisées est démarré, le service Springboot est également lancé, ce qui déclenche l'enregistrement des programmes. Un registre dédié nommé ProgramRegistry est rempli d'entrées de programme, chaque programme étant enregistré à l'aide de ses identifiants, une entrée par identifiant de programme connu, ce qui signifie que si un programme est connu sous plusieurs identifiants différents, le registre contient autant d'entrées qu'il y a d'identifiants.

L'enregistrement d'un programme donné repose sur la collection d'identifiants renvoyés par la méthode getProgramIdentifiers () :

Dans cet exemple, le programme est enregistré une seule fois, sous le nom « CBACT 04C » (regardez le contenu de la programIdentifiers collection). Les journaux Tomcat indiquent chaque enregistrement de programme. L'enregistrement du programme dépend uniquement des identificateurs de programme déclarés et non du nom de classe de programme lui-même (bien que les identifiants de programme et les noms de classe de programme soient généralement alignés).

Le même mécanisme d'enregistrement s'applique aux programmes utilitaires fournis par les différentes applications Web utilitaires AWS Blu Age, qui font partie de la distribution d'exécution AWS Blu Age. Par exemple, l'application Web Gapwalk-Utility-Pgm fournit les équivalents fonctionnels des utilitaires système z/OS (IDCAMS,, ICEGENERSORT, etc.) et peut être appelée par des programmes ou des scripts modernisés. Tous les programmes utilitaires disponibles enregistrés au démarrage de Tomcat sont enregistrés dans les journaux Tomcat.

Enregistrement des scripts et des démons

Un processus d'enregistrement similaire, au démarrage de Tomcat, se produit pour les scripts groovy situés dans la hiérarchie des dossiers /src/main/resources/scripts. La hiérarchie des dossiers de scripts est parcourue et tous les scripts groovy découverts (à l'exception du script réservé special functions.groovy) sont enregistrés dans leScriptRegistry, en utilisant leur nom court (la partie du nom du fichier de script située avant le premier point) comme clé de récupération.

Note

• Si plusieurs scripts ont des noms de fichiers qui produiront la même clé d'enregistrement, seule la dernière est enregistrée, remplaçant ainsi toute inscription précédemment rencontrée pour cette clé donnée.

• Compte tenu de ce qui précède, faites attention lorsque vous utilisez des sous-dossiers, car le mécanisme d'enregistrement aplatit la hiérarchie et peut entraîner des remplacements inattendus. La hiérarchie ne compte pas dans le processus d'enregistrement : en général, /Scripts/a/MyScript.Groovy et /Scripts/B/MyScript.Groovy entraînent le remplacement de /Scripts/B/MyScript.Groovy par /Scripts/a/MyScript.Groovy.

Les scripts groovy du dossier /src/main/resources/daemons sont gérés un peu différemment. Ils sont toujours enregistrés en tant que scripts classiques, mais en plus, ils ne sont lancés qu'une seule fois, directement au moment du démarrage de Tomcat, de manière asynchrone.

Une fois les scripts enregistrés dans leScriptRegistry, un REST appel peut les lancer, en utilisant les points de terminaison dédiés exposés par l'application Gapwalk. Pour plus d'informations, consultez la documentation correspondante.

Programmes, programmes d'appel

Chaque programme peut appeler un autre programme en tant que sous-programme et lui transmettre des paramètres. Pour ce faire, les programmes utilisent une implémentation de l'ExecutionControllerinterface (la plupart du temps, il s'agira d'une ExecutionControllerImpl instance), ainsi qu'un API mécanisme fluide appelé le CallBuilder pour générer les arguments d'appel du programme.

Toutes les méthodes des programmes prennent à la fois a RuntimeContext et an ExecutionController comme arguments de méthode, de sorte que an ExecutionController est toujours disponible pour appeler d'autres programmes.

Voir, par exemple, le schéma suivant, qui montre comment le programme CBST 03A appelle le programme CBST 03B en tant que sous-programme, en lui transmettant des paramètres :

• Le premier argument de ExecutionController.callSubProgram est un identifiant du programme à appeler (c'est-à-dire l'un des identifiants utilisés pour l'enregistrement du programme, voir paragraphes ci-dessus).

• Le deuxième argument, qui est le résultat de la construction sur leCallBuilder, est un tableau deRecord, correspondant aux données transmises de l'appelant à l'appelé.

• Le troisième et dernier argument est l'RuntimeContextinstance de l'appelant.

Les trois arguments sont obligatoires et ne peuvent pas être nuls, mais le second argument peut être un tableau vide.

L'appelé ne pourra traiter les paramètres transmis que s'il a été initialement conçu pour le faire. Pour un ancien COBOL programme, cela signifie avoir une LINKAGE section et une USING clause permettant à la division de procédure d'utiliser les LINKAGE éléments.

Par exemple, consultez le CBSTM03B correspondant. CBLCOBOLfichier source :

Le programme CBSTM 03B prend donc un seul Record comme paramètre (un tableau de taille 1). C'est ce qu'ils CallBuilder sont en train de construire, en utilisant les méthodes byReference () et getArguments () de chaînage.

La API classe CallBuilder Fluent dispose de plusieurs méthodes pour remplir le tableau d'arguments à transmettre à un appelé :

• asPointer(RecordAdaptable) : ajoute un argument de type pointeur, par référence. Le pointeur représente l'adresse d'une structure de données cible.

• byReference(RecordAdaptable) : ajoute un argument par référence. L'appelant verra les modifications qu'il effectue.

• byReference(RecordAdaptable) : variante varargs de la méthode précédente.

• byValue(Objet) : ajoute un argument, transformé en aRecord, par valeur. L'appelant ne verra pas les modifications effectuées par l'appelé.

• byValue(RecordAdaptable) : identique à la méthode précédente, mais l'argument est directement disponible sous forme deRecordAdaptable.

• byValueWithBounds (Object, int, int) : ajoutez un argument, transformé en a, en extrayant la partie du tableau d'octets définie par les limites données, par valeur. Record

Enfin, la getArguments méthode collectera tous les arguments ajoutés et les renverra sous forme de tableau deRecord.

Note

Il est de la responsabilité de l'appelant de s'assurer que le tableau d'arguments a la taille requise, que les éléments sont correctement ordonnés et compatibles, en termes de disposition de la mémoire, avec les dispositions attendues pour les éléments de liaison.

Scripts appelant des programmes

L'appel de programmes enregistrés à partir de scripts groovy nécessite l'utilisation d'une instance de classe implémentant l'MainProgramRunnerinterface. Habituellement, l'obtention d'une telle instance est obtenue grâce à l' ApplicationContext utilisation de Spring :

Une fois qu'une MainProgramRunner interface est disponible, utilisez la runProgram méthode pour appeler un programme et transmettre l'identifiant du programme cible en tant que paramètre :

Dans l'exemple précédent, une étape de travail appelle IDCAMS (programme utilitaire de gestion de fichiers), fournissant un mappage entre les définitions réelles des ensembles de données et leurs identifiants logiques.

Lorsqu'il s'agit d'ensembles de données, les anciens programmes utilisent principalement des noms logiques pour identifier les ensembles de données. Lorsque le programme est appelé à partir d'un script, celui-ci doit associer les noms logiques aux ensembles de données physiques réels. Ces ensembles de données peuvent se trouver sur le système de fichiers, dans un stockage Blusam ou même définis par un flux en ligne, la concaténation de plusieurs ensembles de données ou la génération d'un. GDG

Utilisez withFileConfiguration cette méthode pour créer une carte logique-physique des ensembles de données et la mettre à la disposition du programme appelé.

Écrivez votre propre programme

L'écriture de votre propre programme pour des scripts ou d'autres programmes modernisés à appeler est une tâche courante. Généralement, dans le cadre de projets de modernisation, vous écrivez vos propres programmes lorsqu'un ancien programme exécutable est écrit dans un langage que le processus de modernisation ne prend pas en charge, ou lorsque les sources ont été perdues (oui, cela peut arriver), ou lorsque le programme est un utilitaire dont les sources ne sont pas disponibles.

Dans ce cas, vous devrez peut-être écrire vous-même le programme manquant, en Java (en supposant que vous sachiez suffisamment quel devrait être le comportement attendu du programme, la disposition en mémoire des arguments du programme, le cas échéant, etc.) Votre programme Java doit respecter les mécanismes du programme décrits dans ce document afin que d'autres programmes et scripts puissent l'exécuter.

Pour vous assurer que le programme est utilisable, vous devez effectuer deux étapes obligatoires :

• Écrivez une classe qui implémente correctement l'Programinterface, afin qu'elle puisse être enregistrée et appelée.

• Assurez-vous que votre programme est correctement enregistré, afin qu'il soit visible depuis d'autres programmes/scripts.

Rédaction de l'implémentation du programme

Utilisez votre IDE pour créer une nouvelle classe Java qui implémente l'Programinterface :

L'image suivante montre l'EclipseIDE, qui se charge de créer toutes les méthodes obligatoires à implémenter :

Intégration Spring

Tout d'abord, la classe doit être déclarée en tant que composant Spring. Annotez la classe avec l'@Componentannotation suivante :

Ensuite, implémentez correctement les méthodes requises. Dans le contexte de cet exemple, nous avons ajouté le MyUtilityProgram package qui contient déjà tous les programmes modernisés. Cet emplacement permet au programme d'utiliser l'application Springboot existante pour fournir les éléments requis ConfigurableApplicationContext pour l'implémentation de la getSpringApplication méthode :

Vous pouvez choisir un autre emplacement pour votre propre programme. Par exemple, vous pouvez localiser le programme en question dans un autre projet de service dédié. Assurez-vous que le projet de service donné possède sa propre application Springboot, qui permet de récupérer le ApplicationContext (qui devrait être unConfigurableApplicationContext).

Donner une identité au programme

Pour pouvoir être appelé par d'autres programmes et scripts, le programme doit recevoir au moins un identifiant, qui ne doit entrer en collision avec aucun autre programme enregistré existant dans le système. Le choix de l'identifiant peut être dicté par la nécessité de couvrir le remplacement d'un ancien programme existant ; dans ce cas, vous devrez utiliser l'identifiant attendu, tel que défini dans les CALL occurrences trouvées dans les anciens programmes. La plupart des identifiants de programme comportent 8 caractères dans les anciens systèmes.

La création d'un ensemble non modifiable d'identifiants dans le programme est un moyen d'y parvenir. L'exemple suivant montre comment choisir MYUTILPG « » comme identifiant unique :

Associer le programme à un contexte

Le programme a besoin d'une RuntimeContext instance associée. Pour les programmes modernisés, AWS Blu Age génère automatiquement le contexte associé, en utilisant les structures de données qui font partie de l'ancien programme.

Si vous écrivez votre propre programme, vous devez également écrire le contexte associé.

En référence à ce qui suitCours liés au programme, vous pouvez constater qu'un programme nécessite au moins deux cours complémentaires :

• une classe de configuration.

• une classe de contexte qui utilise la configuration.

Si le programme utilitaire utilise une structure de données supplémentaire, elle doit également être écrite et utilisée par le contexte.

Ces classes doivent se trouver dans un package faisant partie d'une hiérarchie de packages qui sera analysée au démarrage de l'application, afin de s'assurer que le composant contextuel et la configuration seront gérés par le framework Spring.

Écrivons une configuration et un contexte minimaux, dans le base package.myutilityprogram.business.context package, fraîchement créé dans le projet entities :

Voici le contenu de la configuration. Il utilise une version de configuration similaire à celle d'autres programmes (modernisés) situés à proximité. Vous devrez probablement le personnaliser en fonction de vos besoins spécifiques.

Remarques :

• La convention de dénomination générale est ProgramNameConfiguration.

• Il doit utiliser les annotations @org .springframework.context.annotation.Configuration et @Lazy.

• Le nom du haricot suit généralement la ProgramNameContextConfiguration convention, mais cela n'est pas obligatoire. Assurez-vous d'éviter les collisions de noms de beans dans le projet.

• La seule méthode à implémenter doit renvoyer un Configuration objet. Utilisez le ConfigurationBuilder fluent API pour vous aider à en créer un.

Et le contexte associé :

Remarques

• La classe de contexte doit étendre une implémentation d'Contextinterface existante (RuntimeContextsoitJicsRuntimeContext, soit améliorée RuntimeContext avec des JICS éléments spécifiques).

• La convention de dénomination générale est ProgramNameContext.

• Vous devez le déclarer en tant que composant du prototype et utiliser l'annotation @Lazy.

• Le constructeur fait référence à la configuration associée en utilisant l'annotation @Qualifier pour cibler la classe de configuration appropriée.

• Si le programme utilitaire utilise des structures de données supplémentaires, celles-ci doivent être :

  • écrit et ajouté au base package.business.model package.

  • référencé dans le contexte. Examinez d'autres classes de contexte existantes pour voir comment référencer les classes de structures de données et adapter les méthodes de contexte (constructeur/nettoyage/réinitialisation) selon les besoins.

Maintenant qu'un contexte dédié est disponible, laissez le nouveau programme l'utiliser :

Remarques :

• La getContext méthode doit être implémentée strictement comme indiqué, en utilisant une délégation à la getOrCreate méthode de la ProgramContextStore classe et le Spring autocâbléBeanFactory. Un identifiant de programme unique est utilisé pour stocker le contexte du programme dans le ProgramContextStore ; cet identifiant est référencé comme étant « l'identifiant principal du programme ».

• La configuration associée et les classes de contexte doivent être référencées à l'aide de l'annotation @Import Spring.

Mise en œuvre de la logique métier

Lorsque le squelette du programme est terminé, implémentez la logique métier du nouveau programme utilitaire.

Faites-le dans la run méthode du programme. Cette méthode sera exécutée chaque fois que le programme est appelé, que ce soit par un autre programme ou par un script.

Bon codage !

Gestion de l'enregistrement du programme

Enfin, assurez-vous que le nouveau programme est correctement enregistré dans leProgramRegistry. Si vous avez ajouté le nouveau programme au package qui contient déjà d'autres programmes, il n'y a plus rien à faire. Le nouveau programme est sélectionné et enregistré auprès de tous les programmes voisins au démarrage de l'application.

Si vous avez choisi un autre emplacement pour le programme, vous devez vous assurer qu'il est correctement enregistré au démarrage de Tomcat. Pour vous inspirer sur la manière de procéder, examinez la méthode d'initialisation des SpringbootLauncher classes générées dans le ou les projets de service (voirContenu du projet de service).

Consultez les journaux de démarrage de Tomcat. Chaque inscription au programme est enregistrée. Si votre programme est enregistré avec succès, vous trouverez l'entrée de journal correspondante.

Lorsque vous êtes certain que votre programme est correctement enregistré, vous pouvez commencer à itérer sur le codage logique métier.

Mappages de noms entièrement qualifiés

Cette section contient des listes de mappages de noms complets de AWS Blu Age et de tiers à utiliser dans vos applications modernisées.

AWS Mappages de noms entièrement qualifiés Blu Age

Nom court	Nom entièrement qualifié
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

Mappages de noms entièrement qualifiés par des tiers

Nom court	Nom entièrement qualifié
@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