Adobe Experience Manager Assets casos de uso do desenvolvedor, APIs e material de referência

O artigo contém recomendações, materiais de referência e recursos para desenvolvedores de Assets como Cloud Service. Ele inclui um novo módulo de upload de ativos, uma referência de API e informações sobre o suporte fornecido em workflows de pós-processamento.

Experience Manager Assets APIs e operações

Assets como Cloud Service O fornece várias APIs para interagir programaticamente com ativos digitais. Cada API suporta casos de uso específicos, conforme mencionado na tabela abaixo. O Assets interface do usuário, Experience Manager aplicativo de desktop e Adobe Asset Link dar suporte a todas ou algumas das operações.

Upload de ativo

Em Experience Manager como Cloud Service, é possível fazer upload direto dos ativos para o armazenamento na nuvem usando a API HTTP. As etapas para fazer upload de um arquivo binário estão abaixo. Execute essas etapas em um aplicativo externo e não na Experience Manager JVM.

1. Enviar uma solicitação HTTP. Ele informa Experience ManageOu implantação de sua intenção de fazer upload de um novo binário.
2. PUT do conteúdo do binário a um ou mais URI fornecidos pelo pedido de início.
3. Enviar uma solicitação HTTP para informar ao servidor que o conteúdo do binário foi carregado com êxito.

A abordagem oferece uma manipulação escalável e mais eficiente dos uploads de ativos. As diferenças em comparação com Experience Manager 6.5 são:

• Os binários não passam Experience Manager, que agora simplesmente coordena o processo de upload com o armazenamento em nuvem binário configurado para a implantação.
• O armazenamento em nuvem binário funciona com uma Rede de entrega de conteúdo (CDN) ou rede de borda. Um CDN seleciona um ponto de extremidade de upload mais próximo de um cliente. Quando os dados viajam uma distância menor até um terminal próximo, o desempenho de upload e a experiência do usuário melhoram, especialmente para equipes distribuídas geograficamente.

Iniciar upload

Envie uma solicitação HTTP POST para a pasta desejada. Os ativos são criados ou atualizados nesta pasta. Incluir o seletor .initiateUpload.json para indicar que a solicitação é iniciar o upload de um arquivo binário. Por exemplo, o caminho para a pasta onde o ativo deve ser criado é /assets/folder. A solicitação POST é POST https://[aem_server]:[port]/content/dam/assets/folder.initiateUpload.json.

O tipo de conteúdo do corpo da solicitação deve ser application/x-www-form-urlencoded dados do formulário, contendo os seguintes campos:

• (string) fileName: Obrigatório. O nome do ativo como ele aparece em Experience Manager.
• (number) fileSize: Obrigatório. O tamanho do arquivo, em bytes, do ativo que está sendo carregado.

Uma única solicitação pode ser usada para iniciar uploads para vários binários, desde que cada binário contenha os campos necessários. Se bem-sucedida, a solicitação responde com um 201 código de status e um corpo contendo dados JSON no seguinte formato:

{
    "completeURI": "(string)",
    "folderPath": "(string)",
    "files": [
        {
            "fileName": "(string)",
            "mimeType": "(string)",
            "uploadToken": "(string)",
            "uploadURIs": [
                "(string)"
            ],
            "minPartSize": (number),
            "maxPartSize": (number)
        }
    ]
}

• completeURI (string): Chame esse URI quando o binário terminar o upload. O URI pode ser um URI absoluto ou relativo, e os clientes devem ser capazes de lidar com ambos. Ou seja, o valor pode ser "https://[aem_server]:[port]/content/dam.completeUpload.json" ou "/content/dam.completeUpload.json" Consulte upload completo.
• folderPath (string): Caminho completo para a pasta na qual o binário é carregado.
• (files) (matriz): Uma lista de elementos cujo comprimento e ordem correspondem ao comprimento e à ordem da lista de informações binárias fornecidas na solicitação de inicialização.
• fileName (string): O nome do binário correspondente, conforme fornecido na solicitação de inicialização. Esse valor deve ser incluído na solicitação completa.
• mimeType (string): O tipo mime do binário correspondente, conforme fornecido na solicitação de inicialização. Esse valor deve ser incluído na solicitação completa.
• uploadToken (string): Um token de upload para o binário correspondente. Esse valor deve ser incluído na solicitação completa.
• uploadURIs (matriz): Uma lista de strings cujos valores são URIs completos para as quais o conteúdo do binário deve ser carregado (consulte Upload binário).
• minPartSize (número): O comprimento mínimo, em bytes, dos dados que podem ser fornecidos a qualquer uma das uploadURIs, se houver mais de um URI.
• maxPartSize (número): O comprimento máximo, em bytes, dos dados que podem ser fornecidos a qualquer uma das uploadURIs, se houver mais de um URI.

Upload binário

