[AEM Assets]{class="badge positive" title="Si applica ad AEM Assets)."}

Domande frequenti su Dynamic Media con funzionalità OpenAPI new-dynaminc-media-apis-frequently-asked-questions

Dynamic Media con funzionalità OpenAPI (Open Application Programming Interface) fornisce, trasforma e gestisce le risorse rich media (immagini, video e altri contenuti visivi) tramite endpoint API standardizzati e intuitivi per gli sviluppatori. Questa guida con domande frequenti risponde alle domande più frequenti sul funzionamento di queste funzionalità, su cosa consentono e su come adottarle.

Cosa sono gli elementi multimediali dinamici con funzionalità OpenAPI? what-are-dynamic-media-openapi-capabilities

Dynamic Media è un insieme di servizi di distribuzione e trasformazione dei contenuti multimediali che ottimizzano, ridimensionano ed eseguono il rendering automatico delle risorse per qualsiasi dispositivo, canale o schermo. Le funzionalità di OpenAPI espongono questi servizi attraverso specifiche API aperte e ben documentate, consentendo agli sviluppatori di integrare la distribuzione di contenuti multimediali direttamente nelle proprie applicazioni, vetrine ed esperienze di contenuti.

Poiché le interfacce seguono lo standard OpenAPI, sono autodescrittive e prevedibili. Di conseguenza, i team di integrazione possono individuare gli endpoint disponibili, comprendere i formati di richiesta e risposta e generare il codice client più rapidamente rispetto alle interfacce proprietarie non documentate.

Vantaggi principali key-benefits

I principali vantaggi di Dynamic Media con funzionalità OpenAPI includono:

Cosa posso fare con le funzionalità OpenAPI di Dynamic Media? what-can-i-do

Puoi richiedere risorse multimediali su richiesta, applicare trasformazioni in tempo reale come il ritaglio, il ridimensionamento e la conversione del formato, e distribuire contenuti ottimizzati a esperienze web, mobili e connesse, il tutto tramite chiamate API standardizzate.

Quali sono le differenze tra le funzionalità OpenAPI e la distribuzione tradizionale di Dynamic Media? openapi-vs-traditional

La distribuzione tradizionale si basa su modelli e pattern URL predefiniti. Le funzionalità OpenAPI aggiungono un’interfaccia standardizzata e programmatica che semplifica l’implementazione di automazione, integrazione personalizzata e architetture headless (front-end disaccoppiate).

Queste funzionalità sono adatte per architetture headless e componibili? headless-composable

Sì. Poiché i contenuti multimediali vengono recuperati e trasformati tramite API anziché tramite modelli di pagina fissa, le funzionalità OpenAPI di Dynamic Media si integrano naturalmente nelle impostazioni di gestione dei contenuti headless e di e-commerce componibili, in cui il livello di presentazione è separato da contenuti e servizi.

Sono necessarie risorse per gli sviluppatori per utilizzare queste funzionalità? developer-resources

L’integrazione basata su API in genere richiede agli sviluppatori di connettere gli endpoint a un’applicazione. Tuttavia, la specifica OpenAPI riduce questo sforzo fornendo definizioni coerenti e leggibili al computer che supportano la generazione e il test automatizzati dei client.

Nell’archivio di Experience Manager Assets as a Cloud Service sono disponibili tutte le risorse per la ricerca e la consegna tramite Dynamic Media con funzionalità OpenAPI? assets-available-for-search

No. Solo la versione approvata e la versione più recente delle risorse sono disponibili per la ricerca e la distribuzione tramite Dynamic Media con funzionalità OpenAPI. Assets che non sono stati approvati o che esistono solo come revisioni precedenti, sono esclusi da questo ambito di ricerca e consegna.

Due condizioni determinano se una risorsa viene visualizzata nell’archivio Experience Manager Assets as a Cloud Service:

Questo ambito è intenzionale. Poiché solo le risorse correnti approvate sono idonee, la distribuzione è limitata ai contenuti che hanno superato la revisione della governance, il che garantisce la coerenza del brand tra tutti i canali e le applicazioni. Di conseguenza, le esperienze a valle che utilizzano risorse tramite Dynamic Media con funzionalità OpenAPI fanno riferimento in modo affidabile a contenuti revisionati e aggiornati, anziché a revisioni non approvate o obsolete.

