Installation et exploitation

Tranformation Engine 1.4

Anakeen Labs <labs@anakeen.com>

Table des matières

Chapitre 1 Introduction
1.1 Présentation
1.2 Notes de version
Chapitre 2 Installation et mise à jour
2.1 Pré-requis
2.2 Installation
2.3 Configuration du serveur TE
2.4 CLI de contrôle du TE
2.5 Installation des WebUi (client)
Chapitre 3 Exploitation
3.1 Depuis le Centre d'Administration
3.2 Configuration Dynacase
3.3 Surveillance du serveur et des travaux
3.4 Test du serveur
Chapitre 4 Fonctionnement
4.1 Principes
4.2 Création d'un moteur
4.3 Classe \Dcp\TransformationEngine\Client
4.4 Les moteurs
4.5 La base de données

Chapitre 1 Introduction

1.1 Présentation

Le serveur de transformation Dynacase TEngine ou TE est un composant autonome d'une architecture Dynacase.

Il a pour rôle d'exécuter, sur demande de Dynacase Platform ou de ses applications, des travaux de transformation. Il pilote pour cela des moteurs de transformation ou Engine.

Chaque moteur traite un fichier en entrée dans un format donné, et produit en sortie un fichier résultat. Le traitement réalisé et les formats de fichiers font la spécificité du moteur.

Lors de l'installation du serveur TE, un ensemble de moteurs est livré en standard.

Le développeur peut ajouter ses propres moteurs.

Le serveur TE est constitué de quatres services distincts :

te-request-server : le serveur de communication gérant la communication avec ses clients ;
te-rendering-server : le serveur de transformation ayant pour rôle le lancement des travaux et la gestion des produits ;
te-ooo-server : le serveur LibreOffice.org (ou OpenOffice.org) ;
te-tika-server : le serveur Tika.

Ce manuel aborde le fonctionnement du TE selon trois axes :

d'un point de vue installation et mise à jour, thème abordé au chapitre Installation ;
l'exploitation et la supervision du TE sont traités au chapitre Exploitation ;
les mécanismes supportés permettant de développer des clients ou moteurs TE sont décrits au chapitre Fonctionnement.

1.2 Notes de version

Les paragraphes suivant détaillent pour chacune des versions les nouveautés et précisent si nécessaire les instructions de mise à jour.

1.2.1 Compatibilité

Dynacase Platform: version 3.2
Apache Tika Server: version 1.16
OpenOffice.org / LibreOffice.org: OpenOffice version 4.0 - 4.1 / LibreOffice version 4.0 - 5.0 - 5.1 - 5.2 - 5.3 - 5.4

1.2.2 Releases

1.2.2.1 Release 1.4.2

