Bollettino ANS n.43 – Giugno 2011

> Bollettini Periodici 43_logo
OGGETTO: Ristrutturazione terminata degli Eventi di Carriera e arrivo dei “Webservice” ANS
Bollettino inviato martedì 07/06/2011 ore 12.00
Validità della comunicazione: ●●●●
argomenti: Ristrutturazione terminata, Webservice ANS, Spedizione “VIP”, Storicizzazione Vecchie Spedizioni, Monitoraggio dimensioni database, Accorpamenti delle Iscrizioni OFF.F. e degli Attributi, Novità sui Ricalcoli


Salve,
come anticipatovi i mesi scorsi, a maggio abbiamo completato tutto il lavoro di ristrutturazione ANS che globalmente ci ha tenuto impegnati per quasi 9 mesi, sotto profili e argomenti diversi.
Dalla versione 9.05.03 vi presentiamo così una “nuova Anagrafe” per ESSE3: come vi accorgerete nei prossimi mesi, essa presenta il grosso vantaggio di acquisire in sé stessa la coerenza dell’insieme delle informazioni coinvolte di ogni studente, tramite il suo continuo rapportarsi, per ogni singola iscrizione (e non solo), con l’evento di carriera che l’ha preceduta e quello che l’ha seguita. Tra le novità dele nuove versioni, si ha la concretizzazione per tutti di effettuare invii delle schede e ricevere i file degli errori tramite i webservices, nati nell’ambito della Cooperazione Applicativa ITC4U; inoltre, vi vengono qui presentate numerose novità sui Riallineamenti e sulle verifiche in merito alla migliorabilità dei dati degli Insegnamenti.

RISTRUTTURAZIONE COMPLETATA: UNA NUOVA ANAGRAFE IN ESSE3

In versione 9.05.03 di ESSE3, come pianificato da mesi, termina definitivamente la ristrutturazione ANS cominciata la scorsa estate, che ha avuto come suo ultimo atto la completa ristrutturazione degli eventi di carriera (scheda 4), cominciato in versione 9.02.03 (cfr bollettino Marzo 2011). Dalla versione 9.05.03 l’invio di tutte le informazioni delle schede 4 è totalmente condizionato alla presenza degli eventi di carriera, tramite un calcolo preventivo (RIALLINEAMENTO CORSO OFF.F. DELLE ISCRIZIONI), da effettuarsi, a discrezione degli Atenei, come già descritto nei precedenti bollettini. I vantaggi sono fondamentalmente tre:

  1. l’abbattimento dei costi di elaborazione delle schede;
  2. la possibilità, analizzando una singola carriera, di capire da subito come verranno inviati in Anagrafe i dati fondanti, quali l’evento di carriera per anno accademico e data dell’evento;
  3. intercettare un numero maggiore di eventi di carriera prima non ottenibile oppure non possibile in modo elementare.

Non affronteremo in questo bollettino quanto già esposto i mesi scorsi, ma piuttosto vogliamo approfittarne per evidenziarvi alcuni approfondimenti da tenere bene a mente:

  • associata ad un’iscrizione reale si possono avere più eventi di carriera: ad esempio, a fronte di un rinnovo di iscrizione e di un trasferimento in uscita nello stesso anno accademico, si avranno 2 eventi di carriera distinti (IA e TU) entrambi agganciati alla stessa iscrizione reale, di cui condivideranno le caratteristiche della OFF.F. (Corso OFF.F.);
  • grazie alla ristrutturazione si riescono ora ad intercettare casistiche di trasferimenti multipli che in precedenza potevano sfuggire (quali eventi successivi TU e TI nel “bel mezzo” di una carriera);
  • la gestione delle sospensioni si diversifica in 2 tronconi distinti: le sospensioni annuali (tutte aventi iscrizioni reali annuali nate da sospensione) e le sospensioni “attuali” (caratterizzate da uno studente attualmente in stato sospeso per un conseguente motivo di sospensione); permane il nostro non invio di sospensioni infrannuali passate, visto che il dato non pregiudica la coerenza del quadro dello studente; a tal proposito, ricordiamo che i primi schemi Anagrafe NON richiedevano tutti gli eventi di carriera ma al più un evento per anno.
  • ribadiamo come l’evento di carriera di ogni singola iscrizione OFF.F. abbia nella data dell’evento stesso il suo attributo più importante; le date non sensate vanno intercettate e sistemate (cfr CONTROLLI DI CONGRUENZA), pena l’errato calcolo o il non calcolo dell’evento ed un conseguente buco nell’invio della scheda 4. Per questo motivo, la ristrutturazione fa emergere nuove casistiche di iscrizioni da sistemare.
  • abbiamo ridisegnato la logica del cambio di anno di regolamento storicizzato in REGOLAMENTI STUDENTI, tramite utilità nascoste che ripuliscono dati ridondanti e una visualizzazione più compatta. Ci eravamo infatti accorti che la precedente presentazione (più ricca e visualizzatrice di tutte le chiavi matricole coinvolte) risultava di difficile comprensione. Non mancate di farci avere suggerimenti od osservazioni.

