Permisos Origen de datos Lotes en una única tabla Lotes en varias tablas Gestión de errores

Uso de operaciones por lotes de DynamoDB en AWS AppSync

nota

Ahora admitimos de forma básica el tiempo de ejecución APPSYNC_JS y su documentación. Considere la opción de utilizar el tiempo de ejecución APPSYNC_JS y sus guías aquí.

AWS AppSync admite el uso de operaciones por lotes de Amazon DynamoDB en una o más tablas de una sola región. Las operaciones admitidas son BatchGetItem, BatchPutItem y BatchDeleteItem. Estas características de AWS AppSync le permiten realizar tareas como las siguientes:

Transferir una lista de claves en una sola consulta y obtener los resultados desde una tabla
Leer registros de una o varias tablas en una única consulta
Escribir registros de forma masiva en una o varias tablas
Escribir o eliminar condicionalmente registros en varias tablas que pueden tener una relación

El uso de operaciones por lotes con DynamoDB en AWS AppSync es una técnica avanzada que exige reflexión y conocimientos adicionales de las operaciones de backend y las estructuras de las tablas. Además, las operaciones por lotes en AWS AppSync tienen dos diferencias fundamentales con respecto a las operaciones que no se realizan por lotes:

El rol del origen de datos debe tener permisos para todas las tablas a las que el solucionador obtiene acceso.
La especificación de tabla de un solucionador forma parte de la plantilla de mapeo.

Permisos

Al igual que con otros solucionadores, debe crear un origen de datos en AWS AppSync y crear un rol o utilizar uno existente. Dado que las operaciones por lotes requieren diferentes permisos para las tablas de DynamoDB, debe conceder los permisos de rol configurados para las acciones de lectura o escritura:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "dynamodb:BatchGetItem",
                "dynamodb:BatchWriteItem"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:dynamodb:region:account:table/TABLENAME",
                "arn:aws:dynamodb:region:account:table/TABLENAME/*"
            ]
        }
    ]
}

Nota: Los roles están vinculados a orígenes de datos de AWS AppSync y los solucionadores de los campos se invocan con referencia a un origen de datos. Los orígenes de datos configurados para recuperar información de DynamoDB solo tienen especificada una tabla a fin de que la configuración siga siendo sencilla. Por lo tanto, al realizar una operación por lotes en varias tablas con un único solucionador, que es una tarea más avanzada, debe conceder al rol de ese origen de datos acceso a cualquier tabla con la que el solucionador vaya a interactuar. Esto se hace en el campo Resource (Recurso) de la política de IAM anterior. La configuración de las tablas en las que se realizan llamadas por lotes se lleva a cabo en la plantilla de solucionador, que se describe a continuación.

Origen de datos

En aras de la simplicidad, vamos a utilizar el mismo origen de datos para todos los solucionadores que se utilizan en este tutorial. En la pestaña Orígenes de datos, cree un nuevo origen de datos de DynamoDB y llámelo BatchTutorial. El nombre de la tabla pueden ser uno cualquiera, ya que los nombre de las tablas se especifican como parte de la plantilla de mapeo de solicitud para las operaciones por lotes. Llamaremos a la tabla empty.

En este tutorial funcionará cualquier rol con la siguiente política insertada:


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "dynamodb:BatchGetItem",
                "dynamodb:BatchWriteItem"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:dynamodb:region:account:table/Posts",
                "arn:aws:dynamodb:region:account:table/Posts/*",
                "arn:aws:dynamodb:region:account:table/locationReadings",
                "arn:aws:dynamodb:region:account:table/locationReadings/*",
                "arn:aws:dynamodb:region:account:table/temperatureReadings",
                "arn:aws:dynamodb:region:account:table/temperatureReadings/*"
            ]
        }
    ]
}

Lotes en una única tabla

aviso

BatchPutItem y BatchDeleteItem no se admiten cuando se utilizan con la detección y resolución de conflictos. Esta configuración debe estar deshabilitada para evitar posibles errores.

En este ejemplo, supongamos que tiene una sola tabla denominada Posts en la que desea añadir y eliminar elementos mediante operaciones por lotes. Utilice el siguiente esquema teniendo en cuenta que, para la consulta, vamos a pasar una lista de ID:


