Skip to end of metadata
Go to start of metadata


Sommario

1 Introduzione

Il presente documento descrive il DB di frontiera IRIS IE (IRIS Import/Export) concentrandosi sugli aspetti che riguardano la procedura di sincronizzazione delle anagrafiche tra il modulo RM di IRIS e Sistemi Informativi in uso presso il cliente. 

Ricordiamo comunque il DB di frontiera può venire utilizzato non solo ai fini della sincronizzazione delle anagrafiche ma ogni qual volta ci sia la necessità di condividere delle informazioni da moduli di IRIS verso Sistemi Informativi del cliente e viceversa.

Questo DB di frontiera è disponibile nei vari ambienti di deploy di IRIS. Il nome dello schema di frontiera segue questa naming convention:

IRISIE_<CUSTOMER>_<ENVIRONMENT>

dove con

  • CUSTOMER, intendiamo l’acronimo del cliente (tipicamente estratto dal nome del dominio internet)
  • ENVIRONMENT, intendiamo l’ambiente (PROD,PREPROD)

Le tabelle presenti in questo schema seguono la seguente naming convention:

<I|E>_<IRIS_MODULE>_<TABLE_NAME>

dove

  • I, denota una tabella usata per effettuare IMPORT di dati IN IRIS (diritti di lettura/scrittura)
  • E, denota una tabella usata per ESPORTARE dati DA IRIS (diritti di sola lettura)
  • IRIS_MODULE, indica il modulo dal quale (nel quale)  i dati sono esportati (importati)
  • TABLE_NAME, indica il nome della tabella legato al tipo di informazioni caricate.

Ad esempio la tabella I_RM_ADDRESS individua una tabella usata per importare indirizzi nel modulo IRIS RM.

2 DB di Frontiera per la sincronizzazione delle anagrafiche

Di seguito vengono elencate le tabelle utilizzate dalla procedura di sincronizzazione delle anagrafiche, dettagliando, dove necessario, le informazioni contenute nelle varie colonne.

2.1 I_RM_PERSON

Questa tabella raccoglie le informazioni fondamentali (e OBBLIGATORIE) per una persona.
Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBLIGATORIO

VINCOLI

ID

Identificativo UNIVOCO della persona nei SI sorgenti

 

SI

Questo è l’identificativo che verrà utilizzato per effettuare le operazioni di mappatura tra SI sorgenti e IRIS.

FIRST_NAME

 

Nome

 

SI

 

LAST_NAME

Cognome

 

SI

 

ERROR

Codice di errore

 

NO

Usato per check di validità

2.2 I_RM_PERSON_DATA

Questa tabella raccoglie informazioni aggiuntive (NON OBBLIGATORIE) sulle persone, di seguito elencate.

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE O  FORMATO

NOTE

birthDate

Data di nascita

XML DateTime

Il format DateTime è specificato nella seguente forma:

YYYY-MM-DDThh:mm:ss

dove:

YYYY indica l'anno
MM indica il mese
DD indica il giorno
T è il separatore data/orario
hh indica l'ora
mm indica i minuti
ss indica i secondi

Tutte le componenti sono obbligatorie

birthCountryId

Identificativo nazione di nascita

ISO_3166-1 Alpha-2

Cfr http://it.wikipedia.org/wiki/ISO_3166-1

birthPlaceId

Identificativo città/paese di nascita

CODICE CATASTALE

Nel caso di città/paesi italiani deve essere utilizzato il Codice Catastale.
Nel caso di città/paesi NON italiani, deve essere concordata la classificazione.
Pragmaticamente conviene procedere con il caricamento delle città/paesi non italiani nel campo birthPlaceString, di seguito descritto.

birthPlaceString

Nome del paese/città di nascita

 

Questo campo, alternativo a birthPlaceId, deve essere usato quando non è utilizzabile un identificativo

gender

Sesso

M/F

Gli unici valori consentiti sono M o F

codiceFiscale

Codice fiscale

 

Il codice fiscale DEVE essere valido

La tabella prevede le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBL

VINCOLI

FK_PERSON

Chiave esterna verso I_RM_PERSON

 

 

SI

Questo è l’identificativo che verrà utilizzato per effettuare le operazioni di mappatura tra SI sorgenti e IRIS.

DISCRIMINATOR

 

Tipologia di informazione aggiuntiva

I valori accettabili per questo campo sono uno di quelli elencati lista precedente:
- birthDate
- birthCountryId
- birthPlaceId
- birthPlaceString
- gender
- codiceFiscale

 

SI

 

STRING_VALUE

Valore

 

SI

 

ERROR

Codice di errore

 

NO

Usato per check di validità

A titolo esemplificativo considerare il seguente esempio.

Supponiamo di avere già caricato la persona MARIO ROSSI di identificativo XYZ nella tabella I_RM_PERSON.

ID

FIRST_NAME

LAST_NAME