Vi chiediamo di affrontare da subito le novità esposte, a partire da una versione 9.05.03 e successive, tramite una serie di reinvii totali di schede 1 e 4 a partire dall’A.A. 2001/2002, in modo tale da intercettare, con gradualità anno per anno, nuovi dati da sistemare ed avere un quadro completo d’Ateneo. Procedete cronologicamente e tenete a mente che ogni buco introdotto in un anno pregiudicherà “potenzialmente” gli invii successivi. Vi chiediamo inoltre di non effettuare spedizioni 5 fino a versione 9.06.01, poiché conterranno dati ridondanti.

WEBSERVICE ANS: INVIO SPEDIZIONI E RICEZIONE FILE DEGLI ERRORI

Dalla versione 9.05.03 di ESSE3 è contenuto il pacchetto ufficiale per poter inviare all’Osservatorio le 7 spedizioni “classiche”, nonché ricevere i file degli errori ERR ed ERR2,tramite appositi webservice (WS). Vi rammentiamo di attendere una nostra comunicazione, concertata con l’Osservatorio Studenti, prima di procedere con l’attivazione del servizio di webservice ANS in ESSE3, seguendo scrupolosamente le operazioni qui di sotto indicate.

Le spedizioni coinvolte sono attualmente le sole 7 schede “classiche” e l’ambiente di connessione che adottiamo per la connessione da parte di ESSE3 è esclusivamente quello di produzione dell’Osservatorio Studenti; altre combinazioni non sono permesse e non funzioneranno (ad esempio, da standard, non sarà possibile l’utilizzo dei WS da un db di test/pre-produzione ad OSD oppure l’invio da db di produzione ad area di test di OSD). Si richiede inoltre l’UNIVOCITÀ del numero di file presente in ESSE3 con quello delle spedizioni definitive deposite all’Osservatorio Studenti; in ogni modo, in caso di conflitti, l’acquisizione manuale del file degli errori sarà sempre possibile.

Andiamo ora a specificare con cura il funzionamento di questo nuovo processo, dalla configurazione all’utilizzo pratico in ESSE3, in quattro semplici punti.

a) VERIFICA INDIRIZZO DI WEBSERVICE

Soprattutto per gli Atenei con il db “in house”, consigliamo di verificare che l’indirizzo dei webservice ANS sia il seguente: https://osd.cineca.it/php5/ws/ , per i contesti  ANSWSFILESPED  e ANSWSERRFILE:param_contesto

In caso di difformità, correggete l’indirizzo URL nella maschera CONTESTI oppure, se avete accesso alla base dati, lanciate lo script che segue:

update P99_PARAM_CONTESTO
set valore=’https://osd.cineca.it/php5/ws/’
where valore like ‘%cineca%ws%’

b) SETTAGGIO PARAMETRO DI CONFIGURAZIONE

Dapprima, dovete alzare il parametro di configurazione ‘ANS_WEBSERVICE’ (valore numerico ad 1) e controllare che sia specificato, nel valore alfanumerico, ‘DEF’, a denotare l’invio nell’area di produzione dell’Osservatorio Studenti. Come detto in precedenza, non è previsto comunque nessuna comunicazione (di invio e ricezione) con l’area di test dell’Osservatorio Studenti.

c) VERIFICA CREDENZIALI DI ACCESSO PER IL COLLEGAMENTO WEB SERVICES ED INVIO SCHEDA

