

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
<a name="js-aws-appsync-resolver-reference-dynamodb-condition-expressions"></a>

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.

Die AWS AppSync DynamoDB-Funktion ermöglicht die Angabe eines Bedingungsausdrucks in `PutItem``UpdateItem`, und `DeleteItem` Request-Objekten sowie eine Strategie, die befolgt werden kann, wenn die Bedingung fehlschlägt und das Objekt nicht aktualisiert wurde.

## Beispiel 1
<a name="js-id19"></a>

Das folgende `PutItem` Anforderungsobjekt hat 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.

```
import { util } from '@aws-appsync/utils';
export function request(ctx) {
  const { foo, bar, ...values} = ctx.args
  return {
    operation: 'PutItem',
    key: util.dynamodb.toMapValues({foo, bar}),
    attributeValues: util.dynamodb.toMapValues(values),
  };
}
```

## Beispiel 2
<a name="js-id20"></a>

Das folgende `PutItem` Objekt hat einen Bedingungsausdruck, der nur dann ermöglicht, dass der Vorgang erfolgreich ist, wenn ein Element mit demselben Schlüssel *nicht* in DynamoDB vorhanden ist.

```
import { util } from '@aws-appsync/utils';
export function request(ctx) {
  const { foo, bar, ...values} = ctx.args
  return {
    operation: 'PutItem',
    key: util.dynamodb.toMapValues({foo, bar}),
    attributeValues: util.dynamodb.toMapValues(values),
    condition: { expression: "attribute_not_exists(id)" }
  };
}
```

Wenn die Zustandsprüfung fehlschlägt, gibt die AWS AppSync DynamoDB-Funktion standardmäßig einen Fehler für die Mutation aus.

Die AWS AppSync DynamoDB-Funktion bietet jedoch einige zusätzliche Funktionen, die Entwicklern helfen, einige häufig auftretende Randfälle zu bewältigen:
+ Wenn AWS AppSync DynamoDB-Funktionen feststellen können, dass der aktuelle Wert in DynamoDB dem gewünschten Ergebnis entspricht, wird der Vorgang so behandelt, als ob er trotzdem erfolgreich gewesen wäre.
+ Anstatt einen Fehler zurückzugeben, können Sie die Funktion so konfigurieren, dass sie eine benutzerdefinierte Lambda-Funktion aufruft, um zu entscheiden, wie die AWS AppSync DynamoDB-Funktion den Fehler behandeln soll.

