Documentation Oracle Cloud Infrastructure

Demandes de travail

Les demandes de travail vous aident à surveiller les opérations à longue durée d'exécution, comme les sauvegardes de base de données ou le provisionnement d'instances de calcul.

Lorsque vous démarrez une opération à longue durée d'exécution, le service crée une demande de travaux. Une demande de travail est un journal d'activités qui vous permet de suivre chaque étape de la progression d'une opération. Chaque demande de travail dispose d'un OCID qui vous permet d'interagir avec elle par programmation et de l'utiliser à des fins d'automatisation.

Les demandes de travail fournissent généralement des informations sur le statut du workflow associé, les erreurs, les fichiers journaux et la liste des ressources concernées par le workflow.

Remarque

Certains services Oracle Cloud Infrastructure, tels que Compute et Database, prennent en charge des demandes d'intervention à l'aide de la API des demandes d'intervention, qui contient l'opération GetWorkRequest.

Certains services proposent des demandes de travail prises en charge par l'API de service plutôt que l'API des demandes de travail abordée dans cette rubrique. Ces API de service incluent des opérations qui fonctionnent de la même manière que l'opération GetWorkRequest utilisée par l'API des demandes de travail.

Pour plus d'informations, reportez-vous à la documentation de référence de l'API de demande de travail de chaque service. Des liens vers chacune des API sont fournis dans la section Informations supplémentaires et API pour les services pris en charge.

Introduction aux demandes de travail

Les demandes de travail sont utiles dans les scénarios suivants :

  • En cas d'échec d'une opération, une demande de travail peut vous aider à déterminer l'étape du processus qui comportait une erreur. Les demandes de travail capturent les échecs de validation asynchrone.
  • Certaines opérations ont une incidence sur plusieurs ressources. Par exemple, la création d'un pool d'instances a également un impact sur les instances et les configurations d'instance. Une demande de travail fournit la liste des ressources impactées par une opération.
  • Pour les workflows qui nécessitent des opérations séquentielles, vous pouvez surveiller la demande de travail de chaque opération et vérifier que l'opération est terminée avant de passer à la suivante. Par exemple, supposons que vous voulez créer un pool d'instances avec le redimensionnement automatique activé. Pour ce faire, vous devez d'abord créer le pool d'instances, puis configurer le redimensionnement automatique. Vous pouvez surveiller la demande de travail de création du pool d'instances afin de déterminer le moment où ce workflow est terminé, puis configurer le redimensionnement automatique une fois le workflow du pool d'instances terminé.

Les demandes de travail sont conservées pendant 12 heures.

Stratégie IAM requise

Pour utiliser Oracle Cloud Infrastructure, un administrateur doit être membre d'un groupe auquel un administrateur de location a accordé un accès de sécurité dans une stratégie . Cet accès est requis, que vous utilisiez la console ou l'API REST avec un kit SDK, une interface de ligne de commande ou un autre outil. Si un message vous informe que vous n'avez pas d'autorisation ou que vous n'êtes pas autorisé, vérifiez auprès de l'utilisateur le type d'accès qui vous est accordé et le compartiment dans lequel vous travaillez.

Pour les administrateurs : les droits d'accès qui permettent aux utilisateurs de visualiser les demandes de travail, les journaux et les messages d'erreur d'une opération varient en fonction du service. Pour certains services, les demandes de travail héritent des droits d'accès de l'opération qui génère dynamiquement ces demandes de travail. Pour les autres services, les demandes de travail nécessitent des droits d'accès distincts. Pour plus d'informations, reportez-vous à Présentation des stratégies IAM.

Statut de la demande de travail

Les demandes de travail fournissent une visibilité sur la progression des opérations asynchrones à longue durée d'exécution. Le statut d'une demande de travail indique la progression de l'opération.

Les statuts incluent généralement des valeurs telles que IN_PROGRESS, FAILED ou SUCCEEDED. Etant donné que chaque service ou opération qui prend en charge les demandes de travail fournit sa propre API pour obtenir le statut, les valeurs spécifiques renvoyées dans une demande de travail peuvent varier en fonction du service et de l'opération. Afin d'obtenir des informations sur les attributs de statut pris en charge par les demandes de travail pour chaque service, reportez-vous à Statut de la demande de travail.

Résolution des erreurs de validation

Les demandes de travail capturent les échecs de validation asynchrone. En cas d'échec d'une opération asynchrone, une demande de travail peut vous aider à déterminer où l'erreur est survenue dans le processus.