XYZ

MARIO

ROSSI

Supponiamo anche di volere caricare il codice fiscale MRORSS70B25A691H e la data di nascita 15/10/1970. Dovranno essere inseriti due record distinti nella tabella I_RM_PERSON_DATA

FK_PERSON

DISCRIMINATOR

STRING_VALUE

XYZ

codiceFiscale

MRORSS70B25A691H

XYZ

birthDate

1970-10-15T00:00:00

2.3 I_RM_USER

Questa tabella raccoglie informazioni sugli utenti.
Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBLIGATORIO

VINCOLI

USERNAME

Username utilizzato per autenticazione

 

SI

UNIVOCITA’ dello username

LDAP_DN

 

LDAP Distinguished Name nel caso di utilizzo di autenticazione LDAP

 

NO

 

FK_PERSON

Chiave esterna verso I_RM_PERSON

 

SI

 

ERROR

Codice di errore

 

NO

Usato per check di validità

Non viene conservata nessuna password perché si considera prerequisito che il processo di autenticazione venga effettuata su sistemi del cliente (LDAP, IDP, …).

2.4 I_RM_ORG_UNIT

Questa tabella raccoglie informazioni sulle unità organizzative fisiche (come uffici, dipartimenti) e logiche (come ruoli, qualifiche, SSD, Aree ministeriali, eccetera).
Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBL

VINCOLI

ID

Identificativo UNIVOCO dell’unità organizzativa nei SI sorgenti.

 

SI

Questo è l’identificativo che verrà utilizzato per effettuare le operazioni di mappatura tra SI sorgenti e IRIS

DESCRIPTION

 

Denominazione dell’unità organizzativa

 

SI

 

START_DATE

Data di attivazione dell’unità organizzativa

 

SI

 

END_DATE

Data di cessazione dell’unità organizzativa

 

NO

 

FK_ORG_UNIT_TYPE

Chiave esterna verso E_RM_ORG_UNIT_TYPE

 

SI

Ogni unità organizzativa DEVE essere mappata sulle tipologie di unità di IRIS

ERROR

Codice di errore

 

NO

Usato per check di validità

2.5 E_RM_ORG_UNIT_TYPE

Questa tabella viene fornita in sola lettura (notare il prefisso “E_”) ed elenca le tipologie di unità organizzative presenti in IRIS. Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBL

VINCOLI

ID

Identificativo UNIVOCO della tipologia di unità organizzativa in IRIS

 

SI

 

DESCRIPTION

 

Nome breve della tipologia di unità organizzativa

 

SI

 

Di tutte le tipologie di unità organizzativa presenti nella tabella, tipicamente vengono usate:

  • researchRole: indica un ruolo di ricerca (ad esempio Docenti di ruolo di IIa fascia)
    Strutture di questo tipo non hanno nessun legame gerarchico
  • researchTitle: indica una qualifica di ricerca (ad esempio Professori Associati)
    Strutture di questo tipo non hanno nessun legame gerarchico
  • identificationNumber: indica una matricola
    Strutture di questo tipo non hanno nessun legame gerarchico
  • department: con questa tipologia vengono marcate le strutture cardine dell’ente di ricerca o università.  Sono, quindi, fondamentali, pena il funzionamento parziale dei vari moduli di IRIS (IR, ER, …). Strutture di tipo department possono avere SOLO strutture figlie (di tipo subdepartment) e/o padre (di tipo superdepartment)
  • superdepartment: con questa tipologia vengono marcate le sovrastrutture dell’ente di ricerca o università. Queste strutture possono avere come strutture figlie (in dipendenza gerarchica) solo strutture di tipo department ma non possono avere strutture padre.
    Tipicamente queste strutture vengono usate solo per gli enti di ricerca.
  • subdepartment: con questa tipologia vengono marcate le sottostrutture dell’ente di ricerca o università. Queste strutture possono essere strutture figlie (in dipendenza gerarchica) solo di altre strutture di tipo department e non possono avere altre strutture figlie.
    Tipicamente queste strutture vengono usate solo per gli enti di ricerca.
  • supportRole: indica un ruolo di supporto (ad esempio Non Docente di ruolo)
    Strutture di questo tipo non hanno nessun legame gerarchico
  • supportTitle: indica una qualifica di supporto (ad esempio Area Biblioteche)
    Strutture di questo tipo non hanno nessun legame gerarchico
  • administrativeArea: indica un’area amministrativa
    Strutture di questo tipo possono avere legami gerarchici con altre strutture
  • administrativeSector: indica un settore amministrativo
    Strutture di questo tipo possono avere legami gerarchici con altre strutture
  • office: indica un ufficio
    Strutture di questo tipo possono avere legami gerarchici con altre strutture
  • other: indica un’altra struttura che non rientra in nessuna delle categorie precedenti
    Strutture di questo tipo possono avere legami gerarchici con altre strutture