type Post {
    id: ID!
    title: String
}

input PostInput {
    id: ID!
    title: String
}

type Query {
    batchGet(ids: [ID]): [Post]
}

type Mutation {
    batchAdd(posts: [PostInput]): [Post]
    batchDelete(ids: [ID]): [Post]
}

schema {
    query: Query
    mutation: Mutation
}

Asocie un solucionador al campo batchAdd() con la siguiente plantilla de mapeo de solicitud. Esto toma automáticamente cada elemento con el tipo de GraphQL input PostInput y crea un mapa, lo que es necesario para la operación BatchPutItem:


#set($postsdata = [])
#foreach($item in ${ctx.args.posts})
    $util.qr($postsdata.add($util.dynamodb.toMapValues($item)))
#end

{
    "version" : "2018-05-29",
    "operation" : "BatchPutItem",
    "tables" : {
        "Posts": $utils.toJson($postsdata)
    }
}

En este caso, la plantilla de mapeo de respuesta simplemente traslada la información, pero el nombre de la tabla se anexa como ..data.Posts al objeto contexto de este modo:


$util.toJson($ctx.result.data.Posts)

Ahora vaya a la página Consultas de la consola de AWS AppSync y ejecute la siguiente mutación batchAdd:


mutation add {
    batchAdd(posts:[{
            id: 1 title: "Running in the Park"},{
            id: 2 title: "Playing fetch"
        }]){
            id
            title
    }
}

Los resultados deben aparecer en la pantalla y puede validarlos de manera independiente en la consola de DynamoDB que ambos valores han escrito en la tabla Posts.

A continuación, asocie un solucionador al campo batchGet() con la siguiente plantilla de mapeo de solicitud. Esto toma automáticamente cada elemento del tipo de GraphQL ids:[] y crea un mapa que es necesario para la operación BatchGetItem:


#set($ids = [])
#foreach($id in ${ctx.args.ids})
    #set($map = {})
    $util.qr($map.put("id", $util.dynamodb.toString($id)))
    $util.qr($ids.add($map))
#end

{
    "version" : "2018-05-29",
    "operation" : "BatchGetItem",
    "tables" : {
        "Posts": {
            "keys": $util.toJson($ids),
            "consistentRead": true,
            "projection" : {
                "expression" : "#id, title",
                "expressionNames" : { "#id" : "id"}
                }
        }
    }
}

De nuevo, la plantilla de mapeo de respuesta se limita a transferir la información, pero añadiendo otra vez el nombre de la tabla como ..data.Posts al objeto contexto:


$util.toJson($ctx.result.data.Posts)

Ahora, vuelva a la página Consultas de la consola de AWS AppSync y ejecute la siguiente consulta batchGet:


query get {
    batchGet(ids:[1,2,3]){
        id
        title
    }
}

