Les imports de lecteurs – Blog du RéBUB

Table des matières[ Show ]

Périmètre des données fournie et sources utilisées
Mode de fourniture des données
1. Règle de nommage des fichiers
2. Structure du fichier xml
Données exploitées
Mappings nécessaires

Table des matières[ Show ]

Périmètre des données fournie et sources utilisées
Mode de fourniture des données
1. Règle de nommage des fichiers
2. Structure du fichier xml
Données exploitées
Mappings nécessaires

Le principe général est d’essayer de couvrir par l’import automatique la plus grande partie de la population à desservir.

Périmètre des données fournie et sources utilisées

A chaque chargement tous les comptes du périmètre devront être fournis et non uniquement les comptes mis à jour.

Pour les étudiants

Tout étudiant ayant une inscription valide pour l’année universitaire en cour dans un des établissements du réseau bordelais. Si la carte Aquipass n’est pas activée (ie l’étudiant n’a pas été cherché sa carte) le compte du lecteur peut être transmis sans code à barres (ALMA accepte des comptes sans code-barres).

Pour l’UB Les identités étudiantes des personnes préparant un HDR et travaillant pour l’UB ne sont pas envoyées.

Pour les personnels

Personnels gérés ou hébergés¹⁾ par les établissements du réseau.

Pour l’UB les comptes des personnels aussi inscrits en doctorat ne sont pas envoyés.

Sources utilisés

Etablissement	Etudiants	Hébergés	Personnels	Extérieurs
Université de Bordeaux	LDAP Apogée (étudiants à jour de leur inscription uniquement)	LDAP Grouper	LDAP Mangue	A confirmer
Université Bordeaux Montaigne	LDAP Apogée (étudiants à jour de leur inscription uniquement)		LDAP Mangue	A confirmer
Sciences Po Bordeaux	LDAP Apogée (étudiants à jour de leur inscription uniquement)		LDAP Mangue	A confirmer
Bordeaux Sciences Agro	Base élèves		LDAP Mangue	A confirmer
Bordeaux INP	LDAP Apogée (étudiants à jour de leur inscription uniquement)		LDAP Mangue	A confirmer

Mode de fourniture des données

Les données doivent être transmises à Alma dans des fichiers xml encodés en utf8 regroupés dans des fichiers zip. Nous proposons de réaliser un fichier par type de population (étudiants, personnels et hébergés) et une archive par établissement.

Attention ! La taille d’une archive ne peut pas dépasser 4 GB.

Chaque établissement est responsable de la fourniture des données au format attendu par Alma. Les fichiers doivent être déposé sur un serveur sftp de l’UB. [A préciser]

Règle de nommage des fichiers

Pour les archives : [Date du jour de l’opération d’extraction au format AAAAMMJJ] code_etablissement + _LecteursBibliotheques.zip
Pour les fichiers xml :
- Pour les étudiants : [Date du jour de l’opération d’extraction au format AAAAMMJJ] code_etablissement + _LecteursEtudiants.zip
- Pour les personnels : [Date du jour de l’opération d’extraction au format AAAAMMJJ] code_etablissement + _LecteursPersonnels.zip
- Pour les hébergés : [Date du jour de l’opération d’extraction au format AAAAMMJJ] code_etablissement + _LecteursHeberges.zip

Structure du fichier xml

Le schéma est défini dans les deux fichiers xsd téléchargeables à ces adresses :

Données exploitées

