Mendix est tout au sujet de la démocratisation de la technologie. Ce message était au cœur du discours prononcé par Siemens Roland Busch, PDG d'AG, au Consumer Electronics Show (CES) de cette année à Las Vegas.
Roland a partagé à quel point l'IA est générative devenir beaucoup plus largement accessible Grace à Connecteur Amazon Bedrock. Le connecteur, né d'un alliance stratégique entre AWS et Mendix, offre l'accès à une variété de modèles de fondations provenant de différents services.
Mais ce n’est pas seulement l’IA générative qui est désormais plus facile à utiliser dans votre Mendix application. Il existe une large gamme de connecteurs pour les services AWS disponibles dans le Mendix Marketplace.
Ces connecteurs s'appuient sur la Connecteur d'authentification AWS (récemment mis à niveau vers la version 3.0.0). Étant donné que plusieurs connecteurs AWS partagent les mêmes dépendances et s'appuient sur une structure de requête similaire, ces fonctionnalités sont désormais centralisées pour une utilisation plus simple. Les modifications architecturales qui les accompagnent vous permettent également de modifier l'URL du point de terminaison (utilisée pour consommer l'API AWS).
En règle générale, l'URL du point de terminaison est automatiquement définie sur une valeur par défaut spécifique au service et à la région. Mais si vous souhaitez déployer votre application sur site, vous souhaiterez peut-être vous connecter à un autre point de terminaison. Et il existe encore plus de cas où vous préférerez peut-être vous connecter à un point de terminaison local ou à un point de terminaison de cloud privé virtuel.
Pourquoi changer l'URL du point de terminaison http ?
Le changement de l’URL du point de terminaison présente quatre avantages majeurs.
1. Sécurité accrue
Disons que vous avez décidé de déployer votre Mendix application sur site et vous avez besoin que les services Web Amazon utilisés dans votre application adhèrent aux mêmes politiques de sécurité. En modifiant l'URL du point de terminaison, vous n'êtes plus limité aux services déployés dans le cloud AWS. Au lieu de cela, vous pouvez vous connecter à n'importe quel point de terminaison de votre choix.
2. Coût réduit
Lorsque vous vous connectez à un service qui n'est pas hébergé sur un serveur AWS, vous ne payez pas pour l'utilisation du serveur. Cela peut représenter une réelle économie d'argent si, par exemple, vous utilisez un service local pour les tests et que vous n'avez pas besoin de tous les avantages d'un service cloud.
3. Meilleur contrôle de votre environnement de test
L'utilisation d'un service local pour les tests vous donne un contrôle total sur votre environnement. Il permet également des itérations encore plus rapides (si vous devez déployer l'application), un retour d'information instantané et un débogage plus efficace.
4. Aucune connexion Internet requise
Vous n'avez pas besoin d'une connexion Internet pour vous connecter à un point de terminaison local. Si vous utilisez un point de terminaison local, vous n'avez même pas besoin d'une connexion réseau, ce qui peut être utile si vous souhaitez tester votre application en déplacement.
(Notez qu'il existe un compromis entre les instances de service locales et Web. Dans l'exemple Amazon DynamoDB qui suit, la base de données locale n'est pas partagée. Par conséquent, vous ne pouvez pas refléter tous les scénarios de production localement par conception. Il existe d'autres différences entre les instances de service locales et Web que vous pouvez lire ici.)
Maintenant que vous savez pourquoi vous souhaitez modifier l’URL du point de terminaison, laissez-moi vous montrer comment procéder en utilisant un exemple avec Amazon DynamoDB.
Comment modifier l'URL du point de terminaison http ?
Pour suivre ce tutoriel, vous avez besoin d'un Mendix application qui a Authentification AWS v3.0.0 (ou plus tard) et Amazon DynamoDB mis en œuvre comme documenté ici.
Vous aurez également besoin d'une instance locale de DynamoDB en cours d'exécution. Documentation AWS fournit des conseils sur la façon de déployer DynamoDB localement, soit sous forme de fichier .jar, soit dans un conteneur Docker. Choisissez simplement votre approche préférée et suivez la documentation pour créer une instance locale.
Quoi qu'il en soit, une fois DynamoDB installé avec succès, vous pouvez accéder à la base de données à l'aide de l'AWS CLI comme décrit ci-dessous.
1. Accéder à DynamoDB avec l'AWS CLI
Il n'est pas nécessaire d'utiliser l'AWS CLI pour connecter votre Mendix application à l'instance DynamoDB locale. Cependant, l'AWS CLI est un bon moyen d'examiner la base de données à l'aide de la fenêtre d'invite de commande (et de s'assurer que la base de données est en cours d'exécution et qu'elle a l'aspect prévu).
Si vous n'avez pas encore installé l'AWS CLI, vous pouvez le télécharger ici.
Essayez cette invite pour répertorier toutes les tables existantes dans la base de données :
aws dynamodb list-tables --endpoint-url https://localhost:8000
DynamoDB utilise le port 8000 (à moins que, par exemple, vous ne l'ayez spécifié différemment dans le fichier de composition de Docker). Si votre base de données est toujours vide, vous verrez quelque chose comme ceci :
{
"TableNames": []
}
Par exemple, vous pouvez ajouter une nouvelle table appelée « Musique » avec la commande suivante (pour Windows) :
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 https://localhost:8000
Vous trouverez de la documentation sur la façon de créer une table avec la CLI ici.
Si vous répertoriez à nouveau toutes les tables de la base de données, la nouvelle table avec le nom « Musique » aurait dû être ajoutée :
{
"TableNames": [
"Music"
]
}
Utilisez la CLI pour jouer avec la base de données locale si vous le souhaitez. Vous pouvez trouver plus de commandes iciAssurez-vous simplement de toujours ajouter le paramètre '–endpoint-url' afin que la base de données locale soit accessible.
Au lieu d'ajouter des données manuellement, vous pouvez également effectuer une sauvegarde de DynamoDB distant et l'utiliser pour restaurer votre base de données locale comme décrit ici. Cette approche peut même vous donner une idée approximative des performances de l’instance distante.
2. Connectez la base de données locale à votre Mendix appli
Une fois que vous avez configuré le connecteur d'authentification AWS dans votre application avec des informations d'identification statiques ou de session, vous êtes prêt à démarrer. Il n'est pas nécessaire d'utiliser des informations d'identification valides, sauf si vous avez l'intention de basculer entre les bases de données locales et distantes et que vous ne souhaitez pas configurer l'authentification ultérieurement.
Étant donné que toutes les entités de requête de nos connecteurs héritent de l'entité AbstractRequest, à partir de la version AWS Authentication Connector 3.0.0, il est possible de remplacer l'URL du point de terminaison. Créez simplement un objet BasicClientConfig avec la valeur d'URL du point de terminaison correcte et associez-le à la requête.
Voici à quoi ressemblent les deux entités dans le modèle de domaine du connecteur d’authentification AWS :

Vous trouverez ci-dessous trois exemples de microflux illustrant comment modifier le point de terminaison http par défaut pour une opération. Si vous ne savez pas comment créer une requête appropriée, reportez-vous à la section Connecteur Amazon DynamoDB et Base de données Amazon Dynamo documentation pour plus d'informations.




La même recette fonctionne pour toute opération sur l’un de nos connecteurs où vous souhaitez adresser un point de terminaison différent de celui par défaut.
Que vous exécutiez le fichier .jar dans le dossier téléchargé ou que vous utilisiez le conteneur Docker, votre Mendix L'application doit maintenant être connectée à la base de données locale. Amusez-vous à la tester !
Si vous êtes satisfait du fonctionnement local de votre application, supprimez simplement l'objet BasicClientConfig ou supprimez la valeur de l'attribut. L'application se connectera alors de manière transparente à l'instance distante. (N'oubliez pas de configurer vos informations d'identification AWS dans les paramètres ! 😊)
Conclusion
Avec la nouvelle fonctionnalité Authentication Connector, vous n'êtes plus limité aux points de terminaison par défaut. Vous pouvez choisir de vous connecter à un cloud privé sur site ou à un point de terminaison local sans avoir à faire de compromis. La connexion à un autre point de terminaison peut encore améliorer votre projet en termes de coût et en fournissant un environnement de test contrôlé et indépendant du serveur.
Enfin, changer de point de terminaison est vraiment facile avec notre connecteur !