legacy generator marzo 2011 - teamsystem gen… · coordinamento di teamsystem s.p.a., sede legale...

© Copyright ACG Srl 2014 Tutti i diritti riservati. Pagina 1 di 16

Guida tecnica Legacy Generator

Marzo 2011


Note Tutti i contenuti del presente documento e i diritti ad essi correlati sono riservati. Tali contenuti pertanto possono essere consultati esclusivamente per finalità d’informazione personale, essendo espressamente vietato ogni diverso utilizzo senza il preventivo consenso scritto di ACG. Sebbene sia stata usata ogni ragionevole cura nel raccogliere e presentare le informazioni contenute nel presente documento, nessuna garanzia è prestata in ordine alla loro esattezza, completezza, utilità, né ai loro possibili impieghi da parte degli utenti; è pertanto esclusa ogni responsabilità di ACG per errori, inesattezze od omissioni relative a dette informazioni. I contenuti del presente documento sono soggetti a continuo aggiornamento e sono da ritenersi puramente indicativi e suscettibili di eventuali errori e/o imprecisioni. ACG può introdurre miglioramenti e/o variazioni ai prodotti e/o programmi descritti nel presente documento in qualsiasi momento e senza preavviso. Il presente documento può contenere informazioni che riguardano programmi e propositi futuri, che vengono descritti di volta in volta mediante l’utilizzo di termini come "attendersi", "stimare", "prevedere", "prospettare" e "programmare". Tali dichiarazioni per loro natura non comportano alcun impegno a carico di ACG, che pertanto non assume in relazione ad essi alcuna responsabilità di realizzazione. Qualunque riferimento a siti web diversi da www.acginfo.it è fornito a solo titolo esemplificativo e non costituisce invito all’utilizzo e/o navigazione. I contenuti dei siti web referenziati non sono parte dei prodotti ACG e il loro eventuale utilizzo da parte dell’utente è effettuato a suo esclusivo rischio. Le informazioni relative a prodotti non ACG contenute nel presente documento sono fornite dai rispettivi fornitori, dagli annunci pubblicitari e da informazioni liberamente disponibili. ACG non ha collaudato tali prodotti e non può confermarne l’accuratezza delle prestazioni, la compatibilità con i prodotti ACG o qualunque altra caratteristica. Qualunque richiesta sulle caratteristiche operative dei prodotti non ACG deve essere rivolta direttamente ai rispettivi fornitori. Fatti salvi i danni causati da dolo o colpa grave, ACG non assume nessuna responsabilità circa i contenuti del presente documento. In particolare, tali contenuti non rappresentano una promessa o garanzia relativa alla all’idoneità a determinati scopi dei prodotti ACG oppure alla non violazione, da parte dei prodotti ACG stessi, di leggi di qualsivoglia natura.

http://www.acginfo.it/


Trademarks ACG e ACG Vision4 sono marchi di ACG S.r.l., con socio unico e soggetta all’attività di direzione e coordinamento di TeamSystem S.p.A., sede legale in Via Yuri Gagarin, 205 – 61122 Pesaro (PU), Cap. Soc. € 100.000 i.v., codice fiscale e iscrizione al Registro delle Imprese di Milano n. 08419500965 (di seguito “ACG”) - Tutti i diritti riservati. I marchi e loghi riportati nel presente documento diversi da ACG e ACG Vision4 (ivi inclusi, a mero titolo

esemplificativo e non esaustivo, IBM, il logo IBM, Adobe, il logo Adobe, PostScript, il logo PostScript, Intel, il logo

Intel, Intel Inside, il logo Intel Inside, Intel Centrino, il logo Intel Centrino, Celeron, Intel Xeon, Intel SpeedStep,

Itanium e Pentium, Linux, Microsoft, Windows, Windows NT e il logo di Windows, UNIX, Java, Novell, il logo

Novell, openSUSE e il logo openSUSE, AS/400, BladeCenter, Cognos, DB2, DB2 Universal Database, eServer, i5/OS,

iSeries, OpenPower, OS/400, POWER, Power Systems, pSeries, Rational, System i, System i5, System p, System p5,

System Storage, System x, WebSphere, etc.) sono di titolarità di soggetti terzi. ACG rispetta i diritti di proprietà