Block	Champ	Champ source	Obligatoire	Répétable	Donnée attendue	Usage prévu
user	primary_id	LDAP : eduPersonPrincipalName (UB)	VRAI	FAUX	EPPN²⁾ </sup>	identifiant unique permettant aux usagers de s’authentifier dans l’outil public pour accéder au service (authentification via Shibboleth)
	first_name	LDAP : givenName (UB)	VRAI	FAUX	prénom	Pour s’adresser à l’usager dans les messages automatiques
	last_name	Personnels LDAP : sn (UB) Etudiants :nom patronymique(Apogée)	VRAI	FAUX	nom	Pour s’adresser à l’usager dans les messages automatiques
	pref_last_name	Etudiants :sn(LDAP)	VRAI	FAUX	nom	Pour s’adresser à l’usager dans les messages automatiques
	expiry_date	LDAP : étudiants : supanEtuAnneeInscription (UB) ⇒ 31-12-année 1 personnel : ubxDateFinValidite 2 mois (UB) ; si 0 , 31-12-année 1	FAUX	FAUX	date de fin de droit au format AAAA-MM-JJZ³⁾	L’application désactive automatiquement les compte à l’échéance de cette date – nous n’avons aucun besoin de connaître la raison de cette date de fin
	status	FIXE : ‘ACTIVE’	VRAI	FAUX	statut⁴⁾	permet la suppression des comptes et la désactivation d’usagers bloqués ailleurs dans le système (invalidation par la scolarité par exemple)
	preferred_language	FIXE : ‘fr’	VRAI	FAUX	langue de communication de l’usager⁵⁾	Permet l’activation de la langue de communication avec l’usager dans les interfaces et les messages.
	job_category	FIXE : selon la source	FAUX	FAUX	pour définir des types d’usager : – pour compte étudiant, mettre ‘Etudiant’ – Pour comptes personnel mettre ‘Personnel’ – pour compte extérieurs nous mettrons ‘Extérieur’	A usage volumétrique et statistique uniquement
	user_group	APOGEE à préciser user_groups	VRAI	FAUX	user_groups	Sert à définir les droits de prêt des usagers
	campus_code (Pour UB uniquement !)	APOGEE : UFR ETAPE inscription principale (calcul selon campus) LDAP (Personnels) : supannEntiteAffectation campus	FAUX	FAUX	Table de mapping plus bas dans cette page	Sert à définir le campus d’un usager pour l’affichage des ressources réservées à sa discipline
	user_identifiers		FAUX	FAUX	bloc_user_identifiers
	contact_info		FAUX	FAUX	bloc_contact_info
	user_statistics		FAUX	FAUX	bloc_user_statistics

Bloc user_identifiers

Ce bloc contient tous les identifiants de l’utilisateur en dehors de l’EPPN fourni dans le bloc user. Nous ne récupérerons que l’identifiant UNA et le code à barres de la carte Aquipass de l’individu. En cas d’absence de ces deux identifiants supplémentaires le bloc user_identifiers n’est pas créé.

Block	Champ	Champ source	Obligatoire	Répétable	Donnée attendue	Usage prévu
user_identifier⁶⁾	id_type	FIXE : ‘BARCODE’	VRAI	FAUX	BARCODE	Le code barre est le principal moyen d’identification d’un lecteur
	status	FIXE : ‘ACTIVE’	VRAI	FAUX	ACTIVE
	value	LDAP : ubxNumeroDeCarte (UB)	VRAI	FAUX	Le code barre Aquipass de l’usager
userIdentifier⁷⁾	id_type	FIXE : ‘UNA_ID’	VRAI	FAUX	UNA_ID	Pour préparer le jour où nous aurons tous des id UNA
	status	ACTIVE	VRAI	FAUX	ACTIVE
	Value	LDAP : ubxLoginUna préfixé par UB_	VRAI	FAUX	numéro UNA préfixé par le code établissement de la source (impossible dans Alma d’avoir le même identifiant pour 2 comptes différents)
userIdentifier⁸⁾	id_type	FIXE : ‘INE’	VRAI	FAUX	INE	Afin de rapprocher un compte saisi manuellement (cas des étudiants n’ayant pas encore d’inscription) d’un compte issu du SI
	status	ACTIVE	VRAI	FAUX	ACTIVE
	Value	INE	VRAI	FAUX	INE

Bloc contact_info

Ce bloc contient toutes les informations de contact de l’individu.

Block	Champ	Obligatoire	Répétable	Donnée attendue	Usage prévu
contact_info	addresses	FAUX	FAUX	Liste des adresses physiques de l’individu : – Pour les étudiants adresses personnelles et des parents – Pour les personnels : adresse professionnelle	Les adresses servent à l’impression des courriers de relance et de contentieux en cas de long retard – ce courrier est envoyé à l’adresse des parents des étudiants une fois le mois de mai passé pour éviter les retours postaux
	emails	FAUX	FAUX	Liste des adresses emails de l’utilisateur : adresses institutionnelles uniquement.	Utilisé par le système pour l’envoi de messages automatiques : situations de prêt, ticket de transaction, messages de rappel, signalement de retard (début procédure), document demandé arrivé…
	phones	FAUX	FAUX	Lisse des numéros de téléphones de l’individu	Vérification d’identité en cas de demande de service par téléphone et appel direct de l’usager pour certains services (PEB enseignant dans certaines structures) ou en cas de perte d’objets importants à la bibliothèque (carte identité, carte bancaire)

