Per facilitare la creazione di applicazioni è stato implementato il report Zstc_Webui_Basic_App_Creator. Il report seguendo le fasi descritte realizza la configurazione del front-end dell’applicazione in pochi secondi fornendo un report dettagliato degli inserimenti per realizzare l’applicazione.

Ecco la screen iniziale del report

Per lanciarlo abbiamo bisogno di alcune operazioni preliminari ovvero creare le strutture nel dictionary per identificare i campi tramite i quali ricercare l’entità, i campi da visualizzare come risultato della ricerca e la sua struttura di dettaglio ovvero cosa mostrare dell’oggetto in dettaglio.

A seguire i passi per realizzare la configurazione front-end

Strutturazione del dato

Il primo passo da eseguire per realizzare una applicazione è appunto realizzare un disegno di un qualcosa che si voglia rappresentare. Nel nostro esempio consideriamo la ricerca e la visualizzazione di un cliente, per far ciò creiamo tre strutture.

Struttura ricerca:	ZSTC_CUSTOMER_SEARCH_S
Struttura risultato:	ZSTC_CUSTOMER_S
Tipo Tabella risultato:	ZSTC_CUSTOMER_T
Struttura Dettaglio:	ZSTC_CUSTOMER_DETAIL_S

Tali strutture conterranno le informazioni per ricercare e rappresentare l’entità cliente, una volta creata l’applicazione comunque si possono sempre aggiungere/togliere campi alle strutture verranno automaticamente letti dall’applicazione

Compiliamo i campi del report citato in precedenza come in figura e lanciamo il report (per scrivere i dati in tabella spuntare la casella modalità di test)

Il log seguente ci mostra che il report è andato a buon fine

Il primo log contiene il link al quale collegarsi per visualizzare il frontend e tutti gli inserimenti effettuati in tabella. Lanciando il link visualizzeremo appunto l’intera applicazione CLIENTI.

Fino ad ora si è parlato di cosa visualizzare e della sua configurazione, adesso ci occupiamo di come visualizzare il contenuto, naturalmente bisognerà scrivere del codice per recuperare le informazioni desiderate, ma non sono richieste particolari skill di programmazioni ABAP. Si dovrà conoscere principalmente gli enhancement implementatio di SAP, quindi le BAdI e le classi abap.

Workbench

Prima di tutto recuperiamo il nome degli elementi inseriti in tabella dei quali dobbiamo definirne un comportamento, in particolare i moduli e i model, possiamo recuperarli dal log o andando nelle tabelle elencate sempre nel log. In particolare per il nostro esempio abbiamo creato i seguenti componenti:

• Applicazione – Tabella ZSTC_WEBUI_APPS
  • CLIENTI                Applicazione Clienti
• Moduli – Tabella ZSTC_WEBUI_MODUL
  • MOD_CLIENTI_ SEARCH    Modulo Ricerca
  • MOD_CLIENTI_ DETAIL        Modulo Dettaglio
• Model – Tabella ZSTC_WEBUI_MODEL
  • MODEL_CLIENTI_SEARCH    Tipo Struttura    ZSTC_CUSTOMER_SEARCH_S
  • MODEL_CLIENTI_SEARCH_RES    Tipo Tabella        ZSTC_CUSTOMER_T
  • MODEL_CLIENTI_DETAIL    Tipo Root (Struttura)    ZSTC_CUSTOMER_S
• Azioni – Tabella ZSTC_WEBUI_ACTN
  • ACT_CLIENTI_SEARCH    esegue la ricerca e rimane sul modulo ricerca
  • ACT_CLIENTI_DETAIL    legge il dato selezionato e visualizza il dettaglio si sposta sul modulo dettaglio

Dopo aver recuperato i nomi degli elementi di interesse, creiamo un enhancement implementation da se19 utilizzando lo spot ZSTC_WEBUI, per convenzione il nome dovrebbe contenere il nome dell’Applicazione.

N.B Sarebbe conveniente creare un package dedicato per ogni applicazione, dove inserire tutti gli oggetti creati per l’applicazione.

Creato l’enhancement implementation si passa a creare le BadI una per ogni Modulo/ Model del quale si voglia specificarne il comportamento nel nostro caso i due moduli e il model del dettaglio.

Modulo
Nell’esempio in figura si mostra il Modulo di ricerca, si parte dalla Definizione della BaDI ZSTC_WEBUI_BADI_MODULE per i moduli si indica quindi un’implementazione per la badi e il nome della classe di implementazione.

Dopo aver creato l’implementazione per la BAdI ci spostiamo sulla classe dove andremo a modificare la super classe.

inserendo la ZSTC_WEBUI_BADI_ROOT_MODULE, nel caso si tratti di un modulo ex novo, se si tratta di un modulo copiato da un’altra app allora inserire la rispettiva classe di implementazione, in modo da lasciare inalterato il suo comportamento di base. In questo modo il nuovo modulo erediterà i metodi e le interfacce e gli attributi della super classe, eventualmente eliminare interfacce duplicate dal tab interfaces.

Sarebbe meglio prevedere una classe messaggi per applicazione per centralizzare i messaggi.

Sempre nella classe ridefiniamo il metodo “MAP_ACTIONS” in modo da aggiungere le due azioni che abbiamo creato in quanto appartengono entrambe al modulo di ricerca.