intellettuale di terzi.


Legacy Generator

Il file LegacyGenerator.zip contiene gli oggetti di un progetto per l’IDE Rational Application

Developer Versione 7.0 o successiva, tramite il quale è possibile generare le classi Java che

consentono di richiamare codice legacy (vale a dire programmi che girano sotto l’architettura del

Modulo Base ACG) utilizzando la componente del Service Bus ACG denominata Legacy

Connector.

Ulteriori dettagli sulla componente Legacy Connector e sulle modalità di utilizzo del generatore di

codice possono essere reperite consultando il capitolo 5 dalla Programmer’s Guide a partire dal

paragrafo 5.2.

L’import del progetto LegacyGenerator richiede l’esecuzione dei seguenti passi:

- selezionare nel menu "File" in RAD la voce "Import"; verrà presentata la seguente finestra:

- selezionare la voce “Project Interchange” e premere il pulsante “Next”;

verrà presentata la seguente finestra:


- specificare il percorso del file LegacyGenerator.zip, selezionare il progetto ed indicare il

percorso del workspace di destinazione; quindi premere Finish.

Vengono riportate qui di seguito alcune informazioni relativamente al componente di ACG Service

Bus denominato Legacy Connector e la procedura di utilizzo del Legacy Generator.


Legacy Connector

ACG Service Bus consente, tramite questo componente, il riutilizzo di codice legacy ACG da

parte di applicazioni client, sia attraverso le tecnologie J2EE che attraverso le tecnologia standard

dei web service. Nel presente documento, con l’espressione “codice legacy ACG” ci si riferisce a:

qualsiasi programma RPG, RPG-ILE e CLP che gira su un server iSeries sotto architettura di

Modulo Base, che riceva in input quale unico parametro la KPJBA;

qualsiasi classe java ottenuta dalla conversione, effettuata tramite i tool Caravel e Interactive

Converter, di un programma RPG, RPG-ILE e CLP che soddisfi le condizioni descritte nel punto

precedente.

Si ipotizza che il riuso del codice legacy possa prevedere una sua modifica per:

aderire al programming model definito dall’architettura ACG Vision 4 relativamente alla

componente di riuso

estrapolare la logica di presentazione da quella di business o condizionare il flusso elaborativo

in modo da non escludere/inibire l’interazione con l’utente tramite l’emissione di interfacce video

prevedere una nuova modalità di ricezione di dati in input e di emissione in output, in

considerazione del fatto che il codice legacy non deve essere più visto come software destinato a

produrre dati da presentare ad un’interfaccia utente, ma come fornitore di un servizio ad

un’applicazione terza che può utilizzare le informazioni ricevute per presentarle a video o per altri

scopi elaborativi

Diagramma architetturale

La figura sottostante rappresenta il diagramma architetturale delle componenti che

realizzano il richiamo del codice legacy.

I componenti rappresentati nel diagramma sono i seguenti:

Legacy Program Interface: è una classe java che riceve in input i dati da

un’applicazione client (requester) e li prepara per il Legacy Connector. Una volta


terminata l’elaborazione del programma servente, riceve i dati dal Legacy Connector e li

invia all’applicazione richiedente come risposta alla richiesta fatta da quest’ultima.

Legacy Connector: è un insieme di classi Java, il cui scopo è quello di richiamare

un’operazione di Service Bus V4, passando i dati ricevuti dalla Legacy Program Interface.

Al termine dell’esecuzione dell’operazione, l’output prodotto dal codice legacy viene

recuperato ed inviato alla Legacy Program Interface.

Codice legacy: qualsiasi programma RPG, RPG-ILE e CLP che gira su un server iSeries

sotto architettura di Modulo Base che riceva in input quale unico parametro la KPJBA e

non abbia una interfaccia a video oppure qualsiasi classe java ottenuta dalla conversione,

