Loading…

Materials

Customizing


Definizione dell’applicazione e del profilo di navigazione

Dal customizing SAP ramo “Application&Navigation“.

Seguendo i rami della struttura si inseriscono i record per l’applicazione

  • “Profili di navigazione” si aggiunge il nome del profilo di navigazione nel nostro caso ZSTC_NAVPROF_MATERIALS
  • “Applicazioni” inserire il nome dell’app (MATERIALS), il profilo di Navigazione e el principali configurazioni dell’app, quindi le immagini di header e main, e se visualizzare il testo e/o il tooltip per i bottoni dei vari widget.

Gli altri rami verranno popolati in seguito


Definizione Models

Dal Customizing ramo “Models Configuration

Sul Ramo model si creano i vari models che ci interessano, per la definizione dei models servirà strutturare il dato, quindi si andrà sul dictionary per creare delle strutture apposite contenente i campi dell’oggetto che si vuole rappresentare. Nel nostro caso si creeranno due model per la ricerca:

  • MODEL_MATERIAL_SEARCH   Ricerca        ZSTC_MATERIAL_SEARCH_S
  • MODEL_MATERIAL_SEARCH_RES Tabella        ZSTC_MATERIAL_RESULT_T

Il primo per effettuare la ricerca il secondo per la visualizzazione del risultato.

Per il dettaglio invece si creeranno 4 model, il primo di tipo root rappresenterà le informazioni della singola entità, il secondo di tipo Attachment gli allegati, il terzo le sales area dove è coinvolto il materiale, l’ultimo il dettaglio di queste, A seguire l’elenco con i nomi dei model e le rispettive rappresentazioni nel dictionary.

  • MODEL_MATERIAL            Root    ZSTC_MATERIAL_DETAIL_S
  • MODEL_MATERIAL_ATTACH        Att    ZSTC_MATERIAL_ATTACH_T
  • MODEL_MATERIAL_SALES_AREA    Table    ZSTC_MATERIAL_SA_T
  • MODEL_MATERIAL_SALES_AREA_DET    Root    ZSTC_MATERIAL_SA_DETAIL

Definiti i model seguendo i rami della transazione si definiscono le loro relazioni, nel nostro caso si metteranno in relazione il MODEL_MATERIAL con gli altri model non root.

Il codice id identificativo del model sarà necessario nella fase di Workbench per associare le BAdI che definiranno il comportamento dello specifico model.


Definizione delle Azioni

Le azioni sono degli eventi che provocano la navigazione tra i moduli e/ o il cambio stato e vengono definite nel ramo “Server Action Configurations” del customizing SAP

Per il nostro caso definiamo 4 azioni, per ognuna di esse sarà specificato il modulo di destinazione con il task, ovvero lo stato di destinazione. Si potrà inoltre specificare se l’azione ha un comportamento particolare, ovvero di tipo layout o deve essere schedulata o se associare un ulteriore azione da eseguire al verificarsi di essa.

Definiamo quindi le seguenti Azioni

  • ACTN_MAT_SEARCH    ricerca sul MODUL SEARCH applicando i criteri di ricerca specificati nella struttura associata
  • ACTN_MAT_DETAIL        passaggio Dal modul Search al detail trasportando la singola informazione    del materiale
  • ACTN_MAT_DETAIL_EDIT    passaggio di stato sul MODUL_DETAIL da SHOW a EDIT
  • ACTN_MAT_DETAIL_SAVE    passaggio di stato sul MODUL_DETAIL da EDIT a SHOW.

Come per le altre transazioni scendendo nell’albero è possibile specificare i testi in base alla chiave, la direzione delle azioni ed i moduli che le azioni trasportano.

Il codice id identificativo della action sarà necessario nella fase di Workbench per associare l’azione ad un metodo della BAdI associata al modulo.


Definizione Moduli

Dal Customizing ramo “Modules Configuration“, si apre la struttura di configurazione dei moduli, qui seguendo l’albero si può definire uno o più moduli e associare ad essi sia le applicazioni che i model rappresentativi dell’informazione da rappresentare nel nostro caso i materiali che le azioni che i componenti che andranno a visualizzare il dato a schermo.

