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:

2.2 I_RM_PERSON_DATA

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

La tabella prevede le seguenti colonne:

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

2.3 I_RM_USER

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

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:

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:

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.

2.6 I_RM_ORG_UNIT_LINK

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

Considerare, a titolo di esempio, il seguente record.

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:

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:

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:

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:

Supporre di aver caricato in I_RM_ORG_UNIT le seguenti righe:

Considerato che in E_ORG_UNIT_TYPE sono presenti le seguenti righe:

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.
Sono previste le seguenti colonne:

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à.