Loading…

BAdI Implementation – Moduli

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

Metodo Map_Actions

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

Metodo Do_Action_Search

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.