Développement d’une application personnalisée develop

Avant de commencer à développer une application personnalisée :

Création d’une application personnalisée create-custom-application

Assurez-vous qu’Adobe aio-cli est installé localement.

Voir Exemples d’applications personnalisées pour consulter des exemples et des idées d’applications personnalisées.

Ajout des informations d’identification add-credentials

Lorsque vous vous connectez tandis que l’application est en train de se créer, la plupart des informations d’identification d’App Builder sont collectées dans votre fichier ENV. Toutefois, l’utilisation de l’outil de développement nécessite des informations d’identification supplémentaires.

Informations d’identification pour le stockage de l’outil de développement developer-tool-credentials

L’outil permettant à l’équipe de développement d’évaluer des applications personnalisées à l’aide du Asset Compute service nécessite l’utilisation d’un conteneur d’espace de stockage dans le cloud. Ce conteneur est essentiel pour stocker les fichiers de test ainsi que pour la réception et la présentation des rendus produits par les applications.

Assurez-vous d’avoir accès à un conteneur de stockage dans le cloud pris en charge. Ce conteneur est utilisé collectivement par plusieurs développeurs et développeuses pour différents projets, le cas échéant.

Ajouter des informations d’identification au fichier ENV add-credentials-env-file

Insérez les informations d’identification suivantes de l’outil de développement dans le fichier .env. Le fichier se trouve à la racine de votre projet App Builder :

Exécuter l’application run-custom-application

Avant d’exécuter l’application avec l’outil de développement Asset Compute, configurez correctement les informations d’identification.

Pour exécuter l’application dans l’outil de développement, utilisez la commande aio app run. L’action est déployée sur Adobe I/O Runtime et lance l’outil de développement sur votre ordinateur local. Cet outil est utilisé pour tester les demandes des applications au cours du développement. Voici un exemple de demande de rendu :

"renditions": [
    {
        "worker": "https://1234_my_namespace.adobeioruntime.net/api/v1/web/example-custom-worker-master/worker",
        "name": "image.jpg"
    }
]

Voir ici comment tester et déboguer votre application. Lorsque vous avez terminé de développer votre application personnalisée, déployez-la.

Essai de l’exemple d’application fourni par Adobe try-sample

Voici des exemples d’applications personnalisées :

Modèle d’application personnalisée template-custom-application

worker-basic est un modèle d’application. Il génère un rendu en copiant simplement le fichier source. Le contenu de cette application est le modèle reçu lors du choix d’Adobe Asset Compute lors de la création de l’application aio.

Le fichier de l’application worker-basic.js utilise le asset-compute-sdk pour télécharger le fichier source, orchestrer le traitement de chaque rendu et charger les rendus résultants dans l’espace de stockage dans le cloud.

Le renditionCallback défini dans le code de l’application permet d’exécuter toute la logique de traitement de l’application. Le rappel de rendu de worker-basic copie simplement le contenu du fichier source dans le fichier de rendu.

const { worker } = require('@adobe/asset-compute-sdk');
const fs = require('fs').promises;

exports.main = worker(async (source, rendition) => {
    // copy source to rendition to transfer 1:1
    await fs.copyFile(source.path, rendition.path);
});

Appel d’une API externe call-external-api

Dans le code de l’application, vous pouvez effectuer des appels API externes pour faciliter le traitement de l’application. Vous trouverez ci-dessous un exemple de fichier d’application appelant une API externe.

exports.main = worker(async function (source, rendition) {

    const response = await fetch('https://adobe.com', {
        method: 'GET',
        Authorization: params.AUTH_KEY
    })
});

Par exemple, worker-animal-pictures effectue une requête de récupération d’une URL statique à partir de Wikimedia à l’aide de la bibliothèque node-httptransfer.

Transmission de paramètres personnalisés pass-custom-parameters

Vous pouvez transmettre des paramètres personnalisés définis à l’aide des objets de rendu. Ils peuvent être référencés dans l’application au moyen de rendition instructions. Voici un exemple d’objet de rendu :

"renditions": [
    {
        "worker": "https://1234_my_namespace.adobeioruntime.net/api/v1/web/example-custom-worker-master/worker",
        "name": "image.jpg",
        "my-custom-parameter": "my-custom-parameter-value"
    }
]

Voici un exemple de fichier d’application accédant à un paramètre personnalisé :

exports.main = worker(async function (source, rendition) {

    const customParam = rendition.instructions['my-custom-parameter'];
    console.log('Custom paramter:', customParam);
    // should print out `Custom parameter: "my-custom-parameter-value"`
});

example-worker-animal-pictures transmet un paramètre personnalisé animal pour déterminer le fichier à récupérer auprès de Wikimedia.

Prise en charge de l’authentification et de l’autorisation authentication-authorization-support

Par défaut, les applications personnalisées Asset Compute sont fournies avec des contrôles d’autorisation et d’authentification pour le projet App Builder. Ils sont activés en définissant l’annotation require-adobe-auth sur true dans manifest.yml.

Accès à d’autres API d’Adobe access-adobe-apis

