AWS Struttura Blu Age 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), unità di esecuzioneVSAM, script jcl, concetti e così via. CICS

• codifica java utilizzando il framework Spring.

• In tutto il documento, lo utilizziamo short class names per la leggibilità. Per ulteriori informazioni, vedete AWS Mappature dei nomi completamente qualificate di Blu Age per recuperare i nomi completi corrispondenti per gli elementi di runtime AWS Blu Age e Mappature dei nomi completamente qualificate di terze parti 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 del campione/dell'applicazione. COBOL CICS CardDemo

Organizzazione degli artefatti

AWS Le applicazioni modernizzate di Blu Age sono confezionate come applicazioni web java (.war), che possono essere distribuite su un server. JEE In genere, il server è un'istanza Tomcat che incorpora AWS Blu Age Runtime, attualmente basato sui framework Springboot e Angular (per la parte dell'interfaccia utente).

La guerra aggrega diversi artefatti componenti (.jar). Ogni jar è il risultato della compilazione (utilizzando lo strumento maven) di un progetto java dedicato i cui elementi sono il risultato del processo di modernizzazione.

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 COBOL programma legacy, ciò corrisponde alla modernizzazione della sezione I/O (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 COBOL programma. È 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 da CICS BMS mappe, IMS MFS componenti e altre fonti dell'interfaccia utente mainframe. È possibile avere più di un progetto Web.

Entità: contenuti del progetto

Nota

Le seguenti descrizioni si applicano solo agli output COBOL di modernizzazione PL/I. RPGgli output di modernizzazione si basano su un layout diverso.

Prima di qualsiasi rifattorizzazione, l'organizzazione dei pacchetti nel progetto delle entità è 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, che viene spiegata nei corsi di formazione. BluAge Per ulteriori informazioni, vedere il workshop sul 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.

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.Configurationannotazione e contiene un singolo metodo che deve restituire un Configuration oggetto configurato correttamente.

    

  • 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.

    

• 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 COBOL dati 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 Blu Age AWS

  

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 unFile. L'associazione tra a Record e a File viene effettuata nei corrispondenti FileHandler metodi * 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).

Contenuti del progetto di servizio

Ogni progetto di servizio viene fornito con un'applicazione Springboot dedicata, che viene utilizzata come spina dorsale dell'architettura. Ciò si concretizza attraverso la classe denominataSpringBootLauncher, che si trova nel pacchetto base del servizio java sources:

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.

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:

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 ProgramProcessImpl, che è l'implementazione dell'interfaccia Process descritta in precedenza. È qui che le istruzioni precedenti vengono «tradotte» in istruzioni java, basandosi sul framework AWS Blu Age:

  

• 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) 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.

    

    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:

    
    

    Il servizio statemachine effettua anche chiamate all'implementazione del servizio di processo descritta in precedenza:

    

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'Programinterfaccia, indicatore di un punto di ingresso del programma.

Altri manufatti

• BMSMAPscompagni

  Oltre agli elementi relativi al programma, il progetto di servizio può contenere altri artefatti per vari scopi. Nel caso della modernizzazione di un'applicazione CICS online, il processo di modernizzazione produce un file json e lo inserisce nella cartella map della cartella /src/main/resources:

  

  Il runtime Blu Age utilizza quei file json per associare i record utilizzati dall'SENDMAPistruzione ai campi dello schermo.

• Groovy Scripts

  Se l'applicazione precedente aveva JCL degli script, questi sono stati modernizzati come groovy script, archiviati nella cartella /src/main/resources/scripts (più su quella posizione specifica più avanti):

  

  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).

• SQLfile

  Se l'applicazione precedente utilizzava SQL delle query, le corrispondenti SQL query 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.

  

  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:

  

  Ad esempio, il programma COSGN 00C sta eseguendo la query con la chiave "COSGN00C_1" (la prima voce nel file sql):

  

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.

Contenuti dei progetti Web

Il progetto web è presente solo quando si modernizzano gli elementi dell'interfaccia utente legacy. I moderni elementi dell'interfaccia utente utilizzati per creare il front-end dell'applicazione modernizzato sono basati su Angular. L'applicazione di esempio utilizzata per mostrare gli artefatti della modernizzazione è un'CICSapplicazioneCOBOL/, in esecuzione su un mainframe. Il CICS sistema viene utilizzato MAPs per rappresentare le schermate dell'interfaccia utente. Gli elementi moderni corrispondenti saranno, per ogni mappa, un file html accompagnato da file Typescript:

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 della distribuzione di runtime Blu Age standard. AWS

Esecuzione e chiamata di programmi

Nei sistemi precedenti, i programmi vengono compilati come eseguibili autonomi che possono richiamare se stessi tramite un CALL meccanismo, ad esempio l'COBOLCALListruzione, 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'Programinterfaccia, 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 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

