Source: https://wiki.u-gov.it/confluence/pages/releaseview.action?pageId=76101376
Timestamp: 2018-06-22 20:43:10+00:00

Document:
IRIS-IE (IRIS Import/Export) - UGOV - Help utente - CINECA Technical Portal
IRIS-IE (IRIS Import/Export)
Created by Unknown User (m.vaira@cineca.it), last modified by Chiara Aurora Molinaro on Jun 27, 2016
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>
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>
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:
Identificativo UNIVOCO della persona nei SI sorgenti
Questo è l’identificativo che verrà utilizzato per effettuare le operazioni di mappatura tra SI sorgenti e IRIS.
Usato per check di validità
2.2 I_RM_PERSON_DATA
Questa tabella raccoglie informazioni aggiuntive (NON OBBLIGATORIE) sulle persone, di seguito elencate.
CLASSIFICAZIONE O FORMATO
XML DateTime
Il format DateTime è specificato nella seguente forma:
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
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
Gli unici valori consentiti sono M o F
Il codice fiscale DEVE essere valido
La tabella prevede le seguenti colonne:
FK_PERSON
Chiave esterna verso I_RM_PERSON
Tipologia di informazione aggiuntiva
I valori accettabili per questo campo sono uno di quelli elencati lista precedente:
- birthCountryId
- birthPlaceId
- birthPlaceString
- codiceFiscale
A titolo esemplificativo considerare il seguente esempio.
Supponiamo di avere già caricato la persona MARIO ROSSI di identificativo XYZ nella tabella I_RM_PERSON.
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
MRORSS70B25A691H
1970-10-15T00:00:00
2.3 I_RM_USER
Questa tabella raccoglie informazioni sugli utenti.
Username utilizzato per autenticazione
UNIVOCITA’ dello username
LDAP Distinguished Name nel caso di utilizzo di autenticazione LDAP
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).
Identificativo UNIVOCO dell’unità organizzativa nei SI sorgenti.
Questo è l’identificativo che verrà utilizzato per effettuare le operazioni di mappatura tra SI sorgenti e IRIS
Denominazione dell’unità organizzativa
Data di attivazione dell’unità organizzativa
Data di cessazione dell’unità organizzativa
FK_ORG_UNIT_TYPE
Chiave esterna verso E_RM_ORG_UNIT_TYPE
Ogni unità organizzativa DEVE essere mappata sulle tipologie di unità di IRIS
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:
Identificativo UNIVOCO della tipologia di unità organizzativa in IRIS
Nome breve della tipologia di unità organizzativa
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)
identificationNumber: indica una matricola
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.
supportRole: indica un ruolo di supporto (ad esempio Non Docente di ruolo)
supportTitle: indica una qualifica di supporto (ad esempio Area Biblioteche)
administrativeArea: indica un’area amministrativa
Strutture di questo tipo possono avere legami gerarchici con altre strutture
administrativeSector: indica un settore amministrativo
office: indica un ufficio
other: indica un’altra struttura che non rientra in nessuna delle categorie precedenti
Di tutte le tipologie di strutture elencate quelle FONDAMENTALI, per il personale che si occupa di ricerca sono:
researchRole
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.
2.6 I_RM_ORG_UNIT_LINK
Questa tabella raccoglie i legami tra unità organizzative.
Al momento attuale sono gestiti solo i legami gerarchici.
FK_ORG_UNIT_1
Chiave esterna verso I_RM_ORG_UNIT
L’unico valore accettabile è:
Considerare, a titolo di esempio, il seguente record.
FK_ORG_UNIT_2
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).
Tipologia di indirizzo
Gli unici valori accettabili sono:
Identificativo nazione
Identificativo del paese/città
Deve essere popolato alternativamente a PLACE_STRING.
Da usare per i comuni italiani
PLACE_STRING
Nome del paese/città
Deve essere popolato alternativamente a PLACE_ID. Da usare per i paesi/città non italiani
Indirizzo completo di via/piazza e numero civico
Flag indirizzo principale per tipologia (discriminator)
1 = indirizzo principale
0 = indirizzo NON principale
FK_ORG_UNIT
Deve essere popolato alternativamente a FK_PERSON
Deve essere popolato alternativamente a FK_ORG_UNIT
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).
Flag contatto principale per tipologia (discriminator)
1 = contatto principale
0 = contatto NON principale
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.
Cfr §2.9.1
FK_POSITION_TYPE
Cfr §2.9.2
Cfr §2.9.3
Cfr §2.9.4
Cfr §2.9.5
Peso del rapporto di lavoro
Cfr §2.9.6
IRIS_GENERATED
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:
Presidente di CdL
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:
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:
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, …)
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:
FK_POSITION_TYPE specifica unità organizzativa di tipo “researchRole”
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:
Supporre di aver caricato in I_RM_ORG_UNIT le seguenti righe:
DOT-032888
TA-A52454
A52454
Considerato che in E_ORG_UNIT_TYPE sono presenti le seguenti righe:
supportTitle
Possiamo inserire i seguenti record in I_RM_POSITION:
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.
Nome univoco del lock
LAST_ACQUIRE_ACTOR
Stringa dell’ultimo ”attore” che ha acquisito il lock
LAST_ACQUIRE_TIMESTAMP
Timestamp di ultima acquisizione del lock
LAST_RELEASE_TIMESTAMP
Timestamp di ultimo rilascio del lock
Flag indicante lo stato di acquisizione del lock (0/1)
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.
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:
LAST_RELEASE_TIMESTAMP: sysdate
3.2 PROFILI UTENTI DI DEFAULT
La procedura effettua automaticamente l’associazione degli utenti ai team:
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'
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
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
I_RM_ADDRESS: NULL DESCRIPTION
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
’mobile'
I_RM_CONTACT: INVALID DESCRIPTION
I_RM_CONTACT: INVALID MAIL FORMAT
È stato individuato un record con indirizzo mail non valido
I_RM_CONTACT: INVALID PRINCIPAL
I_RM_CONTACT: INVALID FK_ORG_UNIT OR 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:
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
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.
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.
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.
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à.
{"serverDuration": 332, "requestCorrelationId": "9ecd84467cf89c7d"}

References: §2
 §2
 §2
 §2
 §2
 §2
 §2
 §3
 §2
 §2
 §2
 §2