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 que l’Adobe I/O interface en ligne de commande est installée 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 de développement utilisé pour tester les applications personnalisées avec Asset Compute service nécessite un conteneur de stockage dans le cloud pour l’hébergement des fichiers de test, ainsi que la réception et l’affichage des rendus générés par les applications.

Assurez-vous d’avoir accès à un conteneur de stockage dans le cloud pris en charge. Ce conteneur peut être partagé par plusieurs développeurs sur différents projets, selon les besoins.

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

Ajoutez les informations d’identification suivantes pour l’outil de développement dans le fichier ENV dans la racine de votre projet App Builder :

Exécution de 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 Runtime Adobe I/O et lance l’outil de développement sur votre machine locale. 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 d’API externe 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. Cette fonction est activée 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. Ils sont automatiquement chiffrés en transit. Pour plus d’informations, voir Création d’actions dans le guide du développeur 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.

Au cours du développement, la valeur peut être définie dans le fichier ENV local, car aio lit automatiquement les variables d’environnement des fichiers ENV en plus de celles définies dans le shell appelant. 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 Runtime Adobe I/O 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 plus étendu généralement effectué par les applications Asset Compute, il est plus probable qu’il y ait à 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, le 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 est souvent lourd en termes de ressource) et les rendus résultants sont ensuite chargés à nouveau.

La mémoire disponible pour un conteneur d’action est spécifiée par le paramètre memorySize en Mo. Actuellement, il définit également le niveau d’accès du conteneur à l’unité centrale. Il s’agit surtout d’un élément clé du coût d’utilisation du Runtime (les conteneurs plus volumineux coûtent plus cher). Utilisez ici une valeur plus élevée lorsque votre traitement nécessite davantage de mémoire ou d’unité centrale. 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. Il s’agit du 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. Si elle n’est pas définie, la valeur par défaut dans le Runtime est de 200, ce qui est idéal pour les actions App Builder plus modestes, mais généralement trop élevé pour les applications Asset Compute, compte tenu de l’intensité accrue des activités de disque et des traitements locaux. 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.