Approfondimento tecnico

L'SQL incorporato è una parte normale delle codebase RPG, non un caso limite. La maggior parte dei programmi RPG in produzione accede a DB2 for i usando SQL incorporato direttamente nel codice sorgente. Lo gestiamo come parte standard della migrazione.

L'SQL incorporato viene analizzato insieme al codice RPG. Nel Java tradotto, diventa chiamate JDBC. L'SQL stesso viene preservato ed eseguito contro lo stesso database DB2, a meno che lo scope del progetto non includa il passaggio a un database diverso; di questo si parla separatamente più avanti.

La gestione dei cursori, le variabili host, le variabili indicatore e la gestione di SQLSTATE/SQLCODE vengono tutti tradotti. Se la tua codebase RPG usa pattern SQL particolarmente complessi, come SQL dinamico, multi-row fetch o stored procedure, li identifichiamo durante l'analisi del Pilot e discutiamo come verranno gestiti.

Possiamo lavorare con DDL insieme alla migrazione RPG. Questo include file fisici, file logici e definizioni SQL DDL. Se le definizioni dei file fisici sono espresse come DDS piuttosto che SQL DDL, possiamo gestire anche la traduzione di quelle strutture.

Se il database target rimane DB2 for i o si sposta su un'altra piattaforma (PostgreSQL, per esempio) è una decisione di progetto. Entrambe le opzioni sono fattibili. La domanda è solitamente decisa da come appare il resto dell'infrastruttura e da quanto l'azienda vuole spingersi nella prima fase di modernizzazione.

Se il database rimane su IBM i, il Java tradotto usa JDBC per connettersi allo stesso DB2 che ha sempre usato, senza migrazione dei dati e senza modifiche allo schema. Se il database si sposta, ciò comporta la traduzione dello schema, la migrazione dei dati e modifiche al layer adattatore nel codice Java. Lo scopiamo esplicitamente e separatamente dalla migrazione del codice.

I file di display fanno parte dello scope di migrazione. Siamo chiari su cosa è traduzione e cosa è redesign, perché sono cose diverse che dovrebbero essere scopate diversamente.

Opzione 1: Riproduzione fedele. Se vuoi un'interfaccia web che riproduca fedelmente il layout e il modello di interazione delle tue schermate IBM i esistenti, possiamo generare un frontend basato su React che rispecchia l'originale. Questa è traduzione: preserva ciò che esiste già in un nuovo mezzo.

Opzione 2: Frontend web modernizzato. Se vuoi usare la migrazione come opportunità per ridisegnare l'interfaccia utente (flussi migliorati, pattern UX moderni, layout mobile-friendly), è anche possibile. Ma questo è UI design, non traduzione. Richiede più tempo, più input da persone che capiscono i flussi di business, e dovrebbe essere costato di conseguenza.

Non sfumiamo questa distinzione. Saprai esattamente quale opzione è nello scope prima che iniziamo.

La JVM gira nativamente su IBM i dalla V4R2. Ciò significa che il codice Java tradotto può essere deployato sullo stesso hardware del tuo sistema RPG esistente, senza cambiamenti immediati all'infrastruttura.

Questa è una delle ragioni pratiche per cui Java è un target di migrazione solido. Puoi eseguire Java e RPG fianco a fianco durante la migrazione. Un modulo viene migrato in Java, deployato su IBM i, validato in produzione, e solo allora la versione RPG viene dismessa. Il rischio ad ogni passo è limitato.

Passare a Linux o qualsiasi altra piattaforma è anche fattibile, e alcuni clienti lo fanno come secondo passo dopo che la migrazione del codice è completa. Se questo è il tuo obiettivo, ne discutiamo durante il Pilot in modo che il codice tradotto sia strutturato per rendere il deployment finale su Linux semplice.

La decisione tra IBM i e Linux non deve essere presa prima di iniziare. La migrazione del codice può procedere mentre la decisione sull'infrastruttura è ancora in fase di valutazione.