Les erreurs synchrones surviennent lors de l'appel initial à l'API de service et sont renvoyées par celle-ci. Des erreurs asynchrones surviennent au cours du workflow qui survient après l'appel d'API initial et sont renvoyées par la demande de travail. Un appel à l'API de service réussi qui renvoie une réponse HTTP 200 ("demande réussie") peut être suivi d'une erreur asynchrone capturée par la demande de travail.

Par exemple, lorsque vous créez une instance de calcul, un appel d'API est effectué vers l'opération LaunchInstance. A ce stade, la validation synchrone survient. En cas d'échec, une réponse HTTP 4xx est renvoyée. Si l'appel aboutit, une réponse HTTP 200 est renvoyée et le workflow de création d'instance démarre.

Pendant que le workflow de création d'instance continue, des vérifications supplémentaires de validation et d'erreur sont effectuées, et une demande de travail asynchrone est créée pour suivre la progression du workflow. La réponse à l'opération LaunchInstance contient l'OCID de la demande de travail dans l'en-tête opc-work-request-id. Vous pouvez surveiller le statut de la demande de travail à tout moment en appelant l'opération GetWorkRequest et en transmettant l'ID de la demande de travail. Si une erreur survient au cours du workflow, vous pouvez extraire la liste des erreurs en appelant ListWorkRequestErrors et en transmettant l'ID de la demande de travail.

La demande de travail reste dans une file d'attente jusqu'à ce que l'opération soit terminée.

Pour obtenir des informations détaillées sur les demandes de travail, notamment sur la manière de filtrer la réponse à la demande, ainsi que pour consulter un exemple de demande et de réponse, reportez-vous à Demandes de travail asynchrones.

Exemple de workflow de validation de demande de travail

Le diagramme suivant présente un exemple de workflow de création d'instance dans lequel la validation synchrone réussit et la validation asynchrone échoue.

  1. Vous appelez l'adresse LaunchInstance dans l'API Compute.
  2. Une validation synchrone survient et vous recevez une réponse HTTP 2xx de l'API Compute. La réponse inclut l'OCID de la demande de travail dans l'en-tête opc-work-request-id.
  3. Le workflow de création d'instance démarre et la validation asynchrone est effectuée tout au long du workflow. Une erreur survient et la validation échoue.
  4. L'API Compute renseigne les erreurs d'une demande de travail et marque la demande de travail comme ayant échoué.
  5. Pour surveiller la demande de travail, vous appelez GetWorkRequest dans l'API des demandes de travail et transmettez l'ID de la demande de travail se trouvant dans l'en-tête opc-work-request-id.
  6. Voyant que la demande de travail a échoué, vous appelez ListWorkRequestErrors dans l'API des demandes de travail et transmettez l'ID de la demande de travail afin d'extraire la liste des erreurs.
  7. L'API des demandes de travail renvoie la liste des erreurs, que vous pouvez utiliser pour déterminer la cause de l'échec.
Schéma général du workflow de création d'instance présentant les validations synchrone et asynchrone.

Utilisation de la console pour visualiser les demandes de travail

Vous pouvez utiliser la console pour consulter les messages de journal, les messages d'erreur et les ressources associés à une demande de travail spécifique. Les étapes permettant d'afficher une demande de travail peuvent varier en fonction du service et de la ressource dont vous voulez voir les demandes de travail.

  1. Accédez à la ressource dont vous souhaitez visualiser les demandes de travail.

    Par exemple, pour afficher les demandes de travail d'une instance de calcul, ouvrez le menu de navigation et sélectionnez Compute. Sous Compute, sélectionnez Instances.

  2. Si la ressource est affichée dans une vue de liste, cliquez sur son nom pour afficher ses détails.
  3. Sous Ressources, cliquez sur Demandes de travail. Le statut de toutes les demandes de travail apparaît sur la page.

  4. Pour consulter les messages de journal, les messages d'erreur et les ressources associés à une demande de travail spécifique, cliquez sur le nom de l'opération. Ensuite, sélectionnez une option dans la section Plus d'informations.

    Pour la ressource associée, vous pouvez cliquer sur le menu Actions (trois points) en regard d'une ressource afin de copier son OCID.

Informations supplémentaires et API pour les services pris en charge

Pour plus d'autres informations sur l'utilisation de l'API et sur la signature des demandes, reportez-vous à ladocumentation relative aux API REST et aux informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

Utilisez les opérations d'API suivantes pour surveiller l'état des demandes de travail :