Di tutte le tipologie di strutture elencate quelle FONDAMENTALI, per il personale che si occupa di ricerca sono:

  • researchRole
  • department

Nel caso in cui si vogliano usare strutture assimilabili alle tipologia subdepartment, è necessario che venga specificata la dipendenza da una struttura di tipo department.
Ad esempio supponiamo che in I_RM_ORG_UNIT venga caricata una struttura X marcata come subdepartment. Per il corretto funzionamento di IRIS è necessario che questa struttura abbia un link in I_RM_ORG_UNIT_LINK, verso una struttura Y di tipo department.
Lo stesso ragionamento vale per superdepartment e department.
Tenere presente, comunque, che non è necessario completare tutta la gerarchia: in altre parole non è necessario avere strutture in tutte e tre le tipologie superdepartment, department, subdepartment.
Resta fermo che la tipologia obbligatoria è department.

Nella tabella I_RM_POSITION (di seguito descritta) è necessario, per il personale di ricerca, specificare tra le posizioni (individuate da ruoli di tipo researchRole), strutture di tipo subdepartment o department.
Per il personale di supporto (tecnici amministrativi) non ci sono particolari vincoli stringenti nella specifica delle afferenze. Tenere presente, però, che qualora questo personale si occupi anche di ricerca deve rispettare i vincoli sopra imposti.

In ambito prettamente universitario vengono utilizzate anche le seguenti tipologie:

  • academicArea: Area ministeriale
  • academicGroup: Macro-settore concorsuale
  • academicField: Settore concorsuale
  • academicField2000: Settore SSD
  • faculty: Facoltà
  • researchSchool: Scuola di ricerca

Per completezza, nel caso vengano caricate strutture di tipo academicArea, academicGroup, academicField, academicField2000, devono venire caricate anche tutte le gerarchie.

Nella fase di setup della procedura di sincronizzazione è necessario individuare, con il cliente, quali siano le strutture cardine nell’organigramma dell’ente ed eventualmente le strutture al livello gerarchico superiore ed inferiore.
Nel caso in cui la strutturazione dell’ente sia particolarmente complessa, si deve procedere ad una semplificazione. Le strutture cardine (superdepartment, department, subdepartment), infatti, prevedono solo una gerarchia di tre livelli al massimo. Questa limitazione viene imposta dalle necessità di elaborazione dati lato BI. Il limite imposto per i livelli gerarchici delle altre tipologie di strutture è cinque.

All’interno di una gerarchia NON POSSONO essere presenti strutture di una stessa tipologia: unica eccezione è la tipologia "other".
Ad esempio, supponendo che X e Y siano due strutture di tipologia A, la gerarchia X>>Z non è contemplata.

Questa tabella raccoglie i legami tra unità organizzative.
Al momento attuale sono gestiti solo i legami gerarchici.
Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBL

VINCOLI

FK_ORG_UNIT_1

Chiave esterna verso I_RM_ORG_UNIT

 

 

SI

 

DISCRIMINATOR

Tipo di relazione

L’unico valore accettabile è:
- parent

SI

 

ERROR

Codice di errore

 

NO

Usato per check di validità

Considerare, a titolo di esempio, il seguente record.

FK_ORG_UNIT_1

DISCRIMINATOR

FK_ORG_UNIT_2

XXX

Parent

YYY

Questo significa che l’unità organizzativa di ID XXX è gerarchicamente padre dell’unità di ID YYY

2.7 I_RM_ADDRESS

Questa tabella raccoglie centralmente gli indirizzi di unità organizzative (I_RM_ORG_UNIT) e di persone (I_RM_PERSON).
Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBLIGATORIO

VINCOLI

ID

Identificativo univoco

 

SI

 

DISCRIMINATOR

Tipologia di indirizzo

Gli unici valori accettabili sono:
- office

SI

 

COUNTRY_ID

Identificativo nazione

ISO_3166-1 Alpha-2

SI

 

PLACE_ID

Identificativo del paese/città

Codice catastale

NO

Deve essere popolato alternativamente a PLACE_STRING.
Da usare per i comuni italiani

PLACE_STRING

Nome del paese/città

 

NO

Deve essere popolato alternativamente a PLACE_ID. Da usare per i paesi/città non italiani

DESCRIPTION

Indirizzo completo di via/piazza e numero civico

 

SI

 

POSTAL_CODE

Codice postale

 

NO

 

PRINCIPAL

Flag indirizzo principale per tipologia (discriminator)

1 = indirizzo principale
0 = indirizzo NON principale

SI

 

FK_ORG_UNIT

Chiave esterna verso I_RM_ORG_UNIT

 

NO

Deve essere popolato alternativamente a FK_PERSON

FK_PERSON

Chiave esterna verso I_RM_PERSON

 

NO

Deve essere popolato alternativamente a FK_ORG_UNIT

ERROR

Codice di errore

 