Ajoutez les services d’API à l’espace de travail de la console Asset Compute créé lors de la configuration. Ces services font partie du jeton d’accès JWT généré par Asset Compute Service. Le jeton et les autres informations d’identification sont accessibles dans l’objet params d’action de l’application.

const accessToken = params.auth.accessToken; // JWT token for Technical Account with entitlements from the console workspace to the API service
const clientId = params.auth.clientId; // Technical Account client Id
const orgId = params.auth.orgId; // Experience Cloud Organization

Transmission des informations d’identification des systèmes tiers pass-credentials-for-tp

Pour gérer les informations d’identification d’autres services externes, transmettez-les sous la forme de paramètres par défaut sur les actions. Elles sont automatiquement chiffrées en transit. Pour plus d’informations, voir Créer des actions dans le guide de développement Adobe I/O Runtime. Définissez-les ensuite à l’aide de variables d’environnement lors du déploiement. Ces paramètres sont accessibles dans l’objet params à l’intérieur de l’action.

Définissez les paramètres par défaut dans inputs dans le fichier manifest.yml :

packages:
  __APP_PACKAGE__:
    actions:
      worker:
        function: 'index.js'
        runtime: 'nodejs:10'
        web: true
        inputs:
           secretKey: $SECRET_KEY
        annotations:
          require-adobe-auth: true

L’expression $VAR lit la valeur d’une variable d’environnement nommée VAR.

Lors du développement, vous pouvez attribuer la valeur dans le fichier .env local. La raison en est qu’aio importe automatiquement les variables d’environnement depuis les fichiers .env, ainsi que les variables définies par le shell d’initialisation. Dans cet exemple, le fichier .env ressemble à ce qui suit :

#...
SECRET_KEY=secret-value

Pour le déploiement de la production, il est possible de définir les variables d’environnement dans le système d’intégration continue (CI), par exemple en utilisant des secrets dans les actions GitHub. Enfin, accédez aux paramètres par défaut de l’application en tant que tels :

const key = params.secretKey;

Dimensionnement des applications sizing-workers

Une application s’exécute dans un conteneur Adobe I/O Runtime avec des limites configurables à l’aide de manifest.yml :

    actions:
      myworker:
        function: /actions/myworker/index.js
        limits:
          timeout: 300000
          memorySize: 512
          concurrency: 1

En raison du traitement étendu effectué par les applications Asset Compute, vous devez ajuster ces limites pour optimiser les performances (suffisamment pour gérer les ressources binaires) et l’efficacité (sans gaspiller les ressources en raison de la mémoire de conteneur inutilisée).

Le délai d’expiration par défaut pour les actions du Runtime est d’une minute, mais il peut être augmenté en définissant la limite timeout (en millisecondes). Si vous prévoyez de traiter des fichiers plus volumineux, augmentez cette durée. Tenez compte du temps total nécessaire pour télécharger la source, traiter le fichier et charger le rendu. Si une action atteint le délai d’expiration, c’est-à-dire si elle ne renvoie pas l’activation avant la limite de délai spécifiée, Runtime ignore le conteneur et ne le réutilise pas.

Les applications Asset Compute tendent par nature à être liées aux entrées et sorties réseau et disque. Le fichier source doit d’abord être téléchargé. Le traitement consomme souvent beaucoup de ressources, puis les rendus résultants sont chargés à nouveau.

Vous pouvez spécifier la mémoire allouée à un conteneur d’actions en mégaoctets à l’aide du paramètre memorySize. Actuellement, ce paramètre définit également le niveau d’accès du conteneur au processeur. Il s’agit surtout d’un élément clé du coût d’utilisation de Runtime (les conteneurs plus volumineux ont un coût plus important). Utilisez ici une valeur plus élevée lorsque votre traitement nécessite davantage de mémoire ou de processeur. Veillez toutefois à ne pas gaspiller les ressources, car plus les conteneurs sont volumineux, plus le débit global est faible.

En outre, il est possible de contrôler la simultanéité des actions dans un conteneur à l’aide du paramètre concurrency. Ce paramètre représente le nombre d’activations simultanées obtenues par un seul conteneur (de la même action). Dans ce modèle, le conteneur d’action est semblable à un serveur Node.js recevant plusieurs requêtes simultanées, jusqu’à cette limite. La valeur par défaut de memorySize dans l’environnement d’exécution est définie sur 200 Mo, idéale pour les actions App Builder plus petites. Pour les applications Asset Compute, cette valeur par défaut peut être excessive en raison de leur utilisation plus importante du disque et du traitement local. Selon leur mise en œuvre, il est possible que certaines applications ne fonctionnent pas correctement avec les activités simultanées. Le SDK Asset Compute garantit que les activations sont séparées en écrivant des fichiers dans différents dossiers uniques.

Testez les applications pour trouver les valeurs optimales de concurrency et memorySize. Des conteneurs plus volumineux reviennent à une limite de mémoire plus haute, ce qui permet une plus grande simultanéité, mais peut aussi entraîner du gaspillage si le trafic est plus faible.