Petite histoire du pilotage d’Adobe InDesign dans Simple Workspace

La petite histoire

InDesign est né en 1999. Tiens, justement comme J2S ! Le marché savait que avions développé des extensions pour QuarkXPress, qui était depuis belle lurette le leader des logiciels de PAO ¹. Très naturellement, notre réseau nous demanda d’automatiser le fonctionnement de la nouvelle solution d’Adobe.

C’était donc bien avant que la version Serveur ² d’InDesign sortie (en 2005). Celle-ci apportera un moyen officiel de piloter InDesign de l’extérieur. Moyen officiel, car pour la petite histoire, la licence EULA d’Adobe (Adobe End User Licence Agreement) interdisait l’utilisation de la version de bureau dans ce type de contexte automatisé

Puisqu’il n’existait aucune solution sur le marché, nous développâmes nos propres outils.

Les premiers plug-ins

Adobe InDesign est conçu dès le départ comme un ensemble de plug-ins. Il fut immédiatement fourni avec un SDK qui permet d’en développer d’autres, qui peuvent d’ailleurs intervenir très intimement dans le fonctionnement du logiciel.

C’est ainsi qu’est né J2S NetToolbox. Ce plug-in ouvre Adobe InDesign à l’extérieur. Il offre la possibilité d’effectuer des requêtes via le réseau, au format XML. (On parle d’XML-RPC.)

Il prend en charge les requêtes fondamentales comme ouvrir un document, le fermer, le sauvegarder, l’exporter, etc. Il a été rejoint rapidement par son petit frère, J2S LayoutToolbox. Celui-ci peut lui-même être vu comme une extension de J2S NetToolbox puisqu’il apporte un type de requête supplémentaire, et crucial : la mise en page automatique ³.

J2S Dispatcher, performances constantes et continuité de service

Dans un contexte de production, nous nous sommes rapidement rendu compte que nous avions besoin d’un pilote : celui-ci devait faire le lien entre l’émetteur de la requête et Adobe InDesign (version de bureau à l’époque). C’est ainsi que J2S Dispatcher est né. Ce choix s’est renforcé quand InDesign Serveur est arrivé. Sur un serveur où il s’agit de faire fonctionner un grand nombre d’instances, l’utilisation de J2S Dispatcher a été une évidence.

J2S Dispatcher a deux objectifs :

• La continuité de service ;
• Le maintien d’un niveau de performance constant.

J2S Dispatcher surveille en permanence les instances qu’il contrôle : il vérifie qu’elles répondent normalement, qu’elles sont bien exécutées, qu’elles ne consomment pas trop de mémoire ou qu’elles en ont assez, etc. Le cas échéant, les instances sont lancées ou relancées. À ce niveau, l’objectif est de disposer d’un état précis des instances pour gérer au mieux les requêtes qu’il faudra leur envoyer.

Enfin, J2S Dispatcher — comme son nom l’indique — distribue les requêtes entre les différentes instances qu’il a à gérer. Il effectuera un choix en fonction des versions d’InDesign bien sûr, mais aussi en fonction des disponibilités de celles-ci. Quand toutes les instances sont occupées, et bien, les requêtes sont mises en attente…

Le futur

Les versions d’InDesign s’enchaînent désormais très rapidement. Nous effectuons un travail de veille permanent pour permettre de suivre ce rythme tout en garantissant la meilleure continuité de service possible ⁴. (Avec prudence, puisque J2S Dispatcher permet de servir des versions différentes d’Adobe InDesign, les plus récentes sont mises en service progressivement.)

En parallèle, nous travaillons sur les futures architectures qui permettront une plus grande souplesse d’organisation et une résilience encore meilleure ⁵. Ces projets tiennent compte de l’évolution à grande vitesse des architectures Cloud. Par exemple, ces nouvelles architectures continueront de servir des machines locales, mais elles permettront aussi d’envoyer des requêtes vers d’autres centres de données

L’informatique ne s’arrête jamais.

Vous le voyez, nous sommes des experts de ce sujet : quelle que soit votre situation, nous pouvons vous aider. Contactez-nous : nous serons ravis d’échanger.

JY. Jourdain

Cofondateur de J2S