Demandes de travail asynchrones

Les appels d'API envoyés aux services Oracle Cloud Infrastructure peuvent lancer d'opérations à longue durée d'exécution qui n'effectuent pas la demande du client avant qu'une réponse soit renvoyée. Dans ce cas, le service génère de façon dynamique une demande de travail asynchrone permettant de visualiser la progression des opérations asynchrones à longue durée d'exécution. La réponse à l'appel d'API REST contient un ID de demande de travail dans l'en-tête opc-work-request-id, qui vous permet de surveiller sa progression et son statut. La demande de travail reste dans une file d'attente jusqu'à ce que l'opération soit terminée.

Vous pouvez surveiller à tout moment le statut de la demande de travail en appelant GetWorkRequest et en transmettant l'ID de demande de travail.

Deux fonctionnalités de la réponse à la demande présentent un intérêt particulier : le statut de la demande de travail et la liste des ressources concernées par cette demande de travail. Le statut est important car les demandes de travail asynchrones doivent savoir quand une opération est terminée, si elle est toujours en cours d'exécution ou si elle a échoué.

Pour récupérer des informations sur les erreurs ou les échecs de demande de travail, chaque service fournit des API permettant d'extraire des informations sur les erreurs et les journaux. Pour obtenir des liens vers la documentation de référence d'API de chaque service, reportez-vous à Informations supplémentaires.

Dans les cas où une opération de demande de travail concerne plusieurs ressources, il est également important de disposer de la liste des ressources en question, ainsi que des attributs entityType et actionType de chacune d'elles.

Les demandes de travail asynchrones vous permettent de surveiller leur progression en fournissant un attribut de statut sur l'objet WorkRequest. Chaque service pris en charge fournit sa propre API pour obtenir le statut, comme indiqué dans les sections suivantes.

Le tableau ci-dessous répertorie les attributs de statut pris en charge par l'objet WorkRequest sur les services respectifs.

Parfois, vous avez besoin de savoir quelles ressources sont concernées par une demande de travail asynchrone donnée. Si la réponse à la demande comprend une ou deux ressources, le corps de la réponse à la demande est probablement suffisant. Cependant, si la réponse à une demande concerne de nombreuses ressources, vous devez filtrer la réponse afin d'identifier les ressources qui vous intéressent.

Le filtrage des ressources répertoriées dans la réponse à une demande de travail repose sur deux attributs du type WorkRequestResource : entityType et actionType.

• entityType : représente le type de ressource concerné par la demande de travail. Il s'agit d'un attribut facultatif, mais chaque ressource ne peut avoir qu'un seul attribut entityType.
• actionType : représente la manière dont la ressource spécifiée est concernée par l'opération associée à la demande de travail. Chaque service spécifie une liste fixe de valeurs actionType autorisées (indiquées dans les sections suivantes).

Afin d'obtenir des informations de ressource pour une demande de travail, appelez GetWorkRequest et transmettez l'ID de la demande de travail. L'appel renvoie une réponse au format JSON. L'exemple suivant illustre l'appel de GetWorkRequest sur le service Object Storage.

{
    operationType: "COPY_OBJECT",
    status: "IN_PROGRESS",
    id: "f54527d6-029b-4221-9046-a811b7686202",
    resources: [
        {
            entityType: "object",
            actionType: "READ",
            entityUri: "/n/mynamespace/b/backups/o/myobject"
        },
        {
            entityType: "object",
            actionType: "WRITTEN",
            entityUri: "/n/mynamespace/b/backups/o/copyofmyobject"
        },
    ],
    timeAccepted: 2017-10-13T17:23:46.000Z,
    timeStarted: 2017-10-13T17:23:52.198Z,
    percentComplete: 10.0
}

Le tableau ci-dessous répertorie les types d'entité et de l'action pris en charge par les services Oracle Cloud Infrastructure.

Voici une séquence d'appels d'API REST permettant de créer un cluster, qui est une opération à longue durée d'exécution courante. L'appelant extrait l'ID de la demande de travail à partir de la réponse à l'appel POST initial, puis interroge périodiquement WorkRequest pour déterminer le statut de l'opération. La séquence demande/réponse qui suit illustre ce workflow :

1. L'utilisateur émet un appel d'API CreateCluster.
2. Le service répond avec le code de statut 202, indiquant que la demande a été acceptée, et renvoie un ID de demande de travail dans l'en-tête opc-work-request-id.
3. Ensuite, l'utilisateur émet un appel GET sur l'ID de la demande de travail pour obtenir le statut de cette demande.
4. Le service répond avec le code de statut 200, indiquant dans le corps de réponse que l'opération CLUSTER_CREATE a le statut ACCEPTED.
5. En poursuivant l'interrogation, nous voyons un autre appel GET pour la demande de travail.
6. Le service répond avec le code de statut 200. Le corps de réponse signale que l'opération a le statut SUCCEEDED.

Etape 1. Appel d'API initial pour lancer une opération CLUSTER_CREATE.