Bloc addresses

Ce bloc contient toutes les adresses postales de l’individu. A savoir l’adresse personnelle et des parents pour un étudiant et l’adresse professionnelle pour un personnel. Si aucune adresse postale n’est fournie ce bloc n’est pas créé.

Block	Block	Champ	Champ source	Obligatoire	Répétable	Donnée attendue
addresses	address(personnelle pour les étudiants ) Attribut preferred=“true”	line1	APOGEE	FAUX	FAUX
		line2	APOGEE	FAUX	FAUX
		line3	APOGEE	FAUX	FAUX
		city	APOGEE	FAUX	FAUX
		postal_code	APOGEE	FAUX	FAUX
		country	APOGEE	FAUX	FAUX	Code ISO 3166 sur 3 caractères
		start_date	LDAP : étudiants : supanEtuAnneeInscription (UB) ⇒ 01-09-année	FAUX	FAUX	uniquement pour étudiants
		end_date	LDAP : étudiants : supanEtuAnneeInscription (UB) ⇒ 30-04-année 1	FAUX	FAUX	uniquement pour étudiants
		address_types/address_type	FIXE : ‘home’	VRAI	VRAI	ne donner qu’un type – si étudiant, addresse des parents : ‘fixe’ – si étudiant, adresse de l’étudiant ‘annuel’ – si professionnel : ‘professionnelle’
	address(des parents pour les étudiants )	line1	APOGEE	FAUX	FAUX
		line2	APOGEE	FAUX	FAUX
		line3	APOGEE	FAUX	FAUX
		city	APOGEE	FAUX	FAUX
		postal_code	APOGEE	FAUX	FAUX
		country	APOGEE	FAUX	FAUX	Code ISO 3166 sur 3 caractères
		address_types/address_type	FIXE : ‘alternative’ pour adresse parents	VRAI	VRAI	ne donner qu’un type – si étudiant, addresse des parents : ‘fixe’ – si étudiant, adresse de l’étudiant ‘annuel’ – si professionnel : ‘professionnelle’
	adress(professionnelle pour les personnels ) Attribut preferred=“true”	line1	MANGUE	FAUX	FAUX
		line2	MANGUE	FAUX	FAUX
		line3	MANGUE	FAUX	FAUX
		city	MANGUE	FAUX	FAUX
		postal_code	MANGUE	FAUX	FAUX
		country	MANGUE	FAUX	FAUX	Code ISO 3166 sur 3 caractères
		address_types/address_type	FIXE : ‘work’ pour les personnels	VRAI	VRAI	ne donner qu’un type – si étudiant, addresse des parents : ‘fixe’ – si étudiant, adresse de l’étudiant ‘annuel’ – si professionnel : ‘professionnelle’

Bloc emails

Ce bloc contient les adresses mails de l’individu. Pour l’instant seules les adresses institutionnelles sont récupérées mais l’ajout du mail personnel est à étudier. Si aucune adrresse mail n’est fournie ce bloc n’est pas créé.

Block	Block	Champ	Champ source	Obligatoire	Répétable	Donnée attendue	Commentaire
emails	email Attribut preferred=“true”	email_address	LDAP : mail (UB)	VRAI	FAUX	le mail institutionnel	A étudier : ajout du mail perso pour les étudiant avec un type ‘personnel’ – il existe là aussi un attribut preferred à mettre à true uniquement pour les mails institutionnels
emails	email Attribut preferred=“true”	email_types/email_type	Fonction de la source : ‘school’ pour les étudiants ‘work’ pour les professionnels et hébergés	VRAI	VRAI	un seul type : ‘institutionnel’

Bloc phones

Ce bloc contient tous les numéros de téléphone de l’individu : le numéro de téléphone fixe et portable pour les étudiants et le numéro de téléphone professionnel pour les personnels. Si aucun numéro de téléphone n’est fourni ce bloc n’est pas créé.

Block	Block	Champ	Champ source	Obligatoire	Répétable	Donnée attendue	Commentaire
phones	phone (téléphone fixe pour les étudiants) ⁹⁾ )	phone_number	APOGEE : étudiants : numéro téléphone adresse fixe	VRAI	FAUX	Le numéro de téléphone	Utiliser le – comme séparateur / block à répéter autant de fois que de numéros renseigné par l’usager
	phone (téléphone fixe pour les étudiants) ⁹⁾ )	phone_types/phone_type	FIXE : ‘home’	VRAI	VRAI	un seul type par numéros – étudiant : ‘mobile’ ou ‘fixe’ selon le cas – professionel : ‘professionnel’