Esto debe devolver los resultados para los dos valores id que ha añadido anteriormente. Observe que se devuelve un valor null para el id con valor 3. Esto se debe a que aún no hay ningún registro en la tabla Posts con ese valor. Observe también que AWS AppSync devuelve los resultados en el mismo orden en que se pasaron las claves a la consulta, lo que es una característica automática adicional de AWS AppSync. Por lo tanto, si cambia a batchGet(ids:[1,3,2), verá que el orden cambia. También sabrá por qué id devuelve un valor null.

Por último, asocie un solucionador al campo batchDelete() con la siguiente plantilla de mapeo de solicitud. Esto toma automáticamente cada elemento del tipo de GraphQL ids:[] y crea un mapa que es necesario para la operación BatchGetItem:


#set($ids = [])
#foreach($id in ${ctx.args.ids})
    #set($map = {})
    $util.qr($map.put("id", $util.dynamodb.toString($id)))
    $util.qr($ids.add($map))
#end

{
    "version" : "2018-05-29",
    "operation" : "BatchDeleteItem",
    "tables" : {
        "Posts": $util.toJson($ids)
    }
}

De nuevo, la plantilla de mapeo de respuesta se limita a transferir la información, pero añadiendo otra vez el nombre de la tabla como ..data.Posts al objeto contexto:


$util.toJson($ctx.result.data.Posts)

Ahora vuelva a la página Consultas de la consola de AWS AppSync y ejecute la siguiente mutación batchDelete:


mutation delete {
    batchDelete(ids:[1,2]){ id }
}

Ahora se eliminarán los registros con id 1 y 2. Si vuelve a ejecutar la consulta batchGet() anterior, devolverá null.

Lotes en varias tablas

aviso

BatchPutItem y BatchDeleteItem no se admiten cuando se utilizan con la detección y resolución de conflictos. Esta configuración debe estar deshabilitada para evitar posibles errores.

AWS AppSync también permite realizar operaciones por lotes en varias tablas. Vamos a crear una aplicación más compleja. Imagine que queremos crear una aplicación de salud de mascotas, con sensores que comunican la ubicación y temperatura corporal de la mascota. Los sensores funcionan con pilas e intentan conectarse a la red cada pocos minutos. Cuando un sensor establece una conexión, envía sus lecturas a nuestra API de AWS AppSync. A continuación, los disparadores analizan los datos para presentar un panel al propietario de la mascota. Concentrémonos en representar las interacciones entre el sensor y el almacén de datos de backend.

Como requisito previo, vamos a crear primero dos tablas de DynamoDB: locationReadings almacenará las lecturas de ubicación de los sensores y temperatureReadings almacenará las lecturas de temperatura de los sensores. Ambas tablas comparten la misma estructura de clave principal: sensorId (String) es la clave de partición y timestamp (String) la clave de ordenación.

Vamos a utilizar el siguiente esquema de GraphQL:


type Mutation {
    # Register a batch of readings
    recordReadings(tempReadings: [TemperatureReadingInput], locReadings: [LocationReadingInput]): RecordResult
    # Delete a batch of readings
    deleteReadings(tempReadings: [TemperatureReadingInput], locReadings: [LocationReadingInput]): RecordResult
}

type Query {
    # Retrieve all possible readings recorded by a sensor at a specific time
    getReadings(sensorId: ID!, timestamp: String!): [SensorReading]
}

type RecordResult {
    temperatureReadings: [TemperatureReading]
    locationReadings: [LocationReading]
}

interface SensorReading {
    sensorId: ID!
    timestamp: String!
}

# Sensor reading representing the sensor temperature (in Fahrenheit)
type TemperatureReading implements SensorReading {
    sensorId: ID!
    timestamp: String!
    value: Float
}

# Sensor reading representing the sensor location (lat,long)
type LocationReading implements SensorReading {
    sensorId: ID!
    timestamp: String!
    lat: Float
    long: Float
}

input TemperatureReadingInput {
    sensorId: ID!
    timestamp: String
    value: Float
}

input LocationReadingInput {
    sensorId: ID!
    timestamp: String
    lat: Float
    long: Float
}

BatchPutItem: registrar lecturas del sensor

Nuestros sensores tiene que poder enviar sus lecturas cuando se conectan a Internet. El campo de GraphQL Mutation.recordReadings es la API que utilizarán para hacerlo. Vamos a asociar un solucionador para activar nuestra API.

Seleccione Attach (Asociar) junto al campo Mutation.recordReadings. En la pantalla siguiente, elija el origen de datos BatchTutorial creado al inicio del tutorial.

Vamos a añadir la siguiente plantilla de mapeo de solicitud:

Plantilla de mapeo de solicitud


## Convert tempReadings arguments to DynamoDB objects
#set($tempReadings = [])
#foreach($reading in ${ctx.args.tempReadings})
    $util.qr($tempReadings.add($util.dynamodb.toMapValues($reading)))
#end

## Convert locReadings arguments to DynamoDB objects
#set($locReadings = [])
#foreach($reading in ${ctx.args.locReadings})
    $util.qr($locReadings.add($util.dynamodb.toMapValues($reading)))
#end

{
    "version" : "2018-05-29",
    "operation" : "BatchPutItem",
    "tables" : {
        "locationReadings": $utils.toJson($locReadings),
        "temperatureReadings": $utils.toJson($tempReadings)
    }
}

Como puede ver, la operación BatchPutItem nos permite especificar varias tablas.

Vamos a usar la siguiente plantilla de mapeo de respuesta.

Plantilla de mapeo de respuesta


## If there was an error with the invocation
## there might have been partial results
#if($ctx.error)
    ## Append a GraphQL error for that field in the GraphQL response
    $utils.appendError($ctx.error.message, $ctx.error.message)
#end
## Also returns data for the field in the GraphQL response
$utils.toJson($ctx.result.data)

Con operaciones por lotes, la invocación puede devolver tanto errores como resultados. Por lo tanto, podemos realizar algún control de errores adicional.

Nota: el uso de $utils.appendError() es similar al de $util.error(), siendo la principal diferencia que no interrumpe la evaluación de la plantilla de mapeo. En su lugar, indica que hubo un error con el campo, pero permite evaluar la plantilla y, por tanto, devolver los datos al intermediario. Recomendamos que utilice $utils.appendError() cuando la aplicación tenga que devolver resultados parciales.

Guarde el solucionador y vaya a la página Consultas de la consola de AWS AppSync. Enviemos ahora algunas lecturas de los sensores.

Ejecute la mutación siguiente:


mutation sendReadings {
  recordReadings(
    tempReadings: [
      {sensorId: 1, value: 85.5, timestamp: "2018-02-01T17:21:05.000+08:00"},
      {sensorId: 1, value: 85.7, timestamp: "2018-02-01T17:21:06.000+08:00"},
      {sensorId: 1, value: 85.8, timestamp: "2018-02-01T17:21:07.000+08:00"},
      {sensorId: 1, value: 84.2, timestamp: "2018-02-01T17:21:08.000+08:00"},
      {sensorId: 1, value: 81.5, timestamp: "2018-02-01T17:21:09.000+08:00"}
    ]
    locReadings: [
      {sensorId: 1, lat: 47.615063, long: -122.333551, timestamp: "2018-02-01T17:21:05.000+08:00"},
      {sensorId: 1, lat: 47.615163, long: -122.333552, timestamp: "2018-02-01T17:21:06.000+08:00"}
      {sensorId: 1, lat: 47.615263, long: -122.333553, timestamp: "2018-02-01T17:21:07.000+08:00"}
      {sensorId: 1, lat: 47.615363, long: -122.333554, timestamp: "2018-02-01T17:21:08.000+08:00"}
      {sensorId: 1, lat: 47.615463, long: -122.333555, timestamp: "2018-02-01T17:21:09.000+08:00"}
    ]) {
    locationReadings {
      sensorId
      timestamp
      lat
      long
    }
    temperatureReadings {
      sensorId
      timestamp
      value
    }
  }
}

Hemos enviado en una mutación 10 lecturas de sensor repartidas en dos tablas. Utilice la consola de DynamoDB para validar que los datos aparecen en las tablas locationReadings y temperatureReadings.

BatchDeleteItem: eliminar lecturas de los sensores

Del mismo modo, también es necesario eliminar lotes de lecturas de sensor. Vamos a utilizar el campo de GraphQL Mutation.deleteReadings para este fin. Seleccione Attach (Asociar) junto al campo Mutation.recordReadings. En la pantalla siguiente, elija el origen de datos BatchTutorial creado al inicio del tutorial.

Vamos a usar la siguiente plantilla de mapeo de solicitud.

Plantilla de mapeo de solicitud


## Convert tempReadings arguments to DynamoDB primary keys
#set($tempReadings = [])
#foreach($reading in ${ctx.args.tempReadings})
    #set($pkey = {})
    $util.qr($pkey.put("sensorId", $reading.sensorId))
    $util.qr($pkey.put("timestamp", $reading.timestamp))
    $util.qr($tempReadings.add($util.dynamodb.toMapValues($pkey)))
#end

## Convert locReadings arguments to DynamoDB primary keys
#set($locReadings = [])
#foreach($reading in ${ctx.args.locReadings})
    #set($pkey = {})
    $util.qr($pkey.put("sensorId", $reading.sensorId))
    $util.qr($pkey.put("timestamp", $reading.timestamp))
    $util.qr($locReadings.add($util.dynamodb.toMapValues($pkey)))
#end

{
    "version" : "2018-05-29",
    "operation" : "BatchDeleteItem",
    "tables" : {
        "locationReadings": $utils.toJson($locReadings),
        "temperatureReadings": $utils.toJson($tempReadings)
    }
}

La plantilla de mapeo de respuesta es la misma que la que hemos usado para Mutation.recordReadings.

Plantilla de mapeo de respuesta


## If there was an error with the invocation
## there might have been partial results
#if($ctx.error)
    ## Append a GraphQL error for that field in the GraphQL response
    $utils.appendError($ctx.error.message, $ctx.error.message)
#end
## Also return data for the field in the GraphQL response
$utils.toJson($ctx.result.data)

Guarde el solucionador y vaya a la página Consultas de la consola de AWS AppSync. Ahora vamos a eliminar un par de lecturas de sensores.

Ejecute la mutación siguiente:


mutation deleteReadings {
  # Let's delete the first two readings we recorded
  deleteReadings(
    tempReadings: [{sensorId: 1, timestamp: "2018-02-01T17:21:05.000+08:00"}]
    locReadings: [{sensorId: 1, timestamp: "2018-02-01T17:21:05.000+08:00"}]) {
    locationReadings {
      sensorId
      timestamp
      lat
      long
    }
    temperatureReadings {
      sensorId
      timestamp
      value
    }
  }
}

Valide a través de la consola de DynamoDB que estas dos lecturas se han eliminado de las tablas locationReadings y temperatureReadings.

BatchGetItem: recuperar lecturas

Otra operación habitual en nuestra aplicación de salud de mascotas es obtener las lecturas de un sensor en un momento determinado. Vamos a asociar un solucionador al campo de GraphQL Query.getReadings en nuestro esquema. Seleccione Attach (Asociar) y, en la siguiente pantalla, elija el origen de datos BatchTutorial creado al inicio del tutorial.

Vamos a añadir la siguiente plantilla de mapeo de solicitud.

Plantilla de mapeo de solicitud


## Build a single DynamoDB primary key,
## as both locationReadings and tempReadings tables
## share the same primary key structure
#set($pkey = {})
$util.qr($pkey.put("sensorId", $ctx.args.sensorId))
$util.qr($pkey.put("timestamp", $ctx.args.timestamp))

{
    "version" : "2018-05-29",
    "operation" : "BatchGetItem",
    "tables" : {
        "locationReadings": {
            "keys": [$util.dynamodb.toMapValuesJson($pkey)],
            "consistentRead": true
        },
        "temperatureReadings": {
            "keys": [$util.dynamodb.toMapValuesJson($pkey)],
            "consistentRead": true
        }
    }
}

Observe que ahora usamos la operación BatchGetItem.

Nuestra plantilla de mapeo de respuesta será un poco diferente, ya que hemos decidido devolver una lista SensorReading. Demos ahora la forma deseada al resultado de la invocación.

Plantilla de mapeo de respuesta


## Merge locationReadings and temperatureReadings
## into a single list
## __typename needed as schema uses an interface
#set($sensorReadings = [])

#foreach($locReading in $ctx.result.data.locationReadings)
    $util.qr($locReading.put("__typename", "LocationReading"))
    $util.qr($sensorReadings.add($locReading))
#end

#foreach($tempReading in $ctx.result.data.temperatureReadings)
    $util.qr($tempReading.put("__typename", "TemperatureReading"))
    $util.qr($sensorReadings.add($tempReading))
#end

$util.toJson($sensorReadings)

Guarde el solucionador y vaya a la página Consultas de la consola de AWS AppSync. Ahora vamos a recuperar lecturas de sensores.

Ejecute la siguiente consulta:


query getReadingsForSensorAndTime {
  # Let's retrieve the very first two readings
  getReadings(sensorId: 1, timestamp: "2018-02-01T17:21:06.000+08:00") {
    sensorId
    timestamp
    ...on TemperatureReading {
      value
    }
    ...on LocationReading {
      lat
      long
    }
  }
}

Hemos demostrado el uso de operaciones por lotes de DynamoDB mediante AWS AppSync.

Gestión de errores

En AWS AppSync, en ocasiones las operaciones de orígenes de datos pueden devolver resultados parciales. "Resultados parciales" es el término que utilizaremos para indicar que el resultado de una operación se compone de algunos datos y un error. Dado que la gestión de errores es inherentemente específica de la aplicación, AWS AppSync le da la oportunidad de gestionar los errores en la plantilla de mapeo de respuestas. El error de invocación del solucionador, si lo hay, está disponible en el contexto como $ctx.error. Los errores de invocación siempre incluyen un mensaje y un tipo a los que se tiene acceso como propiedades $ctx.error.message y $ctx.error.type. Durante la invocación de la plantilla de mapeo de respuestas, puede gestionar los resultados parciales de tres formas:

pasar por alto el error de la invocación y limitarse a devolver los datos
generar un error (con $util.error(...)) y detener la evaluación de la plantilla de mapeo de respuesta, con lo que no se devuelven datos.
agregar un error (con $util.appendError(...)) y devolver los datos

Vamos a demostrar cada una de estas posibilidades con operaciones por lotes de DynamoDB.

Operaciones por lotes de DynamoDB

Con las operaciones por lotes de DynamoDB, es posible que un lote se complete parcialmente. Es decir, es posible que algunos de los elementos o claves solicitados se queden sin procesar. Si AWS AppSync no puede completar un lote, se establecen en el contexto los elementos que no se han procesado y un error de invocación.

Vamos a implementar la gestión de errores utilizando la configuración del campo Query.getReadings de la operación BatchGetItem de la sección anterior de este tutorial. Esta vez, supongamos que mientras se ejecutaba el campo Query.getReadings, la tabla de DynamoDB temperatureReadings agotó el desempeño aprovisionado. DynamoDB ha generado una excepción ProvisionedThroughputExceededException en el segundo intento de AWS AppSync de procesar los elementos restantes del lote.

El siguiente código JSON representa el contexto serializado después de la invocación por lotes de DynamoDB, pero antes de la evaluación de la plantilla de mapeo de respuesta.


{
  "arguments": {
    "sensorId": "1",
    "timestamp": "2018-02-01T17:21:05.000+08:00"
  },
  "source": null,
  "result": {
    "data": {
      "temperatureReadings": [
        null
      ],
      "locationReadings": [
        {
          "lat": 47.615063,
          "long": -122.333551,
          "sensorId": "1",
          "timestamp": "2018-02-01T17:21:05.000+08:00"
        }
      ]
    },
    "unprocessedKeys": {
      "temperatureReadings": [
        {
          "sensorId": "1",
          "timestamp": "2018-02-01T17:21:05.000+08:00"
        }
      ],
      "locationReadings": []
    }
  },
  "error": {
    "type": "DynamoDB:ProvisionedThroughputExceededException",
    "message": "You exceeded your maximum allowed provisioned throughput for a table or for one or more global secondary indexes. (...)"
  },
  "outErrors": []
}

Cabe tener en cuenta algunos aspectos del contexto:

AWS AppSync ha establecido el error de invocación en el contexto en $ctx.error y el tipo de error se ha establecido en Dynamodb:ProvisionedThroughputExceedException.
los resultados se mapean para cada tabla en $ctx.result.data, aunque haya un error
las claves que quedaron sin procesar están disponibles en $ctx.result.data.unprocessedKeys. Aquí, AWS AppSync no pudo recuperar el elemento con la clave (sensorId:1, timestamp:2018-02-01T17:21:05.000+08:00) debido a un rendimiento insuficiente de la tabla.

Nota: para BatchPutItem, es $ctx.result.data.unprocessedItems. Para BatchDeleteItem, es $ctx.result.data.unprocessedKeys.

Vamos a gestionar este error de tres formas diferentes.

1. Pasar por alto el error de invocación

Si se devuelven los datos sin gestionar el error de invocación se pasa por alto el error, lo que hace que el resultado para el campo de GraphQL indicado siempre tenga éxito.

La plantilla de mapeo de respuesta que escribimos ya es conocida y solo se centra en los datos de resultado.

Plantilla de mapeo de respuestas:


$util.toJson($ctx.result.data)

Respuesta de GraphQL:


{
  "data": {
    "getReadings": [
      {
        "sensorId": "1",
        "timestamp": "2018-02-01T17:21:05.000+08:00",
        "lat": 47.615063,
        "long": -122.333551
      },
      {
        "sensorId": "1",
        "timestamp": "2018-02-01T17:21:05.000+08:00",
        "value": 85.5
      }
    ]
  }
}

No se añadirán errores a la respuesta, ya que solo se actúa en los datos.

2. Generar un error para anular la ejecución de la plantilla

Cuando los errores parciales se deban tratar como errores completos desde la perspectiva del cliente, puede anular la ejecución de la plantilla para evitar la devolución de datos. El método de utilidad $util.error(...) consigue exactamente ese comportamiento.

Plantilla de mapeo de respuestas:


## there was an error let's mark the entire field
## as failed and do not return any data back in the response
#if ($ctx.error)
    $util.error($ctx.error.message, $ctx.error.type, null, $ctx.result.data.unprocessedKeys)
#end

$util.toJson($ctx.result.data)

Respuesta de GraphQL:


{
  "data": {
    "getReadings": null
  },
  "errors": [
    {
      "path": [
        "getReadings"
      ],
      "data": null,
      "errorType": "DynamoDB:ProvisionedThroughputExceededException",
      "errorInfo": {
        "temperatureReadings": [
          {
            "sensorId": "1",
            "timestamp": "2018-02-01T17:21:05.000+08:00"
          }
        ],
        "locationReadings": []
      },
      "locations": [
        {
          "line": 58,
          "column": 3
        }
      ],
      "message": "You exceeded your maximum allowed provisioned throughput for a table or for one or more global secondary indexes. (...)"
    }
  ]
}

Aunque podrían haberse devuelto algunos resultados de la operación por lotes de DynamoDB, decidimos generar un error que hace que el campo de GraphQL getReadings sea nulo y se añada el error al bloque de errors de la respuesta de GraphQL.

3. Añadir el error para devolver tanto los datos como los errores

En algunos casos, para proporcionar una mejor experiencia al usuario, las aplicaciones pueden devolver resultados parciales e informar a sus clientes de los elementos que no se han procesado. Los clientes pueden decidir probar de nuevo o trasladar el error al usuario final. El método $util.appendError(...) es la utilidad que permite este comportamiento al permitir que el creador de la aplicación agregue errores al contexto sin interferir con la evaluación de la plantilla. Después de evaluar la plantilla, AWS AppSync procesará cualquier error de contexto agregándolo al bloque de errores de la respuesta de GraphQL.

Plantilla de mapeo de respuestas:


#if ($ctx.error)
    ## pass the unprocessed keys back to the caller via the `errorInfo` field
    $util.appendError($ctx.error.message, $ctx.error.type, null, $ctx.result.data.unprocessedKeys)
#end

$util.toJson($ctx.result.data)

Hemos reenviado el error de invocación y el elemento unprocessedKeys dentro del bloque de errores de la respuesta de GraphQL. El campo getReadings también devuelve datos parciales de la tabla locationReadings, como puede ver en la respuesta a continuación.

Respuesta de GraphQL:


{
  "data": {
    "getReadings": [
      null,
      {
        "sensorId": "1",
        "timestamp": "2018-02-01T17:21:05.000+08:00",
        "value": 85.5
      }
    ]
  },
  "errors": [
    {
      "path": [
        "getReadings"
      ],
      "data": null,
      "errorType": "DynamoDB:ProvisionedThroughputExceededException",
      "errorInfo": {
        "temperatureReadings": [
          {
            "sensorId": "1",
            "timestamp": "2018-02-01T17:21:05.000+08:00"
          }
        ],
        "locationReadings": []
      },
      "locations": [
        {
          "line": 58,
          "column": 3
        }
      ],
      "message": "You exceeded your maximum allowed provisioned throughput for a table or for one or more global secondary indexes. (...)"
    }
  ]
}

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Combinación de solucionadores de GraphQL

Ejecución de transacciones de DynamoDB