AWS Le service de modernisation du mainframe (expérience de l'environnement d'exécution géré) n'est plus ouvert aux nouveaux clients. Pour des fonctionnalités similaires au service de modernisation AWS du mainframe (expérience de l'environnement d'exécution géré), explorez le service de modernisation AWS du mainframe (expérience autogérée). Les clients existants peuvent continuer à utiliser le service normalement. Pour plus d'informations, consultez la section [Modification de la disponibilité de la modernisation du AWS mainframe](https://docs.aws.amazon.com/m2/latest/userguide/mainframe-modernization-availability-change.html). Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Configuration de la configuration pour AWS Transform for mainframe Runtime Le AWS Transform for mainframe Runtime et le code client sont des applications Web utilisant le [framework Spring Boot](https://docs.spring.io/spring-boot/docs/2.5.14/reference/html/). Il tire parti des fonctionnalités de Spring pour fournir une configuration, avec plusieurs emplacements possibles et règles de priorité. Il existe également des règles de priorité similaires pour fournir de nombreux autres fichiers, tels que les scripts Groovy, SQL, etc. Le AWS Transform for mainframe Runtime contient également des applications Web facultatives supplémentaires, qui peuvent être activées si nécessaire. **Topics** + [Principes de base de configuration des applications](#ba-runtime-config-app-basics) + [Priorité des applications](#ba-runtime-config-app-precedence) + [JNDI pour bases de données](#ba-runtime-config-app-jndi) + [AWS Les secrets d'exécution de Transform for Mainframe](ba-runtime-config-app-secrets.md) + [Autres fichiers (groovy, sql, etc.)](#ba-runtime-config-app-files) + [Application Web supplémentaire](#ba-runtime-config-app-webapp) + [Activer les propriétés de AWS Transform for mainframe Runtime](ba-runtime-key-value.md) + [Propriétés du cache Redis disponibles dans AWS Transform for mainframe Runtime](ba-runtime-redis-configuration.md) + [Configuration de la sécurité pour les applications Gapwalk](ba-runtime-security.md) ## Principes de base de configuration des applications La méthode par défaut pour gérer la configuration des applications consiste à utiliser des fichiers YAML dédiés à fournir dans le `config` dossier du serveur d'applications. Il existe deux principaux fichiers de configuration YAML : + `application-main.yaml` + `application-profile.yaml`(où `profile` la valeur est configurée lors de la génération de l'application). Le premier fichier configure le framework, c'est-à-dire`Gapwalk-application.war`, tandis que le second est destiné à des options supplémentaires spécifiques à l'application cliente. Cela fonctionne avec l'utilisation de profils Spring : l'application Gapwalk utilise le `main` profil, tandis que l'application cliente utilise le `profile` profil. L'exemple suivant montre un fichier YAML principal typique. ![\[Extrait d'un fichier YAML « principal ».\]](http://docs.aws.amazon.com/fr_fr/m2/latest/userguide/images/main-yaml.png) L'exemple suivant montre un fichier YAML client typique. ![\[Exemple de client YAML\]](http://docs.aws.amazon.com/fr_fr/m2/latest/userguide/images/client-yaml.png) Pour plus d'informations sur le contenu des fichiers YAML, consultez[Activer les propriétés de AWS Transform for mainframe Runtime](ba-runtime-key-value.md). ## Priorité des applications Pour ces fichiers de configuration, les règles de priorité Spring s'appliquent. Notamment : + Le fichier `application-main` YAML apparaît dans le fichier war principal de Gapwalk avec les valeurs par défaut, et celui du `config` dossier le remplace. + La même chose doit être faite pour la configuration de l'application cliente + Des paramètres supplémentaires peuvent être transmis sur la ligne de commande au moment du lancement du serveur. Ils remplaceraient ceux de YAML. Pour plus d'informations, consultez la [documentation officielle de Spring Boot](https://docs.spring.io/spring-boot/docs/2.5.14/reference/html/features.html#features.external-config). ## JNDI pour bases de données La configuration de la base de données peut être fournie avec JNDI dans le fichier context.xml de Tomcat. Toute configuration de ce type remplacerait celle de YAML. Mais attention, son utilisation ne permettra pas d'encapsuler vos informations d'identification dans un gestionnaire secret (voir ci-dessous). L'exemple suivant montre des exemples de configurations pour les JICS et les Blusam bases de données. ``` ``` jdbc/jics Ce serait `jdbc/jics` pour la base de données JICS et `jdbc/bluesam` (attention au « e ») pour la Blusam base de données. url="jdbc:postgresql : //xxxx.rds.amazonaws.com:5432/XXXX » Nom d'utilisateur = « XXXX » Mot de passe = « XXXX » URL, nom d'utilisateur et mot de passe de la base de données. ## Autres fichiers (groovy, sql, etc.) Les autres fichiers utilisés par le projet client utilisent des règles de priorité similaires à celles de la configuration Spring. Exemples : + Les scripts Groovy sont des `.groovy` fichiers contenus dans le `scripts` dossier ou les sous-dossiers. + Les scripts SQL sont des `.sql` fichiers contenus dans le `sql` dossier ou les sous-dossiers. + Les scripts Daemon sont des `.groovy` fichiers contenus dans le `daemons` dossier ou les sous-dossiers. + Les fichiers de mappage de base de données de requêtes sont `queries-database.mapping` des fichiers nommés fichiers dans les sous-dossiers du `sql` dossier. + Les modèles Jasper sont des `.jrxml` fichiers contenus dans le `templates` dossier ou les sous-dossiers. + Les catalogues de jeux de données sont `.json` des fichiers contenus dans le `catalog` dossier. + Les fichiers Lnk sont `.json` des fichiers du `lnk` dossier. Tous ces emplacements peuvent être remplacés par le biais d'une propriété système ou d'une propriété YAML du client. + Pour les scripts Groovy : `configuration.scripts` + Pour les scripts SQL : `configuration.sql` + Pour les scripts Daemon : `configuration.daemons` + Pour le fichier de mappage de base de données de requêtes : `configuration.databaseMapping` + Pour les modèles Jasper : `configuration.templates` + Pour les catalogues de jeux de données : `configuration.catalog` + Pour les fichiers Lnk : `configuration.lnk` Si la propriété n'est pas trouvée, les fichiers seront extraits de l'emplacement par défaut mentionné ci-dessus. La recherche sera d'abord effectuée avec le répertoire de travail Tomcat en tant que racine, puis dans le fichier war de l'application. ## Application Web supplémentaire Le AWS Transform for mainframe Runtime contient des applications Web supplémentaires dans son `webapps-extra` dossier. Ces applications ne sont pas desservies par défaut par le serveur Tomcat. L'activation de ces applications Web dépend du projet de modernisation et s'effectue en déplaçant le fichier war souhaité du `webapps-extra` dossier vers le `webapps` dossier. Après cela, la guerre sera servie par le serveur Tomcat au prochain démarrage. Certaines configurations supplémentaires spécifiques au projet peuvent également être ajoutées dans un fichier de configuration YAML pour chaque guerre supplémentaire, comme cela est fait dans le `application-main.yml` fichier et expliqué ci-dessus. Les guerres supplémentaires sont les suivantes : + `gapwalk-utility-pgm.war`: contient le support pour les programmes utilitaires ZOS et l'utilise `application-utility-pgm.yaml` comme configuration. + `gapwalk-cl-command.war`: contient le support pour les programmes utilitaires AS/400 et l'utilise `application-cl-command.yaml` comme configuration. + `gapwalk-hierarchical-support.war`: contient le support des IMS/MFS transactions et `application-jhdb.yaml` l'utilise comme configuration