View a markdown version of this page

Implementieren Sie Operationen an der C2C-Steckverbinderschnittstelle - Verwaltete Integrationen für AWS IoT Device Management

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.

Implementieren Sie Operationen an der C2C-Steckverbinderschnittstelle

Managed Integrations for AWS IoT Device Management definiert vier Vorgänge, die Sie ausführen AWS Lambda müssen, um sich als Konnektor zu qualifizieren. Ihr C2C-Konnektor muss jeden der folgenden Vorgänge implementieren:

  1. AWS.ActivateUser- Managed Integrations for AWS IoT Device Management Service ruft diese API auf, um eine weltweit eindeutige Benutzerkennung abzurufen. Für OAuth 2.0 ist dies mit dem bereitgestellten OAuth 2.0-Token verknüpft. Dieser Vorgang kann optional verwendet werden, um zusätzliche Anforderungen für den Kontoverknüpfungsprozess zu erfüllen.

  2. AWS.DiscoverDevices- Managed Integrations for AWS IoT Device Management Service ruft diese API an Ihren Connector auf, um Benutzergeräte zu erkennen

  3. AWS.SendCommand- Managed Integrations for AWS IoT Device Management Service ruft diese API an Ihren Connector auf, um Befehle für Benutzergeräte zu senden

  4. AWS.DeactivateUser- Managed Integrations for AWS IoT Device Management Service ruft diese API an Ihren Connector auf, um das Zugriffstoken des Benutzers zu deaktivieren, um die Verbindung zu Ihrem Autorisierungsserver zu trennen.

Einzelheiten des Aufrufs

Managed Integrations for ruft AWS IoT Device Management während der Aktion immer die Lambda-Funktion mit einer JSON-Zeichenfolgennutzlast auf. AWS Lambda invokeFunction Anforderungsvorgänge müssen in jeder Anforderungsnutzlast ein operationName Feld enthalten.

Einstellungen für den Aufruf:

  • Timeout: 2 Sekunden pro Aufruf

  • Wiederholungen: 5 Wiederholungsversuche bei einem Fehlschlag

Beispiel für eine Implementierung

Das Lambda, das Sie für Ihren Connector implementieren, analysiert eine operationName aus der Payload der Anfrage und implementiert die entsprechende Funktionalität für die Zuordnung zur Drittanbieter-Cloud:

public ConnectorResponse handleRequest(final ConnectorRequest request) throws OperationFailedException { Operation operation; try { operation = Operation.valueOf(request.payload().operationName()); } catch (IllegalArgumentException ex) { throw new ValidationException( "Unknown operation '%s'".formatted(request.payload().operationName()), ex ); } return switch (operation) { case ActivateUser -> activateUserManager.activateUser(request); case DiscoverDevices -> deviceDiscoveryManager.listDevices(request); case SendCommand -> sendCommandManager.sendCommand(request); case DeactivateUser -> deactivateUser.deactivateUser(request); }; }
Anmerkung

Der Entwickler des Connectors muss die im vorherigen activateUserManager.activateUser(request) Beispiel aufgeführten deactivateUser.deactivateUser Operationen deviceDiscoveryManager.listDevices(request)sendCommandManager.sendCommand(request),, und implementieren.

Beispiele für das Anforderungsformat

In den folgenden Beispielen werden generische Konnektoranfragen von Managed Integrations detailliert beschrieben, in denen gemeinsame Felder für alle erforderlichen Schnittstellen vorhanden sind. Aus den Beispielen können Sie ersehen, dass es sowohl einen Anforderungsheader als auch eine Anforderungs-Payload gibt. Anforderungsheader sind auf jeder Bedienoberfläche üblich.

Beispiel für OAuth 2.0:

{ "header": { "auth": { "token": "ashriu32yr97feqy7afsaf", "type": "OAuth2.0" } }, "payload":{ "operationName": "AWS.SendCommand", "operationVersion": "1.0", "connectorId": "exampleId", … } }

Beispiel für eine allgemeine Autorisierung:

{ "header": { "auth": { "secretsManager": { "arn": "string", "versionId": "string" }, "type": "GeneralAuthorization" } }, "payload":{ "operationName": "AWS.SendCommand", "operationVersion": "1.0", "connectorId": "exampleId", … } }

Standard-Anforderungsheader

Die Standard-Header-Felder variieren je nach Autorisierungstyp. Ihr Connector muss sowohl OAuth 2.0- als auch General Authorization-Anforderungsheader verarbeiten.

OAuth 2.0-Standard-Header:

