AWS Il servizio di modernizzazione del mainframe (esperienza Managed Runtime Environment) non è più aperto a nuovi clienti. Per funzionalità simili a AWS Mainframe Modernization Service (esperienza Managed Runtime Environment), esplora AWS Mainframe Modernization Service (Self-Managed Experience). I clienti esistenti possono continuare a utilizzare il servizio normalmente. [Per ulteriori informazioni, consulta AWS Modifica della disponibilità di Mainframe Modernization.](https://docs.aws.amazon.com/m2/latest/userguide/mainframe-modernization-availability-change.html) Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # AWS Trasformazione per la struttura mainframe di un'applicazione modernizzata Questo documento fornisce dettagli sulla struttura delle applicazioni modernizzate (utilizzando gli strumenti di refactoring della modernizzazione del AWS mainframe), in modo che gli sviluppatori possano svolgere varie attività, come: + navigazione fluida nelle applicazioni. + sviluppo di programmi personalizzati che possono essere richiamati dalle applicazioni modernizzate. + rifattorizzazione sicura di applicazioni modernizzate. Partiamo dal presupposto che tu abbia già conoscenze di base su quanto segue: + concetti di codifica comuni e preesistenti, come record, set di dati e relative modalità di accesso ai record (indicizzata, sequenziale), VSAM, unità di esecuzione, script jcl, concetti CICS e così via. + [codifica](https://spring.io/projects/spring-framework) java utilizzando il framework Spring. + In tutto il documento, lo utilizziamo `short class names` per la leggibilità. Per ulteriori informazioni, vedete [AWS Transform for mainframe: mappature dei nomi completamente qualificate](#ba-shared-structure-fqn-table) per recuperare i nomi completi corrispondenti per gli elementi di runtime AWS Transform for mainframe e [Mappature dei nomi completamente qualificate di terze parti](#ba-shared-structure-3pfqn-table) per recuperare i nomi completi corrispondenti per gli elementi di terze parti. + [Tutti gli artefatti e i campioni vengono prelevati dai risultati del processo di modernizzazione dell'applicazione di esempio. COBOL/CICS CardDemo ](https://github.com/aws-samples/aws-mainframe-modernization-carddemo) **Topics** + [Organizzazione degli artefatti](#ba-shared-structure-org) + [Esecuzione e chiamata di programmi](#ba-shared-structure-run-call) + [Scrivi il tuo programma](#ba-shared-structure-write) + [Mappature dei nomi complete](#ba-shared-structure-fqn) ## Organizzazione degli artefatti AWS Le applicazioni modernizzate Transform for mainframe sono confezionate come applicazioni web java (.war), che possono essere distribuite su un server JEE. [In genere, il server è un'istanza [Tomcat](https://tomcat.apache.org/) che incorpora AWS Transform for mainframe Runtime, attualmente basato sui framework [Springboot e Angular (per la parte dell'interfaccia utente](https://spring.io/projects/spring-boot)).](https://angular.io/) La guerra aggrega diversi artefatti componenti (.jar). Ogni jar è il risultato della compilazione (utilizzando lo strumento [maven](https://maven.apache.org/)) di un progetto java dedicato i cui elementi sono il risultato del processo di modernizzazione. ![\[Esempi di artefatti applicativi modernizzati.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/modernized_application_artifacts.png) L'organizzazione di base si basa sulla seguente struttura: + Progetto Entities: contiene il modello di business e gli elementi di contesto. Il nome del progetto generalmente termina con «-entities». In genere, per un determinato programma COBOL legacy, ciò corrisponde alla modernizzazione della I/O sezione (set di dati) e alla divisione dei dati. È possibile avere più di un progetto di entità. + Progetto di servizio: contiene elementi di modernizzazione della logica aziendale legacy. In genere, la divisione delle procedure di un programma COBOL. È possibile avere più di un progetto di servizio. + Progetto di utilità: contiene strumenti e utilità comuni condivisi, utilizzati da altri progetti. + Progetto Web: contiene la modernizzazione degli elementi relativi all'interfaccia utente, ove applicabile. Non utilizzato per progetti di modernizzazione esclusivamente in batch. Questi elementi dell'interfaccia utente potrebbero provenire dalle mappe CICS BMS, dai componenti IMS MFS e da altre fonti dell'interfaccia utente mainframe. È possibile avere più di un progetto Web. ### Entità: contenuti del progetto **Nota** Le seguenti descrizioni si applicano solo ai risultati COBOL e di PL/I modernizzazione. Gli output di modernizzazione dei giochi di ruolo si basano su un layout diverso. Prima di qualsiasi rifattorizzazione, l'organizzazione dei pacchetti nel progetto Entities è legata ai programmi modernizzati. È possibile farlo in un paio di modi diversi. Il modo preferito è utilizzare il toolbox Refactoring, che funziona prima di attivare il meccanismo di generazione del codice. Si tratta di un'operazione avanzata, spiegata nei corsi di formazione di AWS Transform for mainframe. Per ulteriori informazioni, consulta il workshop sul [refactoring](https://catalog.workshops.aws/aws-blu-age-l3-certification-workshop/en-US/refactoring). Questo approccio consente di preservare la capacità di rigenerare il codice java in un secondo momento, per beneficiare di ulteriori miglioramenti in futuro, ad esempio). L'altro modo è quello di eseguire regolarmente il refactoring java, direttamente sul codice sorgente generato, utilizzando qualsiasi approccio di refactoring java che si desideri applicare, a proprio rischio. ![\[Pacchetti di entità C del programma CBACT04 di esempio.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/entities_packages.png) #### Classi relative al programma Ogni programma modernizzato è correlato a due pacchetti, un pacchetto business.context e un pacchetto business.model. + `base package.program.business.context` Il sottopacchetto business.context contiene due classi, una classe di configurazione e una classe context. + Una classe di configurazione per il programma, che contiene dettagli di configurazione specifici per un determinato programma, come il set di caratteri da utilizzare per rappresentare gli elementi di dati basati su caratteri, il valore in byte predefinito per il riempimento degli elementi della struttura dei dati e così via. Il nome della classe termina con «Configurazione». È contrassegnato con l'`@org.springframework.context.annotation.Configuration`annotazione e contiene un singolo metodo che deve restituire un `Configuration` oggetto configurato correttamente. ![\[Configurazione di esempio in Java.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_configuration.png) + Una classe di contesto, che funge da ponte tra le classi di servizi del programma (vedi sotto) e le strutture di dati (`Record`) e i set di dati (`File`) del sottopacchetto del modello (vedi sotto). Il nome della classe termina con «Context» ed è una sottoclasse della `RuntimeContext` classe. ![\[Classe di contesto di esempio (vista parziale)\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_context.png) + `base package.program.business.model` Il sottopacchetto del modello contiene tutte le strutture di dati che il programma specificato può utilizzare. Ad esempio, qualsiasi struttura dati COBOL di livello 01 corrisponde a una classe nel sottopacchetto del modello (le strutture dati di livello inferiore sono proprietà della loro struttura a 01 livelli). Per ulteriori informazioni su come modernizziamo 01 strutture di dati, consulta. [Cosa sono i semplificatori di dati in AWS Transform for mainframe](ba-shared-data.md) ![\[Entità registrativa di esempio (visualizzazione parziale)\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_record_entity.png) Tutte le classi estendono la `RecordEntity` classe, che rappresenta l'accesso a una rappresentazione di record aziendali. Alcuni record hanno uno scopo speciale, in quanto sono legati a un`File`. L'associazione tra a `Record` e a `File` viene effettuata nei corrispondenti FileHandler metodi \$1 trovati nella classe context durante la creazione dell'oggetto file. Ad esempio, l'elenco seguente mostra come TransactfileFile `File` è associato a TransactFile `Record` (dal sottopacchetto del modello). ![\[Esempio di associazione tra record e file.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_record_file_binding.png) ### Contenuti del progetto di servizio Ogni progetto di servizio viene fornito con un'applicazione [Springboot](https://spring.io/projects/spring-boot) dedicata, che viene utilizzata come spina dorsale dell'architettura. Ciò si concretizza attraverso la classe denominata`SpringBootLauncher`, che si trova nel pacchetto base del servizio java sources: ![\[SpringBoot Applicazione del progetto di servizio.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/springbootlauncher.png) Questa classe è in particolare responsabile di: + creare un collante tra le classi del programma e le risorse gestite (fonti di dati/gestori di transazioni/mappature dei set di dati/ecc...). + fornire un ai programmi. `ConfigurableApplicationContext` + scoprendo tutte le classi contrassegnate come componenti a molla (`@Component`). + assicurando che i programmi siano registrati correttamente nel `ProgramRegistry` -- vedi il metodo di inizializzazione responsabile di questa registrazione. ![\[Registrazione dei programmi.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/programs_registration.png) #### Artefatti relativi al programma Senza un precedente refactoring, i risultati della modernizzazione della logica aziendale sono organizzati su due o tre pacchetti per programma precedente: ![\[Pacchetti di programmi di esempio.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_program_packages.png) Il caso più esaustivo avrà tre pacchetti: + `base package.program.service`: contiene un'interfaccia denominata *Program* Process, che utilizza metodi aziendali per gestire la logica aziendale, preservando il precedente flusso di controllo dell'esecuzione. + `base package.program.service.impl`: contiene una classe denominata *Program*ProcessImpl, che è l'implementazione dell'interfaccia Process descritta in precedenza. È qui che le istruzioni precedenti vengono «tradotte» in istruzioni java, basandosi sul framework AWS Transform for mainframe: ![\[Esempi di istruzioni CICS modernizzate (SEND MAP, RECEIVE MAP)\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_cics_statements.png) + `base package.program.statemachine`: questo pacchetto potrebbe non essere sempre presente. È necessario quando la modernizzazione del flusso di controllo legacy deve utilizzare un approccio basato su una macchina a stati (in particolare utilizzando il [ StateMachine framework Spring](https://spring.io/projects/spring-statemachine)) per coprire adeguatamente il flusso di esecuzione precedente. In tal caso, il sottopacchetto statemachine contiene due classi: + `ProgramProcedureDivisionStateMachineController`: una classe che estende una classe che implementa le interfacce `StateMachineController` (definisce le operazioni necessarie per controllare l'esecuzione di una macchina a stati) e `StateMachineRunner` (definisce le operazioni necessarie per eseguire una macchina a stati), utilizzate per guidare la meccanica della macchina a stati Spring; ad esempio, come nel `SimpleStateMachineController` caso di esempio. ![\[Esempio di controller per macchina a stati.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_statemachine_controller.png) Il controller della macchina a stati definisce i possibili diversi stati e le transizioni tra di essi, che riproducono il flusso di controllo dell'esecuzione precedente per un determinato programma. Durante la creazione della macchina a stati, il controller fa riferimento ai metodi definiti nella classe di servizio associata situata nel pacchetto della macchina a stati e descritti di seguito: ``` subConfigurer.state(States._0000_MAIN, buildAction(() -> {stateProcess._0000Main(lctx, ctrl);}), null); subConfigurer.state(States.ABEND_ROUTINE, buildAction(() -> {stateProcess.abendRoutine(lctx, ctrl);}), null); ``` + `ProgramProcedureDivisionStateMachineService`: questa classe di servizio rappresenta una logica aziendale che deve essere associata alla macchina a stati creata dal controller della macchina a stati, come descritto in precedenza. Il codice nei metodi di questa classe utilizza gli eventi definiti nel controller della macchina a stati: ![\[Servizio Statemachine che utilizza un evento statemachine controller.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/service_using_event_1.png) ![\[Servizio Statemachine che utilizza un evento del controller statemachine.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/service_using_event_2.png) Il servizio statemachine effettua anche chiamate all'implementazione del servizio di processo descritta in precedenza: ![\[servizio .statemachine che effettua chiamate all'implementazione del processo\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/service_using_processimpl.png) Inoltre, un pacchetto denominato `base package.program` svolge un ruolo importante, in quanto raccoglie una classe per programma, che fungerà da punto di ingresso al programma (maggiori dettagli su questo argomento più avanti). Ogni classe implementa l'`Program`interfaccia, indicatore di un punto di ingresso del programma. ![\[Punti di ingresso al programma\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/programs.png) #### Altri manufatti + Compagni BMS MAPs Oltre agli elementi relativi al programma, il progetto di servizio può contenere altri artefatti per vari scopi. Nel caso della modernizzazione di un'applicazione online CICS, il processo di modernizzazione produce un file json e inserisce nella cartella map della cartella/: src/main/resources ![\[File MAPs json BMS nella cartella delle risorse.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/maps_json_files.png) Il AWS Transform for mainframe runtime utilizza questi file json per associare i record utilizzati dall'istruzione SEND MAP ai campi dello schermo. + Script Groovy Se l'applicazione precedente aveva script JCL, questi sono stati modernizzati come script [groovy](https://groovy-lang.org/), archiviati nella src/main/resources/scripts cartella/(maggiori informazioni su quella posizione specifica più avanti): ![\[groovy scripts (modernizzazione JCL)\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/groovy_scripts.png) Questi script vengono utilizzati per avviare processi in batch (carichi di lavoro di elaborazione dati dedicati, non interattivi e che richiedono un uso intensivo della CPU). + File SQL Se l'applicazione precedente utilizzava query SQL, le corrispondenti query SQL modernizzate sono state raccolte in file di proprietà dedicati, con lo schema di denominazione *program .sql, dove program* è il nome del *programma* che utilizza tali query. ![\[File SQL nella cartella delle risorse\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sql_files.png) Il contenuto di questi file sql è una raccolta di voci (key=query), in cui ogni query è associata a una chiave univoca, che il programma modernizzato utilizza per eseguire la query specificata: ![\[Esempio di file sql utilizzato dal programma modernizzato.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_sql_file.png) Ad esempio, il programma COSGN00 C sta eseguendo la query con la chiave "COSGN00C\$11" (la prima voce nel file sql): ![\[esempio di utilizzo delle query per programma\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_sql_query_usage.png) ### Utilità, contenuti del progetto Il progetto utilities, il cui nome termina con «-tools», contiene una serie di utilità tecniche che potrebbero essere utilizzate da tutti gli altri progetti. ![\[Contenuto del progetto Utilities\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/tools_project.png) ### Contenuti dei progetti Web Il progetto web è presente solo durante la modernizzazione degli elementi dell'interfaccia utente legacy. [I moderni elementi dell'interfaccia utente utilizzati per creare il front-end dell'applicazione modernizzato sono basati su Angular.](https://angular.io/) L'applicazione di esempio utilizzata per mostrare gli artefatti della modernizzazione è un' COBOL/CICS applicazione in esecuzione su un mainframe. Il sistema CICS utilizza per rappresentare le schermate dell'interfaccia MAPs utente. Gli elementi moderni corrispondenti saranno, per ogni mappa, un file html accompagnato da file [Typescript](https://www.typescriptlang.org/): ![\[Esempi di mappe CICS modernizzate ad Angular\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_cics_maps_angular.png) Il progetto web si occupa solo dell'aspetto front-end dell'applicazione. Il progetto di servizio, che si basa sui progetti di utilità ed entità, fornisce i servizi di backend. Il collegamento tra il front-end e il backend viene effettuato tramite l'applicazione web denominata Gapwalk-Application, che fa parte dello standard Transform for mainframe runtime distribution. AWS ## Esecuzione e chiamata di programmi Nei sistemi precedenti, i programmi vengono compilati come eseguibili autonomi che possono richiamare se stessi tramite un meccanismo CALL, ad esempio l'istruzione COBOL CALL, passando argomenti quando necessario. Le applicazioni modernizzate offrono le stesse funzionalità ma utilizzano un approccio diverso, poiché la natura degli artefatti coinvolti è diversa da quelle precedenti. Sul versante modernizzato, i punti di ingresso del programma sono classi specifiche che implementano l'`Program`interfaccia, sono componenti Spring (@Component) e si trovano nei progetti di servizio, in un pacchetto denominato. `base package.program` ### Registrazione dei programmi Ogni volta che viene avviato il server [Tomcat](https://tomcat.apache.org/) che ospita le applicazioni modernizzate, viene avviata anche l'applicazione Springboot di servizio, che attiva la registrazione dei programmi. Un registro dedicato denominato `ProgramRegistry` è popolato con le voci del programma, ogni programma viene registrato utilizzando i propri identificatori, una voce per identificatore di programma noto, il che significa che se un programma è conosciuto con diversi identificatori, il registro contiene tante voci quanti sono gli identificatori. La registrazione per un determinato programma si basa sulla raccolta di identificatori restituiti dal metodo (): getProgramIdentifiers ![\[programma di esempio (visualizzazione parziale)\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/sample_program.png) In questo esempio, il programma viene registrato una sola volta, con il nome 'CBACT04C' (guarda il contenuto della collezione ProgramIdentifiers). I log di tomcat mostrano ogni registrazione del programma. La registrazione del programma dipende solo dagli identificatori di programma dichiarati e non dal nome della classe del programma stesso (sebbene in genere gli identificatori di programma e i nomi delle classi di programma siano allineati). Lo stesso meccanismo di registrazione si applica ai programmi di utilità forniti dalle varie utilità AWS Transform for mainframe web applications, che fanno parte della distribuzione di runtime AWS Transform for mainframe. Ad esempio, la Gapwalk-Utility-Pgm webapp fornisce gli equivalenti funzionali delle utilità di z/OS sistema (IDCAMS, ICEGENER, SORT e così via) e può essere richiamata da programmi o script modernizzati. Tutti i programmi di utilità disponibili registrati all'avvio di Tomcat vengono registrati nei log di Tomcat. ### Registrazione di script e demoni Un processo di registrazione simile, all'avvio di Tomcat, si verifica per gli script groovy che si trovano nella gerarchia delle cartelle/. src/main/resources/scripts La gerarchia delle cartelle degli script viene attraversata e tutti gli script groovy scoperti (eccetto lo script riservato special functions.groovy) vengono registrati in`ScriptRegistry`, utilizzando il loro nome breve (la parte del nome del file di script che precede il primo carattere del punto) come chiave per il recupero. **Nota** Se diversi script hanno nomi di file che generano la stessa chiave di registrazione, viene registrata solo la più recente, sovrascrivendo qualsiasi registrazione rilevata in precedenza per quella determinata chiave. Considerando la nota precedente, prestate attenzione quando utilizzate le sottocartelle poiché il meccanismo di registrazione appiattisce la gerarchia e potrebbe portare a sovrascritture impreviste. La gerarchia non conta nel processo di registrazione: tipicamente /.groovy. scripts/A/myscript.groovy and /scripts/B/myscript.groovy will lead to /scripts/B/myscript.groovy overwriting /scripts/A/myscript Gli script groovy nella cartella/src/main/resources/daemonsvengono gestiti in modo leggermente diverso. Sono ancora registrati come normali script, ma in aggiunta vengono lanciati una sola volta, direttamente all'avvio di Tomcat, in modo asincrono. Dopo la registrazione degli script in`ScriptRegistry`, una chiamata REST può avviarli, utilizzando gli endpoint dedicati esposti dall'applicazione Gapwalk. Per ulteriori informazioni, consultate la documentazione corrispondente. ### Programmi che chiamano programmi Ogni programma può richiamare un altro programma come sottoprogramma, passandogli dei parametri. A tale scopo, i programmi utilizzano un'implementazione dell'`ExecutionController`interfaccia (nella maggior parte dei casi si tratta di un'`ExecutionControllerImpl`istanza), oltre a un meccanismo API fluido chiamato the `CallBuilder` per creare gli argomenti delle chiamate al programma. Tutti i metodi dei programmi accettano `RuntimeContext` sia a che an `ExecutionController` come argomenti del metodo, quindi an `ExecutionController` è sempre disponibile per chiamare altri programmi. Si veda, ad esempio, il diagramma seguente, che mostra come il programma CBST03 A chiama il programma CBST03 B come sottoprogramma, passandogli dei parametri: ![\[.esempio di chiamata al sottoprogramma\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/subprogram_call_sample.png) + Il primo argomento di `ExecutionController.callSubProgram` è un identificatore del programma da chiamare (ovvero uno degli identificatori utilizzati per la registrazione del programma, vedere i paragrafi precedenti). + Il secondo argomento, che è il risultato della compilazione di`CallBuilder`, è una matrice di`Record`, corrispondente ai dati passati da chiamante a chiamante. + Il terzo e ultimo argomento è l'istanza del chiamante`RuntimeContext`. Tutti e tre gli argomenti sono obbligatori e non possono essere nulli, ma il secondo argomento può essere una matrice vuota. Il chiamante sarà in grado di gestire i parametri passati solo se originariamente è stato progettato per farlo. Per un programma COBOL precedente, ciò significa avere una sezione LINKAGE e una clausola USING per la divisione delle procedure per utilizzare gli elementi LINKAGE. [Ad esempio, consultate il file sorgente COBOL B.CBL corrispondente: CBSTM03](https://github.com/aws-samples/aws-mainframe-modernization-carddemo/blob/main/app/cbl/CBSTM03B.CBL) ![\[Esempio di collegamento in un file sorgente COBOL\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/linkage_sample.png) Quindi il programma CBSTM03 B ne accetta un singolo `Record` come parametro (un array di dimensione 1). Questo è ciò che `CallBuilder` sta costruendo, usando il concatenamento dei metodi byReference () e getArguments (). La classe API `CallBuilder` fluent dispone di diversi metodi per compilare l'array di argomenti da passare a un chiamante: + asPointer (RecordAdaptable): aggiunge un argomento di tipo puntatore, per riferimento. Il puntatore rappresenta l'indirizzo di una struttura dati di destinazione. + byReference (RecordAdaptable): aggiunge un argomento per riferimento. Il chiamante vedrà le modifiche eseguite dal chiamante. + byReference (RecordAdaptable): variante varargs del metodo precedente. + byValue (Object): aggiunge un argomento, trasformato in a`Record`, per valore. Il chiamante non vedrà le modifiche eseguite dal chiamante. + byValue (RecordAdaptable): uguale al metodo precedente, ma l'argomento è direttamente disponibile come. `RecordAdaptable` + byValueWithBounds (Object, int, int): aggiunge un argomento, trasformato in a`Record`, estraendo la parte dell'array di byte definita dai limiti specificati, per valore. Infine, il metodo getArguments raccoglierà tutti gli argomenti aggiunti e li restituirà come matrice di. `Record` **Nota** È responsabilità del chiamante assicurarsi che l'array di argomenti abbia la dimensione richiesta, che gli elementi siano ordinati correttamente e compatibili, in termini di layout di memoria, con i layout previsti per gli elementi di collegamento. ### Script che chiamano programmi La chiamata ai programmi registrati da groovy script richiede l'utilizzo di un'istanza di classe che implementa l'interfaccia. `MainProgramRunner` Di solito, l'ottenimento di un'istanza del genere si ottiene tramite l'utilizzo di Spring: ApplicationContext ![\[. MainProgramRunner : ottenere un'istanza\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/mpr.png) Dopo che un'`MainProgramRunner`interfaccia è disponibile, utilizzate il metodo runProgram per chiamare un programma e passate l'identificatore del programma di destinazione come parametro: ![\[MainProgramRunner : esecuzione di un programma\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/mpr_runprogram.png) Nell'esempio precedente, una fase di processo richiama IDCAMS (programma di utilità per la gestione dei file), che fornisce una mappatura tra le definizioni effettive dei set di dati e i relativi identificatori logici. Quando si tratta di set di dati, i programmi legacy utilizzano principalmente nomi logici per identificare i set di dati. Quando il programma viene richiamato da uno script, lo script deve mappare i nomi logici con set di dati fisici effettivi. Questi set di dati potrebbero trovarsi sul filesystem, in un archivio Blusam o persino definiti da un flusso in linea, dalla concatenazione di diversi set di dati o dalla generazione di un GDG. Usa il withFileConfiguration metodo per creare una mappa da logica a fisica dei set di dati e renderla disponibile al programma chiamato. ## Scrivi il tuo programma Scrivere il proprio programma per script o altri programmi modernizzati da richiamare è un'attività comune. In genere, nei progetti di modernizzazione, si scrivono i propri programmi quando un programma eseguibile legacy viene scritto in un linguaggio non supportato dal processo di modernizzazione, oppure i sorgenti sono andati perduti (sì, ciò può succedere) oppure il programma è un'utilità i cui sorgenti non sono disponibili. In tal caso, potresti dover scrivere il programma mancante, in java, da solo (supponendo che tu abbia una conoscenza sufficiente di quale dovrebbe essere il comportamento previsto del programma, del layout di memoria degli eventuali argomenti del programma e così via). Il programma java deve essere conforme ai meccanismi di programma descritti in questo documento, in modo che altri programmi e script possano eseguirlo. Per assicurarsi che il programma sia utilizzabile, è necessario completare due passaggi obbligatori: + Scrivete una classe che implementi l'`Program`interfaccia correttamente, in modo che possa essere registrata e chiamata. + Assicuratevi che il programma sia registrato correttamente, in modo che sia visibile da altri programmi/script. ### Scrittura dell'implementazione del programma Usa il tuo IDE per creare una nuova classe java che implementa l'`Program`interfaccia: ![\[Creazione di una nuova classe di programma java\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/new_program.png) L'immagine seguente mostra l'IDE di Eclipse, che si occupa di creare tutti i metodi obbligatori da implementare: ![\[Creazione di una nuova classe di programma java - modifica del codice sorgente\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/new_program_ide.png) ### Integrazione primaverile Innanzitutto, la classe deve essere dichiarata come componente Spring. Annota la classe con l'`@Component`annotazione: ![\[Utilizzo dell'annotazione spring @Component\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/program_component.png) Quindi, implementa correttamente i metodi richiesti. Nel contesto di questo esempio, abbiamo aggiunto `MyUtilityProgram` al pacchetto che contiene già tutti i programmi modernizzati. Tale posizionamento consente al programma di utilizzare l'applicazione Springboot esistente per fornire quanto necessario `ConfigurableApplicationContext` per l'implementazione del metodo: getSpringApplication ![\[Implementazione del metodo. getSpringApplication\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/getSpringApplication.png) Potresti scegliere una posizione diversa per il tuo programma. Ad esempio, è possibile individuare il programma specificato in un altro progetto di servizio dedicato. Assicurati che il progetto di servizio specificato abbia la sua applicazione Springboot, che consenta di recuperare ApplicationContext (che dovrebbe essere un). `ConfigurableApplicationContext` ### Dare un'identità al programma Per essere richiamabile da altri programmi e script, al programma deve essere assegnato almeno un identificatore, che non deve entrare in conflitto con nessun altro programma registrato esistente nel sistema. La scelta dell'identificatore potrebbe essere determinata dalla necessità di coprire un programma esistente sostitutivo di un programma legacy; in tal caso, sarà necessario utilizzare l'identificatore previsto, come indicato nelle occorrenze CALL presenti nei programmi legacy. La maggior parte degli identificatori di programma ha una lunghezza di 8 caratteri nei sistemi legacy. La creazione di un set non modificabile di identificatori nel programma è un modo per farlo. L'esempio seguente mostra la scelta di «MYUTILPG» come identificatore singolo: ![\[Esempio di identificatore di programma\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/program_identifier.png) ### Associa il programma a un contesto Il programma necessita di un'`RuntimeContext`istanza complementare. Per i programmi modernizzati, AWS Transform for mainframe genera automaticamente il contesto complementare, utilizzando le strutture di dati che fanno parte del programma legacy. Se state scrivendo il vostro programma, dovete scrivere anche il contesto complementare. Facendo riferimento a[Classi relative al programma](#ba-shared-structure-org-entities-program), puoi vedere che un programma richiede almeno due classi complementari: + una classe di configurazione. + una classe di contesto che utilizza la configurazione. Se il programma di utilità utilizza una struttura di dati aggiuntiva, anch'essa dovrebbe essere scritta e utilizzata dal contesto. Queste classi dovrebbero trovarsi in un pacchetto che fa parte di una gerarchia di pacchetti che verrà analizzata all'avvio dell'applicazione, per assicurarsi che il componente di contesto e la configurazione vengano gestiti dal framework Spring. Scriviamo una configurazione e un contesto minimi, nel `base package.myutilityprogram.business.context` pacchetto, appena creato nel progetto entities: ![\[Nuova configurazione e contesto dedicati per il nuovo programma di utilità\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/new_program_context_package.png) Ecco il contenuto della configurazione. Utilizza una build di configurazione simile ad altri programmi modernizzati nelle vicinanze. Probabilmente dovrai personalizzarlo per le tue esigenze specifiche. ![\[Nuova configurazione del programma\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/new_program_configuration.png) Note: + La convenzione di denominazione generale è *ProgramName*Configurazione. + Deve utilizzare le annotazioni @org .springFramework.Context.Annotation.Configuration e @Lazy. + Il nome del bean di solito segue la convenzione, ma questo non è obbligatorio. *ProgramName*ContextConfiguration Assicurati di evitare collisioni tra i nomi dei bean all'interno del progetto. + Il singolo metodo da implementare deve restituire un `Configuration` oggetto. Usa l'API `ConfigurationBuilder` fluent per aiutarti a crearne una. E il contesto associato: ![\[Nuovo contesto del programma in un file Java.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/new_program_context.png) Note + La classe context dovrebbe estendere un'implementazione di `Context` interfaccia esistente (`RuntimeContext`o`JicsRuntimeContext`, che è migliorata `RuntimeContext` con elementi specifici JICS). + La convenzione di denominazione generale è Context. *ProgramName* + È necessario dichiararlo come componente Prototype e utilizzare l'annotazione @Lazy. + Il costruttore fa riferimento alla configurazione associata, utilizzando l'annotazione @Qualifier per indirizzare la classe di configurazione corretta. + Se il programma di utilità utilizza alcune strutture di dati aggiuntive, queste dovrebbero essere: + scritto e aggiunto al `base package.business.model` pacchetto. + referenziato nel contesto. Dai un'occhiata ad altre classi di contesto esistenti per vedere come fare riferimento alle classi di strutture di dati e adattare i metodi di contesto (constructor/cleanup/reset) secondo necessità. Ora che è disponibile un contesto dedicato, lascia che il nuovo programma lo utilizzi: ![\[Il nuovo programma utilizza il contesto appena creato.\]](http://docs.aws.amazon.com/it_it/m2/latest/userguide/images/new_program_uses_context.png) Note: + Il metodo getContext deve essere implementato rigorosamente come mostrato, utilizzando una delega al getOrCreate metodo della `ProgramContextStore` classe e al cablato automatico Spring. `BeanFactory` Un singolo identificatore di programma viene utilizzato per memorizzare il contesto del programma in`ProgramContextStore`; questo identificatore è indicato come «identificatore principale del programma». + È necessario fare riferimento alla configurazione complementare e alle classi di contesto utilizzando l'annotazione spring. `@Import` ### Implementazione della logica aziendale Una volta completata la struttura del programma, implementate la logica di business per il nuovo programma di utilità. Fatelo con il `run` metodo del programma. Questo metodo verrà eseguito ogni volta che il programma viene chiamato, da un altro programma o da uno script. Buona codifica\$1 ### Gestione della registrazione al programma Infine, assicurati che il nuovo programma sia registrato correttamente in`ProgramRegistry`. Se avete aggiunto il nuovo programma al pacchetto che già contiene altri programmi, non c'è altro da fare. Il nuovo programma viene prelevato e registrato con tutti i programmi adiacenti all'avvio dell'applicazione. Se hai scelto un'altra posizione per il programma, devi assicurarti che il programma sia registrato correttamente all'avvio di Tomcat. Per qualche ispirazione su come farlo, date un'occhiata al metodo di inizializzazione delle SpringbootLauncher classi generate nei progetti di servizio (vedi[Contenuti del progetto di servizio](#ba-shared-structure-org-service)). Controlla i log di avvio di Tomcat. Ogni registrazione al programma viene registrata. Se il programma è stato registrato correttamente, troverai la voce di registro corrispondente. Quando sei sicuro che il tuo programma sia registrato correttamente, puoi iniziare a ripetere la codifica della logica aziendale. ## Mappature dei nomi complete Questa sezione contiene elenchi dei mapping dei nomi completi di AWS Transform for mainframe e di terze parti da utilizzare nelle applicazioni modernizzate. ### AWS Transform for mainframe: mappature dei nomi completamente qualificate | Nome breve | Nome completamente qualificato | | --- | --- | | `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` | ### Mappature dei nomi completamente qualificate di terze parti | Nome breve | Nome completamente qualificato | | --- | --- | | `@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` |