A questo punto, dovete inserire nel sistema le vostre credenziali di accesso all’Osservatorio Studenti: si ricorda (cfr  articolo http://ans-esse3.cineca.it/2013/09/10/cambio-user-e-password-di-accesso-ai-servizi-di-webservice-ans) che come user andrà indicato l’utente principale del vostro Ateneo, accreditato dall’Osservatorio come abilitato ai servizi, e come password l’accesso al sito osservatorio.cineca.it. In ESSE3 gestiamo un UNICO utente che dovrà essere , ovviamente, pienamente abilitato a questi servizi.

cambio_password_new

Adesso il sistema è pronto per dialogare direttamente con l’Osservatorio Studenti! D’ora in poi, ogniqualvolta che effettuerete una spedizione “classica” in GENERAZIONE SPEDIZIONI ANS, terminata la fase di elaborazione dei record, vi comparirà una piccola spunta “Invio dati ad OSD”: alzandola prima di cliccare su “Genera File”, la spedizione verrà direttamente inviata all’Osservatorio Studenti, in formato zip e con un nome definito da uno standard di OSD.

Come sempre, vi verrà conservata una copia locale della scheda prodotta, in formato txt, con il nome definito dai nostri standard e cambiabile, come sempre, a piacimento dall’utente prima di procedere con la generazione della stessa.

d) RICEZIONE FILE ERR E SETTAGGIO DEI TEMPI

A questo punto, in RIEPILOGO SPEDIZIONI, nel caso in cui abbiate una spedizione in stato spedito, noterete un nuovo tasto “Carica File Errori da OSD”: premendolo, il sistema preleverà  dall’Osservatorio il file degli errori disponibili, effettuando il suo caricamento in ESSE3.

L’operazione descritta di caricamento del file degli errori da OSD è manuale ma la configurazione di questi servizi contiene i seguenti automatismi:

  • ogni 60 minuti, ESSE3 interroga l’Osservatorio per scaricare i file ERR di spedizioni pendenti in stato spedito;
  • in caso in cui il file ERR venga individuato, viene caricato, altrimenti viene restituito un messaggio d’errore che verrà scritto nel campo “Note Tecniche” della spedizione (cfr RIEPILOGO SPEDIZIONI ANS);
  • inoltre, ogni settimana, ESSE3 interrogherà l’Osservatorio per scaricare automaticamente i file ERR2 di tutte le spedizioni valide; nel caso in cui una spedizione valida abbia già avuto il caricamento del suo file di coerenza, se il caricamento è più vecchio di una settimana, ESSE3 caricherà il nuovo file ERR2, altrimenti non procederà. Come dovreste ricordare, per una medesima spedizione valida, viene prodotto l’ERR2 tante volte quante sono le conferme di validità della spedizione stessa, durante le scadenze temporali intercorse; sarà capitato a tutti di attendere un nuovo file di coerenza per lo stessa spedizione, poiché ci si aspettava che fosse migliorativo rispetto all’ultima elaborazione di coerenza, senza bisogno di dover rifare quella scheda… Con il Webservice tutto ciò è realizzato automaticamente.
  • Alleghiamo, per gli Amministratori di sistema e/ DBA, un approfondimento sulla configurazione esatta del minutaggio, che può essere settata, a piacimento, da db o da maschera :
    • verifica da data base -verifica che la schedulazione del Webservice ERR/ERR2 avvenga ogni 60 minuti
      update fw_bs
      set schedule_unit=60, schedule_type=’MINUTI’, attiva_flg=1
      where proc_id=(select id as proc_id
      from fw_bs_proc
      where des=’WS ERR ANS’ );
    • verifica da client:  accedendo alla maschera ELABORAZIONI BATCH, selezionando il processo WS_FILE_ERR (WS ERR ANS), cliccando su “Dettagli”, dove potrete agire su tutto quanto. Raccomandiamo però di alzare unicamente il flag di attivazione e di non agire sul minutaggio, per non “ingolfare” il sistema di richiami inutili ai webservice.

elaborazioni_batch_WSERR_dettagli

**********************************************************************

Crediamo che il nuovo sistema vi sarà molto utile per un paio di motivi principali: permetterà di ritrovarvi il “lunedì” i file di coerenza già caricati e verificherete un tangibile risparmio di tempi nelle fasi di UPLOAD delle schede e DOWNLOAD dei file degli errori dal sito dell’Osservatorio. In ogni modo, ci aspettiamo che vi risulti spesso più comodo scaricarvi direttamente un file ERR tramite RIEPILOGO SPEDIZIONI > Carica File da OSD, piuttosto che aspettare che ESSE3 lo effettui automaticamente, perché, come spiegato sopra, l’interrogazione ad OSD è a cadenza “oraria” in quanto, essendo comunque un processo oneroso, ci pare come la più congrua una schedulazione minima a cadenza di 60 minuti.

esempioAd esempio, se avete inviato una scheda alle ore 15.59 e alle 16.01 il file ERR è già pronto, ESSE3 ve lo caricherà automaticamente a partire dalle 17.00 se l’ultima coda di acquisizioni ERR è partita e si è conclusa già alle 16.00. In tal caso, invocherete manualmente il Webservice da RIEPILOGO SPEDIZIONI>Carica File da OSD

 Ringraziamo gli Atenei di Torino e IUAV per la loro collaborazione e disponibilità nell’essere stati apripisti, nel mese di Maggio, all’invio dei dati in PRODUZIONE delle schede ANS tramite i webservice sopra descritti.

