Todos los productos
Search
Centro de documentos

Intelligent Media Management:Procesamiento de tareas asíncronas

Última actualización: Sep 04, 2026

IMM es compatible con diversas operaciones de salida de datos. Algunas de estas operaciones son de larga duración y no pueden devolver resultados en una sola solicitud síncrona. Para manejar estos casos, IMM proporciona operaciones de API asíncronas, que generalmente siguen el formato CreateXXXTask, así como un mecanismo de notificación para recuperar los resultados.

Nota

Las operaciones de API asíncronas en IMM están diseñadas para trabajos de larga duración que no pueden devolver resultados en una única solicitud síncrona. Este enfoque asíncrono evita el bloqueo del cliente, mejora el rendimiento del sistema y ejecuta trabajos programados o que consumen muchos recursos en segundo plano sin afectar la experiencia del usuario.

Funcionamiento

  1. Cargue sus datos de origen en Object Storage Service (OSS) de Alibaba Cloud.

  2. Llame a una operación de API de IMM, como CreateXXXTask, para iniciar una tarea asíncrona.

  3. IMM recupera y procesa los datos de origen desde la URI de OSS especificada.

  4. IMM escribe los resultados del procesamiento en la URI de OSS especificada.

  5. Una vez completada la tarea, IMM envía el estado de la tarea al tema de MNS o ApsaraMQ for RocketMQ que haya especificado.

  6. Posteriormente, MNS o ApsaraMQ for RocketMQ envía el mensaje de notificación a su aplicación o servicio.

Entrada y salida de la tarea

  • Los parámetros de datos de entrada suelen tener el prefijo Source. A continuación se muestran los parámetros disponibles:

    • SourceURI: La ubicación de los datos de entrada. Solo se admiten URI de OSS.

    • Sources: Una matriz con varias URI de entrada.

    • Source: Un objeto que contiene varias URI de entrada.

  • Los parámetros de datos de salida suelen tener el prefijo Target. A continuación se muestran los parámetros disponibles:

    • TargetURI: El destino de la salida. Este parámetro admite sintaxis de plantilla.

    • TargetURIPrefix: El prefijo para la URI de destino de la salida.

    • Target: Un objeto que contiene varias URI de salida.

Importante

Los datos de entrada y salida deben estar en la misma región que el servicio IMM.

URI de OSS

Una URI de OSS identifica de forma única un recurso en OSS y utiliza el formato oss://<bucket>/<object>, por ejemplo, oss://test-bucket/test-object/test.docx.

Nota

<bucket> es el nombre de un bucket de OSS en la misma región que su proyecto. <object> es la ruta completa al archivo, incluida su extensión.

Algunos formatos no válidos comunes incluyen:

  • http://bucket.oss-cn-hangzhou.aliyuncs.com/test-object/test.docx

  • oss://bucket.oss-cn-hangzhou.aliyuncs.com/test-object/test.docx

Plantilla de TargetURI

Una plantilla de TargetURI permite usar marcadores de posición en una URI. Estos marcadores se reemplazan con valores reales durante la ejecución para generar dinámicamente la URI de salida final. Por ejemplo: oss://{bucket}/{tags.custom}/{dirname}/{barename}.{autoext}.

Para obtener más información, consulte TargetURI template.

Autorización

Para una tarea asíncrona, debe otorgar permisos a IMM para leer datos de entrada y escribir datos de salida en las ubicaciones que proporcione. Estos permisos los determina el parámetro Project Name en su solicitud, el cual identifica el proyecto y su rol vinculado al servicio asociado. Este rol se especifica para el proyecto mediante el parámetro Service Role en la operación de API Create Project. De forma predeterminada, se utiliza AliyunIMMDefaultRole, que se crea automáticamente al activar el servicio. Durante el procesamiento de la tarea, IMM asume este rol para acceder a sus datos.

Obtención del estado de la tarea

Uso de MNS o ApsaraMQ for RocketMQ

Como se describe en la sección How it works, puede configurar MNS o ApsaraMQ for RocketMQ para recibir notificaciones sobre el estado de las tareas de IMM. Este es el método recomendado. Para obtener detalles sobre el formato de notificación, consulte Asynchronous notification message format.

Importante

MNS o ApsaraMQ for RocketMQ deben estar en la misma región que IMM.

  • (Recomendado) Utilice el parámetro Notification para especificar la configuración de MNS o ApsaraMQ for RocketMQ para las notificaciones asíncronas.

    • MNS: Use el campo MNS dentro del parámetro Notification para especificar el endpoint y el tema de MNS.

      {
        "Notification": {
          "MNS": {
            "Endpoint": "The MNS endpoint",
            "TopicName": "The MNS topic"
          }
        }
      }
    • ApsaraMQ for RocketMQ: Use el campo RocketMQ dentro del parámetro Notification para especificar el endpoint, el tema y el ID de instancia de ApsaraMQ for RocketMQ.

      {
        "Notification": {
          "RocketMQ": {
            "Endpoint": "The ApsaraMQ for RocketMQ endpoint",
            "TopicName": "The ApsaraMQ for RocketMQ topic",
            "InstanceId": "The ApsaraMQ for RocketMQ instance ID"
          }
        }
      }
  • Utilice los parámetros NotifyEndpoint y NotifyTopicName para especificar el endpoint y el tema de MNS donde se recibirán las notificaciones de mensajes asíncronos.

    • NotifyEndpoint: El endpoint de MNS para recibir notificaciones. De forma predeterminada, corresponde al endpoint de MNS del llamante.

    • NotifyTopicName: El nombre del tema de MNS. Si este parámetro se deja vacío, no se enviarán notificaciones.

Uso de la API GetTask

IMM también proporciona la operación de API GetTask para consultar el estado de una tarea.

Aunque es posible llamar repetidamente a la operación de API GetTask para sondear el estado de una tarea hasta que finalice, este método es ineficiente y no se recomienda para entornos de producción. En tareas de larga duración, el sondeo puede generar una gran cantidad de llamadas a GetTask. Si hay muchas tareas en cola, esto podría desencadenar limitaciones globales y afectar otras llamadas a la API. Además, el sondeo introduce latencia. Una tarea puede finalizar en cualquier momento entre dos sondeos, pero no se tendrá conocimiento de su conclusión hasta el siguiente sondeo, lo que introduce un retraso promedio equivalente a la mitad del intervalo de sondeo.

Nota

La información de la tarea se conserva solo durante 7 días después de su inicio; transcurrido ese tiempo, ya no se puede recuperar.

Uso de etiquetas

El parámetro Tags en su solicitud permite etiquetar una tarea. Puede utilizar las etiquetas de las siguientes maneras:

  • Buscar tareas por etiqueta.

  • Usar etiquetas como variables en una plantilla de TargetURI.