Table des matières[ Show ]
Dernière mise à jour de la documentation : 16/02/2021
Mise en ligne sur le blog : 20/05/2021
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és1) 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.
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 | EPPN2) </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-JJZ3) | 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 | statut4) | 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’usager5) | 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_identifier6) | 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 | ||
| userIdentifier7) | 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) | ||
| userIdentifier8) | 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 | Champ source | 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 |
| 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) 9) ) | 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_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) 10) | 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 |
| 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) 11) | 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 |
| 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)12) | 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 |
| category_type | FIXE : ‘NIVEAU‘ | FAUX | VRAI | ||||
| user_statistic (2)13) | 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 | |
| category_type | FIXE : ‘ETAPE‘ | FAUX | VRAI | ||||
| user_statistic (3)14) | 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 | |
| category_type | FIXE : ‘DISCIPLINE‘ | FAUX | VRAI | ||||
| user_statistic (4)15) | 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 ) |
|
| 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 | |
| category_type | FIXE : ‘ETABLISSEMENT‘ | FAUX | VRAI | ||||
| user_statistic (6) 16) | statistic_category | MANGUE : cnu (UB) | FAUX | VRAI | code CNU | ne concerne que les enseignants chercheurs | |
| 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 17) | 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 18) |
| 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 |
1)
selon les possibilités de chaque établissement
2)
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
3)
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
4)
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
5)
Mettre par défaut “fr” pour tous les comptes
6)
Si le code à barres n’est pas disponible alors le bloc entier n’est pas fourni
7)
Si l’Id UNA n’est pas disponible alors le bloc entier n’est pas fourni
8)
Si l’INE n’est pas disponible alors le bloc entier n’est pas fourni
9)
9
11)
Ne pas créer le bloc si l’information n’est pas disponible
14)
Bloc à répéter autant de fois qu’il y a d’inscriptions pour l’étudiant
15)
Bloc à répéter autant de fois qu’il y a d’inscriptions pour l’étudiant ou d’affectation pour le personnel
16)
Bloc à répéter autant de fois qu’il y a de CNU
17)
L’IEP utilise le code cycle pour définir le groupe utilisateur des étudiants
18)
A changer en SCPO-ETU-2