Update

GraphQL allows to query and mutate data. Mutations are operations like create, update and delete. This chapter describes how data can be updated.

Simple update mutation

The area runtime allows access to entities of the Runtime Model. To update an entity, you need to provide the rtId of the entity and the fields you want to update.

mutation {
  runtime {
    industryEnergyEnergyMeters {
      update(
        entities: [
          {
            rtId: "662532d5241639b42933057e"
            item: {
              voltage: 235
              state: ON
              name: "Updated Energy Meter"
            }
          }
        ]
      ) {
        rtId
        voltage
        state
        name
      }
    }
  }
}

This mutation will update the energy meter with the given rtId. Only the fields provided in the mutation will be updated. The result will be:

{
  "data": {
    "runtime": {
      "industryEnergyEnergyMeters": {
        "update": [
          {
            "rtId": "662532d5241639b42933057e",
            "voltage": 235,
            "state": "ON",
            "name": "Updated Energy Meter"
          }
        ]
      }
    }
  }
}

Update with variables

For more complex updates, it is recommended to use GraphQL variables. The input type for updates follows the naming convention [TypeName]InputUpdate.

mutation updateMeshAdapter($entities: [SystemCommunicationMeshAdapterInputUpdate]!) {
  runtime {
    systemCommunicationMeshAdapters {
      update(entities: $entities) {
        rtId
        ckTypeId
        name
        description
        configuration
        imageName
        imageVersion
        deploymentState
      }
    }
  }
}

Variables:

{
  "entities": [
    {
      "rtId": "65d5c447b420da3fb12381bc",
      "item": {
        "name": "Updated Adapter Name",
        "configuration": "{\"host\": \"localhost\", \"port\": 8080}"
      }
    }
  ]
}

Batch updates

Multiple entities can be updated in a single mutation by providing an array of entities:

mutation {
  runtime {
    industryEnergyEnergyMeters {
      update(
        entities: [
          {
            rtId: "662532d5241639b42933057e"
            item: {
              state: ON
            }
          },
          {
            rtId: "65dc6d24cc529cdc46c84fcc"
            item: {
              state: OFF
            }
          }
        ]
      ) {
        rtId
        state
      }
    }
  }
}

Update with nested objects

For entities with nested objects like records, the entire nested object must be provided:

mutation updateCustomer($customer: EnergyCommunityCustomerInputUpdate!) {
  runtime {
    energyCommunityCustomers {
      update(entities: [$customer]) {
        rtId
        contact {
          firstName
          lastName
          email
          address {
            street
            zipcode
            cityTown
          }
        }
        bankAccount {
          iban
          accountHolder
        }
      }
    }
  }
}

Variables:

{
  "customer": {
    "rtId": "667acc3be06025c7329fc57c",
    "contact": {
      "firstName": "John",
      "lastName": "Doe",
      "email": "john.doe@example.com",
      "address": {
        "street": "Main Street 1",
        "zipcode": "12345",
        "cityTown": "Berlin"
      }
    },
    "bankAccount": {
      "iban": "DE89370400440532013000",
      "accountHolder": "John Doe"
    }
  }
}

Input type naming convention

Operation	Input Type Pattern	Example
Create	[TypeName]Input	SystemCommunicationMeshAdapterInput
Update	[TypeName]InputUpdate	SystemCommunicationMeshAdapterInputUpdate

The key difference is that update input types always require the rtId field to identify the entity to update.