effettuata tramite i tool Caravel e Interactive Converter, di un programma RPG, RPG-ILE

e CLP che soddisfi le condizioni descritte nel punto precedente.

Operazione di Service Bus V4: rappresenta l’evoluzione del concetto di azione di

Modulo Base ACG in ACG Vision4, così come specificato nel paragrafo “Operazioni”. Il

codice legacy viene legato all’operazione di Service Bus, attraverso la quale viene

controllata l’autorizzazione di un utente all’esecuzione della stessa.

Database ACG: rappresenta la base dati di un sistema informativo ACG, sia nativo

iSeries che DB2 su piattaforma Win/Linux, che viene acceduta dal codice legacy associato

all’operazione di Service Bus V4

Tabelle temporanee: rappresentano un set di tabelle di lavoro che vengono utilizzate

dal codice legacy per leggere i dati in input provenienti dalla Legacy Program interface e

per restituire a quest’ultima una risposta. Sono usate tipicamente nel caso di passaggio di

una grossa mole di dati che deve essere scambiata tra applicazione client e codice legacy.

La sequenza delle operazioni può essere sintetizzata come segue:

a) La Legacy Program Interface riceve in input l’utente di collegamento, la password, il

nome del Sistema Informativo e l’indirizzo IP del server al quale collegarsi. Tali

informazioni, in alternativa, potranno essere ricavati dall’architettura, accedendo alla

componente di Logon

b) La Legacy Program Interface riceve i dati in input da un’applicazione client. Si

distinguono due tipi di input:

- dati da passare al codice legacy tramite KPJBA, inserendoli nella parte utente

KPJBU (possono cioè essere compattati in una stringa di 256 caratteri)

- un insieme di dati che non possono essere passati attraverso la KPJBU, nel caso di

una struttura dati maggiore di 256 caratteri o di una collezione di dati (ad es. un ordine

con dati di testata ed un insieme di righe)

c) La Legacy Program Interface compatta i dati di input formando una stringa unica o un

insieme di stringhe nel caso di collection di dati. Ogni stringa rappresenta la

concatenazione ordinata dei dati ricevuti che il codice client dovrà decifrare utilizzando

un’opportuna maschera di decodifica (vale a dire tramite una DS nel caso di legacy

AS/400). Nel caso di dati non impostati dall’applicazione client (dati facoltativi) questi

vengono impostati a tutti spazi nel caso di alfanumerici o a tutti zero nel caso di valori

numerici. La legacy program interface normalizza la lunghezza di ogni stringa recuperata

dal bean di input alla lunghezza prevista per ciascun tipo dato.

Ciascuna stringa che rappresenta una struttura dati di input, sarà accompagnata

dall’informazione relativa al tipo di struttura dati che la interpreta.


L’ordine con il quale vengono ricevute le stringhe di input sarà rispettato in fase di

scrittura sulle tabelle temporanee

d) La Legacy Program Interface passa al Legacy Connector la stringa che rappresenta

l’input della KPJBU o la collezione di stringhe che rappresentano i dati da scrivere sulle

tabelle temporanee. Inoltre la Legacy Program Interface passa al Legacy Connector le

informazioni di logon (utente, password, indirizzo server e sistema informativo) se le ha

ricevute in input.

e) Il Legacy Connector recupera il logon dal server, se non ha ricevuto le credenziali di

accesso, altrimenti crea un logon utilizzando il Componente di Logon. Quindi verifica

che l’utente sia abilitato all’esecuzione dell’operazione di Modulo Base utilizzando la

Componente di autorizzazione utente

f) Il Legacy Connector crea un identificativo di transazione e costruisce la KPJBA,

impostando opportunamente la KPJBU. Nel caso in cui non debba passare dati al codice

legacy tramite KPJBU, imposta quest’ultima con l’identificativo di transazione.

g) Il Legacy Connector scrive la collezione di dati nelle tabelle temporanee e richiama

l’operazione di Service Bus V4, utilizzando una programma assimilabile all’odierno