SPEDIZIONI “VIP” E STORICIZZAZIONE VECCHIE SPEDIZIONI

Vogliamo porre la vostra attenzione su un nuovo servizio che abbiamo realizzato ma che renderemo operativo fra qualche settimana, per darvi tempo di abituarvi alle varie novità. Da un po’ di tempo in RIEPILOGO SPEDIZIONI ANS avrete notato il flag di Spedizione “VIP” ; lo abbiamo introdotto per darvi la possibilità di marchiare come spedizione importante una scheda inviata, a vostro piacimento (ad esempio, potreste segnarvi la scheda della rilevazione di gennaio, quella utilizzata per gli ultimi FFO, ecc…). Di “default” vi troverete già alcune spedizioni “VIP”, poiché l’introduzione del flag è avvenuta alzandolo per tutte le spedizioni per le quali vi fossero state associate da voi delle note in RIEPILOGO SPEDIZIONI; in ogni modo, la valorizzazione di questo flag spetta a voi. Detto questo, è importante che alziate questo flag se volete conservare una scheda in futuro poiché attiveremo, dalla versione 9.06.03, una piccola utilità che comincerà, con calma, a fare pulizia di vecchie spedizioni, eliminando quelle che non sono “VIP”. È infatti necessario che tutti voi abbiate ben presente il “peso” del modulo Anagrafe nell’intera base dati, che è dell’ordine di un terzo del totale sulla maggioranza dei vostri Atenei. Dalla versione 9.06.01 comparirà, in STORICIZZAZIONE VECCHIE SPEDIZIONI, un pulsante di monitoraggio per tenere controllata la situazione. Vi invitiamo all’eliminazione di quelle vecchie spedizioni che non reputiate più necessarie mantenere: ricordiamo che spedizioni valide e “VIP” non sono eliminabili; per eventuali dubbi sull’utlizzo della maschera, riferitevi a quanto comunicato in precedenti bollettini.

Dalla versione 9.06.03 di ESSE3 viene inoltre introdotto un servizio che permette di pianificare l’eliminazione di una o più spedizioni.

SCHEDE ANTE: SEGNALATECI GLI EVENTI “FUORI SCHEMA”

In merito alle schede ANTE, l’Osservatorio ha di recente aggiunto eventi di trasferimento tra Atenei a corsi di studio ante-riforma. Noi non abbiamo recepito questa modifica poiché, allo stato attuale, nessuno di voi ci ha mai segnalato alcun trasferimento tra corsi ante-riforma dall’anno accademico 2009/10 in poi. Abbiamo avuto segnalazione di 2 passaggi di corso dal post riforma all’ante riforma che saranno oggetto di valutazione ed accordo con l’Osservatorio Studenti nel corso di questa estate. In generale, vi invitiamo a segnalarci qualsiasi peculiarità o discostamento rispetto agli schemi noti, in maniera tale da richiedere all’Osservatorio che vengano valutati per essere inclusi nello schema Anagrafe.

Riassumiamo la gestione degli eventi di carriera per la scheda 4-ANTE in ESSE3:

  • IA: rinnovo di iscrizione al corso USTAT dell’anno precedente
  • PC: passaggio di corso fra corsi ante-riforma
  • RI: ricognizione su corso ante-riforma
  • SO: sospensione (annuale) su corso ante-riforma o attuale sospensione per iscritto a corso ante-riforma

NOVITÀ: ACCORPAMENTI DELLE ISCRIZIONI OFF.F. E DEGLI ATTRIBUTI DEGLI INSEGNAMENTI OFF.F.

