[AEM Assets]{class="badge positive" title="(Se aplica a los AEM Assets)."}
Preguntas frecuentes sobre Dynamic Media con funciones de OpenAPI new-dynaminc-media-apis-frequently-asked-questions
Dynamic Media con las capacidades de OpenAPI (Open Application Programming Interface) ofrece, transforma y administra recursos de medios enriquecidos (imágenes, vídeo y otro contenido visual) a través de extremos de API estandarizados y fáciles de desarrollar. Estas preguntas frecuentes sirven de guía para responder a las consultas más comunes sobre cómo funcionan estas capacidades, qué habilitan y cómo adoptarlas.
¿Qué es Dynamic Media con las capacidades de OpenAPI? what-are-dynamic-media-openapi-capabilities
Dynamic Media es un conjunto de servicios de entrega y transformación de medios que optimizan, redimensionan y procesan automáticamente los recursos de cualquier dispositivo, canal o pantalla. Las funcionalidades de OpenAPI exponen estos servicios a través de especificaciones de API abiertas y bien documentadas, lo que permite a los desarrolladores integrar la entrega de medios directamente en sus propias aplicaciones, tiendas y experiencias de contenido.
Dado que las interfaces siguen el estándar OpenAPI, son autodescriptivas y predecibles. Como resultado, los equipos de integración pueden descubrir los puntos de conexión disponibles, comprender los formatos de solicitud y respuesta y generar código de cliente más rápidamente que con las interfaces propietarias no documentadas.
Principales ventajas key-benefits
Las principales ventajas de Dynamic Media con las capacidades de OpenAPI incluyen:
- Integración estandarizada: los puntos de conexión compatibles con OpenAPI facilitan la conexión de los servicios multimedia a las aplicaciones y cadenas de herramientas existentes.
- Transformación de medios bajo demanda: Assets se optimiza, se cambia de tamaño y se cambia el formato en el momento de la solicitud, lo que elimina la necesidad de almacenar varias variantes manuales.
- Envío multicanal: Un solo recurso se puede entregar y adaptar en experiencias web, móviles y conectadas.
- Arquitectura preparada para sin encabezado: La entrega con prioridad API se alinea con las pilas de tecnología sin encabezado y componible.
- Desarrollo más rápido: Las especificaciones que se describen a sí mismas aceleran la incorporación, la generación de código de cliente y las pruebas para los equipos de integración.
¿Qué puedo hacer con las funcionalidades de OpenAPI de Dynamic Media? what-can-i-do
Puede solicitar recursos de medios bajo demanda, aplicar transformaciones en tiempo real como recorte, cambio de tamaño y conversión de formato, y ofrecer contenido optimizado para experiencias web, móviles y conectadas, todo ello mediante llamadas de API estandarizadas.
¿En qué se diferencian las capacidades de OpenAPI de la entrega tradicional de Dynamic Media? openapi-vs-traditional
La entrega tradicional se basa en patrones de URL y plantillas preestablecidos. Las funciones de OpenAPI añaden una interfaz estandarizada y programática que facilita la implementación de la automatización, la integración personalizada y las arquitecturas sin encabezado (front-end disociado).
¿Son estas capacidades adecuadas para arquitecturas sin encabezado y compuestas? headless-composable
Sí. Debido a que los medios se recuperan y transforman a través de API en lugar de plantillas de página fijas, las capacidades de Dynamic Media OpenAPI se ajustan de forma natural a las configuraciones de administración de contenido sin encabezado y comercio componible, donde la capa de presentación está separada del contenido y los servicios.
¿Se necesitan recursos de desarrollador para utilizar estas capacidades? developer-resources
La integración basada en API generalmente implica a los desarrolladores conectar puntos finales a una aplicación. Sin embargo, la especificación OpenAPI reduce este esfuerzo al proporcionar definiciones coherentes y legibles por el equipo que admiten la generación y prueba automatizadas de clientes.
¿Están todos los recursos del repositorio de Experience Manager Assets as a Cloud Service disponibles para su búsqueda y entrega mediante Dynamic Media con funciones de OpenAPI? assets-available-for-search
No. Solo la versión aprobada y más reciente de los recursos están disponibles para su búsqueda y envío mediante Dynamic Media con capacidades OpenAPI. Las Assets que no se hayan aprobado o que solo existen como revisiones anteriores se excluyen de este ámbito de búsqueda y envío.
Dos condiciones rigen si aparece un recurso en el repositorio de Experience Manager Assets as a Cloud Service:
- Estado de aprobación — el recurso debe marcarse como aprobado. Los Assets que aún están en borrador o pendientes de revisión no se exponen para la búsqueda y la entrega.
- Moneda de versión — solo es elegible la última versión de un recurso aprobado. No se devuelven versiones reemplazadas o históricas.
Este ámbito es intencional. Como solo se aprueban los recursos actuales, la entrega se restringe al contenido que haya pasado la revisión de control, lo que garantiza la coherencia de la marca en todos los canales y aplicaciones. Como resultado, las experiencias descendentes que consumen recursos a través de Dynamic Media con capacidades de OpenAPI hacen referencia de forma fiable a contenido vetado y actualizado en lugar de revisiones no aprobadas u obsoletas.
¿Cómo pueden los administradores marcar los recursos nuevos y existentes que se añadieron a una carpeta como aprobados? add-assets-to-folder-as-approved
Los administradores marcan los recursos nuevos y existentes en una carpeta como aprobados configurando la carpeta para la aprobación masiva y luego reprocesando los recursos preexistentes. En Adobe Experience Manager (AEM) Assets, el estado de un recurso se rige por la propiedad jcr:content/metadata/dam:status. Esta propiedad controla si un recurso se trata como utilizable, bloqueado o pendiente de revisión en toda la biblioteca de recursos.
Los valores de esta propiedad son:
-
Aprobado: el recurso está validado, disponible para su uso y marcado con un icono de aprobado en la tarjeta de recursos.
-
Rechazado: el recurso está bloqueado y marcado con un indicador rechazado.
-
Cambios solicitados: el recurso requiere revisión y se gestiona del mismo modo que un recurso rechazado.
Los AEM Assets distinguen el estado Aprobado mediante un icono de aprobado disponible en la tarjeta de recursos, como se muestra en las siguientes imágenes para los administradores y las vistas de recursos:
Vista Administrador
Vista Recursos
Para aprobar todos los recursos de una carpeta, consulte las instrucciones sobre cómo aprobar recursos de forma masiva en una carpeta. También hay un vídeo que muestra todo el proceso.
Después de configurar una carpeta para su aprobación de forma masiva, todos los recursos nuevos que se añadan a la carpeta se aprobarán automáticamente. Esto garantiza un estado de aprobación coherente en toda la carpeta sin necesidad de una revisión manual de cada nueva carga. Todos los recursos existentes se aprueban sólo después de volver a procesarse, ya que al volver a procesar se evalúa la propiedad dam:status con respecto a la configuración de aprobación masiva de la carpeta. Consulte Reprocesamiento de recursos digitales para obtener instrucciones sobre cómo reprocesar recursos. Si los administradores copian o mueven recursos no aprobados de cualquier otra carpeta, deben reprocesar los recursos para que los recursos movidos hereden el estado aprobado.
AEM Assets marca el recurso como Rejected siempre que el administrador especifique los valores Rejected o Changes requested, ya que ambos valores representan un estado no aprobado. Los AEM Assets distinguen el estado Rechazado usando
Del mismo modo, los AEM Assets distinguen el estado Rechazado en la vista de Assets mediante el siguiente estado Rechazado en la tarjeta de recursos:
¿Cómo puede obtener el ID de usuario o grupo de Adobe IMS (servicios de Identity Management de Adobe) para establecer los roles en los recursos en la vista Administrador de Experience Manager, a fin de proteger la experiencia de entrega y búsqueda? set-roles-secure-delivery-search
Los ID de usuario y grupo de Adobe IMS (Identity Management Services) se recuperan de Admin Console de Adobe y se aplican en Experience Manager Assets Admin view para establecer funciones que protejan las experiencias de envío y búsqueda. La asignación de funciones basadas en estos ID de grupo o usuario de IMS garantiza que solo las identidades autorizadas puedan acceder, enviar o buscar recursos específicos. Dado que el acceso a nivel de recurso se rige por estas identidades, el uso del ID de IMS correcto es el paso fundamental para la seguridad basada en funciones en Experience Manager.
Los usuarios que requieren acceso al entorno Experience Manager Author se administran como usuarios de IMS de Adobe en Admin Console de Adobe. Para obtener información sobre qué son los usuarios de Adobe IMS y cómo se accede a ellos y se administran en Admin Console, consulte Usuarios de Adobe IMS.
Cómo se asignan las identidades de IMS a los roles del recurso:
- Los usuarios de IMS de Adobe representan a personas individuales que se aprovisionan y administran de forma centralizada en Admin Console de Adobe, lo que proporciona una única fuente fiable para la identidad en las aplicaciones de Adobe Experience Cloud.
- Los grupos de Adobe IMS permiten que se administren varios usuarios juntos, de modo que los roles y los permisos se pueden aplicar de manera consistente a un grupo en lugar de a cada usuario individualmente.
- El ID de usuario o ID de grupo obtenido de Admin Console es el valor al que se hace referencia al configurar funciones en recursos, al vincular permisos de entrega y búsqueda directamente a una identidad administrada conocida.
Dado que las experiencias de entrega y búsqueda se rigen por las funciones establecidas en los recursos, es esencial recuperar el ID de grupo o usuario de IMS de Adobe de Admin Console. Este método centraliza la administración de identidades, reduce el riesgo de acceso no autorizado a recursos y mantiene los permisos alineados con la forma en que se administran las identidades en el entorno de Adobe.
¿Puede aprobar varios recursos simultáneamente dentro de una carpeta? approve-multiple-assets-in-folder
Sí. Adobe Experience Manager (AEM) Assets permite a los usuarios aprobar varios recursos dentro de una carpeta simultáneamente, lo que elimina la necesidad de aprobar cada archivo individualmente. La aprobación masiva optimiza los flujos de trabajo de revisión y ahorra un tiempo considerable al administrar bibliotecas de recursos grandes, ya que el estado de revisión Aprobado se aplica a cada recurso seleccionado en una sola acción.
Existen dos métodos compatibles, según la interfaz que utilice: la vista de administración de Assets o la vista de Assets.
Aprobar varios recursos en la vista de administración de Assets
Siga estos pasos para aprobar varios recursos simultáneamente en Experience Manager Assets Admin view:
- Seleccione los recursos y haga clic en Propiedades.
- En la ficha Básico, desplácese hacia abajo hasta Estado de revisión.
- Cambiar el estado de revisión a Aprobado.
- Haga clic en Guardar y cerrar.
Esto aplica el estado de revisión Aprobado a cada recurso seleccionado a la vez, confirmando y cerrando los cambios en un solo paso.
Aprobar varios recursos en la vista de Assets
Del mismo modo, para aprobar varios recursos simultáneamente dentro de una carpeta en la vista Recursos:
-
Seleccione los recursos y haga clic en Edición masiva de metadatos.
-
Seleccione Aprobado en el campo Estado disponible en la sección Propiedades del panel derecho.
-
Haga clic en Guardar.
Al hacer clic en Guardar, se confirma el estado de Aprobado para todos los recursos seleccionados simultáneamente, lo que garantiza estados de revisión coherentes en toda la carpeta.
¿Cómo puedo asegurar la entrega de recursos y la búsqueda para Dynamic Media con OpenAPI? secure-asset-delivery
El control de recursos central en Adobe Experience Manager proporciona a los administradores de administración de recursos digitales (DAM) y a los administradores de marcas control directo sobre quién puede acceder a los recursos que se entregan a través de OpenAPI (interfaces de programación de aplicaciones abiertas). Este modelo de gobernanza garantiza la búsqueda y la entrega de recursos mediante la aplicación de reglas de acceso en origen, de modo que solo los usuarios autorizados recuperan el contenido protegido.
Estos administradores restringen el acceso en el lado de creación (específicamente en la instancia de autor de AEM as a Cloud Service) mediante dos controles principales:
- Configuración de la función: Se concede o deniega el acceso en función de las funciones asignadas, asegurándose de que cada usuario o grupo vea únicamente los recursos que permiten sus permisos.
- Programación de activación y desactivación: Los administradores establecen tiempos precisos de activación y desactivación para los recursos aprobados, de modo que el contenido está disponible o se retira automáticamente según las ventanas de publicación definidas.
Dado que estos controles se aplican en el nivel de creación, rigen todas las solicitudes de flujo descendente. Los usuarios finales que buscan recursos o utilizan direcciones URL de entrega solo reciben recursos restringidos después de pasar correctamente el proceso de autorización. Las solicitudes que no superan la autorización se bloquean, lo que impide la recuperación no autorizada incluso cuando se conoce una dirección URL de entrega. Esto garantiza que las decisiones de gobernanza tomadas por los administradores de DAM y los administradores de marcas se apliquen de forma coherente en los resultados de búsqueda y en los vínculos de envío directo.
Para obtener más información, consulte Restringir el acceso a los recursos en Experience Manager.
¿Cómo puede obtener permisos para editar el estado de aprobación de un recurso? permissions-edit-approval-status
Para obtener permisos para editar el estado de aprobación de un recurso, un administrador debe conceder acceso de edición al campo Estado de revisión dentro del esquema de metadatos aplicado a la carpeta de recursos. Como usuario de Digital Asset Management (DAM), es posible que no tenga permisos para aprobar recursos de forma predeterminada, ya que la aprobación y la edición del estado de revisión se controlan en el nivel de esquema de metadatos en lugar de mediante el acceso general a carpetas.
Los administradores pueden habilitar este acceso siguiendo estos pasos:
- Abra el esquema de metadatos predeterminado o cualquier otro esquema de metadatos aplicado a la carpeta de recursos correspondiente.
- Busque el campo Estado de revisión dentro de ese esquema.
- Proporcione permisos de edición al campo Estado de revisión.
Conceder permisos de edición al campo Estado de revisión garantiza que los usuarios de DAM designados puedan cambiar el estado de aprobación de un recurso directamente, lo que optimiza el flujo de trabajo de revisión. Para obtener más información, consulte cómo deshabilitar la edición para el campo Estado de revisión.
¿Cuál es el tamaño de archivo admitido para los vídeos? supported-file-formats-videos
Dynamic Media con capacidades OpenAPI admite vídeos de formato largo con un tamaño de archivo máximo de 50 GB y una duración máxima de 2 horas por vídeo. Estos límites definen los límites superiores de una sola carga de vídeo, lo que permite que el contenido completo, como seminarios web grabados, sesiones de formación, demostraciones de productos y presentaciones ampliadas, se entregue sin dividir el material de archivo en segmentos más cortos.
Debido a que Dynamic Media admite archivos de hasta 50 GB, el material de archivo de alta resolución y alta velocidad de bits se puede cargar y transmitir a la vez que se conserva la calidad. El límite de duración de 2 horas garantiza que los recursos de formato largo se ajusten a un solo archivo continuo, lo que simplifica la administración y reproducción de contenido para los visores.
¿En qué se diferencia Dynamic Media con funciones de OpenAPI de la solución Dynamic Media? dynamic-media-and-dynamic-media-with-openapi-differences
Dynamic Media con capacidades OpenAPI y Dynamic Media son soluciones distintas, cada una de las cuales ofrece sus propias capacidades de envío especializadas. Revise a fondo sus requisitos específicos para determinar la solución que mejor se ajuste a sus necesidades.
La guía general de Adobe es aprovechar Dynamic Media con la pila OpenAPI (Open Application Programming Interface) para cualquier caso de uso de integración, ya sea que se trate de aplicaciones de origen o de terceros. Dado que las dos pilas utilizan estructuras URL diferentes, utilice las siguientes reglas de decisión para elegir el método correcto:
- Integraciones existentes: Si ya existe una integración con la pila de Dynamic Media, no la cambie, ya que las direcciones URL de la pila OpenAPI difieren en estructura.
- Integraciones nuevas: Para cualquier caso de uso de integración nuevas, aproveche la pila OpenAPI.
- Modificadores avanzados: Si su caso de uso requiere modificadores avanzados que aún no están disponibles con la pila OpenAPI, evite la pila OpenAPI hasta que Adobe reduzca el espacio.
- Envío nativo básico: Incluso para el envío nativo básico desde Adobe Experience Manager (AEM) Assets Cloud Services, la pila OpenAPI se puede evaluar, siempre y cuando su caso de uso esté cubierto por los modificadores disponibles con la pila OpenAPI.
En conclusión, Dynamic Media y Dynamic Media con la pila de OpenAPI pueden coexistir, según la naturaleza del caso de uso.
A continuación, se indican algunas de las diferencias clave entre Dynamic Media con funciones de OpenAPI y Dynamic Media:
¿Cómo aborda Dynamic Media con funciones de OpenAPI las limitaciones de la función de Recursos de red? dynamic-media-openapi-addresses-connected-assets-limitations
Dynamic Media con capacidades OpenAPI supera las limitaciones principales de la función Connected Assets al eliminar la copia binaria, admitir todos los tipos de formato de AEM Assets (incluidos vídeos), eliminar el límite de conexión de cuatro instancias, habilitar integraciones personalizadas ampliables y ofrecer actualizaciones de recursos casi en tiempo real. En la tabla siguiente se describen las principales diferencias entre las dos soluciones:
Algunos modificadores están marcados como Disponibilidad limitada. ¿Cómo puedo empezar a usarlos? use-limited-availability-modifiers
Los modificadores de disponibilidad limitada requieren la habilitación explícita en la cuenta para poder utilizarse en la producción. Adobe no activa estos modificadores de forma predeterminada, por lo que debe solicitar acceso a través del Soporte técnico de Adobe. El proceso consta de dos pasos: abrir un caso de asistencia y proporcionar los detalles de identificación que Adobe necesita para aprovisionar las capacidades solicitadas.
Para habilitar el uso de producción de modificadores en Disponibilidad limitada en su cuenta:
-
Mencione los siguientes detalles en el caso de la asistencia de Adobe para que Adobe pueda identificar a su organización y proporcionar las funciones solicitadas:
-
Organización de IMS (identificador de organización del sistema de Identity Management)
-
Lista de modificadores que se van a habilitar
-
-
Envíe el caso y espere a que el Soporte de Adobe confirme que los modificadores de disponibilidad limitada solicitados se han habilitado para su organización de IMS. Una vez que Adobe confirma la activación, los modificadores especificados pasan a estar disponibles para el uso de producción en su cuenta.
¿Cómo puedo probar los modificadores experimentales? modifiers-not-generally-available
Las API experimentales le permiten probar cualquier modificador que aún no esté disponible de forma general. Las API experimentales (o beta) proporcionan a los desarrolladores acceso anticipado a una funcionalidad que aún se está evaluando, de modo que puede validar nuevos modificadores antes de que se promocionen al conjunto estable y disponible de forma general. Esto le permite probar las próximas funciones, confirmar que se comportan según lo esperado en sus flujos de trabajo y proporcionar comentarios antes de una versión general.
Para probar un modificador que no está disponible de forma general, invítelo a través de la ruta de API experimental. Por ejemplo:
</adobe/experimental/advancemodifiers-expires-YYYYMMDD/assets>
El segmento expires-YYYYMMDD indica que el modificador experimental tiene un límite de tiempo, lo que indica la fecha en la que se espera que la versión experimental cambie o caduque; un recordatorio para migrar al equivalente disponible de forma general una vez que se publique.
Para obtener más información sobre cómo invocar estos extremos, consulte las instrucciones sobre cómo usar las API experimentales. Para identificar qué modificadores están disponibles, consulte la lista completa de modificadores.
Consulte también
- Traducir recursos
- API HTTP de recursos
- Formatos de archivo compatibles con recursos
- Buscar recursos
- Recursos de red
- Informes de recurso
- Esquemas de metadatos
- Descarga de recursos
- Administración de metadatos
- Administración de plantillas de Dynamic Media
- Administración de informes en la vista Recursos
- Facetas de búsqueda
- Administrar colecciones
- Importación masiva de metadatos
- Publicación de recursos en AEM y Dynamic Media