El artículo contiene recomendaciones, materiales de referencia y recursos para desarrolladores de Assets como Cloud Service. Incluye un nuevo módulo de carga de recursos, una referencia de API y información sobre la compatibilidad proporcionada en los flujos de trabajo posteriores al procesamiento.
Assets como Cloud Service proporciona varias API para interactuar mediante programación con recursos digitales. Cada API admite casos de uso específicos, como se menciona en la tabla siguiente. La variable Assets interfaz de usuario, Experience Manager aplicación de escritorio y Adobe Asset Link admiten todas o algunas de las operaciones.
Algunas API siguen existiendo, pero no se admiten de forma activa (indicada con una ×). En la medida de lo posible, no utilice estas API.
Nivel de asistencia | Descripción |
---|---|
✓ | Compatibilidad |
× | No se admite. No usar. |
- | No disponible |
Caso de uso | aem-upload | Experience Manager / Sling / JCR API de Java | servicio de asset compute | Assets API HTTP | Sling GET / POST servlets | GraphQL |
---|---|---|---|---|---|---|
binario original | ||||||
Crear original | ✓ | × | - | × | × | - |
Leer original | - | × | ✓ | ✓ | ✓ | - |
Actualizar original | ✓ | × | ✓ | × | × | - |
Eliminar original | - | ✓ | - | ✓ | ✓ | - |
Copiar original | - | ✓ | - | ✓ | ✓ | - |
Mover original | - | ✓ | - | ✓ | ✓ | - |
Metadatos | ||||||
Crear metadatos | - | ✓ | ✓ | ✓ | ✓ | - |
Leer metadatos | - | ✓ | - | ✓ | ✓ | - |
Actualización de metadatos | - | ✓ | ✓ | ✓ | ✓ | - |
Eliminar metadatos | - | ✓ | ✓ | ✓ | ✓ | - |
Copiar metadatos | - | ✓ | - | ✓ | ✓ | - |
Mover metadatos | - | ✓ | - | ✓ | ✓ | - |
Fragmentos de contenido (CF) | ||||||
Crear CF | - | ✓ | - | ✓ | - | - |
Leer CF | - | ✓ | - | ✓ | - | ✓ |
Actualizar CF | - | ✓ | - | ✓ | - | - |
Eliminar CF | - | ✓ | - | ✓ | - | - |
Copiar CF | - | ✓ | - | ✓ | - | - |
Mover CF | - | ✓ | - | ✓ | - | - |
Versiones | ||||||
Crear versión | ✓ | ✓ | - | - | - | - |
Leer versión | - | ✓ | - | - | - | - |
Eliminar versión | - | ✓ | - | - | - | - |
Carpetas | ||||||
Crear carpeta | ✓ | ✓ | - | ✓ | - | - |
Leer carpeta | - | ✓ | - | ✓ | - | - |
Eliminar carpeta | ✓ | ✓ | - | ✓ | - | - |
Copiar carpeta | ✓ | ✓ | - | ✓ | - | - |
Mover carpeta | ✓ | ✓ | - | ✓ | - | - |
En Experience Manager como Cloud Service, puede cargar directamente los recursos en el almacenamiento en la nube mediante la API HTTP. A continuación se indican los pasos para cargar un archivo binario. Ejecute estos pasos en una aplicación externa y no dentro de la función Experience Manager JVM.
Ejecute los pasos anteriores en una aplicación externa y no dentro del Experience Manager JVM.
El método proporciona una gestión escalable y más eficaz de las cargas de recursos. Las diferencias con respecto a Experience Manager 6.5 son:
Consulte el código de cliente para implementar este método en el código abierto biblioteca aem-upload.
En determinadas circunstancias, es posible que los cambios no se propaguen completamente entre las solicitudes al Experience Manager debido a la naturaleza eventualmente consistente del almacenamiento en Cloud Service. Esto lleva a 404 respuestas para iniciar o completar llamadas de carga debido a que las creaciones de carpetas requeridas no se propagan. Los clientes deben esperar 404 respuestas y manejarlas implementando un reintento con una estrategia de back-off.
Envíe una solicitud de POST HTTP a la carpeta deseada. Los recursos se crean o actualizan en esta carpeta. Incluir el selector .initiateUpload.json
para indicar que la solicitud es iniciar la carga de un archivo binario. Por ejemplo, la ruta a la carpeta en la que se debe crear el recurso es /assets/folder
. La solicitud del POST es POST https://[aem_server]:[port]/content/dam/assets/folder.initiateUpload.json
.
El tipo de contenido del cuerpo de la solicitud debe ser application/x-www-form-urlencoded
datos del formulario, que contienen los campos siguientes:
(string) fileName
: Requerido. El nombre del recurso tal como aparece en Experience Manager.(number) fileSize
: Requerido. El tamaño del archivo, en bytes, del recurso que se está cargando.Se puede utilizar una sola solicitud para iniciar cargas para varios binarios, siempre que cada binario contenga los campos obligatorios. Si se realiza correctamente, la solicitud responde con un 201
código de estado y un cuerpo que contiene datos JSON con el siguiente formato:
{
"completeURI": "(string)",
"folderPath": "(string)",
"files": [
{
"fileName": "(string)",
"mimeType": "(string)",
"uploadToken": "(string)",
"uploadURIs": [
"(string)"
],
"minPartSize": (number),
"maxPartSize": (number)
}
]
}
completeURI
(cadena): Llame a este URI cuando el binario termine de cargarse. El URI puede ser absoluto o relativo, y los clientes deben poder gestionar cualquiera de ellos. Es decir, el valor puede ser "https://[aem_server]:[port]/content/dam.completeUpload.json"
o "/content/dam.completeUpload.json"
Consulte carga completa.folderPath
(cadena): Ruta de acceso completa a la carpeta en la que se carga el binario.(files)
(matriz): Una lista de elementos cuya longitud y orden coinciden con la longitud y el orden de la lista de información binaria proporcionada en la solicitud de inicio.fileName
(cadena): El nombre del binario correspondiente, tal como se proporciona en la solicitud de inicio. Este valor debe incluirse en la solicitud completa.mimeType
(cadena): Tipo mime del binario correspondiente, tal como se suministra en la solicitud de inicio. Este valor debe incluirse en la solicitud completa.uploadToken
(cadena): Un token de carga para el binario correspondiente. Este valor debe incluirse en la solicitud completa.uploadURIs
(matriz): Una lista de cadenas cuyos valores son URI completos a los que se debe cargar el contenido del binario (consulte Cargar binario).minPartSize
(número): La longitud mínima, en bytes, de los datos que se pueden proporcionar a cualquiera de las uploadURIs
, si hay más de un URI.maxPartSize
(número): La longitud máxima, en bytes, de los datos que se pueden proporcionar a cualquiera de las uploadURIs
, si hay más de un URI.El resultado del inicio de una carga incluye uno o más valores de URI de carga. Si se proporciona más de un URI, el cliente puede dividir el binario en partes y realizar solicitudes de PUT de cada parte a los URI de carga proporcionados, en orden. Si decide dividir el binario en partes, siga las siguientes directrices:
minPartSize
.maxPartSize
.maxPartSize
, divida el binario en partes para cargarlo.Si el tamaño del binario es menor o igual que maxPartSize
, puede cargar el binario completo en un único URI de carga. Si se proporciona más de un URI de carga, utilice el primero e ignore el resto. No es necesario que utilice todas las URI.
Los nodos perimetrales de CDN ayudan a acelerar la carga solicitada de binarios.
La forma más sencilla de lograr esto es utilizar el valor de maxPartSize
como su tamaño de pieza. El contrato de API garantiza que haya suficientes URI de carga para cargar el binario si utiliza este valor como tamaño de pieza. Para ello, divida el binario en partes de tamaño maxPartSize
, utilizando un URI para cada parte, en orden. La parte final puede ser de cualquier tamaño menor o igual que maxPartSize
. Por ejemplo, supongamos que el tamaño total del binario es de 20 000 bytes. minPartSize
tiene 5000 bytes, maxPartSize
tiene 8000 bytes y el número de URI de carga es de 5. Siga estos pasos:
minPartSize
.Un error común es calcular el tamaño de la pieza en función del número de URI de carga que proporciona la API. El contrato de API no garantiza que este enfoque funcione y puede dar como resultado tamaños de pieza que estén fuera del rango entre minPartSize
y maxPartSize
. Esto puede provocar errores de carga binaria.
De nuevo, la manera más fácil y segura es simplemente usar partes del tamaño igual a maxPartSize
.
Si la carga se realiza correctamente, el servidor responde a cada solicitud con un 201
código de estado.
Para obtener más información sobre el algoritmo de carga, consulte la documentación oficial de la función y Documentación de API en el proyecto Apache Jackrabbit Oak.
Una vez cargadas todas las partes de un archivo binario, envíe una solicitud de POST HTTP al URI completo proporcionado por los datos de inicio. El tipo de contenido del cuerpo de la solicitud debe ser application/x-www-form-urlencoded
datos de formulario, que contienen los campos siguientes.
Campos | Tipo | Requerido o no | Descripción |
---|---|---|---|
fileName |
Cadena | Requerido | El nombre del recurso, tal como lo proporcionaron los datos de inicio. |
mimeType |
Cadena | Requerido | El tipo de contenido HTTP del binario, tal como proporcionaron los datos de inicio. |
uploadToken |
Cadena | Requerido | Token de carga para el binario, tal como proporcionaban los datos de inicio. |
createVersion |
Booleano | Opcional | If True y existe un recurso con el nombre especificado, Experience Manager crea una nueva versión del recurso. |
versionLabel |
Cadena | Opcional | Si se crea una nueva versión, la etiqueta asociada a la nueva versión de un recurso . |
versionComment |
Cadena | Opcional | Si se crea una nueva versión, los comentarios asociados a la versión. |
replace |
Booleano | Opcional | If True y existe un recurso con el nombre especificado, Experience Manager elimina el recurso y lo vuelve a crear. |
uploadDuration |
Número | Opcional | Cantidad total de tiempo, en milisegundos, que tarda el archivo en cargarse en su totalidad. Si se especifica, la duración de la carga se incluye en los archivos de registro del sistema para el análisis de la velocidad de transferencia. |
fileSize |
Número | Opcional | El tamaño, en bytes, del archivo. Si se especifica, el tamaño del archivo se incluye en los archivos de registro del sistema para el análisis de la velocidad de transferencia. |
Si el recurso existe y ni createVersion
nor replace
se especifica, entonces Experience Manager actualiza la versión actual del recurso con el nuevo binario.
Al igual que el proceso de inicio, los datos de solicitud completos pueden contener información para más de un archivo.
El proceso de carga de un binario no se realiza hasta que se invoca la URL completa para el archivo. Un recurso se procesa una vez finalizado el proceso de carga. El procesamiento no se inicia aunque el archivo binario del recurso se cargue completamente, pero el proceso de carga no se haya completado. Si la carga se realiza correctamente, el servidor responde con un 200
código de estado.
Para obtener más información sobre los algoritmos de carga o para crear sus propios scripts y herramientas de carga, Adobe proporciona bibliotecas y herramientas de código abierto:
Tanto la biblioteca de carga de aem como la herramienta de línea de comandos utilizan la función biblioteca node-httptransfer
El nuevo método de carga solo es compatible con Adobe Experience Manager como Cloud Service. Las API de Adobe Experience Manager 6.5 están en desuso. Los métodos relacionados con la carga o actualización de recursos o representaciones (cualquier carga binaria) quedan obsoletos en las siguientes API:
AssetManager
API de Java, como AssetManager.createAsset(..)
En Experience Manager, el procesamiento de recursos se basa en Perfiles de procesamiento configuración que utiliza microservicios de recursos. El procesamiento no requiere extensiones de desarrollador.
Para la configuración del flujo de trabajo posterior al procesamiento, utilice los flujos de trabajo estándar con extensiones con pasos personalizados.
Si actualiza desde una versión anterior de Experience Manager, puede utilizar los microservicios de recursos para procesar los recursos. Los microservicios de recursos nativos de la nube son más sencillos de configurar y usar. Algunos pasos del flujo de trabajo utilizados en la variable Recurso de actualización DAM no son compatibles con los flujos de trabajo de la versión anterior. Para obtener más información sobre las clases admitidas, consulte la Referencia de API de Java para Javadocs.
Los siguientes modelos técnicos de flujo de trabajo se sustituyen por microservicios de recursos o no hay compatibilidad disponible:
com.day.cq.dam.cameraraw.process.CameraRawHandlingProcess
com.day.cq.dam.core.process.CommandLineProcess
com.day.cq.dam.pdfrasterizer.process.PdfRasterizerHandlingProcess
com.day.cq.dam.core.process.AddPropertyWorkflowProcess
com.day.cq.dam.core.process.CreateSubAssetsProcess
com.day.cq.dam.core.process.DownloadAssetProcess
com.day.cq.dam.word.process.ExtractImagesProcess
com.day.cq.dam.word.process.ExtractPlainProcess
com.day.cq.dam.ids.impl.process.IDSJobProcess
com.day.cq.dam.indd.process.INDDMediaExtractProcess
com.day.cq.dam.indd.process.INDDPageExtractProcess
com.day.cq.dam.core.impl.lightbox.LightboxUpdateAssetProcess
com.day.cq.dam.pim.impl.sourcing.upload.process.ProductAssetsUploadProcess
com.day.cq.dam.core.process.SendDownloadAssetEmailProcess
com.day.cq.dam.similaritysearch.internal.workflow.smarttags.StartTrainingProcess
com.day.cq.dam.similaritysearch.internal.workflow.smarttags.TransferTrainingDataProcess
com.day.cq.dam.switchengine.process.SwitchEngineHandlingProcess
com.day.cq.dam.core.process.GateKeeperProcess
com.day.cq.dam.s7dam.common.process.DMEncodeVideoWorkflowCompletedProcess
com.day.cq.dam.core.process.DeleteImagePreviewProcess
com.day.cq.dam.video.FFMpegTranscodeProcess
com.day.cq.dam.core.process.ThumbnailProcess
com.day.cq.dam.video.FFMpegThumbnailProcess
com.day.cq.dam.core.process.CreateWebEnabledImageProcess
com.day.cq.dam.core.process.CreatePdfPreviewProcess
com.day.cq.dam.s7dam.common.process.VideoUserUploadedThumbnailProcess
com.day.cq.dam.s7dam.common.process.VideoThumbnailDownloadProcess
com.day.cq.dam.s7dam.common.process.VideoProxyServiceProcess
com.day.cq.dam.scene7.impl.process.Scene7UploadProcess
com.day.cq.dam.s7dam.common.process.S7VideoThumbnailProcess
com.day.cq.dam.core.process.MetadataProcessorProcess
com.day.cq.dam.core.process.AssetOffloadingProcess
com.adobe.cq.dam.dm.process.workflow.DMImageProcess