Nella fase di definizione ci limitiamo a creare il module id associarlo all’applicazione, quindi:

  1. Ramo “Anagrafica Moduli” si inseriscono i nomi dei moduli, nel nostro caso creiamo due moduli, uno per la ricerca ed uno per il dettaglio, MOD_MATERIAL_SEARCH e MOD_MATERIAL_DETAIL come in figura, con invio i dati vengono messi in memoria
  2. Ramo “Applicazioni Associate”, selezionando i moduli uno per volta, si associa l’app Materials
  3. Ramo Dettaglio Modulo Componente, selezionando l’applicazione inserita si inserisce un solo record contenente un Titolo e il tipo Modulo al componente. Attenzione i titoli verranno inseriti in lingua di logon per inserire altre lingue in seguito al salvataggio si possono inserire altre traduzioni.
  4. Ramo “Stati per modulo si definiscono gli stati possibili per il modulo”
  5. Ramo “Actions” si inseriscono le azioni inerenti al modulo
  6. Ramo “Models” si inseriscono i models che vengono gestiti nel modulo
     

Con questi tre passi abbiamo definito i due moduli di interesse, prima di associare gli elementi si andranno a creare i Models, le action e i components

Il codice id identificativo del Modulo sarà indispensabile per associare il modulo ad una BAdI che definirà il comportamento del modulo stesso in base alle action e ai model associati


Definizione Components

I widget da associare all’applicazione verranno definiti nel ramo Components Configurations. È possibile quindi per ogni componente definire un tipo un titolo ed una classe css, poi in base alla tipologia selezionata è possibile inserire:

  • Per i button (tipo Action), le azioni definite in precedenza ed una icona vedi campo css-class
  • Per i componenti che visualizzano dei dati o forniscono all’utente un form da riempire (vedi form, griglie, gallery, ricerca…) il model che porta in dote i campi e le eventuali dipendenze
  • I moduli invece definiti in precedenza saranno già disponibili sulla griglia perché sono dei componenti grafici anch’essi ma non necessitano di ulteriori configurazioni

Cluster Components Configurations dell’applicazione Materials

Per definire invece i sottocomponenti dove si indicherà la gerarchia dei componenti si procede con il ramo sottostante

Gli stati invece saranno definiti nel ramo Stati Componenti.

Terminata la configurazione è possibile lanciare l’applicazione aggiungendo al link fornito dall’amministratore il nome applicazione nel nostro caso MATERIALS


Per creare semplici applicazioni di ricerca e dettaglio esiste un tools che genera velocemente una struttura di app partendo dalle strutture dictionary desiderate, una per la ricerca una per i risultati ed una per il dettaglio.

Workbench


La seconda fase dello sviluppo per l’applicazione consiste nel definire il comportamento dell’applicazione, in parole povere implementare le select di ricerca e definire i metodi per gestire le azioni.

Come prima azione si va a definire un enhancement implementation a partire dall’enhancement spot ZSTC_WebUI.

All’enhancement creato si andrà ad aggiungere una BAdI per Modulo inserito nella Modules Configuration ed una BAdI per ogni Model che si vuole gestire.

In fase di creazione delle badi si indicherà la definizione base della BAdI che nel caso del modulo è la ZSTC_WEBUI_BADI_MODULE per il model invece sarà la ZSTC_WEBUI_BADI_MODEL.

Ehnancement Implementation ZSTC_EI_MATERIALS

Per ogni badi si definirà inoltre una classe di implementazione e un filtro per le badi modul la coppia (Applicazione, Modulo) in quanto è possibile associare un modulo a più applicazioni, per le badi model invece si definirà un filtro avente l’id filtro come discriminante

Filtro BAdI *MODUL*
Filtro BAdI *MODEL*

Anche le relative classi di implementazione si dovranno specificare sulla divisione Modulo Model, in quanto le prime devono avere come superclasse la ZSTC_WEBUI_BADI_ROOT_MODULE le seconde la ZSTC_WEBUI_BADI_ROOT_MODEL.

Classe di implementazione model Material
Classe di implementazione modulo Material Search

Per le classi modulo nel caso si voglia inserire un modulo in un’altra app si consiglia per evitare di copiare le BAdI di creare una nuova BAdI ed associare come classe di implementazione una sottoclasse di quella di partenza, ed eventualmente ridefinire i metodi per specificare