4.1 Principes

Le serveur TE s'intègre dans l'architecture Dynacase de manière autonome.

Il peut être installé sur une machine différente de celle supportant Dynacase Platform et ses applications.¹

Il peut être mutualisé pour répondre aux demandes d'applications hébergés par des contextes différents de Dynacase.

Le serveur TE reçoit des demandes de travaux par ses clients. Un travail est une demande de transformation de données (fichiers) par un processus particulier. Ces processus sont matérialisés par des moteurs de transformation ou transformation engines.

4.1.1 Architecture

Le serveur TE comporte plusieurs services qui sont :

Request server

Ce serveur est celui qui est en écoute sur le réseau et qui gère la communication entre Dynacase et TE.

On peut catégoriser les demandes en deux types :

• Demandes de conversion
• Demandes de récupération de résultat

Dans le cas d'une demande de conversion, il stocke en local le fichier et les paramètres de la transformation demandée (nom du moteur à appliquer, URL de callback à appeler en fin de transformation) dans une tâche qui est alors en attente de traitement.

Dans le cas d'une demande de récupération de résultat, il va inspecter la tâche correspondante pour voir si elle à été traitée et fournir le fichier résultat.

Rendering server

Ce serveur tourne en tâche de fond, et scrute continuellement pour voir s'il y a de nouvelles tâches en attente de traitement.

Lorsqu'une nouvelle tâche en attente de traitement est trouvée, il exécute alors le moteur de transformation associé avec le fichier soumit par le client.

Si la tâche s'est correctement déroulée, il enregistre le fichier produit et appelle l'éventuelle URL de callback de la tâche pour notifier Dynacase que le résultat de la conversion peut être récupéré.

OOO server

Ce serveur est une instance de OpenOffice lancée en mode serveur qui est utilisée par certains moteurs de transformations.

4.1.2 Cinématique

4.1.2.1 Échanges Client / Serveur

La communication entre Dynacase et le Request server permet au client de :

• Demander la conversion d'un fichier avec un moteur donné.
• Demander le statut d'une tâche de conversion.
• Demander la liste des moteurs de transformation supporté par le serveur TE avec, pour chacun, la liste des type MIME des fichiers compatibles en entré.
• Demander la liste des tâches et de leurs journaux (management/monitoring).
• Demander les journaux d'un tâche en particulier.
• Demander les informations générale du serveur TE (version, charge, etc.).
• Demander l'exécution des "selftests".
• Demander le résultat d'une tâche réussie.
• Demander l'interruption d'une tâche.
• Demander la purge de l'historique des tâche et des journaux.

4.1.2.2 Cycle de traitement des demandes

Figure 6. Workflow tâche

Request server

• Lors de la réception d'une demande de conversion, le service Request server crée une tâche dans l'état B (Beginning).
• La tâche passe ensuite dans l'état T (Transferring) durant le temps qu'il faut pour lire le fichier de la requête.
• Une fois le fichier lu et enregistré en local, la tâche passe dans l'état W (Waiting) pour indiquer qu'elle est prête à être traitée.
• Si la tâche est en erreur, son statut est positionné à K (Knockout).
• Si la tâche est interrompue, son statut est positionné à I (Interrupted).

Rendering server

• En parallèle, le service Renderer server scrute les nouvelles tâches qui sont en attente de traitement (W).
• Lorsqu'une nouvelle tâche est prise pour exécution, la tâche passe en status P (Processing).
• Si la conversion est réussie, la tâche passe à l'état D (Done) et Dynacase est notifié via l'URL de callback.
• Lorsque Dynacase a récupéré le résultat, alors la tâche est supprimée.
• Si la tâche est en erreur, son statut est positionné à K (Knockout).
• Si la tâche est interrompue, son statut est positionné à I (Interrupted).

4.1.3 Les types mimes

Voir Types MIME.