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 ändern `PutItem``UpdateItem`, können Sie optional einen Bedingungsausdruck angeben, der steuert, ob die Anforderung erfolgreich sein soll oder nicht, basierend auf dem Status des Objekts, das sich bereits in DynamoDB befindet, bevor der Vorgang ausgeführt wird. Der AWS AppSync DynamoDB-Resolver ermöglicht die Angabe eines Bedingungsausdrucks in und die `DeleteItem` Anforderung von Zuordnungsdokumenten sowie eine Strategie `PutItem``UpdateItem`, die befolgt werden muss, wenn die Bedingung fehlschlägt und das Objekt nicht aktualisiert wurde. ## Beispiel 1 Das folgende `PutItem`-Zuweisungsdokument enthält keinen Bedingungsausdruck. Daher fügt er ein Element in DynamoDB ein, auch wenn bereits ein Element mit demselben Schlüssel existiert, 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 es ermöglicht, dass der Vorgang nur dann erfolgreich ist, wenn ein Element mit demselben Schlüssel in DynamoDB * nicht * vorhanden ist. ``` { "version" : "2017-02-28", "operation" : "PutItem", "key" : { "id" : { "S" : "1" } }, "condition" : { "expression" : "attribute_not_exists(id)" } } ``` Wenn die Bedingungsprü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, um Entwicklern bei der Bewältigung einiger häufiger Randfälle zu helfen: + 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 war. + Anstatt einen Fehler zurückzugeben, können Sie den Resolver so konfigurieren, dass er eine benutzerdefinierte Lambda-Funktion aufruft, um zu entscheiden, wie der DynamoDB-Resolver den Fehler behandeln soll. AWS AppSync 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 DynamoDB-Dokumentation. [ ConditionExpressions ](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 ein Fehler bei der Zustandsprüfung zu behandeln ist: ** `equalsIgnore` ** Wenn eine Zustandsprüfung bei Verwendung des `PutItem` Vorgangs fehlschlägt, vergleicht der AWS AppSync DynamoDB-Resolver das aktuell in DynamoDB befindliche Element 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 Eventual Consistent Read 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 den Fehler bei der Zustandsprüfung behandeln 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, um Entwicklern bei der Bewältigung einiger häufiger Randfälle zu helfen: + 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 war. + Anstatt einen Fehler zurückzugeben, können Sie den Resolver so konfigurieren, dass er eine benutzerdefinierte Lambda-Funktion aufruft, um zu entscheiden, wie der DynamoDB-Resolver den Fehler behandeln soll. AWS AppSync Das Flussdiagramm für diesen Prozess ist: ![Flussdiagramm, das den Prozess eines Mutationsversuchs mit Entscheidungspunkten für Erfolg, Strategie und Aktion zeigt.](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/DynamoDB-condition-check-failure-handling.png) ### Auf der Suche nach dem gewünschten Ergebnis 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 dabei alle Attribute aus dem Vergleich aus. `equalsIgnore` Wenn die Elemente identisch sind, behandelt er den Vorgang als erfolgreich und gibt das Element zurück, 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 zu schreiben versucht hat, mit dem aktuellen Wert vergleichen und feststellen, dass der einzige Unterschied das `version` Feld war. 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 aktuell in DynamoDB befindliche Element dem erwarteten Ergebnis entspricht und daher der konfigurierten Strategie folgt. 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. ### Folgt der Strategie „Ablehnen“ Wenn Sie der `Reject` Strategie folgen, 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. ### Wir folgen der „benutzerdefinierten“ Strategie Wenn Sie der `Custom` Strategie folgen, 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, sich so zu verhalten, als ob es die konfigurierte Strategie wäre`Reject`, und gibt einen Fehler für die Mutation und den aktuellen Wert des Objekts in DynamoDB zurück, 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 in der angegebene Lambda-Funktion auf. `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 zum 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 überprüfen und jede Geschäftslogik anwenden, um zu entscheiden, wie der AWS AppSync DynamoDB-Resolver den Fehler behandeln 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, sich so zu verhalten, als ob es die konfigurierte Strategie wäre`Reject`, und gibt einen Fehler für die Mutation und den aktuellen Wert des Objekts in DynamoDB zurück, 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 der Wert wird in DynamoDB zurückgegeben. + 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 von der DynamoDB-Operation 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 er von gestellt wurde`jeffTheAdmin`, wiederholt er die Anfrage und aktualisiert dabei 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) }; ```