NO

Usato per check di validità

Si precisa che

  • uno ed uno solo tra PLACE_ID e PLACE_STRING deve essere popolato.
  • uno ed uno solo tra FK_ORG_UNIT e FK_PERSON deve essere popolato.

2.8 I_RM_CONTACT

Questa tabella raccoglie centralmente i contatti di unità organizzative (I_RM_ORG_UNIT) e di persone (I_RM_PERSON).

Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBLIGATORIO

VINCOLI

ID

Identificativo univoco

 

SI

 

DISCRIMINATOR

Tipologia di contatto

Gli unici valori accettabili sono:
- mail
- phone
- mobile
- web

SI

 

DESCRIPTION

Contatto

 

SI

 

PRINCIPAL

Flag contatto principale per tipologia (discriminator)

1 = contatto principale
0 = contatto NON principale

SI

 

FK_ORG_UNIT

Chiave esterna verso I_RM_ORG_UNIT

 

NO

Deve essere popolato alternativamente a FK_PERSON

FK_PERSON

Chiave esterna verso I_RM_PERSON

 

NO

Deve essere popolato alternativamente a FK_ORG_UNIT

ERROR

Codice di errore

 

NO

Usato per check di validità

Si precisa che uno ed uno solo tra FK_ORG_UNIT e FK_PERSON deve essere popolato

2.9 I_RM_POSITION

Questa tabella raccoglie tutte le informazioni di carriera delle persone.
Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

CLASSIFICAZIONE

OBBLIGATORIO

VINCOLI

FK_PERSON

Chiave esterna verso I_RM_PERSON

 

SI

Cfr §2.9.1

FK_POSITION_TYPE

Chiave esterna verso I_RM_ORG_UNIT

 

SI

Cfr §2.9.2

FK_ORG_UNIT

Chiave esterna verso I_RM_ORG_UNIT

 

SI

Cfr §2.9.3

START_DATE

Data inizio validità

 

SI

Cfr §2.9.4

END_DATE

Data fine validità

 

NO

Cfr §2.9.5

PRIORITY

Peso del rapporto di lavoro

 

NO

Cfr §2.9.6

ERROR

Codice di errore

 

NO

Usato per check di validità

IRIS_GENERATED

Flag

 

NO

Cfr §2.9.7

2.9.1 FK_PERSON

In questa colonna devono essere specificati ID di persone (presenti in I_RM_PERSON).

2.9.2 FK_POSITION_TYPE

In questa colonna devono essere specificati ID di unità organizzative (presenti in I_RM_ORG_UNIT) che semanticamente siano assimilabili a ruoli come ad esempio:

  • Ricercatore
  • Docente
  • Tecnico Amministrativo
  • Professore a Contratto
  • Presidente di CdL
  • etc.

Le unità organizzative in questione devono specificare nella colonna FK_ORG_UNIT_TYPE (della tabella in I_RM_ORG_UNIT) il valore identificativo di una delle seguenti tipologie (presenti nella tabella E_RM_ORG_UNIT_TYPE):

  • researchRole: ruoli di ricerca (Docente, Ricercatore, Dottorando, …)
  • supportRole: ruoli di supporto (Tecnico amministrativo, Collaboratore, Dirigenti…)
  • functionRole: funzioni (Direttore di Dipartimento, …)
  • teachingRole: ruoli di didattica (Professore a Contratto, …)

Le tipologie sopra elencate sono TUTTE E SOLE quelle utilizzabili per le unità organizzative usate come FK_POSITION_TYPE.

I ruoli che hanno delle ricadute sull’utilizzo della piattaforma IRIS sono:

  • researchRole
  • supportRole

Gli altri due (functionRole e teachingRole) invece vengono previsti per completezza e per eventuali sviluppi futuri.

2.9.3 FK_ORG_UNIT

In questa colonna deve essere specificato il riferimento ad un’unità organizzativa come dipartimento, divisione, matricola… Le tipologie di unità organizzative consentite sono tutte quelle presenti nella tabella E_RM_ORG_UNIT_TYPE (cfr. Excel allegato org-unit-type.xls) AD ECCEZIONE di:

  • researchRole
  • supportRole
  • functionRole
  • teachingRole

Questo perché le tipologie di cui sopra sono ad uso esclusivo della colonna FK_POSITION_TYPE descritta in precedenza.

Tra le tipologie di unità organizzative utilizzabili nella colonna FK_ORG_UNIT abbiamo anche le seguenti:

  • researchTitle: qualifiche di ricerca (Ricercatore Confermato, Professore Associato Confermato, Professore Ordinario, …)
  • supportTitle: qualifiche di supporto (Area Tecn., Tecn.Sc., Elaborazione Dati, …)
  • functionTitle
  • teachingTitle