In questo esempio, il programma viene registrato una volta, con il nome 'CBACT04C' (guarda il contenuto della programIdentifiers raccolta). 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 applicazioni web di utilità AWS Blu Age, che fanno parte della distribuzione di runtime AWS Blu Age. Ad esempio, la webapp Gapwalk-Utility-Pgm fornisce gli equivalenti funzionali delle utilità di sistema z/OS (IDCAMS,, e così via) e può essere richiamata da programmi o script ICEGENER SORT 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 scripts viene attraversata e tutti gli script groovy scoperti (tranne lo script riservato special functions.groovy) vengono registrati inScriptRegistry, utilizzando il loro nome breve (la parte del nome del file di script che si trova prima del primo carattere 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: in genere /scripts/a/myscript.groovy e /scripts/b/myscript.groovy porteranno a /scripts/b/myscript.groovy sovrascrivere /scripts/a/myscript.groovy.

Gli script groovy nella cartella /src/main/resources/daemons vengono 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 inScriptRegistry, una REST chiamata 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'ExecutionControllerinterfaccia (nella maggior parte dei casi si tratta di un'ExecutionControllerImplistanza), oltre a un API meccanismo 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 CBST 03A chiama il programma CBST 03B come sottoprogramma, passandogli dei parametri:

• 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 diCallBuilder, è una matrice diRecord, corrispondente ai dati passati da chiamante a chiamante.

• Il terzo e ultimo argomento è l'istanza del chiamanteRuntimeContext.

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 COBOL programma legacy, ciò significa avere una LINKAGE sezione e una USING clausola per la divisione delle procedure per utilizzare gli LINKAGE elementi.

Ad esempio, vedi il corrispondente CBSTM03B. CBLCOBOLfile sorgente:

Quindi il programma CBSTM 03B ne accetta un singolo Record come parametro (un array di dimensione 1). Questo è ciò che CallBuilder sta costruendo, usando il concatenamento dei metodi byReference getArguments () e ().

La API classe 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, come 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(Oggetto): aggiunge un argomento, trasformato in aRecord, per valore. Il chiamante non vedrà le modifiche eseguite dal chiamante.

• byValue(RecordAdaptable): uguale al metodo precedente, ma l'argomento è direttamente disponibile come. RecordAdaptable

• byValueWithLimiti (Object, int, int): aggiungi un argomento, trasformato in aRecord, estraendo la parte dell'array di byte definita dai limiti specificati, per valore.

Infine, il getArguments metodo raccoglierà tutti gli argomenti aggiunti e li restituirà come una 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

Dopo che un'MainProgramRunnerinterfaccia è disponibile, utilizzate il runProgram metodo per chiamare un programma e passate l'identificatore del programma di destinazione come parametro:

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'Programinterfaccia 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'Programinterfaccia:

L'immagine seguente mostra EclipseIDE, che si occupa di creare tutti i metodi obbligatori da implementare:

Integrazione primaverile

Innanzitutto, la classe deve essere dichiarata come componente Spring. Annota la classe con l'@Componentannotazione:

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

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; in tal caso, sarà necessario utilizzare l'identificatore previsto, come CALL accade nelle occorrenze 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:

Associa il programma a un contesto

Il programma necessita di un'RuntimeContextistanza complementare. Per i programmi modernizzati, AWS Blu Age 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 aClassi relative al programma, 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:

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.

Note:

• La convenzione di denominazione generale è ProgramNameConfigurazione.

• Deve utilizzare le annotazioni @org .springFramework.Context.Annotation.Configuration e @Lazy.

• Il nome del bean di solito segue la convenzione, ma questo non è obbligatorio. ProgramNameContextConfiguration Assicurati di evitare le collisioni tra i nomi dei bean all'interno del progetto.

• Il singolo metodo da implementare deve restituire un Configuration oggetto. Usa ConfigurationBuilder Fluent API per aiutarti a crearne uno.

E il contesto associato:

Note

• La classe context dovrebbe estendere un'implementazione di Context interfaccia esistente (RuntimeContextoJicsRuntimeContext, che è migliorata RuntimeContext con elementi JICS specifici).

• La convenzione di denominazione generale è ProgramNameContext.

• È 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.

  • a cui si fa riferimento 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:

Note:

• Il getContext metodo deve essere implementato rigorosamente come mostrato, utilizzando una delega al getOrCreate metodo della ProgramContextStore classe e all'auto cablata SpringBeanFactory. Un singolo identificatore di programma viene utilizzato per memorizzare il contesto del programma inProgramContextStore; 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!

Gestione della registrazione al programma

Infine, assicurati che il nuovo programma sia registrato correttamente inProgramRegistry. 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 (vediContenuti del progetto di servizio).

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 Blu Age e di terze parti da utilizzare nelle applicazioni modernizzate.

AWS Mappature dei nomi completamente qualificate di Blu Age

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