Que sont les Assembly Instructions ?

Les Assembly Instructions de Transloadit définissent les Steps nommés d’un flux de traitement de fichiers. Chaque Step sélectionne un Robot et ses paramètres ; le paramètre use détermine la façon dont les fichiers téléversés, importés ou générés circulent entre les Steps.

Fonctionnement des Assembly Instructions

Les Instructions forment un graphe de traitement orienté acyclique, exprimé sous forme de configurations nommées de Steps et de relations définissant leurs entrées. Chaque Step sélectionne un Robot et des paramètres, tandis que use détermine quels fichiers téléversés ou résultats précédents l’alimentent. Les Steps qui importent ou génèrent des fichiers peuvent omettre use lorsqu’ils ne dépendent pas d’un Step antérieur. Les autres Steps qui omettent use sont implicitement reliés à la sortie du Step précédent ; le premier Step déclaré utilise :original par défaut. Déclarez use explicitement lorsque l’ordre des Steps ne doit pas déterminer le graphe. Le nom réservé de Step :original désigne les fichiers téléversés. Un Step déclaré sous ce nom peut uniquement exécuter le Robot /upload/handle, et aucun autre Step ne peut exécuter ce Robot ; une valeur de use peut faire référence à :original sans le déclarer comme Step. Le document Instructions est distinct d’une Assembly, qui est une exécution du graphe, et d’un Template, qui conserve les Instructions pour les réutiliser. Avant le début du traitement des médias, Transloadit vérifie que chaque Step est un objet bien formé désignant un Robot existant, que chaque référence use déclarée peut être résolue et que le graphe ne contient aucun cycle.

Points clés

  1. Les noms des Steps sont des identifiants du graphe. Si use désigne un Step qui n’existe pas, Transloadit rejette l’Assembly avec ASSEMBLY_STEP_UNKNOWN_USE (HTTP 400) avant le début du traitement.
  2. Les résultats d’un Step peuvent alimenter plusieurs Steps ultérieurs ; chaque version dérivée n’a donc pas besoin de son propre téléversement ou de sa propre importation. Ces Steps s’exécutent en parallèle dès que leur Step d’entrée produit des fichiers. Avec des valeurs use explicites, l’ordre de déclaration des Steps ne détermine donc pas l’ordre de production ou d’exportation des résultats. L’ordre de déclaration n’a d’importance que lorsqu’un Step omet use et se trouve implicitement relié au Step précédent.
  3. Un Template évite d’inclure la logique réutilisable du flux de travail dans les requêtes des clients. Par défaut, les clients peuvent remplacer les Steps ; définissez le paramètre allow_steps_override sur false dans le Template pour que les requêtes qui fournissent encore des Steps soient rejetées avec TEMPLATE_DENIES_STEPS_OVERRIDE (HTTP 400). Ce réglage concerne uniquement les Steps : les autres paramètres de requête sont toujours fusionnés avec ceux du Template et ont priorité sur eux. Pour empêcher des appelants non fiables de les modifier, exigez Signature Authentication (via le réglage du Workspace ou le paramètre require_signature_auth du Template) et chargez un serveur de confiance de signer uniquement les paramètres qu’il approuve. Cette exigence s’applique aux requêtes authentifiées avec une Auth Key ; les jetons porteurs valides la contournent. Une signature couvre uniquement params sous forme sérialisée. Les champs du formulaire de téléversement envoyés à ses côtés ne sont pas signés, alimentent ${fields.*} et ont priorité sur les valeurs de même nom dans la clé signée fields. Ainsi, un Template verrouillé qui construit un chemin de stockage ou un autre réglage à partir de ${fields.*} permet toujours à l’appelant de choisir cette valeur.
  4. Un Step qui ne produit rien n’a pas nécessairement échoué. Par défaut, un Robot ignore les types de fichiers qu’il ne prend pas en charge (l’exemple de la documentation montre que /video/encode ignore les images), de sorte qu’une branche peut simplement ne rien produire pour ces fichiers. Utilisez /file/filter pour acheminer délibérément des téléversements de types variés ; la documentation réserve force_accept au débogage et aux cas particuliers.

Quand les Assembly Instructions sont utiles

Enregistrez les Instructions dans un Template lorsque les appelants doivent réutiliser un flux de travail géré côté serveur. Si les appelants ne doivent pas modifier ses Steps, définissez le paramètre allow_steps_override sur false ; pour les empêcher également de modifier les autres paramètres de requête, exigez Signature Authentication pour les requêtes effectuées avec votre Auth Key. Aucun de ces deux contrôles ne couvre les champs du formulaire de téléversement ; ne déduisez donc pas de ${fields.*} un réglage dont les appelants ne doivent pas pouvoir choisir la valeur. Lorsque vous générez des Instructions ou renommez des Steps, vérifiez que chaque valeur de use fait référence à un nom de Step déclaré ou à :original afin que l’Assembly soit validée.

Comment Transloadit facilite l’utilisation des Assembly Instructions

Transloadit valide et exécute les Assembly Instructions en tant que flux de travail d’une Assembly. Chaque Step nommé appelle un Robot pour téléverser, importer, traiter, analyser, stocker ou servir des fichiers, et le paramètre use achemine les résultats entre les Steps. Un Template stocke des Instructions pour les réutiliser, une Assembly correspond à une exécution de ces Instructions, et l’Assembly Status ainsi que les notifications rendent compte du résultat.

Explorer les fonctionnalités de la plateforme Transloadit

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle

Reliez les téléversements, le traitement, l’IA, le stockage et la diffusion via une seule API déclarative — la pile d’encodage, la montée en charge et l’évolution constante des formats sont prises en charge pour vous.

Essayer Transloadit gratuitement