Queste tipologie (denominate qualifiche, profili, titoli) sono strettamente legate ai ruoli: forniscono una classificazione più fine fatta a partire dai ruoli. Ad esempio per il ruolo “Ricercatore” come qualifiche potrebbero essere associate “Ricercatore Confermato”, “Ricercatore a tempo determinato” e così via.

Le qualifiche devono rispettare i seguenti vincoli di coerenza:

SE

FK_POSITION_TYPE specifica unità organizzativa di tipo “researchRole”

ALLORA

la qualifica (se prevista) DEVE RICADERE nella tipologia “researchTitle”

Il vincolo sopra riportato deve essere replicato per gli altri ruoli (supportRole, functionRole, teachingRole).

2.9.4 START_DATE

In questa colonna DEVE essere specificata la data (non nulla) di inizio validità della tripla (FK_PERSON, FK_POSITION_TYPE, FK_ORG_UNIT).

2.9.5 END_DATE

In questa colonna può essere specificata la data di fine validità della tripla (FK_PERSON, FK_POSITION_TYPE, FK_ORG_UNIT).
Se la colonna non è valorizzata allora si intendono correntemente valide le informazioni fornite dalla tripla.

2.9.6 PRIORITY

In questa colonna viene specificato il peso della tripla (FK_PERSON, FK_POSITION_TYPE, FK_ORG_UNIT).
Viene data priorità a record con valore numerico maggiore.
Questo valore è obbligatorio SOLO in presenza di rapporti di lavoro contemporanei sulle tipologie di ruoli researchRole e supportRole. Viene utilizzato per la selezione della tripla prioritaria da utilizzare.

A titolo di esempio considerare il seguente esempio riepilogativo per la gestione delle posizioni di carriera.

Supporre di aver caricato in I_RM_PERSON la seguenti riga:

ID

FIRST_NAME

LAST_NAME

XYZ

MARIO

ROSSI

Supporre di aver caricato in I_RM_ORG_UNIT le seguenti righe:

ID

DESCRIPTION

FK_ORG_UNIT_TYPE

1544

Dottorando

1

1371

Tecnico Amministrativo

101

5121

Area Tecnica

102

5122

Area Amministrativa

102

DIP22

Dipartimento di Fisica

51

DIP23

Dipartimento di Matematica

51

DOT-032888

032888

5

TA-A52454

A52454

5

Considerato che in E_ORG_UNIT_TYPE sono presenti le seguenti righe:

ID

DESCRIPTION

1

researchRole

101

supportRole

2

researchTitle

102

supportTitle

5

identificationNumber

51

department

Possiamo inserire i seguenti record in I_RM_POSITION:

FK_PERSON

FK_POSITION_TYPE

FK_ORG_UNIT

START_DATE

END_DATE

PRIORITY

XYZ

1544

DIP22

15/01/2015

15/01/2016

5

XYZ

1544

DOT-032888

15/01/2015

15/01/2016

5

XYZ

1371

5121

01/01/2015

 

2

XYZ

1371

DIP23

30/04/2015

 

2

XYZ

1371

TA-A52454

01/01/2015

 

2

XYZ

1371

5122

01/01/2014

31/12/2014

2

XYZ

1371

DIP23

01/01/2014

31/12/2014

2

XYZ

1371

TA-A52454

01/01/2014

31/12/2014

2

In linguaggio naturale, Mario Rossi ha:

Una posizione chiusa

  • Tecnico Amministrativo con matricola A52454, con qualifica Area Amministrativa e afferenza al Dipartimento di Matematica (DIP23)

Due posizioni attive

  • Dottorando con matricola 032888, senza qualifica e afferenza al Dipartimento di Fisica (DIP22)
  • Tecnico Amministrativo con matricola A52454, con qualifica Area Tecnica e afferenza al Dipartimento di Matematica (DIP23)

Notare che per la posizione aperta come Tecnico Amministrativo, la data di inizio afferenza al Dipartimento di Matematica (DIP23) è successiva alle altre informazioni per lo stesso ruolo di Tecnico Amministrativo.
Ovviamente questa è una situazione degenere ma viene fornito comunque esempio per chiarire l’indipendenza temporale delle varie informazioni.

Siccome le due posizioni attive sono contemporanee, viene fornito anche il peso per potere individuare i record prioritari che sono quelli associati al ruolo di Dottorando.
Quindi nel caso in cui sia necessario estrarre il dipartimento di afferenza attuale di Mario Rossi, utilizzando il peso, verrà fornito come risultato il Dipartimento di Fisica (DIP22).

2.9.7 IRIS_GENERATED

Questa colonna viene usata per marcare i record nella tabella I_RM_POSITIION generati direttamente da IRIS inferendoli dalla gerarchia delle strutture.
Se ad esempio la struttura X risulta essere figlia di Y e una persona risulta avere una posizione lavorativa sulla struttura X, IRIS inferisce anche la posizione sulla struttura Y con stesso intervallo temporale di validità della struttura X: questo solo nel caso in cui NON siano già presenti posizioni sulla struttura Y.