programma BMRUN presente in ACG legacy (la chiamata viene eseguita tramite Java

Toolbox per AS/400 o framework Caravel a seconda dell’ambiente di esecuzione). Tale

programma predispone opportunamente l’ambiente di esecuzione dell’operazione di

Service Bus V4, impostando la lista delle librerie.

h) Il codice legacy associato all’operazione di Service Bus V4 legge la KPJBU ed,

eventualmente, le tabelle temporanee per recuperare i dati di input. Quindi esegue la

propria elaborazione accedendo ed aggiornando eventualmente il database, producendo

stampe, lanciando lavori batch o richiamando altri programmi che non prevedano

interfaccia a video

i) Al termine dell’elaborazione il codice legacy associato all’azione di Modulo Base

restituisce il controllo al Modulo Base e questo al Legacy Connector

j) Il Legacy Connector legge la KPJBU ricevuta dal codice legacy; se questa contiene un

identificativo di transazione, vengono lette le tabelle temporanee per recuperare l’output

ed impostare i dati da inviare alla Legacy Program Interface. In caso contrario viene

inviata la KPJBU alla Legacy Program Interface.

k) La Legacy Program Interface scompatta le stringhe che rappresentano la KPJBU ed

eventualmente la collezione di dati di output, utilizzando opportune maschere di

decodifica.

E’ previsto pertanto che il programma legacy possa lavorare nei modi seguenti:

a) scambiare i dati in input tramite KPJBU

b) scambiare i dati in input/output tramite tabelle temporanee

c) scambiare (opzionalmente) i dati in input/output tramite un parametro aggiuntivo di

2000 caratteri in aggiunta alla KPJBA

d) ricevere l’input tramite KPJBU e scrivere l’output sulle tabelle temporanee

e) ricevere l’input tramite tabelle temporanee e scrivere l’output nella KPJBU


Eccetto che nel primo caso, è previsto che l’identificativo di transazione dei record da

leggere/scrivere nelle tabelle temporanee sia passato tramite KPJBU. L’identificativo di

transazione, come detto, viene generato automaticamente dal Legacy Connector.

L’elaborazione, in ogni caso, produce la scrittura di uno o più record nel file di log

dell’elaborazione per tracciare l’esito dell’elaborazione (segnalazione di errori o di elaborazione

terminata regolarmente).

La figura sottostante illustra l’interazione del Legacy Connector con le altre componenti

infrastrutturali di ACG Vision4 e le tabelle di database alle quali accede.


Struttura delle tabelle temporanee e di log dell’elaborazione

Il file temporaneo di input (INPUT00F), il cui scopo è quello di accogliere i dati di input da

inviare al codice legacy che non possono essere passati tramite KPJBU, sarà strutturato come segue:

- Identificativo di transazione (35A)

- Numeratore record (intero di 9 cifre)

- Identificativo del tipo record (10A)

- Dati di input (2000 A)

Il file temporaneo di output (OUTPT00F), il cui scopo è quello di accogliere i dati di output

prodotti dal codice legacy che non possono essere passati tramite KPJBU, sarà strutturato come

segue:

- Identificativo di transazione (35A):

- Numeratore record (intero di 9 cifre)

- Identificativo del tipo record (10A)

- Dati di output (2000 A)

Il file di log dell’elaborazione sarà strutturato come segue:

- Identificativo di transazione (35A)

- Tipo record (10A)

- Numeratore record (9A)

- Catalogo messaggi (10A)

- Tipo messaggio (2,0); valori ammissibili: I=Info - W=Warn - E=Error - F=Fatal

- Identificativo del messaggio (7A)

- Testo del messaggio (80A)

- Testo di secondo livello del messaggio (256A)

- Primo campo in errore (10A)

- Secondo campo in errore (10A)

- Terzo campo in errore (10A)

In ciascun file la chiave univoca è rappresentata da:

- identificativo di transazione

- tipo record

- numeratore record

Nei file temporanei di input e output l’identificativo di tipo record individua la struttura dati

