L'adaptateur LIS met en œuvre les gestionnaires qui sont utilisés par IPSIS pour lancer les appels aux services LIS hébergés par le SIS. Chacun de ces gestionnaires est spécifique au LIS, mais utilise une interface gestionnaire de plateforme IPSIS.
À propos de l'interface IBulkCancelRequestHandler
L'interface du gestionnaire IBulkCancelRequestHandler est utilisée par BulkManager pour prendre en charge la production d'une requête CancelBulkDataExchange ou IgnoreBulkDataExchange.
La mise en œuvre de l'interface est D2L.IM.IPSIS.Bulk.Handlers.IBulkCancelRequestHandler.
La liste de configuration suivante offre un point de départ pour toute mise en œuvre LIS :
Modèle – Annulation en bloc (LIS)
- D2L.IM.IPSIS.LIS.BDEMS.Default.CancelBulkDataExchangeHandler (Sort Order = 10)
CancelBulkDataExchangeHandler
Mise en œuvre
D2L.IM.IPSIS.LIS.BDEMS.Default.CancelBulkDataExchangeHandler
Comportement prévu
Ce gestionnaire effectue les tâches suivantes :
- Vérifie l'état BulkJobStatus de l'objet IBulkCancelRequest pour déterminer s'il faut appeler CancelBulkDataExchange ou IgnoreBulkDataExchange (par l'entremise du client mandataire).
- En cas d'envoi de BulkRequested || BulkRequestSent, le gestionnaire appelle l'annulation. Autrement, le gestionnaire ordonne l'omission.
- Transmet la requête appropriée (annuler ou ignorer).
- Vérifie si la réponse affiche un état Réussite. Si la réponse affiche un état Échec, le gestionnaire actualise l'état de la tâche en bloc à « Erreur ».
- Retire le système source du mode de traitement global (BulkMode) en définissant son état à Activé.
À propos de l'interface IBulkFileProcessor
Le plugiciel pour interface IBulkFileProcessor est utilisé par BulkManager afin d'analyser un fichier en bloc reçu, laisser passer des requêtes individuelles par les adaptateurs pour le traitement et transmettre les résultats à un générateur de rapport.
La mise en œuvre de l'interface est D2L.IM.IPSIS.Bulk.Handlers.IBulkFileProcessor.
La liste de configuration suivante offre un point de départ pour toute mise en œuvre LIS :
Modèle – Traitement de fichiers en bloc (LIS)
- D2L.IM.IPSIS.LIS.BDEMS.Default.BulkFileProcessor (Sort Order = 10)
BulkFileProcessor
Le BulkFileProcessor analyse et traite un seul fichier d'entrée, en faisant passer les résultats par un générateur de rapport.
Mise en œuvre
D2L.IM.IPSIS.LIS.BDEMS.Default.BulkFileProcessor
Comportement prévu
Ce gestionnaire effectue les tâches suivantes :
- Le BuklFileProcessor s'exécute après le téléchargement du fichier localement et est transmis dans un lien IBulkFileUrl avec l'emplacement du fichier.
- Si l'objet de résultat passé ou le ReportGenerator sont nuls, les instances sont créées pendant le prétraitement.
- Au début du traitement, l'état du fichier est mis à jour pour le traitement. Le fichier est analysé en flux et non comme un seul document XML. Ne pas analyser le fichier en entier en une étape permet d'économiser de la mémoire et de la puissance de traitement.
- Si un fichier est partiellement traité et qu'une erreur est relevée, D2L ne doit pas revenir sur les transactions déjà traitées.
- Les en-têtes BDEMS sont analysés à l'aide d'un code personnalisé et elles ne sont pas générées automatiquement.
- Une fois le type de transaction déterminé, le corps de la transaction est forcé dans l'espace nom pour obtenir la version en temps réel et la paralléliser à l'aide d'un code mandataire généré automatiquement.
- Le message parallélisé est assemblé avec de faux en-têtes et transmis à des adaptateurs pour le service en temps réel.
- Les résultats sont communiqués au reportGenerator.
- L'état du fichier est mis à jour à Complété.
Comportement en cas d'erreur
- Si une erreur survient pendant le traitement d'une transaction qui utilise un adaptateur en temps réel :
- Le code d'erreur est enregistré dans le reportGenerator normalement.
- Le traitement se poursuit vers la transaction suivante.
- Si une erreur se produit dans le FileProcessor même :
- Un message d'erreur est journalisé dans la base de données.
- Le processeur modifie l'état du dossier à Échec.
- Il revient immédiatement (avec un code de retour = faux), sans traiter d'entrées subséquentes.
Journalisation
- Entrée au journal de débogage chaque fois que le prétraitement crée un objet manquant dans la requête.
- Entrée au journal de débogage au début et à la fin du traitement principal.
- Un débogage par transaction.
- Les journaux d'erreur sur toute exception soulevée pendant le traitement.
À propos de l'interface de IBulkRequestDataHandler
L'interface du gestionnaire IBulkRequestDataHandler est utilisée par BulkManager pour prendre en charge la production d'une requête RequestBulkDataExchange.
La mise en œuvre de l'interface est D2L.IM.IPSIS.Bulk.Handlers.IBulkRequestDataHandler.
La liste de configuration suivante offre un point de départ pour toute mise en œuvre LIS :
LIS, Template – Bulk Request
D2L.IM.IPSIS.LIS.BDEMS.Default.RequestBulkDataExchangeHandler (Sort Order = 10)
RequestBulkDataExchangeHandler
Mise en œuvre
D2L.IM.IPSIS.LIS.BDEMS.Default.RequestBulkDataExchangeHandler
Comportement prévu
Ce gestionnaire effectue les tâches suivantes :
- Valide le point d'extrémité et configure le client.
- Vérifie les objets BulkEntityTypeFilters de la requête entrante et ajoute un objet FilterRuleType pour chacun à la requête sortante.
- Si l'un des objets EntityTypes ne correspond pas au vocabulaire des objets FilterType pour le traitement en bloc (voir la spécification BDEMS pour la définition de vocabulaire), le gestionnaire génère une exception KeyNotFoundException.
- Valide le format approprié du point d'enregistrement, tel que défini par les spécifications. Tous les points d'extrémités transmis doivent être identiques et afficher le format : AAAA-MM-JJTHH:MM:SS.NNN. T représente la lettre T et NNN, les millisecondes.
- Si l'une de ces conditions échoue, le gestionnaire génère une exception InvalidRequestDataException.
- Ajoute un objet FilterRuleType à la requête sortante pour le point d'enregistrement.
- Envoie la requête requestBulkDataExchange par le client et examine la réponse.
- Si la réponse renvoyée affiche l'état Réussi, le gestionnaire définit le système source en mode de traitement en bloc (BulkMode) s'il ne l'est pas déjà. Renvoie la valeur True (vrai).
- Si la réponse est une erreur, le gestionnaire sort le système source du BulkMode. L'état de la tâche est changé pour Erreur et l'erreur est journalisée. Renvoie la valeur False (faux).
À propos de l'interface de IBulkSendReportHandler
L'interface du gestionnaire IBulkSendReportHandler est utilisée par BulkManager pour prendre en charge la production d'une requête ReportBulkDataExchange.
La mise en œuvre de l'interface est D2L.IM.IPSIS.Bulk.Handlers.IBulkSendReportHandler.
La liste de configuration suivante offre un point de départ pour toute mise en œuvre LIS :
Modèle – Rapport de masse (LIS)
- D2L.IM.IPSIS.LIS.BDEMS.Default.ReportBulkDataExchangeHandler (Sort Order = 10)
ReportBulkDataExchangeHandler
Mise en œuvre
D2L.IM.IPSIS.LIS.BDEMS.Default.ReportBulkDataExchangeHandler
Comportement prévu
Ce gestionnaire effectue les tâches suivantes :
- Valide le point d'extrémité et configure le client.
- Récupère la valeur BulkBlockReportType du générateur de rapport.
- Si la valeur de rapport est nulle, un rapport de base satisfaisant les exigences minimales de la spécification LIS est créé et utilisé, et le système consigne une erreur.
- Le gestionnaire crée la requête reportBulkDataExchangeRequest à l'aide du rapport.
- La requête reportBulkDataExchangeRequest est transmise en passant par le client.
- La réponse est examinée.
- Si la réponse affiche l'état Réussi, le gestionnaire renvoie la valeur True (vrai).
- Si la réponse est un message d'erreur, l'état est changé pour Erreur et celle-ci est journalisée. Renvoie la valeur False (faux).
- Le système source est sorti du mode BulkMode.
À propos de l'interface IPushGradesHandler
L'interface de plugiciel IPushGradesHandler est utilisée par IpsisManager pour soutenir le processus qui pousse les notes au SIS à l'aide des requêtes suivantes : eplaceLineItem et replaceResultsForLineItem.
La mise en œuvre de l'interface est D2L.IM.IPSIS.Grades.Handlers.IPushGradesHandler.
La liste de configuration suivante offre un point de départ pour toute mise en œuvre LIS :
Modèle – Remplacement de résultat (LIS)
D2L.IM.IPSIS.LIS.OMS.Default.ReplaceLineItemHandler (Sort Order = 10)
ReplaceLineItemHandler
Mise en œuvre
D2L.IM.IPSIS.LIS.OMS.Default.ReplaceLineItemHandler
Comportement prévu
Ce gestionnaire effectue les tâches suivantes :
- Valide les points d'extrémité générés et configure les deux clients responsables de l'envoi des requêtes.
- LineItemManagerSyncPortTypeClient - Outcome endpoint must be used for the LineItemManagerSyncPortTypeClient.
- ResultManagerSyncPortTypeClient - Outcome2 endpoint must be used for the ResultManagerSyncPortTypeClient.
- Le gestionnaire obtient l'information nécessaire pour envoyer la requête replaceLineItem.
- Cette information est tirée de la requête IReplaceGradesRequest et est utilisée pour obtenir :
- lineItemSourcedId
- sisOrgUnitIdentifier
- orgUnitType (p. ex., CourseSection)
- lineItemTypeVocabulary
- lineItemTypeLanguage
- gradeType (p. ex., Final)
- Le gestionnaire envoie la requête de replaceLineItem à l'aide du LineItemManagerSyncPortTypeClient.
- Le gestionnaire obtient le résultat défini à l'aide des traducteurs ITranslateReadResultIdsForLineItemWithLineItemTypeResponse et le ReadGradesResult à partir de la requête IReplaceGradesRequest
- La requête replaceResultsForLineItem est transmise à l'aide du ResultManagerSyncPortTypeClient, transmettant l'ensemble de résultats obtenus dans l'étape précédente.
- Le gestionnaire obtient les codes d'état de résultat dans la réponse à la requête replaceResultsForLineItem.
- Le gestionnaire définit les codes d'état de résultat sur le IReplaceGradesResult aux codes obtenus à l'étape précédente.
- Renvoie la valeur True (vrai).
Comportement en cas d'erreur
Si la communication avec le SIS échoue (p. ex., panne de réseau, temporisation, etc.), le gestionnaire effectue jusqu'à trois reprises. Le comportement suivant s'applique aux tentatives répétées :
- Un avertissement est journalisé avant la répétition de la tentative
- Une erreur est inscrite au journal si la communication échoue après trois tentatives de reprise
- Un léger délai est ajouté entre les essais :
- 5 secondes la première fois
- 10 secondes la seconde fois
- 15 secondes la dernière fois
Les nouvelles tentatives se produisent uniquement pour les exceptions CommunicationExceptions et TimeoutExceptions. D'autres exceptions échouent et comptent pour des erreurs.
Dans le cas contraire, si un problème survient lors du traitement, le gestionnaire génère une exception et un message d'information détaillé.