In che modo gli amministratori possono contrassegnare come approvate le risorse nuove ed esistenti aggiunte a una cartella? add-assets-to-folder-as-approved

Gli amministratori contrassegnano le risorse nuove ed esistenti in una cartella come approvate configurando la cartella per l’approvazione in blocco e quindi rielaborando eventuali risorse preesistenti. In Adobe Experience Manager (AEM) Assets, lo stato di una risorsa è disciplinato dalla proprietà jcr:content/metadata/dam:status. Questa proprietà definisce se una risorsa viene trattata come revisione utilizzabile, bloccata o in sospeso in tutta la libreria di risorse.

I valori di questa proprietà sono:

AEM Assets distingue lo stato Approvato utilizzando un’icona approvato disponibile nella scheda delle risorse, come illustrato nelle immagini seguenti per le visualizzazioni Amministratore e Risorse:

Vista amministratore

Vista risorse

Per approvare tutte le risorse in una cartella, consulta le istruzioni in Come approvare in blocco le risorse in una cartella. È inoltre disponibile un video che illustra l’intero processo.

Dopo aver impostato una cartella per l’approvazione in blocco, tutte le nuove risorse aggiunte alla cartella vengono approvate automaticamente. In questo modo viene garantito uno stato di approvazione coerente in tutta la cartella senza richiedere la revisione manuale di ogni nuovo caricamento. Tutte le risorse esistenti vengono approvate solo dopo essere state rielaborate, perché la rielaborazione valuta la proprietà dam:status in base alla configurazione dell’approvazione in blocco della cartella. Per istruzioni su come rielaborare le risorse, consulta Rielaborazione delle risorse digitali. Se gli amministratori copiano o spostano risorse non approvate da qualsiasi altra cartella, devono rielaborare le risorse in modo che le risorse spostate ereditino lo stato approvato.

AEM Assets contrassegna la risorsa come Rejected ogni volta che l’amministratore specifica i valori Rejected o Changes requested, perché entrambi i valori rappresentano uno stato non approvato. AEM Assets distingue lo stato Rifiutato utilizzando disponibile nella scheda delle risorse in visualizzazione Amministratore.

Allo stesso modo, AEM Assets distingue lo stato Rifiutato nella vista Assets utilizzando il seguente stato Rifiutato sulla scheda della risorsa:

In che modo è possibile ottenere l’ID gruppo o utente di Adobe IMS (Adobe Identity Management Services) da utilizzare per impostare i ruoli sulle risorse nella vista Amministratore di Experience Manager, al fine di proteggere la consegna e l’esperienza di ricerca? set-roles-secure-delivery-search

Gli ID gruppo e utente di Adobe IMS (Adobe Identity Management Services) vengono recuperati da Admin Console di Adobe e applicati in Experience Manager Assets Admin view per impostare ruoli che proteggono le esperienze di consegna e ricerca. L’assegnazione di ruoli in base a questi ID utente o gruppo IMS garantisce che solo le identità autorizzate possano accedere, consegnare o cercare risorse specifiche. Poiché l’accesso a livello di risorsa è gestito da queste identità, l’utilizzo dell’ID IMS corretto è il passaggio fondamentale per la sicurezza basata sui ruoli in Experience Manager.

Gli utenti che richiedono l’accesso all’ambiente Experience Manager Author vengono gestiti come utenti Adobe IMS nell’ambiente Admin Console di Adobe. Per informazioni su cosa si intende per utenti di Adobe IMS, nonché come accedervi e gestirli in Admin Console, consulta Utenti Adobe IMS.

Mapping delle identità IMS ai ruoli delle risorse:

Poiché le esperienze di consegna e ricerca sono gestite dai ruoli impostati sulle risorse, è essenziale recuperare l’ID gruppo o utente Adobe IMS accurato da Admin Console. Questo approccio centralizza la gestione delle identità, riduce il rischio di accesso non autorizzato alle risorse e mantiene le autorizzazioni allineate al modo in cui le identità sono già amministrate nell’ambiente Adobe.

