Sviluppare un’applicazione personalizzata develop

Prima di iniziare a sviluppare un’applicazione personalizzata:

Creare un’applicazione personalizzata create-custom-application

Assicurati di avere Adobe I/O CLI installato localmente.

Consulta esempi di applicazioni personalizzate esempi e idee per applicazioni personalizzate.

Aggiungi credenziali add-credentials

Quando effettui l’accesso durante la creazione dell’applicazione, la maggior parte delle credenziali di App Builder viene raccolta nel file ENV. Tuttavia, l’utilizzo dello strumento per sviluppatori richiede credenziali aggiuntive.

Credenziali di archiviazione dello strumento per sviluppatori developer-tool-credentials

Lo strumento per sviluppatori utilizzato per testare le applicazioni personalizzate con Asset Compute service richiede un contenitore di archiviazione cloud per l’hosting dei file di test e per la ricezione e la visualizzazione delle rappresentazioni generate dalle applicazioni.

Assicurati di avere accesso a contenitore di archiviazione cloud supportato. Se necessario, questo contenitore può essere condiviso da più sviluppatori tra progetti diversi.

Aggiungi credenziali al file ENV add-credentials-env-file

Aggiungi le seguenti credenziali per lo strumento per sviluppatori al file ENV nella directory principale del progetto App Builder:

Eseguire l’applicazione run-custom-application

Prima di eseguire l’applicazione con Asset compute Developer Tool, configura correttamente credenziali.

Per eseguire l’applicazione nello strumento per sviluppatori, utilizza aio app run comando. Distribuisce l’azione in Adobe I/O Esegui e avvia lo strumento di sviluppo sul computer locale. Questo strumento viene utilizzato per testare le richieste dell’applicazione durante lo sviluppo. Di seguito è riportato un esempio di richiesta di rappresentazione:

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

Consulta qui come testare ed eseguire il debug dell’applicazione. Al termine dello sviluppo dell'applicazione personalizzata, distribuire l’applicazione personalizzata.

Prova l’applicazione di esempio fornita da Adobe try-sample

Di seguito sono riportati alcuni esempi di applicazioni personalizzate:

Applicazione personalizzata modello template-custom-application

Il worker-basic è un'applicazione modello. Genera una copia trasformata semplicemente copiando il file di origine. Il contenuto di questa applicazione è il modello ricevuto al momento della scelta Adobe Asset Compute nella creazione dell'app aio.

Il fascicolo dell'applicazione, worker-basic.js utilizza asset-compute-sdk per scaricare il file di origine, orchestra ogni elaborazione della rappresentazione e carica di nuovo le rappresentazioni risultanti nell’archiviazione cloud.

Il renditionCallback definito all’interno del codice dell’applicazione, è il punto in cui eseguire tutta la logica di elaborazione dell’applicazione. Il callback della rappresentazione in worker-basic copia semplicemente il contenuto del file di origine nel file della copia trasformata.

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);
});

Chiamare un’API esterna call-external-api

Nel codice dell’applicazione, puoi effettuare chiamate API esterne per facilitare l’elaborazione dell’applicazione. Di seguito è riportato un esempio di file di applicazione che richiama l’API esterna.

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

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

Ad esempio, il worker-animal-pictures effettua una richiesta di recupero di un URL statico da Wikimedia utilizzando node-httptransfer libreria.

Trasmettere i parametri personalizzati pass-custom-parameters

Potete trasmettere parametri definiti personalizzati attraverso gli oggetti di rendering. È possibile farvi riferimento all’interno dell’applicazione in rendition istruzioni. Un esempio di oggetto di rendering è:

"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"
    }
]

Un esempio di file di applicazione che accede a un parametro personalizzato è:

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"`
});

Il example-worker-animal-pictures trasmette un parametro personalizzato animal per determinare quale file recuperare da Wikimedia.

Supporto di autenticazione e autorizzazione authentication-authorization-support

Per impostazione predefinita, le applicazioni personalizzate di Asset compute sono dotate di controlli di autorizzazione e autenticazione per il progetto App Builder. Questa funzione è abilitata impostando require-adobe-auth annotazione a true nel manifest.yml.

Accedere ad altre API Adobe access-adobe-apis