preferred=“true”	phone (téléphone portable pour les étudiants) ¹⁰⁾	phone_number	APOGEE : champ téléphone portable	VRAI	FAUX	Le numéro de téléphone	Utiliser le – comme séparateur / block à répéter autant de fois que de numéros renseigné par l’usager
preferred=“true”	phone (téléphone portable pour les étudiants) ¹⁰⁾	phone_types/phone_type	FIXE : ‘mobile’	VRAI	VRAI	un seul type par numéros – étudiant : ‘mobile’ ou ‘fixe’ selon le cas – professionel : ‘professionnel’
Attribut preferred=“true	phone (téléphone professionnel pour les personnels) ¹¹⁾	phone_number	LDAP : personnels : telephoneNumber	VRAI	FAUX	Le numéro de téléphone	Utiliser le – comme séparateur / block à répéter autant de fois que de numéros renseigné par l’usager
Attribut preferred=“true	phone (téléphone professionnel pour les personnels) ¹¹⁾	phone_types	FIXE : ‘office’	VRAI	VRAI	un seul type par numéros – étudiant : ‘mobile’ ou ‘fixe’ selon le cas – professionel : ‘professionnel’

Bloc user_statistics

Block	Block	Champ	Champ source	Obligatoire	Répétable	Donnée attendue	Commentaire
user_statistics	user_statistic(1)¹²⁾	statistic_category	APOGEE : niveau d’étude pour toutes les inscriptions en cour de l’individu BXSA Base élève : niveau dans le cursus (1A, 2A, 3A, Master MBS, Mastere, Bachelor,…) pour toutes les inscriptions en cour de l’individu valeure préfixée par BXSA BXSA Personnel : personnel ou enseignant	FAUX	VRAI	le niveau d’étude	Valeur à renseigner uniquement pour les étudiants – il s’agit d’un chiffre correspondant au nombre d’années après le BAC, pour les valeurs supérieures à 8, mettre 9 systématiquement / le champs est à répéter autant de fois que d’inscription administrative de l’étudiant
	user_statistic(1)¹²⁾	category_type	FIXE : ‘NIVEAU‘	FAUX	VRAI
	user_statistic (2)¹³⁾	statistic_category	APOGEE : etape pour toutes les inscriptions en cour de l’individu . A préfixer par le code établissement : code_etablissement + _ + Code étape	FAUX	VRAI	code étape	valeur à renseigner uniquement pour les étudiants : indiquer le code de l’ensembre des étapes des inscriptions valides de l’étudiant
	user_statistic (2)¹³⁾	category_type	FIXE : ‘ETAPE‘	FAUX	VRAI
	user_statistic (3)¹⁴⁾	statistic_category	APOGEE : code sise discipline pour toutes les inscriptions en cour de l’individu BXSA Base élève : spécialisation pour les 3eme année a préfixer par “BXSA_”.	FAUX	VRAI	code discipline SISE	valeur à renseigner uniquement pour les étudiants : indiquer le code de secteur disciplinaire de chaque inscription valide de l’étudiant
	user_statistic (3)¹⁴⁾	category_type	FIXE : ‘DISCIPLINE‘	FAUX	VRAI
	user_statistic (4)¹⁵⁾	statistic_category	APOGEE : UFR (UB : préfixé par UB_) LDAP : supannEntiteAffectation BXSA : service ou département A préfixer par le code établissement : code_etablissement + _ + Code affectation	FAUX	VRAI	UFR ou Affectation	indiquer le code composante de chaque inscription valide de l’étudiant pour les personnels, indiquer la composante d’appartenance du personnel (supannEntiteAffectation )
	user_statistic (4)¹⁵⁾	category_type	FIXE : ‘AFFECTATION‘	FAUX	VRAI
	user_statistic (5)	statistic_category	Selon la source d’import de l’usager : cf table des codes établissement	FAUX	VRAI	code établissement	selon la source d’import de l’usager : UB / UBM / INP / IEP / BXSA
	user_statistic (5)	category_type	FIXE : ‘ETABLISSEMENT‘	FAUX	VRAI
	user_statistic (6) ¹⁶⁾	statistic_category	MANGUE : cnu (UB)	FAUX	VRAI	code CNU	ne concerne que les enseignants chercheurs
	user_statistic (6) ¹⁶⁾	category_type	FIXE : ‘CNU‘	FAUX	VRAI