È possibile approvare più risorse contemporaneamente all’interno di una cartella? approve-multiple-assets-in-folder

Sì. Adobe Experience Manager (AEM) Assets consente agli utenti di approvare più risorse contemporaneamente all’interno di una cartella, eliminando la necessità di approvare ogni file singolarmente. L’approvazione in blocco semplifica i flussi di lavoro di revisione e consente di risparmiare tempo prezioso durante la gestione di librerie di risorse di grandi dimensioni, perché lo stato di revisione Approvato viene applicato a ogni risorsa selezionata in un’unica azione.

Esistono due metodi supportati, a seconda dell’interfaccia utilizzata: Assets Admin View o Assets View.

Approvare più risorse nella visualizzazione Amministratore di Assets

Per approvare più risorse contemporaneamente in Experience Manager Assets Admin view esegui la procedura seguente:

In questo modo lo stato di revisione Approvato viene applicato a ogni risorsa selezionata contemporaneamente, confermando e chiudendo le modifiche in un unico passaggio.

Approvare più risorse nella vista Assets

Allo stesso modo, per approvare più risorse contemporaneamente all’interno di una cartella nella vista Assets:

Facendo clic su Salva, lo stato Approvato viene assegnato a tutte le risorse selezionate contemporaneamente, garantendo la coerenza degli stati di revisione nella cartella.

Come posso proteggere la consegna delle risorse e cercare le OpenAPI di Dynamic Media? secure-asset-delivery

La governance centrale delle risorse in Adobe Experience Manager offre a amministratori DAM (Digital Asset Management) e Brand Manager il controllo diretto su chi può accedere alle risorse distribuite tramite OpenAPI (Open Application Programming Interfaces). Questo modello di governance protegge sia la ricerca delle risorse che la loro distribuzione applicando le regole di accesso all’origine, in modo che solo gli utenti autorizzati possano recuperare il contenuto protetto.

Questi amministratori limitano l’accesso dal lato dell’authoring, in particolare nell’istanza di authoring di AEM as a Cloud Service, utilizzando due controlli primari:

Poiché questi controlli vengono applicati a livello di authoring, gestiscono ogni richiesta a valle. Gli utenti finali che cercano risorse o utilizzano URL di consegna ricevono risorse con restrizioni solo dopo aver superato il processo di autorizzazione. Le richieste che non hanno ottenuto l’autorizzazione vengono bloccate, impedendo in tal modo il recupero non autorizzato anche quando è noto un URL di consegna. In questo modo le decisioni di governance prese dagli amministratori di DAM e dai Brand Manager vengono applicate in modo coerente sia nei risultati di ricerca che nei collegamenti di consegna diretta.

Per ulteriori informazioni, consulta Limitare l’accesso alle risorse in Experience Manager.

Come è possibile ottenere le autorizzazioni per modificare lo stato di approvazione di una risorsa? permissions-edit-approval-status

Per ottenere le autorizzazioni di modifica dello stato di approvazione di una risorsa, un amministratore deve concedere l’accesso di modifica al campo Stato revisione nello schema metadati applicato alla cartella risorse. In qualità di utente di Digital Asset Management (DAM), potresti non disporre delle autorizzazioni per approvare le risorse per impostazione predefinita, perché l’approvazione e la modifica dello stato di revisione sono controllate a livello di schema metadati anziché tramite l’accesso generale alla cartella.

Gli amministratori possono abilitare questo accesso seguendo la procedura riportata di seguito.

La concessione delle autorizzazioni di modifica al campo Stato revisione garantisce che gli utenti DAM designati possano modificare direttamente lo stato di approvazione di una risorsa, semplificando il flusso di lavoro di revisione. Per ulteriori informazioni, consulta come disabilitare la modifica per il campo Stato revisione.

Qual è la dimensione file supportata per i video? supported-file-formats-videos

Dynamic Media con funzionalità OpenAPI supporta video in formato esteso con una dimensione massima del file di 50 GB e una durata massima di 2 ore per video. Questi limiti definiscono i limiti superiori per il caricamento di un singolo video, consentendo la distribuzione di contenuti completi quali webinar registrati, sessioni di formazione, dimostrazioni di prodotto e presentazioni estese senza suddividere il metraggio in segmenti più brevi.

