In questo articolo verranno descritte le nuove funzionalità attraverso cui sarà possibile gestire nelle interfacce grafiche Looc.UP, Web e Mobile un oggetto riconosciuto come tale da Sme.Up .

Dove si definiscono le azioni di gestione di un oggetto

A standard le azioni vengono determinate attraverso i seguenti sorgenti

  • Programma SMESRC/B£GES0: tramite una schiera definita a livello di pgm vengono elencati gli oggetti che si vogliono gestire, le autorizzazioni ed il programma di gestione per l’emulazione 5250.
  • Script SCP_SET/B£GES0: questo script si affianca al precedente per andare ad indicare (quando c’è) la funzione grafica di gestione di un oggetto già definito nella schiera B£GES0 (che rimane obbligatoria)

Tale struttura può poi essere integrata/sovrascritta dal cliente in questo modo:

  1. Programma di exit B£GES0_x: può essere attivato tramite la tabella B£7 e permette di integrare/sovrascrivere la schiera del B£GES0
  2. Script SCP_SET/B£GES0_U: il nome è fisso e permette di sovrascrivere/integrare lo script SCP_SET/B£GES0.
  3. Programma di exit B£K04G_U: il nome è fisso, questa exit può permettere di intervenire sul campo £K04O_GC e nel caso di necessità di ripristinare la versione di emulazione 5250
  4. Struttura Workflow: quando è attiva tale struttura (con relativi script e tabelle) va a sovrascrivere le azioni che verrebbero determinate dai punti precedenti.

Come richiamare un’azione di gestione

  • In una nuova finestra:
F(ACT;B£BASE_05;ESE.GES) 1(tp;pa;cd) P(Azi(nn) AziPar(par))  INPUT(AziInp(input))
  • In una sezione di scheda
F(EXD;B£BASE_05;ESE.GES) 1(tp;pa;cd) P(Azi(nn) AziPar(par))  INPUT(AziInp(input))

Queste funzioni vengono poste in evidenza in quanto tramite esse è possibile richiamare le funzioni di gestione senza preoccuparsi dell’azione che verrà effettivamente eseguita. La prima, può essere usata tranquillamente anche nel caso in cui l’azione di gestione corrisponda ad una emulazione 5250. Questo il significato delle variabili riportate in corsivo:

  • tp =  tipo oggetto
  • pa = parametro oggetto (se previsto)
  • cd = codice oggetto
  • nn = codice azione (01= inserimento, 02=modifica, 03=copia, 04=cancellazione, 05=visualizza)
  • par = parametri P opzionali che verranno passati all’azione specifica
  • input = parametri INPUT opzionali che verranno passati all’azione specifica

Il Costruttore A36

Che cos’é?

Il costruttore A36 (oggetto V2LOCOS) corrisponde ad una scheda standard in cui sono predisposte tutte una serie di funzionalità atte a gestire un oggetto Sme.Up tramite un input panel, nel modo più completo possibile. In esso i campi gestibili saranno referenziati attraverso i codici oav (è implicito in questo che saranno automaticamente gestiti non solo gli oav I, ma anche gli oav P, K e N, per gestire parametri, parametri estesi e note in modo trasparente).

Dove viene utilizzata

Il richiamo del costruttore A36 può avvenire essenzialmente in due modi:

  • Se il costruttore A36 è sufficiente a definire la gestione di un oggetto, il suo richiamo può essere indicato nello script SCP_SET/B£GES0 (o B£GES0_U se attivato su oggetti personali o da personalizzazione)
  • Viceversa se la gestione di un oggetto non può dirsi composta da un singolo input panel, allora nello script B£GES0 verrà indicata la scheda specifica, mentre in tale scheda specifica sarà previsto il richiamo della scheda A36.

Come è strutturato

Il costruttore A36 può dirsi costituito dai componenti riportati a seguire.

1. Programma B£K89_xx

