Il modulo come definito in “elementi di EasyBP” è appunto l’oggetto base dell’applicazione di ABAP4Web tramite questo si possono costruire una o più applicazioni in quanto è un elemento indipendente dall’applicazione. Graficamente rappresenta appunto una schermata dell’applicazione e nel post “Modules Configuration” si può configurare, quindi definire un id ed associare dei model, delle azioni e dei widget.

Per ogni Modulo definito nell’applicazione sarà creata una BAdI con:

• definizione base ZSTC_WEBUI_BADI_MODULE,
• classe di implementazione avente come super classe la ZSTC_WEBUI_BADI_ROOT_MODULE e come interfaccia oltre alla IF_BADI_INDERFACE la ZSTC_WEBUI_IF_BADI_MODUL
• Una combinazione di filtri ovvero la coppia id applicazione id modulo definita nella tabella APMOD “Application & Navigation->Moduli” o “Modules Configuration->Applicazioni”.

La classe di implementazione dopo aver specificato la super classe, conterrà i metodi che verranno chiamati dall’esecuzione dell’applicazione.

Se la badi che si sta creando si riferisce ad un modulo preesistente la super classe da specificare non è la “ZSTC_WEBUI_BADI_ROOT_MODULE” ma la classe di implementazione del modulo preesistente, in modo da mantenere inalterata la precedente implementazione ed eventualmente arricchirla ridefinendo i moduli.

Metodo MAP_ACTIONS

La ridefinizione del metodo MAP_ACTIONS è praticamente obbligatoria perché in questo metodo vanno inserite le azioni mappate nel ramo Modules Configuration->Azioni (MOACT)

Nella figura sottostante è possibile vedere un esempio per la BAdI del modulo MOD_KUST_SEARCH dell’applicazione KUST

In questo esempio le azioni associate sono tre, le azioni vengono inserite nell’attributo T_ACTIONS, attributo d’istanza ereditato dalla super-classe (se si sta estendendo un modulo preesistente richiamare prima il metodo della super classe). Ad ogni azione deve essere associato un ‘token’ che, concatenato alla stringa ‘DO_ACTION_’ servirà a richiamare il metodo corrispondente all’azione. L’interfaccia *MODUL porta in dote dei metodi base (DO_ACTION_SEARCH, DO_ACTION_GET_DETAIL, DO_ACTION_CREATE …) ma naturalmente è possibile implementare altri metodi che abbiano la stessa interfaccia e proprietà pubblica.

Metodi DO_ACTION*

L’interfaccia dei metodi DO_ACTION* ha come input l’azione (classe ZSTC_WEBUI_FWK_ACTION) ed esportano una tabella per la gestione dei messaggi (ZSTC_WEBUI_T_WEB_MESSAGE).

In figura si può vedere un esempio riferito all’azione ricerca clienti dell’applicazione KUST

Come si può notare dall’azione viene letto il modulo di ricerca tramite il suo identificativo (il model contenuto nell’azione è definito nel ramo Server Action Configuration->Involved Models, tabella ACTMD).

Sfruttando il model di ricerca si invocherà la ricerca direttamente dall’oggetto model principale che nel caso della figura è il MODEL_KUST.

SI consiglia di eseguire le operazioni sui dati lettura, scrittura DB ai Model associati in quanto ad essi è possibile associare relazioni e quindi andare a leggere in cascata le sotto entità

Il metodo invocato ritornerà un model che verrà settato all’azione in modo tale che il Front-End mostri il risultato ottenuto, anche qui il model è sempre associato nella tabella ACTMD. È possibile anche settare un nuovo stato di visualizzazione o un modulo di destinazione diverso da quelli definiti nel customizing dell’azione

Seguendo l’esempio in figura e i vari esempi descritti nella categoria Step By Step è possibile specificare qualsiasi comportamento per le azioni definite.