Voyez l’application en action ici : RAG Manager (accès réservé).
 

Le dossier ’data’ du thème
Tous les documents ingérés (sur lesquels a été construit l’index) se trouvent sur l’hôte dans le dossier .../data/’theme’/.
Le dossier .../data/’theme’/storage/ contient les différents fichiers composant l’index.
Le fichier ’theme’.txt en est une version comprimée et sérialisée de façon à être chargée rapidement par les applications.

Ajouter document(s)
Cette action permet de sélectionner un document dans un dossier local, de l’importer dans le répertoire des données et l’indexer. Il est également possible d’effectuer une sélection multiple.
Cette action n’assure pas l’enregistrement de l’index.

Ajouter Web
Cette action parcourt le site Web désigné, importe le contenu dans le dossier .../data/’theme’/ et assure l’indexation.
L’index est enregistré à la fin de l’action.
Dans l’état actuel du développement, le parcours est effectué avec le paramètres —forwards, mais sans les paramètres —all, —nostore, —dynamic, —plan etc. (voir Ingestion RAG : le script ingestcmd.py ).
En particulier, l’absence de —all permet de lancer l’action régulièrement pour incrémenter l’index avec les pages nouvelles ou modifiées.

Indexer
Cette action balaye le dossier data à la recherche de documents non-indexés et les indexe.
L’ajout d’un document, du contenu d’un répertoire ou de tout ou partie d’un site Web assure l’importation des documents dans le dossier .../data/’theme’/ et leur indexation. Mais il est également possible d’ajouter des documents par d’autres moyens tels qu’un téléversement. Ces documents ne sont pas indexés et devront l’être par l’action Indexer.
L’index est enregistré à la fin de l’action.

Réindexer
L’action Réindexer efface l’index en mémoire et sur le disque avant de ré-indexer tous les documents du dossier data/’theme’/.
L’index est enregistré à la fin de l’action.
Cette action n’est pertinente que dans certains cas d’erreur.
Noter que l’index sérialisé précédent est préservé pendant l’exécution afin d’éviter les ruptures de service.

Enregistrer
L’index est maintenu dans la mémoire de l’hôte. Pour le rendre persistant et accessible aux applications, il faut l’enregistrer après avoir ajouté des documents.
Ceci est fait systématiquement à la suite des actions Ajouter Web, Indexer et Réindexer.
L’enregistrement est une action relativement longue et coûteuse en ressources. C’est pourquoi, quand on ajoute un ou plusieurs documents, on laisse à l’utilisateur le soin de provoquer l’enregistrement.

Supprimer
La suppression des documents périmés est essentielle pour assurer des résultats fondés sur des données à jour. C’est une décision à prendre fichier par fichier.

A propos du Dashboard

Pourquoi un Dashboard ?
Les actions lancées depuis le RAG Manager sont pour la plupart exécutées en tâche de fond. Une fois la tâche lancée, on n’attend pas la fin de l’exécution - qui peut durer plusieurs minutes - pour revenir à la page principale. Le Dashboard permet de voir la progression des traitements et de vérifier leur bonne fin.

Pour cela, le RAG Manager se connecte à la route /api/stream du Web Service IngestWSG qui génère un flux SSE (Server-Sent Events) de tous les messages générés au cours de l’exécution des actions.

Pourquoi une fenêtre indépendante est requise pour garantir la persistance du flux SSE ?

Lorsqu’un flux SSE est utilisé pour diffuser des messages en temps réel depuis un serveur vers le navigateur, celui-ci repose sur une connexion HTTP persistante attachée à un contexte `window` spécifique. Cette connexion présente plusieurs limites fonctionnelles dans un environnement Web :
– le DOM est rechargé à chaque navigation (ex. clic sur un lien, changement d’onglet, exécution d’une action AJAX non isolée), ce qui est exactement ce que l’on fait en lançant des actions.
– dans ce cas, le contexte JavaScript est détruit et la connexion SSE est interrompue.
– même lorsque le dashboard est inclus dans un INCLURE, une iFrame, appelé par fetch etc., le comportement reste identique : le flux est interrompu.

Solution retenue : une fenêtre autonome

Ouvrir une fenêtre indépendante via `window.open()` permet d’isoler le dashboard dans un contexte JavaScript propre et persistant. Cette approche présente plusieurs avantages :
– Le flux SSE reste actif tant que la fenêtre est ouverte, indépendamment des interactions dans la page principale.
– Le dashboard n’est affecté ni par la navigation SPIP, ni par les rechargements liés au squelette.

Notez qu’une communication bidirectionnelle est établie du dashboard vers la page principale via `postMessage` pour cloner la liste des messages, et dans l’autre sens après un changement de page afin de restituer les messages antérieurs.

Alternatives étudiées (non retenues)

Après essais, ce choix d’architecture semble le seul capable de garantir la stabilité d’un outil de supervision en temps réel. Il permet de s’affranchir des limites imposées par le cycle de vie du DOM dans SPIP et assure une communication continue entre client et serveur.