A saída de iniciar um upload inclui um ou mais valores de URI de upload. Se mais de um URI for fornecido, o cliente poderá dividir o binário em partes e fazer solicitações de PUT de cada parte aos URIs de upload fornecidos, em ordem. Se você optar por dividir o binário em partes, siga as seguintes diretrizes:

• Cada parte, com exceção do último, deve ter um tamanho maior ou igual a minPartSize.
• Cada parte deve ter um tamanho inferior ou igual a maxPartSize.
• Se o tamanho do seu binário exceder maxPartSize, divida o binário em partes para carregá-lo.
• Não é necessário usar todos os URIs.

Se o tamanho do seu binário for menor ou igual a maxPartSize, em vez disso, você pode fazer upload de todo o binário para um único URI de upload. Se mais de um URI de upload for fornecido, use o primeiro e ignore o restante. Não é necessário usar todos os URIs.

Os nós de borda CDN ajudam a acelerar o upload solicitado de binários.

A maneira mais fácil de fazer isso é usar o valor de maxPartSize como seu tamanho de peça. O contrato da API garante que haja URIs de upload suficientes para carregar seu binário se você usar esse valor como tamanho de peça. Para fazer isso, divida o binário em partes do tamanho maxPartSize, usando um URI para cada parte, em ordem. A parte final pode ser de qualquer tamanho menor ou igual a maxPartSize. Por exemplo, suponha que o tamanho total do binário seja de 20.000 bytes, a variável minPartSize é de 5.000 bytes, maxPartSize é de 8.000 bytes e o número de URIs de upload é de 5. Execute as seguintes etapas:

• Faça upload dos primeiros 8.000 bytes do binário usando o primeiro URI de upload.
• Faça upload dos segundos 8.000 bytes do binário usando o segundo URI de upload.
• Faça upload dos últimos 4.000 bytes do binário usando o terceiro URI de upload. Uma vez que esta é a parte final, não é necessário que seja superior a minPartSize.
• Não é necessário usar os dois últimos URIs de upload. Você pode ignorá-los.

Um erro comum é calcular o tamanho da peça com base no número de URIs de upload fornecidos pela API. O contrato da API não garante que essa abordagem funcione e pode realmente resultar em tamanhos de partes fora do intervalo entre minPartSize e maxPartSize. Isso pode resultar em falhas de upload binário.

Novamente, a maneira mais fácil e segura é simplesmente usar partes de tamanho igual a maxPartSize.

Se o upload for bem-sucedido, o servidor responderá a cada solicitação com uma 201 código de status.

Carregamento completo

Depois que todas as partes de um arquivo binário forem carregadas, envie uma solicitação POST HTTP para o URI completo fornecido pelos dados de início. O tipo de conteúdo do corpo da solicitação deve ser application/x-www-form-urlencoded dados do formulário, contendo os seguintes campos.

Como o processo de inicialização, os dados completos da solicitação podem conter informações para mais de um arquivo.

O processo de upload de um binário não é feito até que o URL completo seja chamado para o arquivo. Um ativo é processado após a conclusão do processo de upload. O processamento não é iniciado mesmo se o arquivo binário do ativo for carregado completamente, mas o processo de upload não estiver concluído. Se o upload for bem-sucedido, o servidor responderá com uma 200 código de status.

Biblioteca de upload de código aberto

Para saber mais sobre os algoritmos de upload ou para criar seus próprios scripts e ferramentas de upload, o Adobe oferece bibliotecas e ferramentas de código aberto:

• Biblioteca de upload de aem de código aberto.
• Ferramenta de linha de comando de código aberto.

APIs de upload de ativos obsoletos

O novo método de upload é suportado somente para Adobe Experience Manager como Cloud Service. As APIs de Adobe Experience Manager 6.5 estão obsoletas. Os métodos relacionados ao upload ou atualização de ativos ou representações (qualquer upload binário) estão obsoletos nas seguintes APIs:

• API HTTP Experience Manager Assets
• AssetManager API Java, como AssetManager.createAsset(..)

Fluxos de trabalho de processamento e pós-processamento de ativos

Em Experience Manager, o processamento de ativos é baseado em Processando perfis configuração que usa microsserviços de ativos. O processamento não requer extensões de desenvolvedor.

Para configuração de fluxo de trabalho de pós-processamento, use os fluxos de trabalho padrão com extensões com etapas personalizadas.

Suporte a etapas do fluxo de trabalho no fluxo de trabalho de pós-processamento

Se você atualizar de uma versão anterior de Experience Manager, é possível usar os microsserviços de ativos para processar ativos. Os microsserviços de ativos nativos em nuvem são mais simples de configurar e usar. Algumas etapas do fluxo de trabalho usadas na Ativo de atualização DAM não há suporte para fluxo de trabalho na versão anterior. Para obter mais informações sobre as classes compatíveis, consulte a Referência da API Java ou Javadocs.

Os seguintes modelos de fluxo de trabalho técnicos são substituídos por microsserviços de ativos ou o suporte não está disponível:

• 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