La logica di inferenza delle posizioni NON VALE per le strutture della tipologia other.

2.10 I_E_LOCK

Questa tabella è funzionale alla procedura di sincronizzazione: il suo utilizzo viene descritto in dettaglio nel paragrafo successivo.
Sono previste le seguenti colonne:

NOME CAMPO

DESCRIZIONE

OBBLIGATORIO

NAME

Nome univoco del lock

SI

LAST_ACQUIRE_ACTOR

 

Stringa dell’ultimo ”attore” che ha acquisito il lock

SI

LAST_ACQUIRE_TIMESTAMP

Timestamp di ultima acquisizione del lock

SI

LAST_RELEASE_TIMESTAMP

Timestamp di ultimo rilascio del lock

SI

ACQUIRED

Flag indicante lo stato di acquisizione  del lock (0/1)

SI

3 Procedura di sincronizzazione

La procedura di sincronizzazione delle anagrafiche tramite DB di frontiera prevede di effettuare un reload di tutte le informazioni in IRIS RM con cadenza configurabile (massimo 3 volte al giorno).

Tale job (laddove applicabile) sarà disponibile nella console JENKINS di Cineca sotto il nome

iris-ie-rm-sync-job-<CUSTOMER>-<ENVIRONMENT>

dove CUSTOMER indica il cliente e ENVIRONMENT indica l’ambiente (prod, preprod, …)

3.1 ISOLAMENTO

Lo schema del DB di frontiera descritto nel paragrafo precedente deve essere accessibile in lettura/scrittura sia da IRIS che dai SI del cliente che possono essere visti come i due attori della sincronizzazione.

Per isolare gli accessi al DB da parte dei due attori deve essere utilizzata la tabella I_E_LOCK descritta in precedenza.

In dettaglio vengono elencati gli step da compiere PRIMA di effettuare qualsiasi operazione di scrittura sul DB di frontiera:

  • lock della tabella I_E_LOCK in modalità esclusiva
    Se il lock NON viene acquisito si attende che l’attore correntemente in possesso del lock, termini le operazioni in corso.
    Se il lock viene acquisito allora si prosegue con il passo successivo.
  • aggiornamento dei campi
    • LAST_ACQUIRE_ACTOR: <stringa identificativa dell’attore>
    • LAST_ACQUIRE_TIMESTAMP: sysdate
    • LAST_RELEASE_TIMESTAMP: null
    • ACQUIRED:1

del record con NAME=’IRIS_RM_SYNC_LOCK’

Dopo avere ultimato le operazioni in scrittura sul DB di frontiera devono essere seguiti i seguenti step:

  • aggiornamento dei campi
    • ACQUIRED: 0
    • LAST_RELEASE_TIMESTAMP: sysdate

del record con NAME=’IRIS_RM_SYNC_LOCK’

3.2 PROFILI UTENTI DI DEFAULT

La procedura effettua automaticamente l’associazione degli utenti ai team:

  • Utenti
  • Utenti ricercatori, se in I_RM_POSITION  l’utente ha un record on un FK_POSITION_TYPE relativo ad una ORG_UNIT che ricade nella tipologia researchRole
  • Utenti di supporto, se in  I_RM_POSITION  l’utente ha un record on un FK_POSITION_TYPE relativo ad una ORG_UNIT che ricade nella tipologia supportRole

L’eventuale disabilitazione di questa associazione deve essere fatta da un altro job da eseguire successivamente all’allineamento anagrafiche.

3.3 ALLINEAMENTO RM2ES

Al termine dell’esecuzione della procedura di sincronizzazione deve essere lanciata la procedura di allineamento RM2ES. Accertarsi che questo job sia schedulato DOPO il job di allineamento anagrafiche.

3.4 GESTIONE DEGLI ERRORI

3.4.1 ERRORI DI SISTEMA

Nel caso in cui JENKINS rilevi un errore viene inviata comunicazione via mail al team di assistenza tecnica.
Tra le condizioni che possono causare quest’errore c’è anche il non ottenimento del lock, descritto al §3.1.
I job che insistono sul DB di frontiera (sia quello di IRIS che quello del cliente) dovrebbero essere schedulati in intervalli temporali disgiunti: nel caso in cui ci sia una collisione temporale potrebbe venire generato un errore sul non ottenimento del lock. In questo caso basterà schedulare in maniera opportuna i due job.

Il job di sincronizzazione di IRIS prevede un meccanismo automatico di recovery che prevede  di acquisire il lock anche se risulta essere occupato da qualcun altro nel caso in cui il lock sia stato acquisito e non rilasciato da più di 24 ore.

3.4.2 ERRORI DI VALIDITA’ DEI DATI

La procedura di sincronizzazione prevede di effettuare dei check di validità sui dati presenti sul DB di frontiera prima di procedere al caricamento in IRIS RM.