POST https://containerengine.eu-frankfurt-1.oraclecloud.com/20180222/clusters
Accept: application/json
authorization: <Redacted>
content-length: 480
Content-Type: application/json
date: Mon, 02 Jul 2018 18:20:03 GMT
host: containerengine.eu-frankfurt-1.oraclecloud.com
opc-client-info: Oracle-JavaSDK/1.2.42-preview1-SNAPSHOT
opc-request-id: D7A390ED909C47038C438BA3629FB612
User-Agent: Oracle-JavaSDK/1.2.42-preview1-SNAPSHOT (Mac OS X/10.13.5; Java/1.8.0_172; Java HotSpot(TM) 64-Bit Server VM/25.172-b11)
x-content-sha256: S8U8OKQHyTLNViAzgexkjxvF4ctncJJHTjuRfXn0ya4={
   "name":"JavaSDK.CRUD",
   "compartmentId":"ocid1.compartment.oc1..<unique_ID>",
   "vcnId":"ocid1.vcn.oc1.eu-frankfurt-1.<unique_ID>",
   "kubernetesVersion":"v1.10.3",
   "options":{"serviceLbSubnetIds":["ocid1.subnet.oc1.eu-frankfurt-1.<unique_ID>",
   "ocid1.subnet.oc1.eu-frankfurt-1.<unique_ID>"]}}

Etape 2. Réponse à l'appel d'API initial, qui contient l'ID de demande de travail dans l'en-tête Opc-Work-Request-Id.

202
Access-Control-Allow-Methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: opc-work-request-id
Content-Length: 0
Date: Mon, 02 Jul 2018 18:20:04 GMT
Opc-Request-Id: D7A390ED909C47038C438BA3629FB612/33EEDCAAB2E84508B34AA75CD0FD86F4/8261D1CC89814E9BB934440A1F43DA09
Opc-Work-Request-Id: ocid1.clustersworkrequest.oc1.eu-frankfurt-1.exampleuniqueID
Uri: /20180222/clusters
Vary: Accept-Encoding
X-Rate-Limit-Duration: 1
X-Rate-Limit-Limit: 16.70
X-Rate-Limit-Request-Forwarded-For: 10.237.10.0, 10.237.9.51
X-Rate-Limit-Request-Remote-Addr: 10.237.9.51:53077

Etape 3. Comme il s'agit d'une opération à longue durée d'exécution, l'utilisateur interroge périodiquement la demande de travail à l'aide d'un appel GET pour déterminer son statut.

GET https://containerengine.eu-frankfurt-1.oraclecloud.com/20180222/workRequests/<clusters_work_request_OCID>
Accept: application/json
authorization: <Redacted>
date: Mon, 02 Jul 2018 18:20:04 GMT
host: containerengine.eu-frankfurt-1.oraclecloud.com
opc-client-info: Oracle-JavaSDK/1.2.42-preview1-SNAPSHOT
opc-request-id: E8F20DAC443346B3B0EA599F367EE294
User-Agent: Oracle-JavaSDK/1.2.42-preview1-SNAPSHOT (Mac OS X/10.13.5; Java/1.8.0_172; Java HotSpot(TM) 64-Bit Server VM/25.172-b11)

Etape 4. L'appel GET renvoie la réponse suivante, qui indique dans le corps que l'opération CLUSTER_CREATE a le statut ACCEPTED.

200
Access-Control-Allow-Methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: opc-work-request-id
Content-Length: 717
Content-Type: application/json
Date: Mon, 02 Jul 2018 18:20:05 GMT
Etag: 56a41efaf33d81a54933495ee910c24d7bce7a83adf18810f95e07bdd2055805
Opc-Request-Id: E8F20DAC443346B3B0EA599F367EE294/8B19C9FC3B4442CEA14685D1973D0856/0BA60B0711764DE4A4373071632708C7
Retry-After: 30
Uri: /20180222/workRequests/_id_
Vary: Accept-Encoding
X-Rate-Limit-Duration: 1
X-Rate-Limit-Limit: 16.70
X-Rate-Limit-Request-Forwarded-For: 10.237.10.0, 10.237.9.51
X-Rate-Limit-Request-Remote-Addr: 10.237.9.51:43533
{
  "id": "ocid1.clustersworkrequest.oc1.eu-frankfurt-1.exampleuniqueID",
  "operationType": "CLUSTER_CREATE",
  "status": "ACCEPTED",
  "compartmentId": "ocid1.compartment.oc1..exampleuniqueID",
  "resources": [
    {
      "actionType": "IN_PROGRESS",
      "entityType": "cluster",
      "identifier": "ocid1.cluster.oc1.eu-frankfurt-1.exampleuniqueID",
      "entityUri": "/clusters/ocid1.cluster.oc1.eu-frankfurt-1.exampleuniqueID"
    }
  ],
  "timeAccepted": "2018-07-02T18:20:05Z",
  "timeStarted": null,
  "timeFinished": null
}

Etape 5. L'opération se poursuit et l'utilisateur continue d'interroger la demande de travail à l'aide de la méthode GET.