Aggiungi i servizi API alla Asset Compute Area di lavoro della console creata durante la configurazione. Questi servizi fanno parte del token di accesso JWT generato da Asset Compute Service. Il token e le altre credenziali sono accessibili all’interno dell’azione dell’applicazione params oggetto.

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

Trasmettere le credenziali per i sistemi di terze parti pass-credentials-for-tp

Per gestire le credenziali per altri servizi esterni, passa questi come parametri predefiniti sulle azioni. Questi vengono crittografati automaticamente in transito. Per ulteriori informazioni, consulta creazione di azioni nella guida per gli sviluppatori di Runtime. Quindi impostale utilizzando le variabili di ambiente durante la distribuzione. È possibile accedere a questi parametri in params all'interno dell'azione.

Imposta i parametri di default all'interno del inputs nel manifest.yml:

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

Il $VAR espressione legge il valore da una variabile di ambiente denominata VAR.

Durante lo sviluppo, il valore può essere impostato nel file ENV locale come aio legge automaticamente le variabili di ambiente dai file ENV, oltre alle variabili impostate dalla shell di richiamo. In questo esempio, il file ENV si presenta come segue:

#...
SECRET_KEY=secret-value

Per la distribuzione di produzione è possibile impostare le variabili di ambiente nel sistema CI, ad esempio utilizzando i segreti nelle azioni GitHub. Infine, accedi ai parametri predefiniti all’interno dell’applicazione in quanto tale:

const key = params.secretKey;

Ridimensionamento delle applicazioni sizing-workers

Un’applicazione viene eseguita in un contenitore in Adobe I/O Runtime con limiti che possono essere configurati tramite manifest.yml:

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

A causa della maggiore estensione dell’elaborazione solitamente eseguita dalle applicazioni Asset compute, è più probabile che si debbano regolare questi limiti per ottenere prestazioni ottimali (abbastanza grandi da gestire le risorse binarie) ed efficienza (senza sprecare risorse a causa della memoria contenitore non utilizzata).

Il timeout predefinito per le azioni in fase di esecuzione è di un minuto, ma può essere aumentato impostando timeout limite (in millisecondi). Se prevedi di elaborare file di dimensioni maggiori, aumenta questo tempo. Considera il tempo totale necessario per scaricare l’origine, elaborare il file e caricare la rappresentazione. Se un’azione si interrompe per timeout, ovvero non restituisce l’attivazione prima del limite di timeout specificato, Runtime elimina il contenitore e non lo riutilizza.

Le applicazioni di Asset compute per natura tendono ad essere collegate alla rete e al disco. Il file di origine deve essere scaricato per primo, l’elaborazione richiede spesso molte risorse e quindi le rappresentazioni risultanti vengono caricate di nuovo.

La memoria disponibile per un contenitore di azioni è specificata da memorySize in MB. Attualmente questo definisce anche la quantità di accesso alla CPU che il contenitore ottiene, e soprattutto è un elemento chiave del costo di utilizzo di Runtime (i contenitori più grandi costano di più). Utilizzare un valore maggiore quando l'elaborazione richiede una quantità maggiore di memoria o di CPU, ma occorre fare attenzione a non sprecare risorse in quanto più grandi sono i contenitori, minore è il throughput complessivo.

Inoltre, è possibile controllare la concorrenza delle azioni all’interno di un contenitore utilizzando concurrency impostazione. Questo è il numero di attivazioni simultanee che un singolo contenitore (della stessa azione) ottiene. In questo modello, il contenitore delle azioni è simile a un server Node.js che riceve più richieste simultanee, fino a tale limite. Se non è impostato, il valore predefinito in Runtime è 200, ideale per le azioni di App Builder di dimensioni ridotte, ma in genere è troppo grande per applicazioni di Asset compute, data la maggiore intensità dell’elaborazione locale e dell’attività del disco. Alcune applicazioni, a seconda dell’implementazione, potrebbero non funzionare correttamente con le attività simultanee. L’SDK di Asset compute garantisce che le attivazioni siano separate scrivendo file in diverse cartelle univoche.

Eseguire test delle applicazioni per trovare i numeri ottimali per concurrency e memorySize. Contenitori più grandi = un limite di memoria più alto potrebbe consentire una maggiore concorrenza, ma potrebbe anche sprecare per un traffico più basso.