Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Bedingungsausdrücke Wenn Sie Objekte in DynamoDB mithilfe der Operationen,, und `DeleteItem` DynamoDB mutieren `PutItem``UpdateItem`, können Sie optional einen Bedingungsausdruck angeben, der steuert, ob die Anforderung erfolgreich sein soll oder nicht, basierend auf dem Zustand des Objekts, das sich bereits in DynamoDB befand, bevor der Vorgang ausgeführt wird. Der AWS AppSync DynamoDB-Resolver ermöglicht die Angabe eines Bedingungsausdrucks in `PutItem``UpdateItem`, und `DeleteItem` fordert Mapping-Dokumente an sowie eine Strategie, die befolgt werden kann, wenn die Bedingung fehlschlägt und das Objekt nicht aktualisiert wurde. ## Beispiel 1 Das folgende `PutItem`-Zuweisungsdokument enthält keinen Bedingungsausdruck. Dadurch wird ein Element in DynamoDB platziert, auch wenn ein Element mit demselben Schlüssel bereits vorhanden ist, wodurch das vorhandene Element überschrieben wird. ``` { "version" : "2017-02-28", "operation" : "PutItem", "key" : { "id" : { "S" : "1" } } } ``` ## Beispiel 2 Das folgende `PutItem` Zuordnungsdokument enthält einen Bedingungsausdruck, der nur dann den Erfolg des Vorgangs ermöglicht, wenn ein Element mit demselben Schlüssel *nicht* in DynamoDB vorhanden ist. ``` { "version" : "2017-02-28", "operation" : "PutItem", "key" : { "id" : { "S" : "1" } }, "condition" : { "expression" : "attribute_not_exists(id)" } } ``` Wenn die Zustandsprüfung fehlschlägt, gibt der AWS AppSync DynamoDB-Resolver standardmäßig einen Fehler für die Mutation zurück. Der AWS AppSync DynamoDB-Resolver bietet jedoch einige zusätzliche Funktionen, mit denen Entwickler einige häufig auftretende Grenzfälle bewältigen können: + Wenn der AWS AppSync DynamoDB-Resolver feststellen kann, dass der aktuelle Wert in DynamoDB dem gewünschten Ergebnis entspricht, behandelt er den Vorgang so, als ob er trotzdem erfolgreich gewesen wäre. + Anstatt einen Fehler zurückzugeben, können Sie den Resolver so konfigurieren, dass er eine benutzerdefinierte Lambda-Funktion aufruft, um zu entscheiden, wie der AWS AppSync DynamoDB-Resolver den Fehler behandeln soll. Diese werden im Abschnitt [Handling a Condition Check Failure](#aws-appsync-resolver-mapping-template-reference-dynamodb-condition-handling) detaillierter beschrieben. Weitere Informationen zu DynamoDB-Bedingungsausdrücken finden Sie in der [ ConditionExpressions DynamoDB-Dokumentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.ConditionExpressions.html). ## Angabe einer Bedingung Die Zuweisungsdokumente der `PutItem`- `UpdateItem`- und `DeleteItem`-Anforderung erlauben das Angeben eines optionalen `condition`-Abschnitts. Wenn nicht angegeben, wird keine Bedingungsprüfung ausgeführt. Wenn angegeben, muss die Bedingung wahr sein, damit die Operation erfolgreich ausgeführt werden kann. Ein `condition`-Abschnitt weist die folgende Struktur auf: ``` "condition" : { "expression" : "someExpression" "expressionNames" : { "#foo" : "foo" }, "expressionValues" : { ":bar" : ... typed value }, "equalsIgnore" : [ "version" ], "consistentRead" : true, "conditionalCheckFailedHandler" : { "strategy" : "Custom", "lambdaArn" : "arn:..." } } ``` Die folgenden Felder geben die Bedingung an: ** `expression` ** Der Aktualisierungsausdruck selbst. Weitere Informationen zum Schreiben von Bedingungsausdrücken finden Sie in der [DynamoDB-Dokumentation ConditionExpressions ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.ConditionExpressions.html). Dieses Feld muss angegeben werden. ** `expressionNames` ** Die Ersetzungen für Platzhalter für Ausdrucksattributnamen in der Form von Schlüssel-Wert-Paaren. Der Schlüssel entspricht einem Namensplatzhalter, der im *Ausdruck* verwendet wird, und der Wert muss eine Zeichenfolge sein, die dem Attributnamen des Elements in DynamoDB entspricht. Dieses Feld ist optional und sollte nur mit Ersetzungen für Platzhalter der Namen von Ausdrucksattributen gefüllt sein, die im *Ausdruck* verwendet werden. ** `expressionValues` ** Die Ersetzungen für Platzhalter der Werte von Ausdrucksattributen in Form von Schlüssel-Wert-Paaren. Der Schlüssel entspricht einem Wertplatzhalter, der im Ausdruck verwendet wird, und der Wert muss ein typisierter Wert sein. Weitere Informationen zum Angeben eines „typisierten Werts“ finden Sie unter [Typsystem (Anforderungszuweisung)](aws-appsync-resolver-mapping-template-reference-dynamodb-typed-values-request.md). Dieser muss angegeben werden. Dieses Feld ist optional und sollte nur mit Ersetzungen für Platzhalter der Werte von Ausdrucksattributen gefüllt sein, die im Ausdruck verwendet werden. Die verbleibenden Felder teilen dem AWS AppSync DynamoDB-Resolver mit, wie er mit einem Fehler bei der Zustandsprüfung umgehen soll: ** `equalsIgnore` ** Wenn eine Zustandsprüfung bei der Verwendung des `PutItem` Vorgangs fehlschlägt, vergleicht der AWS AppSync DynamoDB-Resolver das Element, das sich derzeit in DynamoDB befindet, mit dem Element, das er zu schreiben versucht hat. Wenn sie identisch sind, wird die Operation behandelt, als wäre sie trotzdem erfolgreich ausgeführt worden. Sie können das `equalsIgnore` Feld verwenden, um eine Liste von Attributen anzugeben, die bei diesem Vergleich ignoriert AWS AppSync werden sollen. Wenn der einzige Unterschied beispielsweise ein `version` Attribut war, wird der Vorgang so behandelt, als ob er erfolgreich war. Dies ist ein optionales Feld. ** `consistentRead` ** Wenn eine Zustandsprüfung fehlschlägt, AWS AppSync wird der aktuelle Wert des Elements mithilfe eines stark konsistenten Lesevorgangs von DynamoDB abgerufen. Sie können dieses Feld verwenden, um den AWS AppSync DynamoDB-Resolver anzuweisen, stattdessen einen eventuell konsistenten Lesevorgang zu verwenden. Dieses Feld ist optional und standardmäßig auf `true` gesetzt. ** `conditionalCheckFailedHandler` ** In diesem Abschnitt können Sie angeben, wie der AWS AppSync DynamoDB-Resolver einen Fehler bei der Zustandsprüfung behandelt, nachdem er den aktuellen Wert in DynamoDB mit dem erwarteten Ergebnis verglichen hat. Dieser Abschnitt ist optional. Wenn nicht angegeben, wird standardmäßig eine Strategie von `Reject` verwendet. ** `strategy` ** Die Strategie, die der AWS AppSync DynamoDB-Resolver verfolgt, nachdem er den aktuellen Wert in DynamoDB mit dem erwarteten Ergebnis verglichen hat. Dieses Feld ist erforderlich und besitzt die folgenden möglichen Werte: ** `Reject` ** Die Mutation schlägt fehl und der GraphQL-Antwort wird ein Fehler hinzugefügt. ** `Custom` ** Der AWS AppSync DynamoDB-Resolver ruft eine benutzerdefinierte Lambda-Funktion auf, um zu entscheiden, wie mit dem Fehler bei der Zustandsprüfung umgegangen werden soll. Wenn die `strategy` auf `Custom` gesetzt ist, muss das `lambdaArn`-Feld den ARN der aufzurufenden Lambda-Funktion enthalten. ** `lambdaArn` ** Der ARN der aufzurufenden Lambda-Funktion, die bestimmt, wie der AWS AppSync DynamoDB-Resolver mit dem Fehler bei der Zustandsprüfung umgehen soll. Dieses Feld muss nur angegeben werden, wenn `strategy` auf `Custom` festgelegt ist. Weitere Informationen zur Verwendung dieser Funktion finden Sie unter [Umgang mit einem Bedingungsausdrucksfehler](#aws-appsync-resolver-mapping-template-reference-dynamodb-condition-handling). ## Behandlung eines Fehlers bei der Zustandsprüfung Wenn eine Zustandsprüfung fehlschlägt, gibt der AWS AppSync DynamoDB-Resolver standardmäßig einen Fehler für die Mutation und den aktuellen Wert des Objekts in DynamoDB zurück. Der AWS AppSync DynamoDB-Resolver bietet jedoch einige zusätzliche Funktionen, mit denen Entwickler einige häufig auftretende Grenzfälle bewältigen können: + Wenn der AWS AppSync DynamoDB-Resolver feststellen kann, dass der aktuelle Wert in DynamoDB dem gewünschten Ergebnis entspricht, behandelt er den Vorgang so, als ob er trotzdem erfolgreich gewesen wäre. + Anstatt einen Fehler zurückzugeben, können Sie den Resolver so konfigurieren, dass er eine benutzerdefinierte Lambda-Funktion aufruft, um zu entscheiden, wie der AWS AppSync DynamoDB-Resolver den Fehler behandeln soll. Das Flussdiagramm für diesen Prozess ist: ![\[Flowchart showing process for transforming requests with mutation attempts and value checks.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/DynamoDB-condition-check-failure-handling.png) ### Es wird geprüft, ob das gewünschte Ergebnis vorliegt Wenn die Zustandsprüfung fehlschlägt, führt der AWS AppSync DynamoDB-Resolver eine `GetItem` DynamoDB-Anforderung aus, um den aktuellen Wert des Elements von DynamoDB abzurufen. Standardmäßig wird ein Strongly Consistent-Lesevorgang verwendet, jedoch kann dies mit dem `consistentRead`-Feld im `condition`-Block konfiguriert werden, und mit dem erwarteten Ergebnis verglichen: + Für den `PutItem` Vorgang vergleicht der AWS AppSync DynamoDB-Resolver den aktuellen Wert mit dem Wert, den er zu schreiben versucht hat, und schließt alle unter aufgelisteten Attribute aus dem Vergleich `equalsIgnore` aus. Wenn die Elemente identisch sind, wird der Vorgang als erfolgreich behandelt und das Element zurückgegeben, das von DynamoDB abgerufen wurde. Andernfalls wird die konfigurierte Strategie verfolgt. Beispiel: Wenn das Zuweisungsdokument der `PutItem`-Anforderung wie folgt ausgesehen hat: ``` { "version" : "2017-02-28", "operation" : "PutItem", "key" : { "id" : { "S" : "1" } }, "attributeValues" : { "name" : { "S" : "Steve" }, "version" : { "N" : 2 } }, "condition" : { "expression" : "version = :expectedVersion", "expressionValues" : { ":expectedVersion" : { "N" : 1 } }, "equalsIgnore": [ "version" ] } } ``` Und das Element, das sich derzeit in DynamoDB befindet, wie folgt ausgesehen hat: ``` { "id" : { "S" : "1" }, "name" : { "S" : "Steve" }, "version" : { "N" : 8 } } ``` Der AWS AppSync DynamoDB-Resolver würde das Element, das er schreiben wollte, mit dem aktuellen Wert vergleichen und feststellen, dass der einzige Unterschied das `version` Feld ist. Da er jedoch so konfiguriert ist, dass er das `version` Feld ignoriert, behandelt er den Vorgang als erfolgreich und gibt das Element zurück, das von DynamoDB abgerufen wurde. + Für den `DeleteItem` Vorgang überprüft der AWS AppSync DynamoDB-Resolver, ob ein Element von DynamoDB zurückgegeben wurde. Wenn kein Element zurückgegeben wurde, behandelt er die Operation als erfolgreich. Andernfalls wird die konfigurierte Strategie verfolgt. + Für den `UpdateItem` Vorgang verfügt der AWS AppSync DynamoDB-Resolver nicht über genügend Informationen, um festzustellen, ob das Element, das sich derzeit in DynamoDB befindet, dem erwarteten Ergebnis entspricht, und folgt daher der konfigurierten Strategie. Wenn der aktuelle Status des Objekts in DynamoDB vom erwarteten Ergebnis abweicht, folgt der AWS AppSync DynamoDB-Resolver der konfigurierten Strategie, entweder die Mutation zurückzuweisen oder eine Lambda-Funktion aufzurufen, um zu bestimmen, was als Nächstes zu tun ist. ### Wir folgen der Strategie „Ablehnen“ Wenn die `Reject` Strategie befolgt wird, gibt der AWS AppSync DynamoDB-Resolver einen Fehler für die Mutation zurück. Angenommen, Sie haben folgende Mutationsanforderung: ``` mutation { updatePerson(id: 1, name: "Steve", expectedVersion: 1) { Name theVersion } } ``` Wenn das von DynamoDB zurückgegebene Element wie folgt aussieht: ``` { "id" : { "S" : "1" }, "name" : { "S" : "Steve" }, "version" : { "N" : 8 } } ``` Und die Antwortzuweisungsvorlage wie folgt aussieht: ``` { "id" : $util.toJson($context.result.id), "Name" : $util.toJson($context.result.name), "theVersion" : $util.toJson($context.result.version) } ``` Die GraphQL-Antwort sieht wie folgt aus: ``` { "data": null, "errors": [ { "message": "The conditional request failed (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: ConditionalCheckFailedException; Request ID: ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ)" "errorType": "DynamoDB:ConditionalCheckFailedException", ... } ] } ``` Beachten Sie auch, dass, wenn bei einer erfolgreichen Mutation alle Felder im zurückgegebenen Objekt von anderen Resolvern ausgefüllt werden, diese nicht auf den Resolver angewendet werden, wenn das Objekt im `error`-Abschnitt zurückgegeben wird. ### Folgen Sie der „benutzerdefinierten“ Strategie Wenn die `Custom` Strategie befolgt wird, ruft der AWS AppSync DynamoDB-Resolver eine Lambda-Funktion auf, um zu entscheiden, was als Nächstes zu tun ist. Die Lambda-Funktion wählt eine der folgenden Optionen aus: + Die Mutation `reject`. Dadurch wird der AWS AppSync DynamoDB-Resolver angewiesen`Reject`, sich wie bei der konfigurierten Strategie zu verhalten und einen Fehler für die Mutation und den aktuellen Wert des Objekts in DynamoDB zurückzugeben, wie im vorherigen Abschnitt beschrieben. + Die Mutation `discard`. Dadurch wird der AWS AppSync DynamoDB-Resolver angewiesen, den Fehler bei der Zustandsprüfung stillschweigend zu ignorieren und den Wert in DynamoDB zurückzugeben. + Die Mutation `retry`. Dadurch wird der AWS AppSync DynamoDB-Resolver angewiesen, die Mutation mit einem neuen Anforderungszuordnungsdokument erneut zu versuchen. **Die Lambda-Aufrufanforderung** Der AWS AppSync DynamoDB-Resolver ruft die Lambda-Funktion auf, die in der angegeben ist. `lambdaArn` Er verwendet die gleiche `service-role-arn`-Konfiguration für die Datenquelle. Die Nutzlast des Aufrufs hat die folgende Struktur: ``` { "arguments": { ... }, "requestMapping": {... }, "currentValue": { ... }, "resolver": { ... }, "identity": { ... } } ``` Die Felder sind wie folgt definiert: ** `arguments` ** Die Argumente aus der GraphQL-Mutation. Diese entsprechen den Argumente, die dem Zuweisungsdokument der Anforderung in `$context.arguments` zur Verfügung stehen. ** `requestMapping` ** Das Zuweisungsdokument der Anforderung für diese Operation. ** `currentValue` ** Der aktuelle Wert des Objekts in DynamoDB. ** `resolver` ** Informationen über den Resolver AWS AppSync . ** `identity` ** Informationen über den Aufrufer. Diese entsprechen den Identitätsinformationen, die dem Zuweisungsdokument der Anforderung in `$context.identity` zur Verfügung stehen. Ein vollständiges Beispiel für die Nutzlast: ``` { "arguments": { "id": "1", "name": "Steve", "expectedVersion": 1 }, "requestMapping": { "version" : "2017-02-28", "operation" : "PutItem", "key" : { "id" : { "S" : "1" } }, "attributeValues" : { "name" : { "S" : "Steve" }, "version" : { "N" : 2 } }, "condition" : { "expression" : "version = :expectedVersion", "expressionValues" : { ":expectedVersion" : { "N" : 1 } }, "equalsIgnore": [ "version" ] } }, "currentValue": { "id" : { "S" : "1" }, "name" : { "S" : "Steve" }, "version" : { "N" : 8 } }, "resolver": { "tableName": "People", "awsRegion": "us-west-2", "parentType": "Mutation", "field": "updatePerson", "outputType": "Person" }, "identity": { "accountId": "123456789012", "sourceIp": "x.x.x.x", "user": "AIDAAAAAAAAAAAAAAAAAA", "userArn": "arn:aws:iam::123456789012:user/appsync" } } ``` **Die Lambda-Aufrufantwort** Die Lambda-Funktion kann die Nutzlast des Aufrufs untersuchen und jede Geschäftslogik anwenden, um zu entscheiden, wie der AWS AppSync DynamoDB-Resolver mit dem Fehler umgehen soll. Es gibt drei Optionen für den Umgang mit dem Bedingungsprüfungsfehler: + Die Mutation `reject`. Die Antwortnutzlast für diese Option muss diese Struktur aufweisen: ``` { "action": "reject" } ``` Dadurch wird der AWS AppSync DynamoDB-Resolver angewiesen`Reject`, sich wie bei der konfigurierten Strategie zu verhalten und einen Fehler für die Mutation und den aktuellen Wert des Objekts in DynamoDB zurückzugeben, wie im obigen Abschnitt beschrieben. + Die Mutation `discard`. Die Antwortnutzlast für diese Option muss diese Struktur aufweisen: ``` { "action": "discard" } ``` Dadurch wird der AWS AppSync DynamoDB-Resolver angewiesen, den Fehler bei der Zustandsprüfung stillschweigend zu ignorieren und den Wert in DynamoDB zurückzugeben. + Die Mutation `retry`. Die Antwortnutzlast für diese Option muss diese Struktur aufweisen: ``` { "action": "retry", "retryMapping": { ... } } ``` Dadurch wird der AWS AppSync DynamoDB-Resolver angewiesen, die Mutation mit einem neuen Anforderungszuordnungsdokument erneut zu versuchen. Die Struktur des `retryMapping` Abschnitts hängt vom DynamoDB-Vorgang ab und ist eine Teilmenge des vollständigen Anforderungszuordnungsdokuments für diesen Vorgang. Für `PutItem` weist der `retryMapping`-Abschnitt die folgende Struktur auf. Eine Beschreibung des `attributeValues` Felds finden Sie unter. [PutItem](aws-appsync-resolver-mapping-template-reference-dynamodb-putitem.md) ``` { "attributeValues": { ... }, "condition": { "equalsIgnore" = [ ... ], "consistentRead" = true } } ``` Für `UpdateItem` weist der `retryMapping`-Abschnitt die folgende Struktur auf. Eine Beschreibung des `update` Abschnitts finden Sie unter [UpdateItem](aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem.md). ``` { "update" : { "expression" : "someExpression" "expressionNames" : { "#foo" : "foo" }, "expressionValues" : { ":bar" : ... typed value } }, "condition": { "consistentRead" = true } } ``` Für `DeleteItem` weist der `retryMapping`-Abschnitt die folgende Struktur auf. ``` { "condition": { "consistentRead" = true } } ``` Es ist nicht möglich, eine andere Operation oder einen anderen Schlüssel anzugeben. Der AWS AppSync DynamoDB-Resolver erlaubt nur Wiederholungen derselben Operation für dasselbe Objekt. Beachten Sie auch, dass der Abschnitt `condition` nicht zulässt, dass ein `conditionalCheckFailedHandler` angegeben wird. Schlägt der Wiederholungsversuch fehl, folgt der AWS AppSync DynamoDB-Resolver der Strategie. `Reject` Hier sehen Sie ein Beispiel für eine Lambda-Funktion zum Umgang mit einer fehlgeschlagenen `PutItem`-Anforderung. Die Geschäftslogik prüft, wer den Aufruf ausgeführt hat. Wenn es von erstellt wurde`jeffTheAdmin`, wiederholt es die Anfrage und aktualisiert das `version` und `expectedVersion` aus dem Element, das sich derzeit in DynamoDB befindet. Andernfalls wird die Mutation ablehnt. ``` exports.handler = (event, context, callback) => { console.log("Event: "+ JSON.stringify(event)); // Business logic goes here. var response; if ( event.identity.user == "jeffTheAdmin" ) { response = { "action" : "retry", "retryMapping" : { "attributeValues" : event.requestMapping.attributeValues, "condition" : { "expression" : event.requestMapping.condition.expression, "expressionValues" : event.requestMapping.condition.expressionValues } } } response.retryMapping.attributeValues.version = { "N" : event.currentValue.version.N + 1 } response.retryMapping.condition.expressionValues[':expectedVersion'] = event.currentValue.version } else { response = { "action" : "reject" } } console.log("Response: "+ JSON.stringify(response)) callback(null, response) }; ```