GET https://containerengine.eu-frankfurt-1.oraclecloud.com/20180222/workRequests/<clusters_work_request_OCID>
Accept: application/json
authorization: <Redacted>
date: Mon, 02 Jul 2018 18:24:13 GMT
host: containerengine.eu-frankfurt-1.oraclecloud.com
opc-client-info: Oracle-JavaSDK/1.2.42-preview1-SNAPSHOT
opc-request-id: 64595B97E39A471A886DA29966BB6B1D
User-Agent: Oracle-JavaSDK/1.2.42-preview1-SNAPSHOT (Mac OS X/10.13.5; Java/1.8.0_172; Java HotSpot(TM) 64-Bit Server VM/25.172-b11)

Etape 6. Le dernier appel GET a généré la réponse suivante, qui indique que l'opération est terminée. La valeur de entityType est "cluster" et celle de actionType est "CREATED".

200
Access-Control-Allow-Methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: opc-work-request-id
Content-Length: 750
Content-Type: application/json
Date: Mon, 02 Jul 2018 18:24:14 GMT
Etag: 023d2a8ccb6d893fa8c875f64652353f21d22607825f49eeeb15b5394ae24918
Opc-Request-Id: 64595B97E39A471A886DA29966BB6B1D/3A81140991C94794AF365016E31DBE82/6245FBD8C25842B6BDF15187EA6ADB21
Uri: /20180222/workRequests/_id_
Vary: Accept-Encoding
X-Rate-Limit-Duration: 1
X-Rate-Limit-Limit: 16.70
X-Rate-Limit-Request-Forwarded-For: 10.237.3.0, 10.237.40.183
X-Rate-Limit-Request-Remote-Addr: 10.237.40.183:55856

{
  "id": "ocid1.clustersworkrequest.oc1.eu-frankfurt-1.exampleuniqueID",
  "operationType": "CLUSTER_CREATE",
  "status": "SUCCEEDED",
  "compartmentId": "ocid1.compartment.oc1..exampleuniqueID",
  "resources": [
    {
      "actionType": "CREATED",
      "entityType": "cluster",
      "identifier": "ocid1.cluster.oc1.eu-frankfurt-1.exampleuniqueID",
      "entityUri": "/clusters/ocid1.cluster.oc1.eu-frankfurt-1.exampleuniqueID"
    }
  ],
  "timeAccepted": "2018-07-02T18:20:05Z",
  "timeStarted": "2018-07-02T18:20:10Z",
  "timeFinished": "2018-07-02T18:24:01Z"
}

• API Application Performance Monitoring pour les demandes de travail
• API des demandes de travail Autonomous Recovery Service
• API d'une demande de travail Bastion
• Demandes de travail Blockchain Platform
• API des demandes de travail Cloud Advisor
• API de demande de travail des groupes de placement de cluster
• API Compute de demande de travail

• Connector Hub:

  • Visualisation de l'état d'une demande d'un travail Connector Hub
  • API de demande d'intervention Connector Hub
• API des demandes de travail Container Instances
• API des demandes de travail Content Management

• Data Catalog :

  • Demandes de travail Data Catalog
  • API des demandes de travail Data Catalog
• API des demandes de travail Data Integration

• Data Labeling:

  • Demandes d'intervention Data Labeling
  • API d'une demande de travail Data Labeling

• Data Science:

  • Création de sessions de bloc-notes et Suppression des projets
  • API des demandes de travail Data Science
• API des demandes de travail de base de données
• API des demandes de travail Database Management
• API des demandes de travail Database Migration
• API de demande de travail Database Tools
• OCI Database with PostgreSQL
• DevOps API des demandes de travail
• API de demande d'intervention File Storage
• File Storage avec API de demande de travail Lustre
• API de demande de travail Fleet Application Management
• API des demandes de travail Full Stack Disaster Recovery
• API de demande de travail Globally Distributed Autonomous Database
• Base de données Exadata distribuée globalement sur l'API de demande de travail d'infrastructure Exascale
• API de demande de travail GoldenGate

• IAM:

  • API de demande de travail IAM (Procédure de suppression d'un autre compartiment)
  • API TaggingWorkRequest (Concepts relatifs aux balises et à l'espace de noms de balise)
• API de demande de travail Integration
• API des demandes de travail Java Management
• API de demande de travail du moteur Kubernetes

• L'équilibreur de charge :

  • Demandes de travail pour Load Balancer
  • API des demandes de travail de l'équilibreur de charge
• API Log Analytics de demande de travail
• API des demandes de travail d'agent de gestion
• API de demande de travail MySQL HeatWave
• API des demandes de travail Network Firewall

• Object Storage :

  • Demandes de travail de copie d'objets
  • API des demandes de travail Object Storage
• API Oracle Cloud Bridge pour les demandes de travail
• API Oracle Cloud Migrations pour les demandes de travail
• API de demande de travail OS Management Hub
• API des demandes de travail Process Automation
• API de demande de travail Queue
• API des demandes de travail Resource Manager
• API de demande de travail Secure Desktops
• API des demandes de travail Service Mesh
• API des demandes de travail Stack Monitoring
• API de demande de travail Vision
• Visual Builder Studio : API WorkRequest
• API des demandes de travail Vulnerability Scanning
• WebLogic API de demande d'intervention de gestion