Diese werden im Abschnitt [Behandlung eines Fehlers bei der Zustandsprüfung](#condition-check) ausführlicher 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
<a name="js-aws-appsync-resolver-reference-dynamodb-condition-specification"></a>

Die Objekte `PutItem``UpdateItem`, und `DeleteItem` request ermöglichen alle die Angabe 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:

```
type ConditionCheckExpression = {
  expression: string;
  expressionNames?: { [key: string]: string};
  expressionValues?: { [key: string]: any};
  equalsIgnore?: string[];
  consistentRead?: boolean;
  conditionalCheckFailedHandler?: {
    strategy: 'Custom' | 'Reject';
    lambdaArn?: string;
  };
};
```

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 zur Angabe eines „typisierten Werts“ finden Sie unter [Typsystem (](https://docs.aws.amazon.com/appsync/latest/devguide/js-resolver-reference-dynamodb.html#js-aws-appsync-resolver-reference-dynamodb-typed-values-request)Anforderungszuordnung). 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 der AWS AppSync DynamoDB-Funktion mit, wie sie mit einem Fehler bei der Zustandsprüfung umgehen soll:

** `equalsIgnore` **  
Wenn eine Zustandsprüfung bei der Verwendung des `PutItem` Vorgangs fehlschlägt, vergleicht die AWS AppSync DynamoDB-Funktion das Element, das sich derzeit in DynamoDB befindet, mit dem Element, das sie 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 die AWS AppSync DynamoDB-Funktion 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 die AWS AppSync DynamoDB-Funktion einen Fehler bei der Zustandsprüfung behandelt, nachdem der aktuelle Wert in DynamoDB mit dem erwarteten Ergebnis verglichen wurde. Dieser Abschnitt ist optional. Wenn nicht angegeben, wird standardmäßig eine Strategie von `Reject` verwendet.    
** `strategy` **  
Die Strategie, die die AWS AppSync DynamoDB-Funktion verfolgt, nachdem sie 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` **  
Die AWS AppSync DynamoDB-Funktion 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, der bestimmt, wie die AWS AppSync DynamoDB-Funktion 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 [Behandlung eines](#condition-check) Fehlers bei der Zustandsprüfung.

## Behandlung eines Fehlers bei der Zustandsprüfung
<a name="js-aws-appsync-resolver-reference-dynamodb-condition-handling"></a>

Wenn eine Zustandsprüfung fehlschlägt, kann die AWS AppSync DynamoDB-Funktion den Fehler für die Mutation und den aktuellen Wert des Objekts mithilfe des `util.appendError` Dienstprogramms weitergeben. Die AWS AppSync DynamoDB-Funktion bietet jedoch einige zusätzliche Funktionen, die Entwicklern helfen, einige häufig auftretende Randfälle zu bewältigen:
+ Wenn AWS AppSync DynamoDB-Funktionen feststellen können, dass der aktuelle Wert in DynamoDB dem gewünschten Ergebnis entspricht, wird der Vorgang so behandelt, als ob er trotzdem erfolgreich gewesen wäre.
+ Anstatt einen Fehler zurückzugeben, können Sie die Funktion so konfigurieren, dass sie eine benutzerdefinierte Lambda-Funktion aufruft, um zu entscheiden, wie die AWS AppSync DynamoDB-Funktion 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
<a name="js-checking-for-the-desired-result"></a>

Wenn die Zustandsprüfung fehlschlägt, führt die AWS AppSync DynamoDB-Funktion 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 die AWS AppSync DynamoDB-Funktion den aktuellen Wert mit dem Wert, den sie 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.

  Wenn das `PutItem` Anforderungsobjekt beispielsweise wie folgt aussah:

  ```
  import { util } from '@aws-appsync/utils';
  export function request(ctx) {
    const { id, name, version} = ctx.args
    return {
      operation: 'PutItem',
      key: util.dynamodb.toMapValues({foo, bar}),
      attributeValues: util.dynamodb.toMapValues({ name, version: version+1 }),
      condition: { 
        expression: "version = :expectedVersion",
        expressionValues: util.dynamodb.toMapValues({':expectedVersion': version}),
        equalsIgnore: ['version']
      }
    };
  }
  ```

  Und das Element, das sich derzeit in DynamoDB befindet, wie folgt ausgesehen hat:

  ```
  {
     "id" : { "S" : "1" },
     "name" : { "S" : "Steve" },
     "version" : { "N" : 8 }
  }
  ```

  Die AWS AppSync DynamoDB-Funktion würde das Element, das sie schreiben wollte, mit dem aktuellen Wert vergleichen und feststellen, dass der einzige Unterschied das `version` Feld war. Da sie jedoch so konfiguriert ist, dass sie das `version` Feld ignoriert, behandelt sie den Vorgang als erfolgreich und gibt das Element zurück, das von DynamoDB abgerufen wurde.
+ Für den `DeleteItem` Vorgang überprüft die AWS AppSync DynamoDB-Funktion, 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 die AWS AppSync DynamoDB-Funktion nicht über genügend Informationen, um festzustellen, ob das Element, das sich derzeit in DynamoDB befindet, dem erwarteten Ergebnis entspricht und daher der konfigurierten Strategie folgt.

Wenn der aktuelle Status des Objekts in DynamoDB vom erwarteten Ergebnis abweicht, folgt die AWS AppSync DynamoDB-Funktion 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“
<a name="js-following-the-reject-strategy"></a>

Wenn die `Reject` Strategie befolgt wird, gibt die AWS AppSync DynamoDB-Funktion 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 der Response-Handler der Funktion sieht wie folgt aus:

```
import { util } from '@aws-appsync/utils';
export function response(ctx) {
  const { version, ...values } = ctx.result;
  const result = { ...values, theVersion: version };
  if (ctx.error) {
    if (error) {
      return util.appendError(error.message, error.type, result, null);
    }
  }
  return result
}
```

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
<a name="js-following-the-custom-strategy"></a>

Wenn Sie der `Custom` Strategie folgen, ruft die AWS AppSync DynamoDB-Funktion 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 die AWS AppSync DynamoDB-Funktion 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 die AWS AppSync DynamoDB-Funktion angewiesen, den Fehler bei der Zustandsprüfung stillschweigend zu ignorieren und den Wert in DynamoDB zurückzugeben.
+  Die Mutation `retry`. Dadurch wird die AWS AppSync DynamoDB-Funktion angewiesen, die Mutation mit einem neuen Anforderungsobjekt erneut zu versuchen.

 **Die Lambda-Aufrufanforderung**

Die AWS AppSync DynamoDB-Funktion 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. Dies entspricht den Argumenten, die für das Anforderungsobjekt in verfügbar sind. `context.arguments`

** `requestMapping` **  
Das Anforderungsobjekt für diesen Vorgang.

** `currentValue` **  
Der aktuelle Wert des Objekts in DynamoDB.

** `resolver` **  
Informationen über den AWS AppSync Resolver oder die Funktion.

** `identity` **  
Informationen über den Aufrufer. Dies entspricht den Identitätsinformationen, die dem Anforderungsobjekt 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 die AWS AppSync DynamoDB-Funktion 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 die AWS AppSync DynamoDB-Funktion 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 die AWS AppSync DynamoDB-Funktion 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 die AWS AppSync DynamoDB-Funktion angewiesen, die Mutation mit einem neuen Anforderungsobjekt erneut zu versuchen. Die Struktur des `retryMapping` Abschnitts hängt von der DynamoDB-Operation ab und ist eine Teilmenge des vollständigen Anforderungsobjekts für diesen Vorgang.

  Für `PutItem` weist der `retryMapping`-Abschnitt die folgende Struktur auf. Eine Beschreibung des `attributeValues` Felds finden Sie unter. [PutItem](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-putitem)

  ```
  {
      "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](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem).

  ```
  {
      "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. Die AWS AppSync DynamoDB-Funktion 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 die AWS AppSync DynamoDB-Funktion 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)
};
```