Il sistema Java migrato può continuare a lavorare con DB2 for i. Non è necessario migrare il database come parte della migrazione del codice. Molti clienti scelgono di mantenere i dati su IBM i per almeno la prima fase, il che riduce significativamente lo scope e il rischio del progetto iniziale.

Se in seguito vuoi passare a PostgreSQL, Oracle o un altro database esterno, questo è un progetto separato. Comporta analisi dello schema, migrazione dei dati e test contro il nuovo database. Possiamo assisterti in questo, ma non è incluso nella migrazione del codice.

Il codice Java che consegniamo è scritto con JDBC standard. Adattarlo a un database diverso è un cambiamento contenuto; non richiede di rifare la traduzione della business logic.

La maggior parte delle codebase RPG che sono state in produzione per 20 o 30 anni ha accumulato inconsistenze: programmi che usano convenzioni diverse, moduli scritti da sviluppatori diversi in momenti diversi, workaround aggiunti quando il design originale non si adattava al requisito di business, e pattern che violano ogni principio che uno sviluppatore moderno riconoscerebbe.

Questo è comune, non eccezionale. Non rende la migrazione impossibile. Significa però che i sistemi più complessi richiedono più lavoro per riga di codice: analisi più attenta, più revisione, più collaborazione con le persone dalla tua parte che capiscono perché il codice fa quello che fa.

La valutazione del Pilot è in parte una valutazione della complessità. Al termine del Pilot, ti forniamo una valutazione onesta di cosa comporterebbe la migrazione completa per la tua specifica codebase, con indicazione di dove si trovano le parti difficili e quanto costeranno in termini di tempo e impegno.

Non ti diciamo che la migrazione è semplice se non lo è. Non giova né a te né a noi.

Il tuo codice sorgente contiene la tua business logic, la logica che differenzia la tua azienda dai tuoi concorrenti. Viene trattata con la cura corrispondente.

Il tuo codice sorgente viene utilizzato solo per eseguire la migrazione. Non viene condiviso con terze parti, non viene utilizzato per nessun altro scopo e non viene conservato dopo la conclusione dell'engagement. Siamo lieti di firmare un NDA prima che tu condivida qualsiasi cosa.

Il toolchain gira su infrastruttura che controlliamo. Non viene elaborato attraverso servizi AI di terze parti né archiviato in nessun sistema fuori dal nostro controllo. Se hai requisiti specifici su dove può essere elaborato il tuo codice (per esempio per obblighi normativi o politiche di sicurezza interne), sollevali prima di condividere qualsiasi cosa e confermeremo cosa è possibile.

Per i clienti europei con requisiti di sovranità dei dati (obblighi GDPR, normative specifiche del settore o politiche interne che vietano l'elaborazione su infrastruttura non UE), possiamo eseguire l'intero toolchain di migrazione su infrastruttura ospitata in Europa senza dipendenze da servizi o cloud provider basati negli USA.

Ciò include il transpiler, il toolchain di analisi e qualsiasi archiviazione intermedia del tuo codice sorgente durante la migrazione.

Se questo è un requisito per la tua organizzazione, sollevalo prima di condividere qualsiasi codice e confermeremo i dettagli per la tua situazione.

Tutto ciò che consegniamo ti appartiene. Il codice Java tradotto, la suite di test e il runtime sono tuoi. Non ci sono licenze, abbonamenti né dipendenze continue da noi per operare quanto consegnato.

Puoi mantenerlo, modificarlo, estenderlo o consegnarlo a un altro team o fornitore interamente. Non sei bloccato con noi per il lavoro futuro. Il codice gira senza nessun componente Strumenta nel deployment.

Forniamo il runtime preparato per il codice tradotto. "Runtime" qui significa la libreria di supporto che gestisce il comportamento specifico di IBM i su cui si basava il tuo codice RPG, come la gestione degli indicatori, alcune conversioni di tipi di dati e pattern di integrazione. Lo ricevi come codice sorgente che puoi leggere, modificare e su cui puoi costruire.

Non ci sono dipendenze nascoste. Il sistema tradotto è progettato per essere manutenibile da qualsiasi team Java competente.