Skip to content Skip to footer

Ridimensionamento di campo

Hai bisogno di aumentare le dimensioni di un campo? Il codice prodotto o il numero fattura? Questa è una richiesta comune che può verificarsi per qualsiasi applicazione, inclusa applicazioni IBM i.

Identificazione di tutti i file e tabelle

Filtro potente e flessibile
Trovare esattamente tutti i file che contengono il campo che vuoi ridimensionare è fondamentale.
Nel sistema IBMi i nomi del campo che si vuole identificare possono essere criptici, la tipologia e la dimensione di tutte le sue declinazioni non sono sempre costanti. Anche il testo del campo e le intestazioni delle colonne o le descrizioni degli alias sono di grande aiuto per includere o escludere i candidati dall'elenco.Il nostro strumento integra un filtro nativo e flessibile per manipolare qualsiasi ricerca al fine di ottenere l'elenco esatto di file che contiene qualsiasi iterazione del campo che devi ridimensionare.

Identificazione di tutte le propagazioni

Programmi & Stored Procedures
Programmi e Stored Procedures (SP) possono utilizzare un file con diversi metodi:
- Accesso I/O ai file nativi (accesso ai record RLA) - per i programmi- Accesso SQL statico- Accesso SQL dinamicoTutti questi metodi sono identificati dallo strumento parte del nostro servizio.All'interno di un programma la propagazione di un campo di database può essere molto estesa; può andare a una variabile che poi va a un'altra var, a un DS o parm o display o print-field e continuare con qualsiasi combinazione di quegli elementi e così via.Il nostro strumento può tracciare tutte quelle estensioni e identificare ciascuna riga interessata nel codice.

Analisi d'impatto

Analisi d'impattoComprendere l'impatto del cambiamento è necessario per impostare l'attività di sforzo, in particolare per la preparazione del test.

Ridimensionamento automatizzato

Setting di regole globalli o a livelo granulare. Cambiamento del codice automatizzato con ridimensionamento del campo interessato e tutte le sue propagazioni ed eventuale spostamento di campi adiacenti (RPG, DS, DSPF, PRTF)

Validazione di tutte le ricompilazioni

Riconoscere tutti i pgm che devono essere ricompilati e verificare la validità di ogni compilazione è un esercizio obbligatorio in un progetto di ridimensionamento del campo dell'app, prima e soprattutto dopo la modifica del ridimensionamento del campo dell'app. Questa funzionalità è integrata nel nostro pacchetto.

Integrazione di tutti gli scenari di test

Test end-to-end con copertura del codice (code coverage) potenziata
Integrazione di tutti gli scenari di test
Test end-to-end con copertura del codice potenziataPer un progetto di ridimensionamento del campo, il test rappresenta dal 40 al 50% dell'intero budget. Disporre di una solida struttura di test in grado di consentire test end-to-end e in particolare di identificare che il codice modificato è stato sottoposto alla copertura del codice durante i test è una risorsa importante per ridurre il rischio di fallimento del progetto. Il nostro strumento ReplicTest accompagna il progetto di ridimensionamento dei campi dell'app a questo scopo.

CONTACT US

