Mendix dreht sich alles um die Demokratisierung der Technologie. Diese Botschaft stand im Mittelpunkt der Keynote von Siemens AG-Vorstandsvorsitzender Roland Busch auf der diesjährigen Consumer Electronics Show (CES) in Las Vegas.
Roland erzählte, wie generativ KI ist immer besser zugänglich Danke an die Amazon Bedrock Connector. Der Konnektor, geboren aus einem strategische Allianz zwischen AWS und Mendix, bietet Zugriff auf eine Vielzahl von Stiftungsmodellen verschiedener Dienste.
Aber nicht nur generative KI lässt sich jetzt einfacher in Ihrem Mendix Anwendung. Es gibt eine breite Palette von Anschlüsse für AWS-Dienste verfügbar im Mendix Marketplace.
Diese Konnektoren basieren auf der AWS-Authentifizierungsconnector (kürzlich aktualisiert auf Version 3.0.0). Da mehrere AWS-Konnektoren dieselben Abhängigkeiten teilen und auf einer ähnlichen Anforderungsstruktur basieren, sind diese Funktionen jetzt zur einfacheren Verwendung zentralisiert. Die begleitenden Architekturänderungen ermöglichen Ihnen auch die Bearbeitung der Endpunkt-URL (die zur Nutzung der AWS-API verwendet wird).
Normalerweise wird die Endpunkt-URL automatisch auf einen dienst- und regionsspezifischen Standardwert eingestellt. Wenn Sie Ihre Anwendung jedoch vor Ort bereitstellen möchten, möchten Sie möglicherweise eine Verbindung zu einem anderen Endpunkt herstellen. Und es gibt noch mehr Fälle, in denen Sie möglicherweise eine Verbindung zu einem lokalen oder Virtual Private Cloud-Endpunkt herstellen möchten.
Warum die HTTP-Endpunkt-URL ändern?
Das Ändern der Endpunkt-URL bringt vier wesentliche Vorteile mit sich.
1. Erhöhte Sicherheit
Angenommen, Sie haben sich entschieden, Ihre Mendix Anwendung vor Ort, und Sie benötigen für die in Ihrer Anwendung verwendeten Amazon-Webdienste dieselben Sicherheitsrichtlinien. Durch Ändern der Endpunkt-URL sind Sie nicht mehr auf die in der AWS-Cloud bereitgestellten Dienste beschränkt. Stattdessen können Sie eine Verbindung zu jedem beliebigen Endpunkt herstellen.
2. Geringere Kosten
Wenn Sie eine Verbindung zu einem Dienst herstellen, der nicht auf einem AWS-Server gehostet wird, zahlen Sie nicht für die Servernutzung. Dies kann eine echte Geldersparnis sein, wenn Sie beispielsweise einen lokalen Dienst zu Testzwecken verwenden und nicht alle Vorteile eines Cloud-Dienstes benötigen.
3. Bessere Kontrolle über Ihre Testumgebung
Wenn Sie zum Testen einen lokalen Dienst verwenden, haben Sie die vollständige Kontrolle über Ihre Umgebung. Außerdem sind dadurch noch schnellere Iterationen möglich (wenn Sie die Anwendung andernfalls bereitstellen müssten), sofortiges Feedback und effizienteres Debuggen.
4. Kein Internet erforderlich
Sie benötigen keine Internetverbindung, um eine Verbindung zu einem lokalen Endpunkt herzustellen. Wenn Sie einen lokalen Endpunkt verwenden, benötigen Sie nicht einmal eine Netzwerkverbindung, was nützlich sein kann, wenn Sie Ihre Anwendung unterwegs testen möchten.
(Beachten Sie, dass es einen Kompromiss zwischen lokalen und Webservice-Instanzen gibt. Im folgenden Amazon DynamoDB-Beispiel wird die lokale Datenbank nicht gemeinsam genutzt. Daher können Sie nicht alle Produktionsszenarien lokal pro Design spiegeln. Es gibt noch weitere Unterschiede zwischen lokalen und Webservice-Instanzen, über die Sie lesen können. hier.)
Nachdem Sie nun wissen, warum Sie die Endpunkt-URL ändern möchten, möchte ich Ihnen anhand eines Beispiels mit Amazon DynamoDB zeigen, wie das geht.
Wie ändern Sie die HTTP-Endpunkt-URL?
Um diesem Tutorial zu folgen, benötigen Sie ein Mendix Anwendung, die AWS-Authentifizierung v3.0.0 (oder später) und Amazon DynamoDB implementiert wie dokumentiert hier.
Sie müssen außerdem eine lokale Instanz von DynamoDB ausführen. Die AWS-Dokumentation bietet Anleitungen zum lokalen Bereitstellen von DynamoDB, entweder als .jar-Datei oder in einem Docker-Container. Wählen Sie einfach Ihren bevorzugten Ansatz und folgen Sie die Dokumentation um eine lokale Instanz zu erstellen.
Sobald Sie DynamoDB erfolgreich installiert haben, können Sie in jedem Fall über die AWS CLI auf die Datenbank zugreifen, wie unten beschrieben.
1. Zugriff auf DynamoDB mit der AWS CLI
Es ist nicht notwendig, die AWS CLI zu verwenden, um Ihre Mendix Anwendung auf die lokale DynamoDB-Instanz. Die AWS CLI ist jedoch eine gute Möglichkeit, die Datenbank mithilfe des Eingabeaufforderungsfensters zu untersuchen (und sicherzustellen, dass die Datenbank wie vorgesehen ausgeführt wird und aussieht).
Wenn Sie die AWS CLI noch nicht installiert haben, können Sie sie herunterladen hier.
Probieren Sie diese Eingabeaufforderung aus, um alle vorhandenen Tabellen in der Datenbank aufzulisten:
aws dynamodb list-tables --endpoint-url http://localhost:8000
DynamoDB verwendet Port 8000 (es sei denn, Sie haben ihn beispielsweise in der Docker-Compose-Datei anders angegeben). Wenn Ihre Datenbank noch leer ist, sehen Sie etwa Folgendes:
{
"TableNames": []
}
Sie können beispielsweise mit dem folgenden Befehl (für Windows) eine neue Tabelle namens „Musik“ hinzufügen:
aws dynamodb create-table --table-name Music --attribute-definitions AttributeName=Artist,AttributeType=S AttributeName=SongTitle,AttributeType=S --key-schema AttributeName=Artist,KeyType=HASH AttributeName=SongTitle,KeyType=RANGE --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 --table-class STANDARD --endpoint-url http://localhost:8000
Dokumentation zum Erstellen einer Tabelle mit der CLI finden Sie hier.
Wenn Sie alle Tabellen in der Datenbank erneut auflisten, sollte die neue Tabelle mit dem Namen „Musik“ hinzugefügt worden sein:
{
"TableNames": [
"Music"
]
}
Verwenden Sie die CLI, um mit der lokalen Datenbank herumzuspielen, wenn Sie möchten. Weitere Befehle finden Sie hier. Achten Sie nur darauf, immer den Parameter „–endpoint-url“ hinzuzufügen, damit auf die lokale Datenbank zugegriffen wird.
Anstatt Daten manuell hinzuzufügen, können Sie auch eine Sicherungskopie der Remote-DynamoDB erstellen und diese wie beschrieben zum Wiederherstellen Ihrer lokalen Datenbank verwenden. hierDieser Ansatz kann Ihnen sogar eine ungefähre Vorstellung von der Leistung der Remote-Instanz geben.
2. Verbinden Sie die lokale Datenbank mit Ihrem Mendix App
Sobald Sie den AWS Authentication Connector in Ihrer Anwendung mit statischen oder Sitzungsanmeldeinformationen konfiguriert haben, können Sie loslegen. Es ist nicht erforderlich, gültige Anmeldeinformationen zu verwenden, es sei denn, Sie möchten zwischen lokalen und Remote-Datenbanken wechseln und die Authentifizierung später nicht einrichten.
Da alle Anforderungsentitäten in unseren Konnektoren von der Entität AbstractRequest erben, ist es ab der Version AWS Authentication Connector 3.0.0 möglich, die Endpunkt-URL zu überschreiben. Erstellen Sie einfach ein BasicClientConfig-Objekt mit dem richtigen Endpunkt-URL-Wert und verknüpfen Sie es mit der Anforderung.
So sehen die beiden Entitäten im Domänenmodell des AWS Authentication-Connectors aus:
Nachfolgend finden Sie drei Microflow-Beispiele, wie Sie den Standard-HTTP-Endpunkt für eine Operation ändern können. Wenn Sie nicht sicher sind, wie Sie eine geeignete Anfrage erstellen, lesen Sie bitte die Amazon DynamoDB-Konnektor und Amazon Dynamo-DB Dokumentation für weitere Informationen.
Das gleiche Rezept funktioniert für alle Vorgänge an jedem unserer Konnektoren, bei denen Sie einen anderen Endpunkt als den Standardendpunkt ansprechen möchten.
Unabhängig davon, ob Sie die .jar-Datei im heruntergeladenen Ordner ausführen oder den Docker-Container verwenden, Mendix Die Anwendung sollte nun mit der lokalen Datenbank verbunden sein. Viel Spaß beim Ausprobieren!
Wenn Sie mit der lokalen Funktionsweise Ihrer Anwendung zufrieden sind, entfernen Sie einfach das BasicClientConfig-Objekt oder löschen Sie den Attributwert. Die Anwendung stellt stattdessen nahtlos eine Verbindung zur Remote-Instanz her. (Vergessen Sie nicht, Ihre AWS-Anmeldeinformationen in den Einstellungen zu konfigurieren! 😊)
Fazit
Mit der neuen Funktion „Authentifizierungs-Connector“ sind Sie nicht mehr auf die Standardendpunkte beschränkt. Sie können sich für eine Verbindung zu einer privaten Cloud vor Ort oder zu einem lokalen Endpunkt entscheiden und müssen sich nicht mit einem Kompromiss zufrieden geben. Die Verbindung zu einem anderen Endpunkt kann Ihr Projekt hinsichtlich der Kosten weiter verbessern und eine kontrollierte und serverunabhängige Testumgebung bereitstellen.
Schließlich ist das Ändern von Endpunkten mit unserem Connector ganz einfach!