Poiché Dynamic Media supporta file di dimensioni pari a 50 GB, è possibile caricare e inviare in streaming metraggio ad alta risoluzione e bitrate mantenendo la qualità. Il limite di durata di 2 ore garantisce che le risorse in formato esteso rientrino in un unico file continuo, semplificando la gestione e la riproduzione dei contenuti per i visualizzatori.

In che modo Dynamic Media con funzionalità OpenAPI è diverso dalla soluzione Dynamic Media? dynamic-media-and-dynamic-media-with-openapi-differences

Dynamic Media con funzionalità OpenAPI e Dynamic Media sono soluzioni distinte, ognuna delle quali offre le proprie funzionalità di consegna specializzate. Rivedi attentamente i requisiti specifici per determinare la soluzione più adatta alle tue esigenze.

Le linee guida generali di Adobe consistono nell’utilizzare lo stack Dynamic Media con OpenAPI (Open Application Programming Interface) per tutti i casi di utilizzo dell’integrazione, che si tratti di applicazioni di prima parte o di terze parti. Poiché i due stack utilizzano strutture URL diverse, utilizza le seguenti regole di decisione per scegliere l’approccio corretto:

In conclusione, Dynamic Media e lo stack Dynamic Media con OpenAPI possono coesistere, a seconda della natura del caso d’uso.

Di seguito sono riportate alcune delle principali differenze tra Dynamic Media con funzionalità OpenAPI e Dynamic Media:

In che modo Dynamic Media con funzionalità OpenAPI soddisfa le limitazioni della funzione Risorse collegate? dynamic-media-openapi-addresses-connected-assets-limitations

Dynamic Media con funzionalità OpenAPI supera le limitazioni principali della funzione Connected Assets eliminando la copia binaria, supportando tutti i tipi di formato AEM Assets (inclusi i video), rimuovendo il limite di connessione di quattro istanze, abilitando integrazioni personalizzate estensibili e distribuendo aggiornamenti delle risorse quasi in tempo reale. La tabella seguente illustra le principali differenze tra le due soluzioni:

Alcuni modificatori sono contrassegnati come Disponibilità limitata. Come posso iniziare a utilizzarli? use-limited-availability-modifiers

I modificatori Disponibilità limitata richiedono l’abilitazione esplicita sul tuo account prima di poter essere utilizzati in produzione. Adobe non attiva questi modificatori per impostazione predefinita, pertanto devi richiedere l’accesso tramite il supporto Adobe. Il processo consiste di due passaggi: aprire un caso di supporto e fornire i dettagli di identificazione necessari ad Adobe per il provisioning delle funzionalità richieste.

Per abilitare l’utilizzo di produzione di modificatori in disponibilità limitata sul tuo account:

Come si testano i modificatori sperimentali? modifiers-not-generally-available

Le API sperimentali consentono di testare qualsiasi modificatore non ancora generalmente disponibile. Le API sperimentali (o beta) consentono agli sviluppatori di accedere in anteprima a funzionalità ancora in fase di valutazione, in modo da poter convalidare nuovi modificatori prima che vengano promossi nel set stabile e generalmente disponibile. Questo consente di provare le funzionalità future, confermarne il comportamento previsto nei flussi di lavoro e fornire un feedback prima di una versione generale.

Per testare un modificatore non generalmente disponibile, richiamalo attraverso il percorso API sperimentale. Ad esempio:

</adobe/experimental/advancemodifiers-expires-YYYYMMDD/assets>

Il segmento expires-YYYYMMDD indica che il modificatore sperimentale è vincolato al tempo, segnalando la data entro la quale la versione sperimentale dovrebbe cambiare o scadere. Questo è un promemoria per la migrazione all’equivalente generalmente disponibile una volta rilasciata.

Per informazioni dettagliate sulla chiamata di questi endpoint, consulta le linee guida sull’utilizzo delle API sperimentali. Per identificare i modificatori disponibili, consultare l’elenco completo dei modificatori.

Consulta anche