Get in Touch!

    Your request

    FAQ

    Il ridimensionamento dei campi in un’applicazione legacy IBM i può variare in difficoltà a seconda di diversi fattori, come il linguaggio di programmazione utilizzato, l’architettura dell’applicazione e la complessità dell’applicazione stessa. Ecco alcuni fattori da considerare riguardo al ridimensionamento del campo:

    1. Linguaggio e tecnologia: Se l’applicazione è scritta esclusivamente con accesso al database o in maggioranza con accessi SQL, il compito di ridimensionare i campi può essere relativamente vantaggioso. L’impatto inizierà dalla propagazione delle colonne SQL interessate a variabili RPG (o Cobol ecc.) e così via. Ogni volta che una variabile o una struttura dati definita in modo indipendente con una dimensione rigorosa è un contenitore del campo da ridimensionare, dovrà essere ridefinita. Anche quelle variabili o DS dovranno essere tracciate per la propria propagazione per ottenere ulteriori variabili che potrebbero dover essere ridefinite e così via.
    2. Dipendenze dai dati: il ridimensionamento del campo diventa più complicato se il campo viene fatto ampiamente riferimento in tutta l’applicazione o se fa parte di strutture dati complesse. In questi casi, il ridimensionamento del campo potrebbe richiedere aggiornamenti a più programmi, file e strutture dati, il che aumenta la complessità e lo sforzo richiesto.
    3. Analisi d’impatto: prima di ridimensionare un campo, è essenziale condurre un’analisi d’impatto approfondita per identificare eventuali conseguenze. Ciò comporta l’identificazione di tutte le aree dell’applicazione che utilizzano o sono interessate dal campo e la determinazione dell’entità delle modifiche richieste. Questa analisi aiuta a stimare lo sforzo richiesto e i potenziali rischi associati al processo di ridimensionamento.
    4. Test di regressione: il ridimensionamento di un campo in un’applicazione legacy può richiedere test di regressione approfonditi per garantire che le modifiche non introducano problemi imprevisti o incoerenze dei dati. Questo test dovrebbe coprire tutte le aree interessate dell’applicazione per convalidare il corretto funzionamento del campo ridimensionato.
    5. Considerazioni sul database: il ridimensionamento di un campo nei file di database associati all’applicazione può richiedere considerazioni aggiuntive, come la migrazione dei dati, la riorganizzazione dei file o i blocchi a livello di file durante il processo di ridimensionamento. Questi fattori possono influire sulla difficoltà complessiva e sulla durata dell’operazione di ridimensionamento.

    Nel complesso, la difficoltà di ridimensionare i campi in un’applicazione legacy IBM i può variare da relativamente semplice a complessa, a seconda dei fattori sopra menzionati. Si consiglia di affrontare il ridimensionamento sul campo con un’attenta pianificazione, analisi dell’impatto e test approfonditi per ridurre al minimo i rischi potenziali e garantire un’implementazione di successo.

    Quando si analizza l’impatto del ridimensionamento di un campo in un’applicazione legacy IBM i, è fondamentale considerare i seguenti elementi:

    1. Codice dell’applicazione: valutare quanto ampiamente viene utilizzato il campo all’interno del codice dell’applicazione. Determinare se si fa riferimento direttamente al campo o se viene utilizzato indirettamente tramite altre variabili o strutture dati. Identificare tutti i programmi, i moduli e le procedure che richiederanno modifiche a causa del ridimensionamento del campo.
    2. Strutture dati: esamina le strutture dati che contengono il campo da ridimensionare. Determinare se sono presenti dipendenze o effetti a catena su altri campi o strutture dati all’interno dell’applicazione. L’aggiornamento della dimensione del campo potrebbe richiedere modifiche alla definizione dei dati e all’utilizzo in tutta l’applicazione.
    3. Interfacce utente: valuta eventuali interfacce utente (schermate, moduli, report) che visualizzano il campo ridimensionato. Considera l’impatto sull’esperienza utente, sul layout, sull’allineamento e su eventuali regole aziendali o calcoli associati che si basano sul campo. Assicurati che l’interfaccia possa adattarsi alla nuova dimensione del campo senza problemi visivi o funzionali.
    4. Archiviazione dati: valutare l’impatto sui file di database che contengono il campo da ridimensionare. Determina se la modifica della dimensione del campo influirà sui requisiti di archiviazione, sull’indicizzazione o sull’integrità dei dati. Determina se è necessaria una conversione o migrazione dei dati per gestire la nuova dimensione del campo.
    5. Sistemi di interfaccia: identificare eventuali sistemi o applicazioni che si interfacciano con l’applicazione legacy IBM i. Analizza in che modo il ridimensionamento del campo influirà sullo scambio di dati, sulle chiamate API o sulle integrazioni dei dati. Assicurarsi che questi sistemi siano compatibili con le modifiche e apportare le modifiche necessarie.
    6. Reporting e analisi: considera l’impatto su eventuali report, query o analisi esistenti che utilizzano il campo da ridimensionare. Analizzare l’impatto sull’estrazione, manipolazione, calcoli e presentazione dei dati in questi meccanismi di reporting.
    7. Test e garanzia di qualità: pianificare test completi per garantire che il campo ridimensionato funzioni correttamente e non introduca effetti collaterali indesiderati. Includere test di regressione per verificare che la funzionalità esistente rimanga intatta dopo il ridimensionamento del campo.
    8. Documentazione e comunicazione: aggiorna la documentazione pertinente, inclusi dizionari di dati, specifiche di sistema, guide per l’utente e documentazione per gli sviluppatori, per riflettere il ridimensionamento dei campi. Comunicare le modifiche a tutte le parti interessate, inclusi utenti, amministratori e team di supporto.

    Considerando questi punti, è possibile eseguire un’analisi approfondita dell’impatto e ridurre al minimo i rischi ridimensionando un campo in un’applicazione legacy IBM i.

    Polverini&Partners © 2024. P.IVA: IT02675510982 – All Rights Reserved