Cette version introduit le support du redémarrage automatique des services de TE : lorsqu'un des services s'arrête (ex. serveur OOo qui plante et qui s'arrête), il est alors automatiquement redémarré.

Lorsqu'un service s'arrête 5 fois consécutives avec un temps d'exécution <= 1 seconde, alors le service est considéré comme étant en échec immédiat et répétitif, et le service n'est plus redémarré automatiquement.

Le redémarrage des services donne lieu à l'émission d'un message sur syslog avec le nom du service concerné et le mot clé "(respawn)" :

Exemple :

te-ooo-server: (respawn) Command exited after 4288s with code '255'.
te-ooo-server: (respawn) Waiting 0 seconds...
te-ooo-server: (respawn) Respawning command.
te-ooo-server: (respawn) Executing '[...]'
te-ooo-server: (respawn) Command running with PID '9739'.

Le format des messages syslog émis lorsque TE_SERVER_DEBUG est activé, a été uniformisé pour suffixer ceux-ci avec le nom du service concerné :

te-request-server: [...] ;
te-rendering-server: [...] ;
te-ooo-server: [...] ;
te-tika-server: [...].

Le script rc-init ted a été modifié pour supporter l'interrogation unitaire du statut, et l'arrêt/redémarrage, d'un service spécifique en spécifiant le nom du service.

Exemple :

# /etc/init.d/ted restart te-ooo-server
Stopping (te-ooo-server) OOO server (LibreOffice 5.2)... 5549
 * Stopping ted service:  OK
 
 Starting (te-ooo-server) OOO server (LibreOffice 5.2)... 10135
  * Starting ted service:  OK

# /etc/init.d/ted status te-ooo-server
(te-ooo-server) OOO server (LibreOffice 5.2) running (10135)

Si aucun service n'est spécifié, alors l'opération est appliquée à tous les services comme précédemment.

1.2.2.2 Release 1.4.1

Cette version permet d'utiliser les versions 5.0 et 5.1 de LibreOffice.

Le paramètrage de LibreOffice/OpenOffice a été simplifiée.

1.2.2.3 Release 1.4.0

Point majeur de cette release, des interfaces permettant de réaliser les opérations de paramétrage de Platform et de surveillance de TE sont disponibles.

Elles sont installées dans le centre d'administration Dynacase Platform grâce aux modules Dynacase TEngine Configuration (disponible publiquement) ou Dynacase TEngine Monitor (disponible sous licence Anakeen).

Cette version introduit aussi le support de Tika en mode serveur afin d'accélérer les conversions texte et réduire la charge serveur.

utilisation de Tika en mode serveur ;
suppression des moteurs html2txt, ooo2txt et pdf2txt (remplacés par tika2txt) ;
suppression des répertoires de travail REQUEST_DIRECTORY et RENDERING_DIRECTORY remplacés par une seul et même paramètre TE_WORK_DIR ;
chaque transformation crée ses fichiers temporaires dans un répertoire temporaire de travail dédié créé dans le répertoire TE_WORK_DIR (préfixe te-task-);
l'argument cleantmpfiles du script rc/init ted a été modifié pour supprimer les répertoires de travail des transformations (préfixe te-task-) ;
suppression du moteur txt2txt (la transformation étant à présent gérée par le moteur tika2txt) ;
l'URL de callback d'une transformation est appelée à la fin de la transformation quelque soit sont "status" final ({K, D, I}) ;

1.2.2.3.1 Mise à jour depuis la version 1.3.4

Après avoir installé la nouvelle version de TE, les modifications suivantes sont à faire :

Stopper le serveur TE.
Installer tika-server-<version>.jar : voir Installation de tika-server.
Configurer les variables TE_TIKA_SERVER_* dans etc/te.conf : voir Configuration serveur Tika.
Supprimer les variables REQUEST_DIRECTORY et RENDERING_DIRECTORY dans etc/te.conf et renseigner la variable TE_WORK_DIR : voir Paramètres.
Supprimer toutes les transformations de la table task :

# PGSERVICE=${TE_PG_SERVICE} psql
te=# DELETE FROM task;

Supprimer le fichier $TE_HOME/lib/engines/te-xvfb-server.
Supprimer le fichier $TE_HOME/lib/engines/tika-app-<version>.jar.
Supprimer le fichier $TE_HOME/lib/engines/html2txt.
Supprimer le fichier $TE_HOME/lib/engines/ooo2txt.
Supprimer le fichier $TE_HOME/lib/engines/pdf2txt.
Supprimer le fichier $TE_HOME/lib/engines/txt2txt.
Démarrer le serveur TE.

Lors du redémarrage, le nouveau serveur Tika doit être lancé :

Starting OOO server... 16020
Starting Tika server... 16065
Starting te_request_server... 16104
Starting te_rendering_server... 16140
 * Starting ted service:  OK

Pour la mise à jour de la liste des moteurs :

Sauvegarder la définition de vos propres moteurs.
Supprimer le contenu de la table engine :

# PGSERVICE=${TE_PG_SERVICE} psql
te=# DELETE FROM engine;

Re-charger la nouvelle liste de moteurs :

# PGSERVICE=${TE_PG_SERVICE} psql
te=# \i $TE_HOME/lib/engines/engine_init.sql

Re-importer la définition de vos propres moteurs.

Chapitre 2 Installation et mise à jour

2.1 Pré-requis

2.1.1 Logiciels

PostgreSQL >= 9.x

Le TE utilise la base de donnée pour stocker les informations de gestion des travaux. Cette base de donnée peut être locale (sur le même serveur) ou distante.

PHP >= 5.4 (cli)

TE est écrit en PHP et nécessite donc l'interpréteur PHP (php-cli) avec les extensions suivantes :

curl
gettext
json
pcntl
pgsql
posix
SimpleXML

Java Runtime Environment 7 (ou 8)

TE nécessite un environnement Java 7 (ou 8) pour utiliser l'API Java d'OpenOffice en mode serveur et Apache Tika. Il est mis à disposition soit par OpenJDK ou par Oracle.

OpenOffice (4.1.4) ou LibreOffice (5.x)

TE nécessite Apache OpenOffice ou LibreOffice.

1.4.1 Les versions de LibreOffice 5.2, 5.3 et 5.4 ont été testées et sont compatibles.

Des différences peuvent exister dans le support et le rendu des documents entre OpenOffice et LibreOffice. Le choix de l'utilisation de l'un ou l'autre vous incombe donc en fonction de votre utilisation.

tika-server-1.16.jar

TE nécessite l'outil tika-server du projet Apache Tika pour l'extraction de texte (voir tika-server). À la date de rédaction de ces pré-requis, la version actuellement disponible et préconisée est la 1.16.

a2ps et ps2pdf14

TE utilise les outils a2ps et ps2pdf14 pour les conversions texte vers PDF. Ils sont fournis par a2ps et Ghostscript.

convert

TE utilise l'outil de conversion d'image convert (fourni par ImageMagick).

zip et unzip

TE utilise les commandes zip et unzip (fournie par Info-ZIP).

Script /lib/lsb/init-functions

TE utilise le script /lib/lsb/init-functions présent sur les systèmes Linux compatibles "Linux Standard Base". Dans le cas où ce script ne serait pas présent, il est possible qu'un paquet fournisse cette fonctionnalité (redhat-lsb sur les distribution RedHat Enterprise Linux par exemple).

2.1.2 Base de donnée TE

Le serveur TE utilise une base de données pour stocker les travaux qu'il gère et les logs associés.
Cette base peut être sur la machine hébergeant le serveur TE lui même ou sur un machine tierce.

2.1.2.1 Créer une base `te` sur votre serveur de base de données

# su postgres -c psql
postgres=# CREATE DATABASE "te" WITH OWNER "dynacaseowner";

2.1.2.2 Créer/ajouter le service postgresql pour l'accès à cette base `te`

# vi ${PGSYSCONFDIR}/pg_service.conf
 
...
 
[te]
host=127.0.0.1
port=5432
user=dynacaseowner
password=password
dbname=te

Note : La valeur de ${PGSYSCONFDIR} est dépendante de votre distribution, et peut être trouvée avec la commande : pg_config --sysconfdir.

2.1.2.3 Valider l'accès à la base de donnée `te`

# PGSERVICE=te psql
te=# \q

2.1.2.4 Paramétrage de la base de données `te`

2.1.2.4.1 Nombre maximum de connections

Le service TE comprend deux processus qui tournent en continue (te_request_server et te_request_renderer). Chacun de ces processus ouvre et maintient une connexion ouverte sur la base de donnée.

Ensuite, à chaque fork (pour le traitement d'un client pour te_request_server, ou le traitement d'une tâche pour te_request_renderer) une nouvelle connexion est faite sur la base de données.

Le nombre maximum de connections (max_connections) à la base de données est donc donné par la formule¹ :

Nombre max de connections Postgresql = 2 + REQUEST_MAX_CLIENT + RENDERING_MAX_CLIENT

Les paramètres REQUEST_MAX_CLIENT et RENDERING_MAX_CLIENT sont modifiables lors de la configuration du server. ↩

2.2 Installation

TE est disponible sous forme d'archive à installer sur un serveur dédié (ou non) qui assurera la fonction de serveur de transformation pour Dynacase.

2.2.1 Télécharger et décompresser l'archive `dynacase-te-current.tar.gz`

# wget http://dynacase.anakeen.com/tengine/dynacase-te-current.tar.gz
# tar zxvf dynacase-te-current.tar.gz

L'archive se décompresse et crée un sous-répertoire dynacase-te-${VERSION}-${RELEASE} avec le numéro de version et de release de dynacase-te.

Pour simplifier le nommage et l'accès à ce répertoire vous pouvez le renommer :

# mv dynacase-te-${VERSION}-${RELEASE} dynacase-te

Par la suite, nous ferons référence à ce répertoire à l'aide de la variable TE_HOME :

# TE_HOME=/opt/dynacase-te

Si vous avez un compte EEC, il est recommandé de télécharger dynacase-te depuis votre dépôt EEC afin d'avoir les dernières corrections disponibles.

2.2.2 Initialisation

Une fois les éléments installés, il vous faut initialiser la base de données TE.

# $TE_HOME/bin/ted init
 * Initializing ted service: OK

L'initialisation crée les tables engine et task dans la base TE.

2.2.3 Montée en version et mise à jour

La mise à jour de TE consiste à :

déployer le contenu de l'archive de la nouvelle version sur l'installation de l'ancienne version ;
- télécharger la version courante (e.g. http://eec.anakeen.com/public/tengine/dynacase-te-current.tar.gz ;
- décompresser le contenu de l'archive de la version courante (e.g. dynacase-te-current.tar.gz) dans le répertoire racine de votre installation de TE (e.g. /opt/dynacase-te) :
```
# wget -O /tmp/dynacase-te-current.tar.gz http://eec.anakeen.com/public/tengine/dynacase-te-current.tar.gz
# tar -C /opt/dynacase-te -zxvf /tmp/dynacase-te-current.tar.gz --strip-components 1
```
suivre ensuite les éventuelles procédures de migration fournies dans les notes de version ;
pour finir, redémarrer le daemon TE.

2.2.4 Installation des éléments additionnels

Installer les composants logiciel requis par TE (voir Pré-requis) puis procéder à leur configuration (voir Configuration du serveur TE).

Les versions à utiliser dépendent de la version du serveur TE. Elles sont identifiées dans les notes de version.

2.2.4.1 Installation de tika-server

L'archive tika-server-<version>.jar peut être obtenue en téléchargement sur le site officiel de Apache Tika, ou bien sur notre dépôt third-party : tika-server-1.16.jar

L'archive JAR de tika-server doit ensuite être déposée dans le sous-répertoire $TE_HOME/lib/engines :

# cp /tmp/tika-server-<version>.jar $TE_HOME/lib/engines/

2.3 Configuration du serveur TE

2.3.1 Initialisation

Les paramètres du serveur TE sont définis dans le fichier $TE_HOME/etc/te.conf.

Lors de la première utilisation, le fichier d'exemple te.conf.sample être copié dans le fichier te.conf :

# cp $TE_HOME/etc/te.conf.sample $TE_HOME/etc/te.conf

2.3.2 Paramètres

Le fichier de configuration est composé des paramètres suivants :

2.3.2.1 Base de données

# Transformation Engine Configuration
# - - - - - - - - - - - - - - - - - -
TE_PG_SERVICE="te"                # Postgresql database service name

TE_PG_SERVICE : permet d'indiquer le service d'accès à la base de données TE

2.3.2.2 Serveur de communication

PORT=51968                        # port number where listen client
LISTEN_ADDRESS=0.0.0.0            # address mask to listen : listen everybody by default
REQUEST_MAX_CLIENT=15             # max request in parallel 
TE_WORK_DIR=/var/tmp              # Directory where task's files and engine's temporary files are stored

PORT : port d'écoute sur serveur
LISTEN_ADDRESS : plage d'adresse (mask) d'écoute du serveur
REQUEST_MAX_CLIENT : nombre maximum de connexions client simultanées
TE_WORK_DIR : répertoire de stockage des fichiers reçus

2.3.2.3 Mécanisme de purge

PURGE_DAYS=7                      # remove tasks older than 7 days
PURGE_INTERVAL=100                # trigger tasks purge every 100 requests (set to 0 to disable purge)

Ces paramètres permettent de définir le fonctionnement de la purge (suppression des transformations dont la date de création est inférieure à une limite donnée).

Si la tâche est en cours d'exécution, le processus de la tâche est tué.

Ensuite, quelque soit le status de la transformation, la transformation est supprimée avec son répertoire de travail.

PURGE_DAYS : les travaux antérieurs à ce nombre de jours sont purgés.
PURGE_INTERVAL : précise la fréquence de la purge, la purge est lancée toute les n transformations exécutés.

2.3.2.4 Serveur de transformation

RENDERING_MAX_CLIENT=10           # max conversion in parallel

RENDERING_MAX_CLIENT Nombre de moteurs de transformation activé en parallèle

2.3.2.5 Identité pour les serveurs

TE_SERVER_USER=root
TE_SERVER_DEBUG=no

TE_SERVER_USER : permet de spécifier l'identité (unix user) sous laquelle les serveurs sont exécutés.
TE_SERVER_DEBUG : permet de rediriger (yes ou no) la sortie standard (STDOUT) et d'erreur (STDERR) des services te-request-server, te-rendering-server, te-ooo-server et te-tika-server dans syslog (pour analyser les éventuels problèmes de démarrage de ces services).

2.3.2.6 Serveur OpenOffice.org / LibreOffice.org

Sites officiels des logiciels : OpenOffice.org / LibreOffice.org.

TE_OOO_SERVER_ENABLED=yes
TE_OOO_BASE_DIR=/replace/me/with/path/to/openoffice.org/directory
TE_OOO_SERVER_SOFFICE=${TE_OOO_BASE_DIR}/program/soffice
TE_OOO_JVM_OPTS=""
TE_OOO_SERVER_HOST=127.0.0.1
TE_OOO_SERVER_PORT=8123

Les chemin d'accès aux fichiers OpenOffice.org sont relatifs.

Le paramètre principal TE_OOO_BASE_DIR est utilisé pour définir les paramètres secondaires :

TE_OOO_SERVER_ENABLED : permet d'activer (yes) ou désactiver (no) le lancement du serveur OpenOffice. Attention : cela ne désactive pas l'exécution des moteurs de conversion qui utilisent OpenOffice. Ces derniers seront alors mis en erreur.
TE_OOO_BASE_DIR : chemin d'accès au répertoire racine d'installation de OpenOffice ou LibreOffice (e.g. /opt/libreoffice5.3). 1.4.1Ce paramètre est facultatif. Il sert, dans le configuration par défaut, à repérer le programme soffice qui est défini par variable TE_OOO_SERVER_SOFFICE .
TE_OOO_SERVER_SOFFICE : chemin d'accès au programme soffice de OpenOffice/LibreOffice.
TE_OOO_JVM_OPTS : variable pour positionner des paramètres spécifiques pour la JVM si besoin.
TE_OOO_SERVER_HOST : adresse IP d'écoute du serveur OpenOffice/LibreOffice.
TE_OOO_SERVER_PORT : port TCP d'écoute du serveur OpenOffice/LibreOffice.
TE_OOO_PRODUCTKEY : 1.4.1 Paramètre optionnel. Valeur possible "LibreOffice" ou "OpenOffice". Il permet de d'indiquer explicitement le logiciel utilisé. Il est renseigné automatiquement s'il n'est pas indiqué.

2.3.2.6.1 Ancienne version 1.4.0

1.4.0 TE_OOO_CLASSPATH : classpath Java pour accéder aux librairies Java d'OpenOffice. Les classes nécessaires sont contenus dans les fichiers java suivants : unoil.jar, juh.jar, jurt.jar et ridl.jar.

La valeur de TE_OOO_CLASSPATH est différente suivant l'utilisation d' OpenOffice ou de LibreOffice :
- Exemple de valeur pour OpenOffice :
```
TE_OOO_CLASSPATH="${TE_OOO_BASE_DIR}/program/classes/unoil.jar:${TE_OOO_BASE_DIR}/program/classes/juh.jar:${TE_OOO_BASE_DIR}/program/classes/jurt.jar:${TE_OOO_BASE_DIR}/program/classes/ridl.jar"
```
- Exemple de valeur pour LibreOffice :
```
TE_OOO_CLASSPATH="${TE_OOO_BASE_DIR}/program/classes/unoil.jar:${TE_OOO_BASE_DIR}/ure/share/java/juh.jar:${TE_OOO_BASE_DIR}/ure/share/java/jurt.jar:${TE_OOO_BASE_DIR}/ure/share/java/ridl.jar"
```
Sous debian (ou ubuntu), pour LibreOffice, les classes java sont fournies par le paquet "ure" (LibreOffice UNO runtime environment).

1.4.1 Ce paramètre est détecté automatiquement et ne nécessite plus d'être renseigné.
TE_OOO_JVM_OPTS : variable pour positionner des paramètres spécifiques pour la JVM si besoin.

Serveur Tika: Ces variables dépendent de l'installation de Tika server.

TE_TIKA_SERVER_ENABLED=yes
TE_TIKA_SERVER_JAR="/replace/me/with/path/to/tika-server-#version#.jar"
TE_TIKA_SERVER_HOST=127.0.0.1
TE_TIKA_SERVER_PORT=9998
TE_TIKA_SERVER_LOGLEVEL="" # 'debug' or 'info'

TE_TIKA_SERVER_ENABLED : permet d'activer (yes) ou désactiver (no) le lancement du serveur Tika. Attention : cela ne désactive pas l'exécution des moteurs de conversion qui utilisent Tika. Ces derniers seront alors mis en erreur.
TE_TIKA_SERVER_JAR : chemin d'accès au fichier JAR de Tika Server.
TE_TIKA_SERVER_HOST : adresse IP d'écoute du serveur Tika.
TE_TIKA_SERVER_PORT : port TCP d'écoute du serveur Tika.
TE_TIKA_SERVER_LOGLEVEL : loglevel spécifique du serveur Tika (à utiliser conjointement avec TE_SERVER_DEBUG=yes décrit ci-dessus).

2.3.3 Type mimes

La détection du type MIME textuel et du type MIME système des fichiers par TE est paramétrable via des règles appliquées sur l'extension du nom du fichier.

Ces règles sont décrites au format XML dans le fichier $TE_HOME/etc/user-mime.conf.

Un fichier d'exemple est fourni par défaut dans $TE_HOME/etc/user-mime.conf.sample.

Exemple de définition des types MIME textuel et système pour les fichiers d'extension .foo et .bar :

<?xml version="1.0" encoding="utf-8"?>
<mimes>
    <mime ext="foo" sys="application/foo" text="Foo file" />
    <mime ext="bar" sys="application/bar" text="Bar file" />
</mimes>

Chaque règle est décrite à l'aide d'un élément <mime/> comportant l'extension (sans le point de l'extension) sur laquelle elle s'applique (attribut ext) et le type MIME textuel et système correspond qui est retourné (attribut text et sys).

Les règles sont évalués dans l'ordre et s'arrête à la première règle qui correspond à l'extension du fichier.

Ces règles $TE_HOME/etc/user-mime.conf viennent en complément et sont évalués en priorité par rapport au jeu de règles fournit par défaut par TE (consultable dans le fichier $TE_HOME/etc/mime.conf).

2.4 CLI de contrôle du TE

2.4.1 Démarrage/Arrêt des services de TE (`ted start`) (`ted stop`)

Démarrage ted start: Le script démarre les services OpenOffice, Tika et TE (communication et transformation).

# $TE_HOME/bin/ted start
Starting (te-ooo-server) OOO server (LibreOffice 5.4)... 20307
Starting (te-tika-server) Tika server... 20366
Starting (te-request-server) TE Request server... 20417
Starting (te-rendering-server) TE Rendering server... 20475
 * Starting ted service:  OK

Le script ted lance les quatre services, et affiche leur PID. Les erreurs d'activation sont signalées sur la console de lancement.

Arrêt ted stop: Le script arrête les services TE (communication et transformation), Tika et OpenOffice.

# $TE_HOME/bin/ted stop
Stopping (te-request-server) TE Request server... 20417
Stopping (te-rendering-server) TE Rendering server... 20475
Stopping (te-tika-server) Tika server... 20366
Stopping (te-ooo-server) OOO server (LibreOffice 5.4)... 20307
 * Stopping ted service:  OK

Il est aussi possible de contrôler chacun de service indépendamment en spécifiant son nom :

# $TE_HOME/bin/ted stop te-ooo-server
Stopping (te-ooo-server) OOO server (LibreOffice 5.4)... 20631
 * Stopping ted service:  OK

# $TE_HOME/bin/ted start te-ooo-server
Starting (te-ooo-server) OOO server (LibreOffice 5.4)... 21096
 * Starting ted service:  OK

2.4.2 Statut des services de TE (`ted status`)

# $TE_HOME/bin/ted status
(te-request-server) TE Request server running (20743)
(te-rendering-server) TE Rendering server running (20801)
(te-tika-server) Tika server running (20692)
(te-ooo-server) OOO server (LibreOffice 5.4) running (20631)

Le script ted affiche pour chacun des quatre services s'ils sont en fonction ou non, et leur PID (Process Identifier).

Il est aussi possible d'interroger le status d'un service spécifique en spécifiant son nom :

# $TE_HOME/bin/ted status te-ooo-server
(te-ooo-server) OOO server (LibreOffice 5.4) running (21096)

2.4.3 Vérification des moteurs de transformation (`ted check`)

Le script ted permet de lancer une vérification des moteurs de transformations. Pour cela, il faut démarrer le serveur (voir ted start), et ensuite exécuter la commande suivante :

# $TE_HOME/bin/ted check
 
* Checking conversion from ODT to PDF...
  Ok: '/tmp/test.odtn27155.pdf' (7957 bytes)
 
* Checking conversion from ODT to PDF/A-1...
  Ok: '/tmp/test.odtQ27176.pdfa' (14430 bytes)
 
* Checking conversion from ODT to TXT...
  Ok: '/tmp/test.odtu27199.txt' (22 bytes)
 
[etc.]

Si le nom d'hôte/nom de domaine du système est mal configuré, les temps de conversion peuvent être long du fait de timeouts de résolution de noms lors de la connexion au serveur OOo. Pour corriger cela, le nom d'hôte (tel que retourné par la commande hostname) et le nom de domaine (tel que retourné par la commande dnsdomainname) doivent être corrects, et que le fichier /etc/hosts est correctement renseigné.

2.4.4 Nettoyage des répertoires de travail (`ted cleantmpfiles`)

L'option cleantmpfiles permet de supprimer les répertoires de travail des transformation nommés te-task-*, présents dans le répertoire $TE_WORK_DIR et qui ont plus de 7 jours (valeur par défaut).

# $TE_HOME/bin/ted cleantmpfiles

Le paramètre de la fonction permet de spécifier une autre durée (exprimée en jours).

Exemple pour supprimer les fichiers temporaires de plus de 15 jours :

# $TE_HOME/bin/ted cleantmpfiles 15

Pour effectuer le nettoyage régulièrement, La commande peut être placée dans une crontab.

2.4.5 Automatisation des démarrages/arrêts

Pour que TE démarre, et s'arrête, lors du démarrage, et l'arrêt, du système, le script ted doit être intégré au système d'initialisation de votre serveur.

Exemple pour les distributions de type RedHat et Debian :

Distribution de type RedHat: Les distributions de type RedHat utilisent la commande chkconfig pour administrer les scripts rc/init.

Faire un lien symbolique de $TE_HOME/bin/ted dans le répertoire /etc/rc.d/init.d/ :

# ln -sf $TE_HOME/bin/ted /etc/rc.d/init.d/ted

Enregistrer ted :

# chkconfig --add ted
# chkconfig ted on
# chkconfig --list ted
ted             0:arrêt 1:arrêt 2:marche        3:marche        4:marche        5:marche        6:arrêt

Distribution de type Debian: Les distributions de type Debian utilisent la commande update-rc.d pour administrer les scripts rc/init.

Faire un lien symbolique de $TE_HOME/bin/ted dans le répertoire /etc/init.d/ :

# ln -sf $TE_HOME/bin/ted /etc/init.d/ted

Enregistrer ted :

# update-rc.d ted defaults
Adding system startup for /etc/init.d/ted ...
 /etc/rc0.d/K20ted -> ../init.d/ted
 /etc/rc1.d/K20ted -> ../init.d/ted
 /etc/rc6.d/K20ted -> ../init.d/ted
 /etc/rc2.d/S20ted -> ../init.d/ted
 /etc/rc3.d/S20ted -> ../init.d/ted
 /etc/rc4.d/S20ted -> ../init.d/ted
 /etc/rc5.d/S20ted -> ../init.d/ted

2.5 Installation des WebUi (client)

Ces interfaces permettent de connecter Dynacase Platform au serveur TE et de monitorer ses principales fonctions.

Elles sont disponibles dans le Centre d'Administration de Dynacase Platform.

Elles sont distribuées par les modules dynacase-tengine-configuration (Dynacase TEngine Configuration) ou dynacase-tengine-monitor¹ (Transformation Engine Monitor) installables via Dynacase Control.

Le fonctionnement du serveur TE est indépendant de l'installation des interfaces Web clientes.

Ce module n'est disponible que sous licence Anakeen. ↩

Chapitre 3 Exploitation

3.1 Depuis le Centre d'Administration

L'installation des interfaces clientes permet d'accéder à des outils de test et de surveillance du serveur TE.

Figure 1. Surveillance TE

Configuration : paramétrage de Dynacase Platform pour la connexion au serveur TE
Transformation unitaire: permet de tester un moteur de transformation en fournissant un fichier
Autotest serveur : permet de lancer unitaire ou globalement les autotests disponibles sur le serveur et de contrôler leur résultat (fonction accessible en CLI sur le serveur).
Surveillance : offre des moyens de surveillance du serveur TE et des travaux qu'il traite

3.2 Configuration Dynacase

Elle est réalisée depuis le Centre d'Administration de Dynacase Platform.

L'interface suivante permet de modifier les différents paramètres agissant sur la connexion au serveur TE.

Figure 2. Configuration connexion TE

3.2.1 Paramètres

Activation du serveur de transformation: Indique si le serveur de transformation est utilisé pour cette instance de Dynacase Platform.
Activation de l'indexation plein texte avec le TE: Si activé, les différents fichiers de format supporté sont envoyés au serveur de transformation pour extraire les contenus textuels.
Adresse IP du serveur: Adresse IP (ou nom DNS) du serveur TE.
Port IP du serveur: Port TCP d'écoute du serveur TE.
URL pour les callback du serveur: URL d'accès à la racine du contexte Dynacase utilisée par le serveur TE pour signaler la fin des traitements au contexte Dynacase. Cette URL doit être accessible depuis le serveur TE.
Délai de connexion au serveur (secondes): Délai de connexion au serveur TE. Si la connexion au serveur TE ne peut pas être établie dans ce temps imparti, la connexion est mise en erreur.

3.2.2 Contrôle

Le bouton Contrôler la connexion au serveur permet de vérifier que les paramètres pour contacter le serveur TE (i.e. Adresse IP et port TCP) sont corrects.

Messages d'erreurs communs aux tests :

Ne peut pas se connecter au serveur TE : Erreur lors de la création d'une socket

Le serveur ne peut pas être contacté sur l'adresse ou le port paramétré.

Vérifier que le serveur est bien en écoute sur l'adresse et le port paramétré.

Ne peut pas se connecter au serveur TE : Erreur de négociation de la connexion

Le serveur n'a pas répondu correctement à l'initialisation de la connexion.

Vérifier que le serveur sur l'adresse et le port paramétré est bien un serveur TE.

Ne peut pas se connecter au serveur TE : Message de négociation de collection inattendu : [...]

Le serveur n'a pas répondu avec le message d'initialisation de connexion attendu.

Vérifier que le serveur sur l'adresse et le port paramétré est bien un serveur TE.

Ne peut pas envoyer la commande au serveur TE.

L'envoi d'une commande au serveur TE à échoué.

Le serveur a mis fin prématurément à la connexion (arrêt ou crash de celui-ci après l'établissement de la connexion).

Ne peut pas lire la réponse du serveur TE.

La lecture de la réponse à échouée.

Le serveur a mis fin prématurément à la connexion (arrêt ou crash de celui-ci après l'établissement de la connexion).

Taille de réponse invalide '[...]'

La réponse reçue par le serveur indique une taille <= 0.

Le serveur a mis fin prématurément à la connexion (arrêt ou crash de celui-ci après l'établissement de la connexion).

La donné retournée n'est pas de type array ([...])

La réponse du serveur est incorrecte.

Le serveur a mis fin prématurément à la connexion (arrêt ou crash de celui-ci après l'établissement de la connexion).

Messages d'erreurs spécifiques aux tests :

Vérification connexion au serveur

Le serveur n'a pas envoyé de réponse valide : la version du serveur n'est peut-être pas compatible.

La version du serveur est incompatible avec la librairie cliente.

Vérifier que la version du serveur TE est >= 1.4.0.
Création d'une nouvelle transformation

Échec de création de fichier temporaire.

Échec d'écriture du contenu dans le fichier temporaire '[...]'

La création d'un fichier temporaire sur Dynacase a échouée.

Vérifier qu'il y a suffisamment d'espace disque dans le répertoire temporaire de Dynacase.

Ne peut pas se connecter au serveur TE : Erreur lors de la création d'une socket

Le serveur ne peut pas être contacté sur l'adresse ou le port paramétré.

Vérifier que le serveur est bien en écoute sur l'adresse et le port paramétré.

Erreur lors de l'envoi du fichier

L'envoi du fichier a échoué.

Le serveur a mis fin prématurément à la connexion.
Attente du traitement de la transformation

Transformation échouée (status '%s').

La transformation est en échec.

Transformation interrompue (status '%s').

La transformation a été interrompue.
Attente du callback de la transformation

Le callback a échoué avec le message : [...]

La connexion de callback du serveur TE est en échec.

Vérifier que l'URL de callback paramétrée est correcte et permet de joindre correctement par HTTP le serveur Dynacase depuis le serveur TE.

3.3 Surveillance du serveur et des travaux

Figure 3. Surveillance et journaux

L'interface Surveillance permet de voir l'historique des tâches traités et des tâches en cours.

Pour chacune des tâches, l'interface permet de consulter le journal associé avec les éventuels messages d'erreurs.

3.4 Test du serveur

3.4.0.1 Lancement d'une transformation unitaire

Cette interface vous permet de sélectionner un fichier et indiquer quel moteur utiliser pour la transformation.

La liste des types MIME supportés par le moteur sélectionné est proposée.

Lorsque le traitement est lancé, l'interface met à jour son avancement en indiquant le statut de la conversion.

Figure 4. Conversion d'un fichier

3.4.0.2 Lancement des autotests serveur

L'interface permet de lancer l'ensemble des autotests serveur ou d'en sélectionner un en particulier.

Les résultats des conversions sont affichés (statut et journal).

Figure 5. Autotests

Chapitre 4 Fonctionnement

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.

Sur des architectures de production nous préconisons une installation systématique sur un serveur autonome. Les ressources consommées (disque, cpu et mémoire) par le serveur et ses moteurs peuvent fortement pénaliser le fonctionnement d'autres applications. ↩

4.2 Création d'un moteur

4.2.1 Protocole moteur

Un moteur est un exécutable (ou un shell-script) qui répond au protocole suivant :

Arguments

L'exécutable est appelé avec deux arguments qui sont :

le fichier à transformer (entrée) ;
un fichier temporaire (existant) dans lequel le résultat doit être inscrit (sortie).

Exit code

L'exécutable doit se terminer avec :

un exit code égal 0 si la conversion est réussie ;
un exit code différent de 0 si la conversion à échouée.

Messages d'erreurs

L'exécutable émet ses messages d'erreurs sur STDERR.

Variables d'environnement

Les variables d'environnement suivantes sont positionnées lors de l'exécution du moteur :

TE_HOME : contient le chemin d'accès à la racine du répertoire d'installation de TE.

Exemple de script Bash conforme au protocole des moteurs décrit ci-dessus :

#!/bin/bash
 
# Le premier argument est le fichier à transformer.
IN=$1
# Le deuxième argument est un fichier temporaire dans lequel
# sera inscrit le résultat.
OUT=$2
 
# Notre moteur compte simplement le nombre de lignes
# dans le fichier d'entré, et inscrit le résultat dans 
# le fichier de sortie.
wc -l "$IN" > "$OUT"
 
if [ $? -ne 0 ]; then
    # En cas d'erreur, on émet un message sur STDERR
    echo "Erreur lors de l'exécution du moteur." 1>&2
    # Et on se termine avec un exit code <> 0
    exit 1
fi
 
# La conversion est réussi, on se termine avec
# un exit code = 0
exit 0

4.2.2 Enregistrement d'un moteur

Pour être utilisable par TE, le moteur doit être exécutable et être déposé dans le répertoire $TE_HOME/lib/engines.

Ensuite, le moteur doit être enregistré auprès de TE afin de déclarer son non de conversion et les types MIME des fichiers qu'il supporte en entrée.

L'enregistrement des moteurs est géré dans la table engine :

INSERT INTO engine (name, mime, command, comment) VALUES (
    'linecount',
    'text/plain',
    '@TE_HOME@/lib/engines/linecount',
    'Compte le nombre de lignes dans un fichier texte'
);

Dans l'exemple ci-dessus, on déclare que notre shell-script aura comme nom de transformation linecount et qu'il est compatible avec les fichiers texte brut de type MIME text/plain.

Notes :

La chaîne @TE_HOME@ sera automatiquement remplacée par la racine du répertoire d'installation de TE lors de l'exécution du moteur.

4.3 Classe \Dcp\TransformationEngine\Client

La classe \Dcp\TransformationEngine\Client implémente l'API cliente pour l'utilisation d'un serveur TE.

Cette API cliente est fourni par le module dynacase-tengine-client.

Elle permet de soumettre des fichiers pour transformation, récupérer le status des tâches ainsi créés, récupérer le fichier produit par ces tâches et interrompre des tâches.

4.3.1 Constructeur

new \Dcp\TransformationEngine\Client( string $host, int $port )

4.3.1.1 Liste des paramètres

(string) host: Le nom d'hôte (ou l'adresse IP) du serveur TE auquel doit se connecter le client.
(int) port: Le port TCP du serveur TE auquel doit se connecter le client.

4.3.1.2 Exemples

L'adresse et le port renseignés dans les paramètres applicatifs de Dynacase sont accessibles avec la fonction \ApplicationParameterManager::getScopedParameterValue() et les paramètres TE_HOST et TE_PORT :

$clientTE = new \Dcp\TransformationEngine\Client(
    \ApplicationParameterManager::getScopedParameterValue("TE_HOST"),
    \ApplicationParameterManager::getScopedParameterValue("TE_PORT")
);

4.3.1.3 Notes

Aucune.

4.3.1.4 Voir aussi

Aucun.

4.3.2 Client::sendTransformation

Envoi d'un fichier pour transformation.

4.3.2.1 Description

string sendTransformation ( string $te_name,
                            string $fkey,
                            string $filename,
                            string $callback,
                             array & $info )

Crée une tâche pour la transformation du fichier $filename avec le moteur de transformation $te_name.

L'identifiant de la tâche (tid) crfée sur le serveur TE est retourné dans la structure $info.

Si une URL de callback est fournie via l'argument $callback, celle-ci est alors appelée lorsque la conversion est terminée avec un argument HTTP tid contenant l'identifiant de la tâche : c'est alors à la charge du code déclenché par le callback de venir récupérer le résultat à l'aide de l'identifiant de la tâche tid.

Le code peut aussi interroger régulièrement le serveur TE pour voir le status de la tâche à l'aide de l'identifiant tid retourné dans la structure $info (voir getInfo()).

Le client soumet une transformation avec l'URL de callback : http://localhost/dynacase/?app=TEST&action=CALLBACK
Lorsque la tâche de transformation est terminée, le serveur TE appelle l'URL de callback en y ajoutant la variable HTTTP tid contenant la valeur de l'identifiant de la tâche : http://localhost/dynacase/?app=TEST&action=CALLBACK&tid=54c8a79a4780d2.85897641
L'action CALLBACK de l'application TEST est alors exécutée.
L'action peut alors récupérer le résultat de la tâche en faisant une requête de récupération de résultat avec l'identifiant de la tâche ainsi obtenu.

4.3.2.1.1 Avertissements

4.3.2.2 Liste des paramètres

(string) te_name: Le nom du moteur de transformation à appliquer.
(string) fkey: Un identifiant à la discrétion de l'appelant.
(string) filename: Le chemin d'accès du fichier à convertir.
(string) callback: L'URL à appeler à la fin de la transformation.
[out] (array) info: Informations retournées de la tâche créée sur le serveur TE.

4.3.2.3 Valeur de retour

La méthode sendTransformation() retourne une chaîne non vide, contenant un message d'erreur, si la création de la tâche de transformation a échoué, ou une chaîne vide si la transformation a été correctement soumise au serveur.

Si la transformation a été correctement soumise au serveur, la variable $info contient les informations de la tâche créée sur le serveur :

array(
    'status'  => (string) $taskStatus,
    'tid'     => (string) $taskId,
    'comment' => (string) $transformationComment
)

Liste des constantes de statut de tâche :

\Dcp\TransformationEngine\Client::TASK_STATE_BEGINNING (B): Demande de conversion reçue.
\Dcp\TransformationEngine\Client::TASK_STATE_TRANSFERRING (T): Lecture/transfert du fichier à convertir.
\Dcp\TransformationEngine\Client::TASK_STATE_ERROR (K): Erreur.
\Dcp\TransformationEngine\Client::TASK_STATE_SUCCESS (D): Transformation réussie.
\Dcp\TransformationEngine\Client::TASK_STATE_PROCESSING (P): En cours de traitement.
\Dcp\TransformationEngine\Client::TASK_STATE_WAITING (W): Attente de traitement par le moteur.
\Dcp\TransformationEngine\Client::TASK_STATE_INTERRUPTED (I): Interrompue.

Si la transformation n'a pas pu être soumise au serveur ($err retourné != chaîne vide), la variable $info contient le code de l'erreur dans la propriété status :

array(
    'status' => \Dcp\TransformationEngine\Client::error_connect |
                \Dcp\TransformationEngine\Client::error_noengine |
                \Dcp\TransformationEngine\Client::error_sendfile |
                \Dcp\TransformationEngine\Client::error_emptyfile
)

Les constantes de code d'erreur sont :

\Dcp\TransformationEngine\Client::error_connect

Le client n'a pu établir une connexion avec le serveur TE.

Vérifier que les paramètres de connexion TE_HOST et TE_PORT sont corrects et que le client peut se connecter sur l'hôte et le port TCP du serveur TE).

\Dcp\TransformationEngine\Client::error_noengine

Le nom du moteur de transformation demandé n'est pas connu par le serveur TE.

Vérifier que le moteur demandé est bien déclaré sur le sereur TE.

\Dcp\TransformationEngine\Client::error_sendfile

Le fichier n'a pu être envoyé correctement au serveur TE.

Voir le message d'erreur retourné par sendTransformation() pour plus de détails sur l'erreur rencontrée.

\Dcp\TransformationEngine\Client::error_emptyfile

Le fichier soumis pour transformation n'existe pas ou est vide.

Vérifier que le fichier $filename soumis pour transformation existe et n'est pas vide.

4.3.2.4 Erreurs / Exceptions

4.3.2.5 Historique

4.3.2.6 Exemples

/* Un fichier texte */
$filename = '/tmp/hello.txt';
$textContent = 'Hello world.';
file_put_content($filename, $textContent);
 
/* On envoi une demande de conversion du fichier texte en PDF */
$fkey = sprintf("test-conversion-%s", uniqid());
$callback = '';
$info = array();
$err = $clientTE->sendTransformation(
    'pdf',     /* Nom de la conversion à appliquer : 'pdf' */
    $fkey,     /* Identifiant de la conversion côté Dynacase */
    $filename, /* Chemin du fichier à convertir */
    $callback, /* URL de callback pour la notification de fin de tâche */
    $info      /* Information en retour de la tâche de conversion créée */
);
if ($err != '') {
    throw new Exception(sprintf("sendTransformation() returned with error: %s", $err));
}
/* Si la demande est accceptée, l'identifiant de la conversion
 * est retourné dans la structure $info
 */
var_export($info);

array(3) {
  'tid'     => "54c8a79a4780d2.85897641",
  'status'  => "W",
  'comment' => "13 bytes read in 0.005 sec"
}

4.3.2.7 Notes

4.3.2.8 Voir aussi

getInfo()

4.3.3 Client::getInfo

Récupérer les informations sur une tâche de transformation.

4.3.3.1 Description

string getInfo ( string $tid,
                  array & $info )

Une fois la tâche soumise (à l'aide de [sendTransformation()][Client::sendTransformation]), le client peut interroger régulièrement (ou dans le code exécuté par le callback du serveur TE) la tâche à partir de sontid` pour voir si elle est terminée (ou en attente, ou en échec, etc.).

4.3.3.1.1 Avertissements

4.3.3.2 Liste des paramètres

(string) tid: Identifiant de la tâche dont on souhaite obtenir les informations.
[out] (array) info: Informations retournées de la tâche.

4.3.3.3 Valeur de retour

La méthode getInfo() retourne une chaîne non vide, contenant le message d'erreur, si la demande d'information a échoué, ou une chaîne vide si la demande d'information est réussie.

Si la demande d'information est réussie, la variable $info contient les informations de la tâche.

Les propriétés de $info peuvent être :

array(
    'tid'        => (string) $taskId,
    'infile'     => (string) $inputFile,
    'inmime'     => (string) $inputFileMimeType,
    'outfile'    => (string) $outputFile,
    'engine'     => (string) $transformationName,
    'status'     => (string) $status,
    'callback'   => (string) $clientCallbackURL,
    'callreturn' => (string) $callbackReturn,
    'fkey'       => (string) $clientForeignKey,
    'pid'        => (string) $transformationPID,
    'comment'    => (string) $transformationComment
)

tid

Identifiant de la tâche.

infile

Chemin d'accès (sur le serveur) du fichier à transformer.

inmime

Type MIME du fichier à transformer.

outfile

Chemin du fichier résultat de la transformation.

engine

Moteur de transformation demandé par le client.

status

Status de la tâche (voir Cycle de traitement des demandes).

Liste des constantes de statut de tâche :

\Dcp\TransformationEngine\Client::TASK_STATE_BEGINNING (B): Demande de conversion reçue.
\Dcp\TransformationEngine\Client::TASK_STATE_TRANSFERRING (`T): Lecture/transfert du fichier à convertir.
\Dcp\TransformationEngine\Client::TASK_STATE_ERROR (K): Erreur.
\Dcp\TransformationEngine\Client::TASK_STATE_SUCCESS (D): Transformation réussie.
\Dcp\TransformationEngine\Client::TASK_STATE_PROCESSING (P): En cours de traitement.
\Dcp\TransformationEngine\Client::TASK_STATE_WAITING (W): Attente de traitement par le moteur.
\Dcp\TransformationEngine\Client::TASK_STATE_INTERRUPTED (I): Interrompue.

callback

URL de callback fournie par le client.

callreturn

Message retourné par l'appel à l'URL de callback.

fkey

Clef fkey soumise par le client lors de la demande de transformation.

pid

Le PID du processus de transformation lorsque celui-ci tourne.

comment

Dernier message de la tâche.

4.3.3.4 Erreurs / Exceptions

La méthode retourne une chaîne non vide contenant le message d'erreur si les informations de la tâche n'ont pu être récupérées.

4.3.3.5 Historique

4.3.3.6 Exemples

$tid = '54c8a79a4780d2.85897641';
$info = array();
$err = $te->getInfo(
    $tid, /* Identifiant de la tâche qu'on souhaite interroger */
    $info
);
if ($err != '') {
    throw new Exception(sprintf("getInfo() returned with error: %s", $err));
}
var_export($info);

array (
  'tid' => "54c8a79a4780d2.85897641",
  'infile' => "/var/tmp/tes-6FDTUK.txt",
  'inmime' => "text/plain;",
  'outfile' => "/var/tmp/ter-xbpYHM.pdf",
  'engine' => "pdf",
  'status' => "D",
  'callback' => "",
  'callreturn' => "",
  'fkey' => "",
  'pid' => "15678",
  'comment' => "generated by [/opt/te/lib/engines/txt2pdf] command; "
)

4.3.3.7 Notes

4.3.3.8 Voir aussi

4.3.4 Client::getTransformation

Récupérer le fichier produit par la transformation.

4.3.4.1 Description

string getTransformation ( string $tid,
                           string & $outputFile )

Permet de récupérer dans le fichier local $outputFile le résultat de la transformation d'identifiant de tâche $tid.

4.3.4.1.1 Avertissements

4.3.4.2 Liste des paramètres

(string) tid: Identifiant de la tâche dont on souhaite obtenir le fichier résultant.
(string) outputFile: Chemin local du fichier dans lequel sera stocké le fichier résultant de la tâche.

4.3.4.3 Valeur de retour

La méthode getTransformation() retourne une chaîne non vide, contenant le message d'erreur, si l'opération n'a pu être réalisée, ou une chaîne vide si l'opération est réussie.

4.3.4.4 Erreurs / Exceptions

La méthode retourne une chaîne non vide contenant le message d'erreur si l'opération n'a pu être réalisée.

4.3.4.5 Historique

4.3.4.6 Exemples

$tid = '54c8a79a4780d2.85897641';
$tmpFile = tempnam(getTmpDir(), 'test');
$err = $te->getTransformation(
    $tid,    /* Identifiant de la tâche dont on souahite récupérer le résultat */
    $tmpFile /* Fichier dans lequel inscrire le résultat */
);
if ($err != '') {
    throw new Exception(sprintf("getTransformation() returned with error: %s", $err));
}
printf("Fichier '%s' : %d octets\n", $tmpFile, filesize($tmpFile));

Fichier '/var/www/dynacase/var/tmp/dcp/test1f3ic0' : 2729 octets.

4.3.4.7 Notes

4.3.4.8 Voir aussi

4.3.5 Client::abortTransformation

Interrompre une tâche.

4.3.5.1 Description

string abortTransformation ( string $tid )

Permet d'interrompre le traitement d'une tâche.

4.3.5.1.1 Avertissements

4.3.5.2 Liste des paramètres

(string) tid: Identifiant de la tâche dont on souhaite interrompre le traitement.

4.3.5.3 Valeur de retour

La méthode abortTransformation() retourne une chaîne non vide contenant le message d'erreur si l'opération n'a pu être réalisée, ou une chaîne vide si l'opération est réussie.

4.3.5.4 Erreurs / Exceptions

La méthode retourne une chaîne non vide contenant le message d'erreur si l'opération n'a pu être réalisée.

4.3.5.5 Historique

4.3.5.6 Exemples

$tid = '54c8a79a4780d2.85897641';
$err = $clientTE->abortTransformation(
    $tid /* Identifiation de la tâche qu'on souhaite interrompre */
);
if ($err != '') {
    throw new Exception(sprintf("abortTransformation() returned with error: %s", $err));
}

4.3.5.7 Notes

L'interruption de la tâche :

tue le processus de rendering si ce dernier est actif (pid de la tâche != 0) ;
les fichiers infile et outfile de la tâche sont conservés jusqu'à ce que la tâche soit supprimée.

4.3.5.8 Voir aussi

4.3.6 Client::purgeTransformation

Supprime la demande de transformation.

4.3.6.1 Description

string purgeTransformation ( string $tid, )

Les fichiers d'entrée et de sortie liés à la tâche sont supprimés ainsi que la référence à la tâche.

4.3.6.1.1 Avertissements

La suppression ne vérifie pas si la tâche est en cours d'exécution. Par conséquent, si la demande est en cours d'exécution il faut au préalable l'interrompre (voir méthode abortTransformation()).

4.3.6.2 Liste des paramètres

(string) tid: Identifiant de la tâche qu'on souhaite supprimer.

4.3.6.3 Valeur de retour

La méthode getTransformation() retourne une chaîne non vide, contenant le message d'erreur, si l'opération n'a pu être réalisée, ou une chaîne vide si l'opération est réussie.

4.3.6.4 Erreurs / Exceptions

La méthode retourne une chaîne non vide contenant le message d'erreur si l'opération n'a pu être réalisée.

4.3.6.5 Historique

Aucun.

4.3.6.6 Exemples

$tid = '54c8a79a4780d2.85897641';
$err = $te->getInfo($tid, $info);
if ($info['status'] == \Dcp\TransformationEngine\Client::TASK_STATE_PROCESSING) {
    throw new Exception("La transformation est en cours d'exécution. Veuillez d'abord l'interrompre.");
}
$err = $te->purgeTransformation($tid)
if ($err != '') {
    throw new Exception(sprintf("Erreur lors de la suppression de la transformation '%s': %s", $tid, $err));
}

4.3.6.7 Notes

Aucune.

4.3.6.8 Voir aussi