{ "header": { "auth": { "token": string, // End user's Access Token "type": "OAuth2.0" } } }

Standard-Header für die allgemeine Autorisierung:

{ "header": { "auth": { "secretsManager": { "arn": "string", "versionId": "string" }, "type": "GeneralAuthorization" } } }
Header-Parameter
Feld Required/Optional Beschreibung

header:auth

Ja

Autorisierungsinformationen, die vom C2C-Connector-Builder bei der Registrierung des Connectors bereitgestellt wurden.

header:auth:token

Bedingt

Autorisierungstoken des Benutzers, das vom Cloud-Drittanbieter generiert und mit dem verknüpft wurde. connectorAssociationID Für OAuth 2.0 erforderlich, für die allgemeine Autorisierung nicht vorhanden.

header:auth:secretsManager

Bedingt

AWS Secrets Manager ARN und Versions-ID mit Autorisierungsdaten. Für die allgemeine Autorisierung erforderlich, für OAuth 2.0 nicht vorhanden.

header:auth:type

Ja

Die Art der Autorisierung: OAuth2.0 oder. GeneralAuthorization

Anmerkung

Alle Anfragen an Ihren Connector enthalten Autorisierungsinformationen. Für OAuth 2.0 beinhaltet dies das Zugriffstoken des Endbenutzers. Bei der allgemeinen Autorisierung gehören dazu der AWS Secrets Manager ARN und die Versions-ID. Sie können davon ausgehen, dass die entsprechende Autorisierung bereits eingerichtet wurde.

Payload anfordern

Zusätzlich zu den allgemeinen Headern hat jede Anfrage eine Nutzlast. Diese Payload wird zwar eindeutige Felder für jeden Operationstyp haben, aber jede Payload hat eine Reihe von Standardfeldern, die immer vorhanden sein werden.

Payload-Felder anfordern:
  • operationName: Der Vorgang einer bestimmten Anfrage, der einem der folgenden Werte entspricht:AWS.ActivateUser,, AWS.SendCommandAWS.DiscoverDevices,AWS.DeactivateUser.

  • operationVersion: Jeder Vorgang ist versioniert, um seine Weiterentwicklung im Laufe der Zeit zu ermöglichen und eine stabile Schnittstellendefinition für Konnektoren von Drittanbietern bereitzustellen. Managed Integrations übergibt ein Versionsfeld in der Nutzlast aller Anfragen.

  • connectorId: Die ID des Connectors, an den die Anfrage gesendet wurde.

Standard-Antwort-Header

Jeder Vorgang reagiert mit einer Antwort ACK auf verwaltete Integrationen für AWS IoT Device Management, die bestätigt, dass Ihr C2C-Connector die Anfrage erhalten und mit der Bearbeitung begonnen hat.

Beispiel Beispiel für eine generische Antwort
{ "header":{ "responseCode": 200 }, "payload":{ "responseMessage": “Example response!” } }
Beispiel Format des Antwort-Headers
{ "header": { "responseCode": Integer } }
Feld für den Antwort-Header
Standard-Header und -Feld für Antworten
Feld Required/Optional Kommentar

header:responseCode

Ja

ENUM von Werten, die den Ausführungsstatus der Anfrage angeben.

In den verschiedenen Connector-Schnittstellen und API-Schemas, die in diesem Dokument beschrieben werden, gibt es ein responseMessage Oder-Feld. Message Dies ist ein optionales Feld, das für den C2C-Konnektor Lambda verwendet wird, um mit jedem Kontext bezüglich der Anfrage und ihrer Ausführung zu antworten. Vorzugsweise 200 sollten alle Fehler, die zu einem anderen Statuscode führen, einen Nachrichtenwert enthalten, der den Fehler beschreibt.

Beantworten Sie Anfragen zum Betrieb des C2C-Connectors mit der API SendConnectorEvent

Managed Integrations for AWS IoT Device Management erwartet, dass sich Ihr Connector bei jedem AND-Vorgang asynchron verhält. AWS.SendCommand AWS.DiscoverDevices Das bedeutet, dass die erste Antwort auf diese Operationen lediglich „bestätigt“, dass Ihr C2C-Connector die Anfrage erhalten hat.

Bei Verwendung der SendConnectorEvent API wird von Ihrem Connector erwartet, dass er die Ereignistypen aus der folgenden Liste für AWS.DiscoverDevices und AWS.SendCommand Operationen sowie proaktive Geräteereignisse (z. B. manuelles Ein- und Ausschalten eines Lichts) sendet.

Beispiel für einen Arbeitsablauf

Wenn Ihr C2C-Connector eine DiscoverDevices Anfrage empfängt, AWS IoT Device Management erwartet Managed Integrations for, dass diese:

  • Antworten Sie synchron mit dem oben definierten Antwortformat

  • Rufen Sie die SendConnectorEvent API mit einem DEVICE_DISCOVERY-Ereignis auf

Der SendConnectorEvent API-Aufruf kann überall dort erfolgen, wo Sie Zugriff auf Ihre AWS-Konto Lambda-Anmeldeinformationen für den C2C-Connector haben. Die Geräteerkennung ist erst erfolgreich, wenn Managed Integrations for AWS IoT Device Management dieses Ereignis empfängt.

Anmerkung

Alternativ kann der SendConnectorEvent API-Aufruf bei Bedarf vor der Lambda-Aufrufreaktion des C2C-Konnektors erfolgen. Dieser Ablauf widerspricht jedoch dem asynchronen Modell für die Softwareentwicklung.

SendConnectorEvent API

Ihr Connector ruft diese verwalteten Integrationen für die AWS IoT Device Management API auf, um Geräteereignisse zu senden. Es werden nur 3 Arten von Ereignissen akzeptiert:

  • „DEVICE_DISCOVERY“ — Wird verwendet, um eine Liste der erkannten Geräte innerhalb der Cloud eines Drittanbieters für ein bestimmtes Zugriffstoken zu senden

  • „DEVICE_COMMAND_RESPONSE“ — Wird verwendet, um ein bestimmtes Geräteereignis als Ergebnis der Befehlsausführung zu senden

  • „DEVICE_EVENT“ — Wird für jedes Ereignis verwendet, das vom Gerät ausgeht und nicht das direkte Ergebnis eines benutzerbasierten Befehls ist. Dies kann als allgemeiner Ereignistyp dienen, um proaktiv Gerätestatusänderungen oder Benachrichtigungen zu melden