che decodifica il contenuto dei dati che il codice legacy deve leggere o scrivere. Ad esempio, se si

devono passare al codice legacy i dati della testata di un ordine più un insieme di righe, nel file

temporaneo di input viene scritto un record per la testata, indicando nel campo “Identificativo del

tipo record” il nome della struttura dati per la decodifica della testata; analogamente verranno scritte

tante righe quante sono le righe dell’ordine, indicando come tipo record la struttura dati per la

decodifica della riga d’ordine.


Si è scelto di indicare una lunghezza di 2000 caratteri per la scrittura dei dati; nel caso

particolare che un record abbia una struttura dati di lunghezza superiore, dovranno essere scritti due

o più record con tipo differente. Sarà cura del programma chiamante scomporre la struttura su più

record diversi ed il codice legacy dovrà leggere opportunamente tali dati, ricombinandoli

logicamente a formare una struttura dati unica (si ritiene tuttavia che si tratti di una evenienza

remota).

La scrittura e la lettura sui file temporanei e su quello di log dell’elaborazione sarà effettuata

da programmi generalizzati del Service Bus.

Al termine dell’elaborazione i file temporanei saranno ripuliti dei record scritti per

scambiare l’I/O con il codice legacy, su indicazione specifica dell’utente.

Amministrazione delle tabelle temporanee

La scrittura e la cancellazione di un gran numero di record nei file temporanei potrebbe

causare problemi di occupazione disco su server iSeries, nel quale la cancellazione di un record da

programma determina la cancellazione logica ma non quella fisica.

Per poter ovviare a questo inconveniente è necessario creare i file temporanei impostando il

parametro REUSEDLT ad *YES.


Generazione codice Java per la Legacy program interface

La generazione del codice java di richiamo del codice legacy può essere effettuata

a) utilizzando un semplice editor per la scrittura di due file funzionali allo sviluppo e

lanciando la classe di generazione da linea comando DOS avendo impostato

opportunamente il CLASSPATH

b) importando il progetto LegacyGenerator.jar in Rational Application Developer (RAD)

creando un progetto Java, utilizzando i tool della piattaforma di sviluppo per editare i file

e lanciare la classe di generazione.

La generazione del codice java richiede fondamentalmente la stesura di due file:

o File di property strutturato con le seguenti chiavi:

src_path=source

system=xxx.xxx.xxx.xxx

user=QPGMR

password=PWDQPGMR

libraries=ACG_OBJV4;ACG_DATV4

pkg_action=com.ibm.acgv4.xx.action

pkg_bean= com.ibm.acgv4.xx.bean

DS=ACV4DS;ADV4DS

TABLES=

ACTION=ACV4Action

essendo:

src_path: directory sorgenti progetto in RAD)

system: IP address sistema iSeries

user: utenza di servizio per il logon al sistema

password: password utenza di servizio

libraries: una lista di librerie nelle quali sono presenti tutti gli oggetti

da elaborare (file di database, DS)

pkg_action: nome del package per la classe Action

pkg_bean: nome del package per le classi bean

DS: nomi delle DS utilizzate separati da ;

TABLES: nomi dei file di database utilizzati separati da ;

ACTION: nome del file XML da utilizzare per la generazione della classe Action

o File XML di definizione della classe Action nel formato

<?xml version="1.0" encoding='UTF-8'?>

<action actionName="AC43" actionType='AS400RPG' deleteOutput="true"

deleteInput="true" extendedParms="true" batch="true">

<configuration name="configuration" type="ConfBean"/>

<parameter name="parameter" type="AC43DS"/>

<param2 type="AC43DS"/>

<input type="INP1DS"/>

<output type="OUT1DS"/>

</action>


essendo:

Elemento action ( <action actionName="AC43" ...) Cardinalità dell’elemento = 1

actionName = nome dell’azione di Modulo Base da lanciare

actionType = tipo azione (‘AS400RPG’) per le azioni AS400

deleteOutput = specifica se deve essere cancellato il contenuto di OUTPT00F al termine

dell’esecuzione dell’azione (valori ammissibili: true o false)

