Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Blocage optimiste pour les écritures sur les modèles d'actifs
Lors de la mise à jour d'un modèle d'actif, l'utilisateur effectue les opérations suivantes :
1. Lisez la définition actuelle du modèle d'actif.
1. Modifiez la définition du modèle d'actif avec les modifications requises.
1. Mettez à jour le modèle d'actif avec la nouvelle définition.
Dans un scénario où deux utilisateurs mettent à jour un modèle, les opérations suivantes sont possibles :
+ L'utilisateur A lit la définition du modèle d'actif X.
+ L'utilisateur B lit la définition du modèle d'actif X et valide les modifications, en modifiant la définition de X.
+ L'utilisateur A valide et remplace la modification apportée par l'utilisateur B pour le modèle d'actif X, sans vérifier ni intégrer les modifications de l'utilisateur B.
Le verrouillage optimiste est un mécanisme utilisé AWS IoT SiteWise pour empêcher les écrasements accidentels, comme dans le scénario ci-dessus. Le verrouillage optimiste est une stratégie visant à garantir que la version actuelle du modèle d'actif en cours de mise à jour ou de suppression est la même que sa version actuelle dans AWS IoT SiteWise. Cela protège les écritures du modèle d'actif contre le remplacement par des mises à jour accidentelles.
Suivez ces étapes pour effectuer des écritures de modèles d'actifs avec un verrouillage optimiste :
**Topics**
+ [Réaliser des écritures de modèles d'actifs avec Optimistic Lock (console)](#opt-locking-for-model-console)
+ [Réaliser des écritures de modèles d'actifs avec un verrouillage optimiste (AWS CLI)](#opt-locking-for-model-cli)
## Réaliser des écritures de modèles d'actifs avec Optimistic Lock (console)
La procédure ci-dessous décrit comment effectuer des écritures de modèles d'actifs en verrouillant de manière optimiste la version active du modèle d'actif dans la console.
1. Accédez à la [console AWS IoT SiteWise](https://console.aws.amazon.com/iotsitewise/).
1. Dans le panneau de navigation, choisissez **Models (Modèles)**.
1. Choisissez le modèle d'actif ou le modèle de composant à mettre à jour.
1. Choisissez **Modifier**.
1. Apportez des modifications sur la ** page ** Modifier le modèle.
1. Choisissez **Enregistrer**.
**Note**
Parfois, une ou plusieurs mises à jour réussies du modèle ont eu lieu entre le moment où l'utilisateur commence à modifier le modèle et l'enregistrement des modifications apportées au modèle.
Pour éviter que l'utilisateur ne remplace accidentellement les nouvelles mises à jour réussies, l'écriture de l'utilisateur est rejetée. La console désactive le ** bouton ** Enregistrer et invite l'utilisateur à actualiser la page ** Modifier le modèle**. L'utilisateur doit à nouveau mettre à jour la nouvelle version active du modèle. L'utilisateur doit effectuer les étapes supplémentaires suivantes :
1. Choisissez **Refresh**.
1. Suivez à nouveau les étapes 5 et 6.
## Réaliser des écritures de modèles d'actifs avec un verrouillage optimiste (AWS CLI)
La procédure ci-dessous décrit comment effectuer des écritures de modèles d'actifs avec un verrouillage optimiste dans le AWS CLI.
1. **Récupère l'ETag associé à la définition actuelle du modèle **
`ETag`est un jeton unique généré pour chaque nouvelle représentation d'un modèle d'actif. Appelez [ DescribeAssetModel ](https://docs.aws.amazon.com/iot-sitewise/latest/APIReference/API_DescribeAssetModel.html) l'API pour récupérer la définition actuelle du modèle d'actif et l'associer à `ETag` partir de la réponse.
Lors de mises à jour simultanées, les utilisateurs effectuent soit des mises à jour réussies (modèle en `ACTIVE` état), soit des mises à jour infructueuses (modèle en `FAILED` état). Pour éviter qu'un utilisateur ne remplace accidentellement une mise à jour réussie, vous devez récupérer la version active du modèle d'[Versions des modèles d'actifs](model-active-version.md)actif et obtenir la `ETag` valeur.
Exécutez la commande suivante :
```
aws iotsitewise describe-asset-model --asset-model-id asset-model-id \
--asset-model-version ACTIVE
```
La réponse renvoie la structure suivante :
```
{
"assetModelId": "{{String}}",
"assetModelArn": "{{String}}",
"assetModelName": "{{String}}",
...
"eTag": "{{String}}"
}
```
**Note**
Vous devez récupérer la dernière version du modèle d'actif et de celui-ci `ETag` afin de ne pas remplacer les mises à jour.
1. **Effectuez des opérations UPDATE et DELETE avec des conditions d'écriture **
Les API de modèles d'actifs suivantes prennent en charge le verrouillage optimiste :
+ [UpdateAssetModel](https://docs.aws.amazon.com/iot-sitewise/latest/APIReference/API_UpdateAssetModel.html)
+ [DeleteAssetModel](https://docs.aws.amazon.com/iot-sitewise/latest/APIReference/API_DeleteAssetModel.html)
+ [CreateAssetModelCompositeModel](https://docs.aws.amazon.com/iot-sitewise/latest/APIReference/API_CreateAssetModelCompositeModel.html)
+ [UpdateAssetModelCompositeModel](https://docs.aws.amazon.com/iot-sitewise/latest/APIReference/API_UpdateAssetModelCompositeModel.html)
+ [DeleteAssetModelCompositeModel](https://docs.aws.amazon.com/iot-sitewise/latest/APIReference/API_DeleteAssetModelCompositeModel.html)
**Note**
Les scénarios ci-dessous utilisent `UpdateAssetModel` l'API comme référence. Les conditions s'appliquent à toutes les opérations listées ci-dessus.
Les scénarios ci-dessous décrivent les différentes conditions d'écriture en fonction des exigences de contrôle de simultanéité :
+ Exécutez la commande suivante afin de ne pas remplacer les mises à jour réussies. Aucune nouvelle version active ne doit exister depuis la dernière version active lue. Remplacez `e-tag` par le `ETag` résultat renvoyé dans l'opération d'API utilisée lors de la lecture de la version active.
```
aws iotsitewise update-asset-model \
--asset-model-id asset-model-id \
--if-match e-tag \
--match-for-version-type ACTIVE \
--cli-input-json file://model-payload.json
```
+ Lorsque la création d'un modèle échoue, il n'existe pas encore de version active pour celui-ci, car il est dans un `FAILED` état. Il est toujours possible de remplacer une nouvelle version active présente avant que vos modifications ne soient validées. Exécutez la commande suivante pour ne pas remplacer une nouvelle version active, alors qu'aucune version active n'existe lors de votre dernière lecture.
```
aws iotsitewise update-asset-model \
--asset-model-id asset-model-id \
--if-none-match "*" \
--match-for-version-type ACTIVE \
--cli-input-json file://model-payload.json
```
+ Exécutez la commande suivante pour éviter de remplacer les mises à jour réussies ou non. Cette commande définit une condition d'écriture qui garantit qu'aucune version la plus récente n'est créée depuis la dernière version lue. Remplacez `e-tag` par le `ETag` résultat renvoyé dans l'opération d'API utilisée lors de la lecture de la version active.
```
aws iotsitewise update-asset-model \
--asset-model-id asset-model-id \
--if-match eTag \
--match-for-version-type LATEST \
--cli-input-json file://model-payload.json
```
Si la condition d'écriture est évaluée à`FALSE`, la demande d'écriture échoue avec le`PreconditionFailedException`.