Mappings nécessaires

User groups

Ventilation des usagers

Etablissement	Source du compte	Niveau d’étude pour étudiant ou code cycle ¹⁷⁾	User Group
UB/UBM/INP	Apogée	bac 1 à bac 3	RESO-ETU-1
UB/UBM/INP	Apogée	bac 4 à bac 5	RESO-ETU-2
UB/UBM/INP	Apogée	bac 6 et au-delà	RESO-ETU-3
UB/UBM/INP/BxSA	LDAP Mangue	sans objet	RESO-PRO-1
Sciences Po	Apogée	cod_cyc=1 ou 2	SCPO-ETU-1
Sciences Po	Apogée	cod_cyc=3	SCPO-PRO-1 ¹⁸⁾
Sciences Po	LDAP Mangue	sans objet	SCPO-PRO-1
Bordeaux Sciences Agro	Base élève	sans objet	BXSA-ETU-1
Si erreur ou cas non -couvert			RESO-INV-1

Campus

Nous pouvons réutiliser le même mécanisme que pour l’attribution actuelle des divisions : la composantes dans la plupart des cas, l’étape parfois lorsque nécessaire pour différencier.

Etablissement	Etape	Composante	Code campus
BxSA			campus code inutile – ne pas fournir
IEP			campus code inutile – ne pas fournir
INP			campus code inutile – ne pas fournir
UB			1100000000
			1200000000
			1300000000
			1400000000
			1500000000
			1600000000
UBM			campus code inutile – ne pas fournir

Code établissement

Etablissement	Code établissement
Bordeaux sciences Agro	BXSA
Bordeaux INP	INP
Sciences Po Bordeaux	IEP
Université Bordeaux Montaigne	UBM
Université de Bordeaux	UB

¹⁾

selon les possibilités de chaque établissement

²⁾

Nous souhaitons utiliser l’ EPPN car c’est à ce jour le seule identifiant qui ne puisse pas être en doublon entre 2 institutions. De fait cela signifie qu’une même personne pourra avoir 2 identités dans le système

³⁾

c’est la date prévisionnelle de fin de droit dans l’application qui permet aussi de prévoir la suppression par lot des comptes devenus obsolète – pour les étudiants, il s’agit du 31 décembre de l’année universitaire en cours (31/12/2018 pour l’année 2017-2018 par exemple) – pour les personnels, cette date n’a de sens que pour les personnels dont la date de départ est connue et ne devrait donc être renseignée que pour les contrats, les personnels hébergés ou à partir du moment où une date de départ est connue ; prévoir date de fin de contrat 2 mois

⁴⁾

3 valeurs possible dans Alma active/inactive/deleted : – active pour les comptes valide dans leur source – inactive pour les comptes suspendus dans leur source – deleted pour les comptes à supprimer (?) ⇒Mettre à Active systématiquement

⁵⁾

Mettre par défaut “fr” pour tous les comptes

⁶⁾

Si le code à barres n’est pas disponible alors le bloc entier n’est pas fourni

⁷⁾

Si l’Id UNA n’est pas disponible alors le bloc entier n’est pas fourni

⁸⁾

Si l’INE n’est pas disponible alors le bloc entier n’est pas fourni

⁹⁾

¹⁰⁾ , ¹³⁾

_FCKG_BLANK_TD_

¹¹⁾

Ne pas créer le bloc si l’information n’est pas disponible

¹²⁾

¹⁴⁾

Bloc à répéter autant de fois qu’il y a d’inscriptions pour l’étudiant

¹⁵⁾

Bloc à répéter autant de fois qu’il y a d’inscriptions pour l’étudiant ou d’affectation pour le personnel

¹⁶⁾

Bloc à répéter autant de fois qu’il y a de CNU

¹⁷⁾

L’IEP utilise le code cycle pour définir le groupe utilisateur des étudiants

¹⁸⁾

A changer en SCPO-ETU-2

Date de publication

22 mars 2024

Mis à jour le

6 mai 2024

Attention ! Certains établissements utilisent parfois de procédures complémentaires

Signaler une erreur