Nel nostro esempio abbiamo creato una macro per aggiungere le due azioni, associate ad un token. La concatenazione del token inserito con il prefisso “DO_ACTION_” definiscono il nome del metodo che sarà invocato allo scattare dell’azione corrispondente, da notare che alcuni metodi sono ereditati dalla superclasse quindi basterà ridefinirli per aggiungere del codice, in caso i metodi non esistano si possono creare rispettando sia nomenclatura (DO_ACTION_XXX) che la signature e dichiarandoli pubblici.

Nel nostro caso andremo a ridefinire due metodi:

1. Il metodo “DO_ACTION_SEARCH” per aggiungere il codice per ricavare i clienti sfruttando i campi definiti nella struttura di ricerca
2. Il metodo “DO_ACTION_GET_DETAIL” per aggiungere il codice che partendo dal record selezionato del model “MODEL_CLIENTI_SEARCH_RES” recuperi tutte le informazioni descritte nella struttura di dettaglio

Attiviamo la classe e torniamo sulla schermata dell’enhancement, per specificare il filtro della BAdI, identificato come la coppia Applicazione (APPID) Modulo (MODULEID) in questo modo ogni azione del frontend sarà gestita da questa BAdI, che si può ampliare a seconda delle azioni inserite nel Modulo

Model
Per la creazione del model si parte dall’enhancement implementation creando un’ulteriore BAdI per il model come fatto in precedenza, ma partendo dalla definizione BAdI ZSTC_WEBUI_BADI_MODEL, invece la classe avrà come super classe la ZSTC_WEBUI_BADI_ROOT_MODEL, anche qui ci saranno i delle interfacce specifiche per i model con i metodi da ridefinire, eventualmente dalla tab interfaces della classe eliminare le interfacce duplicate. Come per il modulo si deve creare un filtro che leghi la BAdI creata alla tabella MODEL come in figura

Anche per il model definiamo un filtro come per il modulo ma questa volta avremo un solo valore con il nome del Modulo ovvero MODEL_CLIENTI_DETAIL

Come fatto per il modulo di ricerca si va a definire una BAdI per il modulo dettaglio, per il nostro caso non è necessaria in quanto andiamo solo a mostrare i dati del cliente ma per un futuro ampliamento.

Definizione Metodi
Come accennato nel precedente paragrafo per creare il comportamento dell’applicazione è necessario implementare tre metodi. In particolare due per il modulo di ricerca ed uno sul model:

Modul – metodo DO_ACTION_SEARCH
Metodo del modulo caratterizza l’azione ‘ACT_CLIENTI_SEARCH’. Qui si andrà a richiamare il model del cliente passandogli le informazioni del model di ricerca di tipo ZSTC_WebUI_FWK_Model_SF.

Quindi in primis recuperiamo il model di ricerca dall’azione in ingresso riga 8 in figura. Si chiama il metodo del framework per leggere il model di uscita dell’azione riga 10. Tale metodo non fa altro che andare a richiamare l’implementazione del model indicato come id nei parametri. Si consiglia di utilizzare sempre un model radice per gestire la ricerca, in modo tale da poter gestire anche una eventuale lettura gerarchica dei model.

Per verificare i model di I/O controllare la tabella ACTMD.

Recuperato il model di output, ‘MODEL_CLIENTI_SEARCH_RES’ di tipo tabella ZSTC_WebUI_FWK_Model_T, possiamo restituirlo all’azione. Naturalmente è consigliato gestire la messaggistica per avvisare l’utente sugli esiti delle operazioni. La messaggistica va inserita sempre nell’azione come nel caso in figura riga 18.

Model– metodo SEARCH
Il metodo in questione viene invocato dal framework method alla riga 10 nella figura a seguire, in particolare va definito all’interno della BAdI del model Clienti dettaglio indicato come radice.

Qui andiamo a leggere il modulo di ricerca per estrapolare i filtri di ricerca tramite il metodo ‘get_Field_Values’ del model di ricerca passato in ingresso. In base ai range ricavati dal metodo eseguiamo una select in tabella per creare una tabella di tipo indicato in selection screen del programma ZSTC_CUSTOMER_T. A seguire si creao un’istanza del model da restituire, model di tipo TABELLA con id MODEL_CLIENT_SEARCH_RES e se il model è stato creato gli impostiamo la base dati estratta.

Modul – metodo DO_ACTION_GET_DETAIL
Altro metodo necessario alla nostra applicazione è il get_Detail, ovvero il metodo associato all’azione ‘ACT_CLIENTI_DETAIL‘, che scatta alla pressione del button sul widget dei risultati.
Avremo sempre un model di entrata che sarà il record selezionato sulla griglia e uno di output, il modulo clienti dettaglio MODEL_CLIENTI_DETAIL, a differenza dell’azione precedente causerà il cambio di modulo, perchè come definito nella tabella ACTN chiamerà il modulo di dettaglio associato ovvero il MODUL_CLIENTI_DETAIL.
In questa azione possiamo anche andare a recuperare eventuali model dipendenti per magari associare al Modulo altri widget.

Ad esempio al cliente si possono assocriare le Sales Area dove il cliente è operativo, o i materialimaggiormente richiesti, l’elenco di magazzini e cosi via, per ogni widget naturalmente va gestito un model con la sua struttura dati e una fase di recupero dati.