Se un record di una tabella di frontiera non supera i check di validità, il relativo campo ERROR verrà marcato con il codice di errore descrittivo associato.

La procedura di sincronizzazione procede con il caricamento dei SOLI dati che hanno superato i check di validità.
Al termine della procedura, qualora vengano rilevati dei record che non superano i check di validità, verrà inviata una mail ai referenti dei Sistemi Informativi del cliente con un file Excel che riporta il dettaglio dei record errati.

3.4.3 CODICI DI ERRORE CONTEMPLATI

Di seguito vengono riportati i vari codici di errore che possono essere restituiti dalla procedura di sincronizzazione.

Tutti i codici seguono il seguente formato:

<NOME_TABELLA>: <CODICE_ERRORE>:

I_RM_PERSON: NULL FIRST_NAME OR LAST_NAME
Individuata persona con FIRST_NAME o LAST_NAME nullo

I_RM_PERSON_DATA: INVALID DISCRIMINATOR
È stato individuato un record con un DISCRIMINATOR NON VALIDO. Gli unici discriminator validi sono:

  • 'birthDate'
  • 'birthCountryId'
  • 'birthPlaceId'
  • 'birthPlaceString'
  • 'gender'
  • 'codiceFiscale'

I_RM_PERSON_DATA: NULL VALUE
È stato individuato un record con un STRING_VALUE nullo

I_RM_PERSON_DATA: INVALID BIRTH_DATE
È stato individuato un record con una data che non rispetta il formato DateTime (YYYY-MM-DDThh:mm:ss)

I_RM_PERSON_DATA: INVALID BIRTH_COUNTRY_ID
È stato individuato un record con una codice non recuperabile da ISO_3166-1 Alpha-2

I_RM_PERSON_DATA: INVALID BIRTH_PLACE_ID
È stato individuato un record con una codice catastale non valido

I_RM_PERSON_DATA: INVALID GENDER

È stato individuato un record con sesso non valido

I_RM_PERSON_DATA: INVALID CODICE_FISCALE
È stato individuato un record con codice fiscale non valido

I_RM_PERSON_DATA: DUPLICATE INFO
Sono stati individuati record con informazione duplicata

I_RM_ORG_UNIT: NULL FK_ORG_UNIT_TYPE
È stato individuato un record con FK_ORG_UNIT_TYPE nullo

I_RM_ORG_UNIT: NULL DESCRIPTION
È stato individuato un record con DESCRIPTION nulla

I_RM_ORG_UNIT: NULL START_DATE
È stato individuato un record con START_DATE nulla

I_RM_ORG_UNIT: INCOMPATIBLE DATE
È stato individuato un record con START_DATE e END_DATE non consistenti

I_RM_ORG_UNIT_LINK: INVALID DISCRIMINATOR
È stato individuato un record con DISCRIMINATOR non valido. L'unico valido è 'parent'

I_RM_ADDRESS: INVALID DISCRIMINATOR
È stato individuato un record con DISCRIMINATOR non valido. L'unico valido è 'office'

I_RM_ADDRESS: INVALID COUNTRY_ID
È stato individuato un record con una codice non recuperabile da ISO_3166-1 Alpha-2

I_RM_ADDRESS: INVALID PLACE_ID OR PLACE_STRING
È stato individuato un record che presenta entrambi popolati o entrambi nulli i campi PLACE_ID e PLACE_STRING

I_RM_ADDRESS: INVALID PLACE_ID
È stato individuato un record con una codice catastale non valido

I_RM_ADDRESS: NULL DESCRIPTION
È stato individuato un record con DESCRIPTION nulla

I_RM_ADDRESS: INVALID PRINCIPAL
È stato individuato un record con PRINCIPAL nullo o con valore diverso da 0 e 1

I_RM_ADDRESS: INVALID FK_ORG_UNIT OR FK_PERSON
È stato individuato un record che presenta entrambi popolati o entrambi nulli i campi FK_ORG_UNIT e FK_PERSON

I_RM_CONTACT: INVALID DISCRIMINATOR
È stato individuato un record con un DISCRIMINATOR NON VALIDO. Gli unici discriminator validi sono:

  • 'mail'
  • 'phone'
  • ’mobile'
  • 'web'

I_RM_CONTACT: INVALID DESCRIPTION
È stato individuato un record con DESCRIPTION nulla

I_RM_CONTACT: INVALID MAIL FORMAT
È stato individuato un record con indirizzo mail non valido

I_RM_CONTACT: INVALID PRINCIPAL
È stato individuato un record con PRINCIPAL nullo o con valore diverso da 0 e 1

I_RM_CONTACT: INVALID FK_ORG_UNIT OR FK_PERSON
È stato individuato un record che presenta entrambi popolati o entrambi nulli i campi FK_ORG_UNIT e FK_PERSON