Dalla versione 9.06.00 di ESSE3 abbiamo introdotto due importanti parametri di configurazione, che potranno aiutarvi nel semplificare casistiche fino ad oggi intercettate come errori nel sistema e per le quali non avete possibilità di effettuare ulteriori miglioramenti. Entrando nello specifico, introduciamo i seguenti parametri di configurazione:

  • ANS_ACCORPA_ISCR_STESSOGIORNO: a default zero, se valorizzato ad 1 effettua, al termine del ricalcolo degli eventi di carriera, in caso di più iscrizioni reali nello stesso giorno per lo stesso studente, un “accorpamento” di iscrizioni OFF.F. che consiste nel mantenerne solo una ed eliminando le altre, il tutto tramite un raffronto logico con l’iscrizione dell’anno prima, evitando quindi di ritrovarsi con più iscrizioni OFF.F. reali lo stesso giorno. Sarà quindi l’iscrizione attiva ad avere l’Iscrizione OFF.F., mentre le iscrizioni chiuse per passaggio nello stesso giorno non avranno Iscrizione OFF.F.
    • Consigliamo l’utilizzo del parametro qualora si riscontrino difficoltà di controllo e/o correzione di date su carriere aventi più iscrizioni reali a medesima data. Rammentiamo che al di là della semplice casistica coppia di un’iscrizione XP ed iscrizione A a medesima data, ci imbattiamo nella realtà in situazioni molto più arzigogolate e “bruttine” (la più strana trovata di recente è 5 passaggi di corso nella stessa data tra i medesimi corsi: A–>B–>A—>B–>A) che a nostro parere meriterebbero assolutamente il “passaggio” dell’Amministratore di sistema.
  • ANS_ACCORPA_ATTRIBUTI_99999: a default zero, se valorizzato ad 1 effettua l’accorpamento fisico degli attributi del medesimo insegnamento derivanti da TAF e ambiti distinti (a parità di tipo credito, ad esempio LEZ) che producono ambito univoco non definito, poiché contengono combinazioni di TAF e ambito non lecite o, peggio, monche.
    • Suggeriamo l’utilizzo di questo parametro SOLTANTO ad Atenei che non siano in grado di migliorare la qualità delle attività formative e degli ambiti delle loro Offerte , essendo impossibilitati a specificarli e a renderli coerenti con lo schema della propria classe di laurea attuata in Ateneo.
    • In ogni modo, siete da noi esplicitamente invitati a monitorare le attività a taf prioritari (per lo meno A e B) perché inviare un Insegnamento OFF.F. ad ambito univoco non definito significa che l’Ateneo non lo sa inquadrare nemmeno nel TAF.

In merito alla migliorabilità degli Insegnamenti OFF.F., abbiamo rilasciato, in forma “Beta”, già in versione 9.05.03 un nuovo insieme di Controlli di Congruenza a nome “Incongruenze degli Insegnamenti OFF.F.”, i quali esplorano le posizioni da controllare sugli esami. Visto il probabile alto numero di casistiche coinvolte, vi suggeriamo di tenere monitorata la situazione e di seguirla, con calma, nel tempo. L’oggetto di interrogazione è la vista materializzata MV15_MON_INSEGNAMENTI.

RICALCOLO INCREMENTALE: NOVITÀ E NUOVI SVILUPPI

Dalla versione 9.06.00, sono presenti delle implementazioni inerenti i Riallineamenti, che vi permetteranno di distinguere meglio l’utilizzo di una fase incrementale piuttosto di quella totale. Vi confermiamo i seguenti schemi concettuali:

  • un’Iscrizione OFF.F. non definita (9999999999) viene sempre ripresa e ricalcolata in un Riallineamento Incrementale dei Corsi OFF.F.;
  • un Insegnamento OFF.F. su Corso OFF.F. non definito (9999999999) viene sempre ripreso e ricalcolato in un Riallineamento Incrementale degli Insegnamenti OFF.F.;
  • un Insegnamento OFF.F. ricava il suo Corso OFF.F. da quanto risulta in quel momento caricato a sistema (schede 1 e 4); nel caso in cui non si trovi alcun evento di carriera, il sistema ora proverà a ricavare il Corso OFF.F. direttamente dalle Iscrizioni OFF.F. Si ponga attenzione a non abusare di questo escamotage tecnico, che deve essere uno strumento per venire incontro a situazioni comunque ORDINATE; in caso contrario, la situazione risulterà pasticciata. NOTA BENE: eventuali ticket sull’argomento (“come mai il corso del tale insegnamento è diverso da quanto ho ora in scheda 4?”) verranno chiusi rimandandovi al riallineamento a schede 1 e 4 incamerate.
  • Siamo tecnicamente in grado di produrre una terza modalità di RIALLINEAMENTO, che peschi SOLTANTO quanto variato rispetto all’ultimo riallineamento. Il tutto vi verrà presentato a LUGLIO 2011 a nome “RIALLINEAMENTO SULLE VARIAZIONI”. Vi ringraziamo per aver partecipato al sondaggio per darci un’indicazione sul nome di questo terzo tipo di riallineamento — si veda questo link: —> Sondaggio sul Terzo Tipo di Riallineamento .

A disposizione per qualsiasi chiarimento,
Buon lavoro,
Christian Marcone