Automar

2 Dicembre - 12 Dicembre¶

La struttura della di sw_MOVIMENTAZIONE e sue relazioni è stata spiegata il 2 Dicembre

Il 5 dicembre ho messo questo task nel gestore di progetto.

Durante la settimana dall'8 dicembre al 11 dicembre, ho implementato una stored procedure che esportava i movimenti e i dettagli di arrivo, partenza, stato, e mezzo di ingresso, tramite una stored procedure con join alla tabella a_TIPOINOUT, come pensavo che fosse necessario.

Questo tentativo è fallito per la quantità di dati esportati, e la necessità di filter dei dati.

Ma erano corretti il controller e il model nel servizio REST, per entrypoint /Infos/Movements

Il giorno 11 dicembre (sera, ore 19) mi è stato detto di usare una view per movimentazioni.

Grazie alla view il grosso del lavoro dell'estrazione dati e definizione della query era risolto.

Il giorno 12 dicembre ho adattato il controller e model per l'entrypoint REST /Infos/Movements

Le problematiche affrontate durante l'implementazione sono state:

• numero di parametri trattati nella request ed inviati al backend db (codice C#)
• logica di filtering ed implementazione della stored procedure
• Testing con input di filtraggio efficace. (test case definiti ma non registrati)
• Deployment dell'applicazione sul sito di test

Considerazioni¶

• si può migliorare il modo col quale si definiscono test case, senza dover chiedere ogni volta "come faccio la prova?"
• si potrebbero automatizzare i test, nel caso che il codice del servizio, o il codice della/e stored procedure, dovessero cambiare
• il deployment è macchinoso e ripetitivo. Al tempo stesso è poco frequente, quindi tendo a scordarmi i passi necessari per fare il deploy a mano. (devo scrivere esplicitamente i passi nel gestore di progetti)
• la logica dei dati, cosa si può esportare cosa no, cosa serve cosa no, non mi sono ben chiari, e neppure tutte le relazioni presenti a sistema. (devo chiedere più feedback e controllare)

Risultati (funzionalità)¶

/Infos/Movements filtri:

• vin
• origine
• destino
• idgruppoO : gruppo origine
• idgruppoD : gruppo destino
• tipodata : selettore data, ARRIVATO o USCITO
• datafrom: da data
• datato: a data

Dati esportati:

• Stato: PREVISTO, GIACENTE, USCITO, ARRIVATO
• vin
• DesModello
• Origine
• Destino
• DataProgrammazioneDATA
• DataDisponibilitaDATA
• idGruppoO
• idGruppoD
• Lotto
• datainDATA
• DataOUTDATA
• DataPOD
• Cliente

Problema mole di dati e paginazione¶

Filtri troppo laschi possono produrre una quantità enorme di dati.

La paginazione in ambito REST può essere implementata

• in modo puro: nel payload si specifica: page_nr, page_size. Per ogni richiesta: è sessionless come specifica REST
• usando una session con scadenza:
  • alla prima richiesta si registra il payload in un db key-value (redis), e si genera un sessionid. key è sessionid, value è: payload di filtering, elementi per pagina.
  • la prima richiesta restituisce i valori in un array, ed un metainfo contenente il sessionid
  • le richieste per le pagine successive come payload hanno: sessionid, page_nr
  • si usa sessionid per interrogare il key-value db (redis), e una prepared con parametri numero di pagina per interrogare il dbms

In quali casi è meglio usare la session con scadenza: ottimizzazioni interne

• Architettura specifica
• esecuzione predittiva del retrievement dei dati
• accesso al dbms limitato da traffic shaping: caricamento dei dati da dbms (relazionale) e storage su key-value db (redis) per poter fornire le pagine successive senza disturbare il relazionale

Quanto è complesso implementare sessionid? è complesso, discretamente.

Chi usa sessionid con scadenza: Amazon Merchant, eBay.

Quanto è opportuno? Non lo so, non credo.