I_RM_POSITION: INVALID FK_POSITION_TYPE
È stato individuato un record che presenta il campo FK_POSITION_TYPE che punta ad una ORG_UNIT non valida.
Le tipologie di ORG_UNIT valide per questo campo sono SOLO:

  • 'researchRole'
  • 'supportRole'
  • 'functionRole'
  • 'teachingRole'

I_RM_POSITION: INVALID FK_ORG_UNIT
È stato individuato un record che presenta il campo FK_ORG_UNIT che punta ad una ORG_UNIT non valida.
Le tipologie di ORG_UNIT valide per questo campo sono tutte quelle che NON RICADONO in:

  • 'researchRole'
  • 'supportRole'
  • 'functionRole'
  • 'teachingRole'

I_RM_POSITION: INVALID FK_ORG_UNIT_FOR_FK_POSITION_TYPE
È stato individuato un record che presenta dati non validi per i campi FK_ORG_UNIT e FK_POSITION_TYPE
Per maggiori dettagli fare riferimento al §2.9.3

I_RM_POSITION: INVALID DATE
È stato individuato un record che presenta START_DATE successiva alla END_DATE

I_RM_ORG_UNIT_LINK: TOO_MANY_LINKS
È stata individuata una gerarchia troppo profonda. Il numero massimo di livelli consentiti è 5.
Il caricamento della gerarchia è completamente disabilitato.

I_RM_ORG_UNIT_LINK: VIOLATED HIERARCHICAL CONSTRAINT FOR department
Sono state individuate strutture di tipo department che hanno strutture padre o figlie il cui tipo non ricade rispettivamente in  superdepartment, subdepartment. Per maggiori dettagli fare riferimento al §2.5
Il caricamento della gerarchia è completamente disabilitato.

I_RM_ORG_UNIT_LINK: VIOLATED HIERARCHICAL CONSTRAINT FOR superdepartment
Sono state individuate strutture di tipo superdepartment che hanno strutture padre (di qualsiasi tipo) o che hanno strutture figlie il cui tipo non ricade in  department. Per maggiori dettagli fare riferimento al §2.5.
Il caricamento della gerarchia è completamente disabilitato.

I_RM_ORG_UNIT_LINK: VIOLATED HIERARCHICAL CONSTRAINT FOR subdepartment
Sono state individuate strutture di tipo subdepartment che hanno strutture figlie (di qualsiasi tipo) o che hanno strutture padre il cui tipo non ricade in department. Per maggiori dettagli fare riferimento al §2.5.
Il caricamento della gerarchia è completamente disabilitato.

I_RM_ORG_UNIT_LINK: ORG_UNIT_TYPE NOT UNIQUE DETECTED IN HIERARCHY
È stata rilevata una gerarchia all’interno della quale ci sono più volte strutture della stessa tipologia.
Questo utilizzo è consentito SOLO per la tipologia other.
Il caricamento della gerarchia è completamente disabilitato.

I_RM_ADDRESS: DUPLICATED PRINCIPAL ADDRESS
Sono stati individuati più indirizzi marcati come principali.

I_RM_CONTACT: DUPLICATED PRINCIPAL CONTACT
Sono stati individuati più contatti marcati come principali.

I_RM_ADDRESS: ADDRESS PRINCIPAL NOT SPECIFIED
Non è stato trovato indirizzo principale

I_RM_CONTACT: CONTACT PRINCIPAL  NOT SPECIFIED
Non è stato trovato contatto principale

I_RM_POSITION: OVERLAPPING WITHOUT PRIORITY OR EQUAL PRIORITY
Sono stati rilevati record con sovrapposizioni temporali senza priorità specificata o priorità uguale

I_RM_USER: USERNAME COLLISION BETWEEN SYSTEM MANAGED AND USER MANAGED
È stato rilevato un tentativo di caricamento di uno username già presente in IRIS che è stato caricato manualmente da un operatore.
Procedere all'eliminazione in IRIS dello username in questione dopo avere eventualmente salvato il profilo dell'utente.

I_RM_USER: USERNAME admin NOT ALLOWED
È stato rilevato un tentativo di caricamento dello username admin: non è possibile caricare questo username.

I_RM_ADDRESS: ADDRESS BELONGING TO PERSON OR ORG_UNIT IN ERROR

I_RM_CONTACT: CONTACT BELONGING TO PERSON OR ORG_UNIT IN ERROR

I_RM_USER: USERNAME BELONGING TO PERSON IN ERROR

I_RM_ORG_UNIT_LINK: LINK BELONGING TO ORG_UNIT IN ERROR

I_RM_PERSON_DATA: DATA BELONGING TO PERSON IN ERROR

I_RM_POSITION: USE INVALID PERSON OR ORG_UNIT

Sono stati rilevati record relativi ad entità che sono in uno stato invalido a seguito di un precedente check di validità.

 

  • No labels