deleteInput = specifica se deve essere cancellato il contenuto di INPUT00F al termine

dell’elaborazione (valori ammissibili: true o false)

extendedParams = specifica se il programma associato all’azione richiede come parametro di input

solo la KPJBA (valore impostato a false) oppure, in aggiunta al parametro di architettura, richiede il

parametro di I/O alfanumerico di 2000 caratteri

param2 = deve essere definito nell'XML in accoppiata con il parametro extendedParms impostato a

true. Specifica il nome della DS nell’attributo type da usare per l’impostazione del secondo

parametro di I/O

batch = specifica se il programma da richiamare deve essere lanciato in interattivo o in batch

(valori ammissibili: true o false; default è false in assenza dell’attributo)

Elemento configuration ( <configuration name="co ...)

Cardinalità dell’elemento = 1

Non modificare: serve ad aggiungere all’action java un’istanza della classe ConfBean da utilizzare

in alternativa all’istanza della classe com.ibm.acgv4.base.ACGLogon

Elemento parameter ( <parameter name="parameter" ...)

Cardinalità dell’elemento = 1

name = nome della variabile usate per impostare la variabile KPJBU nella KPJBA (non modificare)

type = nome del bean rappresentativo della DS da usare per impostare la KPJBU

Elemento input ( <input type=" ...)

Cardinalità dell’elemento = 0, n (vale a dire, specificare sole se il programma prevede

l’acquisizione di dati dal file INPUT00F)

type = nome del bean rappresentativo della DS da usare per scrivere nel campo DATA del file di

database INPUT00F; il nome della DS viene riportato nel campo TPREC del file INPUT00F

Elemento output ( <output type=" ...)

Cardinalità dell’elemento = 0, n (vale a dire, specificare sole se il programma prevede la scrittura di

dati nel file OUTPT00F)

type = nome del bean rappresentativo della DS da usare per scrivere nel campo DATA del file di

database OUTPT00F; il nome della DS viene riportato nel campo TPREC del file OUTPT00F

I file .properties e .xml devono essere collocati nella medesima cartella


Lancio del code generator

Aprire la vista (view) Navigator nella prospettiva Java e posizionarsi su progetto

LegacyGenerator.

Selezionare il file acg_legacy.jar, quindi le voci di menu Run – Run As – Java Application

(vedi fig.1) e successivamente selezionare la classe CodeGenerator dalla finestra RunType (vedi

fig. 2).

La classe richiederà l’indicazione, nella finestra “Console”, del percorso del file di

properties da utilizzare per la generazione (ad. esempio, si può digitare gen\AC43 per eseguire la

generazione a partire da AC43.properties presente nella cartella source\gen visibile nella view

“Package Explorer” della prospettiva Java.

Al termine dell’elaborazione verranno generati una classe Action nel package relativo alle

action e una serie di bean (bean di input e di output, bean rappresentativi di DS e table)

Fig. 1


Fig. 2

Al lancio della classe di generazione verrà richiesta l’indicazione del percorso nel quale è

presente il file di property (vedi fig. 3). Al termine dell’elaborazione effettuare il refresh del

progetto per visualizzare i file generati.


Fig. 3

La classe che rappresenta la Legacy Program Interface dovrà includere il metodo

runService() che si preoccuperà di leggere i dati in input, formattarli e di passarli al Legacy

Connector, insieme ad informazioni quali il nome dell’operazione di Service Bus V4 ed il tipo di

operazione ed alle credenziali di accesso.

In ricezione dovrà recuperare la risposta dal Legacy Connector e caricarla nella collection

dei dati di output da passare all’applicazione client.

Le classi da utilizzare in fase di generazione possono essere impacchettate all’interno di una libreria

di classi java, che può essere rilasciata con un progetto WAR da importare in RAD insieme ai

package di base che realizzano le funzionalità di logon e controllo delle autorizzazioni, da cui

dipendono.

legacy generator marzo 2011 - teamsystem gen… · coordinamento di teamsystem s.p.a., sede legale...

Documents