Préproduction

Chez J2S

Comment faisons-nous pour réguler les performances de Simple Workspace ?

Nos utilisateurs travaillent quotidiennement avec Simple Workspace, qui se présente de manière classique sous la forme d’une application Web.

Rien de plus simple !

La plateforme Simple Workspace est capable de gérer en entrée des flux de données produit, des articles de presse, des images, des documents InDesign, etc. Elle met à disposition des workflows paramétrables pour gérer ces flux entrants.

Elle peut générer des catalogues, des livres, des fiches, etc. regroupés dans des chemins de fer, et met à disposition des workflows pour gérer les flux de travail inhérents, tels que les relectures, les validations, les traductions.

Elle produit in-fine des données validées, des PDF, des fichiers InDesign ou Excel, etc.

Elle est utilisée par de nombreuses entreprises, chacune ayant des modèles de données, des flux de travail de production, des documents finaux très différents les uns des autres.

Comment la plateforme Simple Workspace, sollicitée 24/24, conserve-t-elle un niveau de performance régulier, qu’il s’agisse de fiabilité ou de régularité des temps de réponse ? Comment cloisonne-t-elle chaque client et la confidentialité de leurs données, comment permet-t-elle des mises à jour régulières mais également cloisonnées et étagées ?

Simple Workspace évolue en permanence !

Simple Workspace évolue en permanence !

Vous vous en doutez, il n’y a pas de miracle !

Derrière cette régularité, il y a bien entendu une équipe humaine qui depuis des années a construit et fait évoluer la plateforme, un ensemble de briques logicielles élémentaires qui ont été assemblées logiquement et coopèrent pour optimiser leur temps de réponse, optimisation qui repose tant sur le hardware que sur la manière dont ces briques interagissent entre elles.

Avec cet article, je vous propose d’aborder deux exemples qui illustrent la manière dont Simple Workspace a été architecturé pour obtenir ses performances et sa fiabilité générale, et qui permettent à la plateforme d’évoluer régulièrement sans ruptures.

Lorsqu’un utilisateur se connecte, la phase d’authentification l’aiguille vers un ou des espaces de travail , dont les contenus sont filtrés. C’est à ce moment-là qu’est récupérée la liste des tâches de l’utilisateur, qui peuvent le guider vers des éléments précis, comme des produits à valider, des pages à relire, etc. Ses actions génèrent des requêtes qui sont dirigées vers l’un des serveurs « frontaux » disponible.

La notion d’espace de travail est importante. En pratique, il s’agit des espaces présentés à l’utilisateur dans l’interface. Chaque espace peut disposer de ses propres bases de données : c’est là l’une des clés de l’architecture, qui explique par exemple en quoi le DAM d’une entreprise est une base différente du DAM d’une autre entreprise au sein de Simple Workspace, ou en quoi une même entreprise peut utiliser plusieurs DAM.

Ce cloisonnement physique a plusieurs conséquences, dont la sécurité (une base ne peut impacter le fonctionnement d’une autre base), les performances et leur régularité (les actions de l’un n’impactent pas les actions de l’autre), la flexibilité (chaque base contient des données différemment décrites), la souplesse (on peut recopier des bases, voire utiliser des bases dans des versions différentes, pour évaluer les conséquences d’une montée de version par exemple).

La notion de bases multiples ne concerne pas que le DAM : le BRIEF (chemin de fer) ainsi que le MOM (bases de données source) sont également des bases réparties au sein des espaces de travail. En fait, toutes les applications Simple Workspace bénéficient de cette conception cloisonnée.

Vous vous en doutez, répartir ainsi des milliers de bases de données demande une orchestration. Elles doivent coopérer entre elles, comme par exemple lorsqu’on glisse une image dans une fiche produit ou dans une page ou un article de presse. Cette orchestration des espaces de travail et des bases qu’elles contiennent (ou héritent) repose elle-même sur des bases réparties, des bases « qui gèrent des bases ».

Autre thème, le fonctionnement des serveurs InDesign, objet de toutes les attentions : le temps de réponse d’une tâche confiée à un serveur InDesign est en effet crucial pour l’utilisateur, qu’il s’agisse de générer des centaines de pages ou la prévisualisation d’un article.

Pour gérer cela, Simple Workspace met en œuvre ce que nous nommons en interne des « dispatchers », que l’on peut voir comme des « aiguilleurs » qui d’un côté reçoivent des demandes de travaux (par exemple, générer le rendu d’une fiche produit), et de l’autre connaissent les services InDesign disponibles les plus appropriés et leur affectent le travail, puis retournent la réponse vers l’utilisateur – qui voit alors le rendu sous la forme d’une image.

Choisir le service InDesign le plus approprié est un exercice délicat, qui repose entre autre sur la connaissance des services libres (qui ne sont pas en train de générer un document par exemple), et le fait que les images dont le service InDesign aura besoin sont disponibles et accessibles rapidement : rien n’est laissé au hasard pour que le document InDesign soit traité aussi rapidement que possible. Au pire, si tous les services InDesign sont occupés, alors la tâche attend une libération : on parle alors de contention. Mais nous avons suffisamment de services parallèles pour que cela n’arrive qu’exceptionnellement !

Je n’ai jusqu’ici pas abordé l’infrastructure hardware sous-jacente, or elle est elle-même très sophistiquée et redondante, pour offrir un service fiable et résilient. Cette infrastructure contribue à la « scalabilité » de Simple Workspace, c’est-à-dire à la capacité de Simple Workspace à devenir plus puissant pour accueillir des clients plus nombreux, ainsi qu’absorber les pics de charge, comme lorsque plusieurs clients ont des cycles de production qui se superposent.

Il y aurait beaucoup (vraiment beaucoup) d’autres thèmes à aborder, dont chacun a mobilisé les équipes J2S à un moment donné pour d’une part, effectuer des choix pérennes et optimisés, et d’autre part, les mettre en œuvre, les tester et les suivre. Mais cela sera l’occasion d’autres articles !

Lisez la suite de cet article !

Prenez contact  avec nous : nous serons ravis d’échanger.

D. Lantier

Business Developer

(Article Chez J2S du 23/3/2023)