Questo programma (dove xx = al tipo oggetto) si occupa di eseguire l’azione di conferma sull’archivio corrispondente all’oggetto (immissione, modifica, cancellazione), nonchè di eseguire tutti gli eventuali controlli di congruenza aggiuntivi che non si basano meramente sulla consistenza dell’oggetto inputato. Cioè: uno strato di software generale si occupa di verificare che se un campo è previsto che sia una provincia, che nel campo venga indicata un’istanza della tabelle province esistente, viceversa nel pgm B£K89_xx specifico, posso ad esempio dire che non posso scegliere una provincia che non abbia un agente capozona intestato.

A questo pgm è possibile poi affiancare un ulteriore exit B£K89_xxyy implementabile per introdurre ulteriori logiche specifiche del cliente.

2. Script SCP_A36

Con codice = Tipo Oggetto. Lo script è così strutturato:

Azione (AZI) : definisce che tutte le istruzioni riportate a seguire riguardando una specifica azione (compresa fra 00, 01, 02, 03, 04, 05). E’ anche possibile prevedere un’azione ** cui risalgono tutte le azioni che non sono indicate esplicitamente.

Nome contesto (NAM): “**” rappresenta il default, cui si risale sempre se non viene specificato un contesto particolare nel richiamo o se il contesto particolare non ha indicazioni esplicite. Nota bene: il contesto mi permette di avere versioni alternative della stessa gestione in differenti contesti (es. se si vuole sviluppare un concetto di “gestione veloce” o “gestione B2B”)

Varianti (VAR): qui vengono indicati tutti i valori tramite cui si va a configurare che cosa l’input panel presenterà. Qui, in particolare, sono fondamentali due valori:

  • Attraverso l’attributo Cnz è possibile indicare che l’istruzione deve essere presa in considerazione solo se la condizione indicata qui risulta veritiera. Tramite questo attributo ho la possibilità di definire a parità di Azione/Contesto differenti “varianti” della gestione a seconda di caratteristiche dell’oggetto (es. in base al tipo articolo se è una vite mi comporto in un modo se è un tubo in un altro) o anche dell’utente o del gruppo utente.
  • Attraverso l’attributo ScpLay è possibile referenziare un membro del file SCP_LAY. Questo attributo è fondamentale in quando determinerà come e quali dati presentare nell’input panel di gestione (se vedo 10 campi o 50 campi dipende da questo script)
3. Script SCP_LAY

Come accennato in precedenza è fondamentale per andare a specificare che cosa gestirà nell’input panel. E’ importante notare che di base tutti i campi possono essere riferiti attraverso il loro codice oav e che nello standard sono nativamente gestiti gli oav  N/ (Note), P/ (parametri), K/ (parametri estesi), che alla conferma verranno aggiornati sui corrispondenti archivi specifici.

Oltre a questo sopratutto in web, ma parzialmente anche in Looc.UP sarà possibile definire una serie di attributi grafici dei singoli campi.

Fatte queste cose, richiamando la scheda A36, passando oggetto, azione ed eventualmente contesto, tutta la transazione di gestione verrà gestita autonomamente dalla scheda A36.

Si rimanda alla documentazione specifica per maggiori dettagli.

Esempi

Chiamata della scheda (che normalmente dovrei indicare solo nello script SCP_SET/B£GES0 o B£GES0_U)

F(EXD;*SCO;) 1(CM;£R1;xxxxxxxx) 2(MB;SCP_SCH;LOA36) P(AziExe(02))

Qui di seguito invece la stessa scheda A36 visibile da Web (con l’impiego di nuove funzionalità grafiche) e da Looc.UP.

Questa invece una porzione del corrispondente script SCP_LAY (relativo ai primi campi dell’input panel delle precedenti schermate). Si noti in particolare le istruzioni ::Sez che permettono in web di dividere l’input panel in sezioni e gli attributi Cmp ed Ext delle istruzioni ::Fld che invece permetto di applicare tipici componenti web per l’imputazione del singolo campo.