In un sistema informativo sono fondamentali tutti quei programmi che operano degli aggiornamenti immediati di uno o più records facenti parte degli archivi del sistema. Questi tipi di programmi utilizzano delle videate che permettono all’utente di gestire in tempo reale le informazioni presenti nel sistema; tutti i dati devono essere controllati dal programma al fine di garantirne una corretta memorizzazione. Le caratteristiche fondamentali di questi tipi di programmi in ambiente SAP sono le seguenti:
- L’esecuzione del programma è attivata digitando il relativo codice transazione e non premendo il pulsante dell’esecuzione presente nella videata della transazione SE38.
- Il programma tratta pochi records, ha tempi di risposta immediati ed essere di tipo conversazionale.
- Il programma ha una interfaccia con l’utente costituita da una o più videate che prendono il nome di Dynpro.
Gran parte dei programmi forniti da SAP per la gestione degli archivi del sistema appartengono a questa categoria e sono spesso sufficienti alle esigenze del cliente. Tuttavia non sono rari i casi in cui sono chiesti nuovi programmi di gestione archivi o modifiche a quelli già presenti in SAP. Un esempio potrebbe essere costituito da un nuovo programma di creazione materiale ottenuto riunendo in una sola dynpro tutte le più comuni informazioni relative al materiale, che SAP invece distribuisce su più videate utilizzate come “viste” (vedi transazione MM01). Se un programmatore ha il compito di sviluppare un programma di inserimento dati alternativo a quello standard di SAP, deve verificare che il proprio programma garantisca un aggiornamento corretto e completo del data base, mantenendo l’allineamento e la congruenza delle operazioni di aggiornamento così come lo opera il corrispondente programma SAP.
Si comprende quindi come SAP stessa scosigli lo sviluppo eccessivo di programmi di questo tipo, ma spinga l’utente ad utilizzare le transazioni standard.
Programmi appartenenti a questa tipologia sono chiamati indifferentemente SCREEN PAINTER o MODULE POOL. Il nome SCREEN PAINTER deriva dal fatto che per la realizzazione delle videate utilizzate dal programma è costituito da un insieme di moduli creati tramite la transazione SE38 e accumulati uno dopo l’altro secondo la logica seguente.
Poiché un programma di tipo screen painter è attivato tramite il richiamo di una transazione, il primo passo è proprio quello di definire un nuovo codice transazione rendendolo così noto al sistema SAP. In fase di definizione della transazione, sarà necessario indicare anche quale programma e quale dynpro devono essere attivati richiamando quella transazione (cioè digitandone il codice nel campo dell’OK_CODE).
Tutti i codici transazione noti a SAP si trovano in una apposita tabella di sistema chiamata TSTC, interrogabile come tutte le altre tramite il codice transazione SE16. Per inserire un nuovo codice occorre richiamare la transazione adibita alla gestione della tabella TSTC il cui codice è SM31. In sede di definizione il sistema sistema richiede le seguenti informazioni:
- Una breve descrizione della nuova transazione;
- Il nome del programma (Screen Painter) che deve essere richiamato quando l’utente digita il codice della transazione;
- La dynpro che deve essere emessa per prima (ad uno stesso programma possono essere associate più dynpro).
Occorre definire il nome del programma e inserirlo nel catalogo dei programmi tramite la transazione SE38. Ovviamente il nome deve essere quello indicato in sede di definizione della transazione (v. precedente punto 2). Inizialmente conviene solo definire gli attributi del programma, temendo presente che il campo tipo deve assumere il valore “M”, che sta ad indicare che non si tratta di un report, ma di un Module-pool. Si noti che la prima istruzione del sorgente è PROGRAM e inizialmente è l’unica istruzione presente nel programma.
Quando si sviluppa un REPORT tutte le informazioni ad esso relative (attributi, sorgente, varianti, testi fissi,…) sono creati e gestiti tramite la transazione SE38, in fase di sviluppo di uno screen painter invece si utilizzano le seguenti transazioni con le relative funzionalità:
SE51 (Screen Painter)
|
SE38 (Module Pool) |
Disegno delle videate (Dynpro) gestite dal programma e definizione dei campi che compaiono nelle videate con le relative caratteristiche.
Definizione della logica di controllo, cioè della sequenza con cui sono richiamati i moduli (MODULE) che compongono il sorgente del Module Pool creato tramite il codice transazione SE38. Nel processo logico sono identificati 2 fasi tipiche durante l’esecuzione di un programma conversazionale:
- PROCESS BEFORE OUTPUT (PBO)
Che deve contenere tutti i richiami ai moduli che devono essere eseguiti prima dell’emissione della dynpro.
- PROCESS AFTER INPUT (PAI)
Che deve contenere tutti i richiami ai moduli che devono essere eseguiti appena il programma acquisisce la mappa.
|
Definizione di tutte le tabelle utilizzate dal programma, delle strutture corrispondenti alle dynpro definite nello screen painter (tramite la transazione SE51) e dei campi propri del programma.
Scrittura dei moduli previsti nello screen painter tramite le consuete istruzioni ABAP/4. I moduli possono essere inseriti uno dopo l’altro senza un particolare ordine, perché la sequenza di esecuzione è definita dalla logica di controllo definita nello screen painter. Oltre ai moduli, in questa sede occorre inserire tutte le eventuali routines (FORM) che i vari moduli possono chiamare. |
Durante la fase di sviluppo di un programma di tipo conversazionale è opportuno abituarsi ad utilizzare contemporaneamente due sessioni di lavoro operando con le transazioni SE38 e SE51.
Ad esempio: si ipotizza la creazione di un programma di visualizzazione dei dati del fornitore, in cui inserito il codice del fornitore, sono visualizzati la ragione sociale e l’indirizzo. La fase iniziale consiste nel definire la transazione e creato gli attributi al nuovo programma module pool (SE38), occorre iniziare il disegno della dynpro tramite la transazione SE51 e la scelta di Fullscreen editor. Comparirà una videata vuota di 80 caratteri per 24 righe dove il programmatore potrà inserire tutte le informazioni che intende visualizzare nella dynpro. In particolare si possono identificare i seguenti elementi fondamentali:
- Campi fissi, contenenti intestazioni, titoli, descrizioni di campi e varie altre informazioni che non subiranno mai modifiche durante l’esecuzione del programma e che l’utente non deve poter modificare (il cursore non deve poter posizionarsi in questi campi);
- Campi variabili in solo output, cioè campi il cui valore può variare durante l’esecuzione del programma, ma che devono comunque restare inibiti all’utente e in sola visualizzazione;
- Campi variabili in input/output, cioè campi per i quali è permessa una digitazione da parte dell’utente e che quindi devono permettere il relativo posizionamento del cursore;
- Elementi grafici come pulsanti, bottoni,…
Un possibile disegno della dynpro relativa all’esempio precedente potrebbe essere il seguente:
I campi (VISUALIZZAIONE FORNITORI, CODICE FORNITORE, RAGIONE SOCIALE, INDIRIZZO, LOCALITA’, NAZIONE) appartengono alla categoria dei campi fissi, quelli indicati dalla sola sottolineatura rappresentano i campi variabili di solo output, mentre quelli nel riquadro ombreggiato (riservato alla digitazione del codice fornitore) sono di tipo variabile in input/output; è, infine, un elemento grafico il pulsante FINE che compare alla base della videata inserito in un riquadro.
A tutti i campi variabili occorre attribuire un nome e delle caratteristiche così come è indicato dal sistema. Nel nostro caso possiamo attribuire i seguenti nomi:
- D-LIFNR al codice del fornitore;
- D-NAME1 alla ragione sociale del fornitore;
- D-STRAS all’indirizzo (inteso come via e numero);
- D-ORT01 alla località;
- D-LAND1 alla nazione.
seguendo il consueto data dictionary di SAP.
La sequenza operativa del programma potrebbe essere la seguente:
- L’utente digita il codice transazione, il programma è attivato;
- il programma pulisce i campi della dynpro variabili;
- è emessa la dynpro;
- l’utente digita il codice del fornitore e preme l’invio, oppure preme il pulsante FINE;
- il programma riceve la dynpro;
- il programma verifica se è stato premuto il pulsante FINE; in caso affermativo termina e ritorna il controllo a SAP, altrimenti deve leggere la tabella dei fornitori (LFA1);
- il programma riempie i campi variabili di solo output con i relativi valori trovati in LFA1 e torna al punto 3 per l’emissione della dynpro.
I punti 3 (emissione dynpro) e 5 (acquisizione dynpro) sono automatici in SAP e il programmatore non deve preoccuparsi di introdurre nel suo sorgene alcuna istruzione a tale scopo. Il punto 6 deve essere eseguito non appena il programma acquisisce la dynpro, rifacendosi a quanto indicato precedentemente si deduce che il richiamo al modulo che realizza tali attività deve essere inserito nel PROCESS AFTER INPUT (PAI). Analogamente il punto 2 ( in sede di prima emissione della dynpro) e il punto 7 (a regime) devono essere eseguiti prima dell’emissione della dynpro, cioè nel PROCESS BEFORE OUTPUT (PBO).
Risulta, quindi, fondamentale inserire in maniera opportuna il richiamo dei moduli nella logica di controllo presente nella definizione della dynpro (SE51). Andando in variazione nella schermata della logica di controllo ci comparirà una videata simile a quella utilizzata per inserire un sorgente di un programma e gestibile tramite i consueti comandi previsti per l’editor di un sorgente ABAP/4.
In essa troviamo già inserite due sole istruzioni come indicato in figura:
Tra le due istruzioni occorre inserire i richiami ai moduli che si andrà a sviluppare, utilizzando la transazione SE38. Si suppone di creare un modulo per effettuare le operazioni di cui al precedente punto 6 che si chiamerà VERIFICA e un modulo adibito ad eseguire le operazioni di cui al punto 2 (in sede di prima emissione della dynpro) o al punto 7 (a regime), che si chiamerà EMETTI. In queste condizioni la logica di controllo dovrà essere modificata nel modo indicato nella figura seguente:
Nella logica di controllo sono ammesse solo due tipi di istruzioni: MODULE e LOOP (con la relativa ENDLOOP), pertanto non è possibile introdurre le normali istruzioni ABAP/4 (IF, MOVE,…).
In dipendenza di questa logica di controllo, nel sorgente della transazione SE38 si dovrà creare ed inserire i due moduli EMETTI e VERIFICA, indicando per ciascuno la relativa caratteristica (OUTPUT) per i moduli appartenenti PBO e INPUT per quelli PAI). Pertanto il sorgente ABAP/4 assumerà una forma di massima molto simile allo schema indicato nella figura seguente:
Il sistema non effettua alcun controllo tra il nome del MODULE indicato nella logica di controllo e quello riportato nel sorgente, inoltre non è verificata la coerenza tra il tipo di MODULE indicato nel sorgente (INPUT, OUTPUT) e la posizione in cui è definito nella logica di controllo. Se esistono dei disallineamenti tra questi elementi non sono segnalati errori, ma semplicemente il modulo non è eseguito. Anche tra i nomi e le caratteristiche dei campi della mappa inseriti nello screen painter (SE51) e quelli indicati nelle istruzioni dichiarative del sorgente (SE38) deve esserci una perfetta corrispondenza. In caso contrario il sistema non rileva errori formali, ma non riesce a trasferire i valori dalla dynpro ai campi del sorgente (e viceversa), che restano non valorizzati, con conseguente malfunzionamento del programma.
È possibile definire più dynpro per uno stesso programma, in tale caso si avrà sempre un solo module pool (SE38) contenente i moduli di tipo INPUT e OUTPUT di tutte le dynpro utilizzate dal programma senza alcuna particolare sequenza, mentre nello screen painter (SE51) si inseriranno le varie dynpro corredandole ciascuna della relativa logica di controllo. Il passaggio da una dynpro all’altra in sede di esecuzione è gestita dall’istruzione SET SCREEN.
Per ulteriori approfondimenti si rimanda all’uso dell’help in linea fornito da SAP. |
