Conformité par personne

Ce rapport constitue le volet Formation de l’export de conformité par personne d’un fournisseur précédent : identité issue de l’annuaire, puis une ligne par personne et par inscription à une formation (statut et dates du module). La granularité est de type long — personne × affectation — car c’est ce que GET /v1/assignments/{id}/enrollments renvoie déjà. La requête ne transforme pas les modules en colonnes (pas de pivot). La configuration, les identifiants, la pagination et la nouvelle tentative en cas de limitation du débit sont identiques à ceux du guide de connectivité Power BI / Excel. Ajoutez d’abord la requête partagée Fn_FetchAll ; ce rapport l’appelle par son nom.

​

Portées de clé requises

​

Points de terminaison sources

Cette requête n’appelle pas GET /v1/entities. La ligne d’inscription contient déjà email et display_name, et la liste des entités ne comporte ni service ni intitulé de poste : la parcourir ne renseignerait donc pas de colonnes d’annuaire que la ligne d’inscription ne fournit pas déjà.

​

Granularité

Une ligne par inscription (personne × affectation). Une personne affectée au même cours par deux affectations génère deux lignes. Une personne sans inscription n’apparaît pas : /v1 ne peut pas produire de ligne d’annuaire exploitable sans adresse e-mail, et créer des lignes par personne seule mélangerait les granularités. Budget de requêtes : un parcours paginé par affectation, de manière séquentielle, dans le respect de la limite de débit partagée par clé. Définissez toujours limit = "500".

​

Correspondance des colonnes

Les noms de colonnes hérités proviennent de l’export de votre fournisseur précédent. Les champs /v1 correspondent aux noms de l’API publique ; la requête en renomme certains pour le rapport. Clés de jointure conservées pour un modèle en étoile : entity_id, assignment_id, course_id, user_assignment_id. La requête conserve également course_slug, assignment_title, passed, attempts, assignment_lifecycle_status et assignment_created_at. enrollment_status correspond à la progression de l’apprenant, et non au cycle de vie de l’affectation (active / paused / completed).

​

Différences par rapport à l’export hérité

• Les acceptations de politiques ne sont pas disponibles. Cette plateforme n’a pas de domaine de politiques : il n’existe ni /policies, ni /policy_acceptances, ni ressource /v1 équivalente. Ne considérez pas ces colonnes comme une correspondance en attente. Elles sont hors périmètre.
• Les informations d’annuaire supplémentaires sont omises, et non renseignées à null. Le service, l’intitulé de poste, le responsable hiérarchique et le site ne figurent pas dans /v1. La requête ne crée pas de colonnes vides pour ces informations.
• La date d’échéance est incluse même si l’export hérité ne la comportait pas, car Enrollment.due_at est disponible dans l’API.
• Le nom du cours privilégie le titre du catalogue. Course.title correspond au nom du module. Assignment.title n’est utilisé que lorsque la ligne du catalogue est absente (supprimée ou non publiée).
• Format long, sans pivot. Une ligne par inscription, et non une ligne par personne avec une colonne par module.

​

Étapes suivantes