Action communautaire

Un autre résultat de la Mendix la collaboration avec AWS a été la richesse des connaissances et des outils créés pour aider Mendix Créateurs et constructeurs AWS dans leur parcours de développement. Ce matériel d'activation comprend ARTICLES DE BLOGUE, parcours d'apprentissage, vidéos informativesou exemples d'implémentationsIl comprend également des guides étape par étape, des bonnes pratiques et des informations pratiques pour créer des solutions avec Mendix sur AWS pour ceux qui débutent Mendix.

Quand vous vous déconnectez, votre profil Mendix La communauté a joué un rôle déterminant dans l'élaboration du contenu. Ils ont fourni des commentaires sur le forum, a créé un environnement propice à la croissance et à l'innovation, et a mis en évidence les domaines à améliorer. La communauté a librement partagé ses frustrations (par exemple, devoir configurer les mêmes informations d'identification sur différents connecteurs pour s'authentifier) ​​et ses idées (par exemple, invoquer des points de terminaison personnalisés et remplacer les configurations de délai d'expiration HTTP pour prolonger la durée d'exécution d'une fonction AWS Lambda). Tous ces commentaires se reflètent dans la récente mise à jour de la Connecteur d'authentification AWS et améliore l'expérience du développeur avec la suite AWS Connector plus large.

Mises à niveau et améliorations

Plongeons-nous plus en détail dans ces changements. Je fournirai un aperçu complet des changements majeurs, expliquerai les délibérations et discuterai des impacts que ces changements peuvent avoir sur le flux de travail d'un développeur. J'espère que ces informations conduiront à une expérience de développement plus fluide et plus efficace.

Les mises à jour et améliorations apportées à AWS Connector Suite vont au-delà des mises à niveau techniques. Elles améliorent le flux de travail de développement lors de la combinaison Mendix et AWS.

Ces modifications auront un impact sur les applications qui utilisent des versions antérieures des connecteurs. Nous allons examiner en détail ce que ces modifications impliquent et comment vous pouvez effectuer une transition en douceur vers la nouvelle version.

Centralisation des composants

Le changement le plus notable est la centralisation des composants d'authentification, notamment les constantes de détails de connexion et le microflux de génération d'un objet Credentials. Ce changement entraînera des erreurs dans les applications qui n'ont pas été mises à jour, car les constantes d'authentification et les microflux ne se trouvent plus dans les modules de connecteur, mais dans AWS Authentication Connector. Ces erreurs peuvent être résolues en configurant les constantes de détails de connexion et le microflux de génération d'informations d'identification situés dans AWS Authentication Connector.

Une entité de demande à chaque

Nous avons standardisé toutes les opérations pour inclure une entité de requête, que l'opération ait ou non une entité de requête auparavant. Ce changement apporte de la cohérence à l'ensemble de la suite. Lors de la mise à niveau, des erreurs peuvent se produire pour les opérations qui n'avaient pas auparavant d'entité de requête. Pour résoudre ces erreurs, ajoutez simplement une instance de l'entité de requête nouvellement introduite pour s'aligner sur la mise à jour.

Héritage de l'entité AbstractRequest

Cette modification s'appuie sur l'introduction d'entités de requête pour chaque opération. Nous avons incorporé une nouvelle fonctionnalité où toutes les entités de requête héritent désormais de l'entité AbstractRequest du connecteur d'authentification AWS. Cet héritage ouvre la voie à la fonctionnalité de remplacement des configurations client HTTP. Bien que cette modification vise à normaliser les opérations, elle peut entraîner des erreurs lors des mises à niveau pour les opérations qui n'avaient auparavant pas d'entité de requête. Ce changement, bien qu'il puisse nécessiter d'apporter des modifications pendant le processus de mise à niveau, accorde un contrôle avancé du comportement des opérations du connecteur.

Refonte de la suite AWS Connectors

Chaque connecteur de la suite a subi une refonte pour garantir l'uniformité et la cohérence. Il est important de noter que ces mises à jour introduiront des changements radicaux pour chaque connecteur de la suite AWS Connectors. Le nombre d'ajustements requis varie en fonction du connecteur spécifique. Il est essentiel que tous les connecteurs mis à niveau disposent désormais d'AWS Authentication Connector 3.0.0 comme condition préalable pour s'aligner sur les normes et fonctionnalités améliorées de la suite.

La compréhension de ces changements et des étapes de migration garantira une transition en douceur vers la version mise à jour. Cela aidera les créateurs à tirer parti des fonctionnalités améliorées d'AWS Connector Suite.

Centralisation sur la suite de connecteurs AWS

Un autre changement concerne la centralisation des composants de l'ensemble de la suite AWS Connectors vers AWS Authentication Connector, un module qui est un prérequis pour tous les connecteurs AWS. Voici les éléments clés de ce changement.

Énumération des régions AWS

Fini le temps où il était difficile de déterminer quelle énumération de région spécifique à un module vous deviez sélectionner. La centralisation de l'énumération des régions AWS simplifie désormais l'accès à la liste de toutes les régions de service AWS. Nous avons étendu cette liste pour inclure des régions supplémentaires pour des options d'intégration plus larges.

Ces régions ajoutées garantiront que les connecteurs sont à jour avec les dernières régions AWS, offrant ainsi aux développeurs davantage d'options pour le déploiement des flux de travail AWS. Les nouvelles régions incluent :

• Asie-Pacifique – Hyderabad (ap_south_2)
• Asie-Pacifique – Melbourne (ap_southeast_4)
• Europe – Espagne (eu_south_2)
• Europe – Zurich (eu_central_2)
• Israël – Tel-Aviv (il_central_1)
• Moyen-Orient – ​​Émirats arabes unis (me_central_1)
• AWS GovCloud – États-Unis Est (us_gov_east_1)
• AWS GovCloud – États-Unis-Ouest (us_gov_west_1)

Constantes d'authentification

Nous avons centralisé les constantes des détails de connexion utilisées dans la configuration de l'authentification AWS, un changement motivé par les commentaires de la communauté. La communauté a indiqué que le fait de devoir configurer plusieurs ensembles de constantes crée une surcharge de configuration inutile pendant le développement. La nouvelle mise à jour élimine ce problème en déplaçant ces constantes vers le connecteur d'authentification AWS. Cela favorise la réutilisation des informations d'identification tout en conservant la possibilité de configurer plusieurs ensembles d'informations d'identification.

Nous avons également revu le flux de travail d'authentification. Nous avons supprimé la constante « UseStaticCredentials », précédemment utilisée pour l'authentification. La nouvelle approche de l'entité Credentials est désormais plus conforme aux pratiques d'AWS.

L'authentification statique reste inchangée. Cependant, pour l'authentification temporaire, nous avons introduit l'entité TemporaryCredentials, une spécialisation de l'objet Credentials. Cela reflète non seulement la convention de dénomination AWS, mais établit également une séparation plus claire et améliorée des problèmes d'authentification.

En outre, la suite AWS Connectors a adopté la terminologie « identifiants temporaires » au lieu des « identifiants basés sur la session » précédemment utilisés. Cette terminologie est plus largement reconnue et adoptée au sein de l'écosystème AWS. Cette approche incarne notre engagement à rester en phase avec les normes AWS, améliorant ainsi la clarté et la cohérence des connecteurs pour les créateurs.

Microflow prêt à l'emploi pour générer des informations d'identification valides

Auparavant, les actions du connecteur incluaient une logique de création d'un objet Credentials dans le flux de l'action elle-même. Cependant, cette approche a évolué, nécessitant désormais l'objet Credentials comme paramètre d'entrée. Ce changement, déjà adopté par les connecteurs plus récents, améliore la flexibilité en permettant une gestion personnalisée des informations d'identification.

Dans la dernière mise à jour, nous avons standardisé toutes les actions du connecteur selon cette approche. Par conséquent, chaque microflux générateur d'informations d'identification qui existait dans chaque connecteur AWS distinct est désormais centralisé dans le connecteur d'authentification AWS sous la forme de deux microflux distincts pour l'authentification statique et temporaire. Cette séparation favorise un contrôle plus précis, permettant aux développeurs d'opter pour des informations d'identification statiques pour une authentification rapide pendant le développement ou des informations d'identification temporaires pour un accès sécurisé à court terme dans les environnements de production.

La centralisation de ces composants dans le module AWS Authentication Connector améliore la réutilisabilité et l'efficacité, d'autant plus que chaque connecteur nécessite déjà le connecteur d'authentification AWS. Cette approche, motivée par les commentaires de la communauté, résout le problème de la gestion des ensembles de constantes en double dans les projets comportant plusieurs connecteurs AWS et garantit un processus de développement plus fluide et plus unifié.

Remplacement des configurations du client HTTP

Lors du développement de la suite AWS Connectors, nous avons utilisé le kit de développement logiciel (SDK) AWS au lieu du kit natif. Mendix Appeler le service REST Activité. Cette approche privilégie l'efficacité dans la gestion des intégrations AWS. Elle élimine la complexité de la personnalisation des en-têtes HTTP et de la signature des requêtes, car le SDK automatise ces tâches. De plus, il offre des fonctionnalités intégrées telles que la logique de nouvelle tentative et la gestion de la limitation. Cette base ouvre la voie à la discussion sur le remplacement des configurations client HTTP du SDK, accordant aux développeurs davantage de contrôle sur le comportement de l'application.

Remplacement des configurations par défaut pour le client HTTP du SDK

Pour résoudre des problèmes tels que l'expiration du délai d'attente des fonctions AWS Lambda en raison des paramètres client HTTP par défaut, nous avons introduit des configurations client HTTP personnalisables. Chaque action de connecteur possède une entité de demande qui hérite de l'entité AbstractRequest. Pour remplacer les configurations HTTP par défaut, les créateurs définissent les attributs sur un objet de (sous-)type BasicClientConfig et l'associent à la demande avant d'appeler l'action du connecteur.

Certains cas d'utilisation incluent :

• Extension des paramètres de délai d'expiration pour prendre en charge les opérations susceptibles de s'exécuter plus longtemps, telles que les fonctions AWS Lambda.
• Personnalisation du mécanisme de nouvelle tentative pour modifier le comportement de récupération du client après l'échec des demandes de service AWS.
• Remplacement des points de terminaison d'invocation (requis pour les cas d'utilisation tels que les tests locaux), intégration à une instance auto-hébergée du service AWS et appel de points de terminaison VPC (cloud privé).

Ces améliorations offrent un meilleur contrôle et une plus grande flexibilité, permettant aux fabricants d’adapter les connecteurs à leurs besoins d’application spécifiques.

Passer des modules complémentaires aux modules réguliers

Des commentaires tels que « Qu'est-ce qu'un module complémentaire ? » et « Pourquoi le module connecteur ne peut-il pas être trouvé sous les modules Marketplace ? » sont des questions typiques concernant le type de module de certains connecteurs AWS. Un module complémentaire est un composant spécialisé dans Mendix qui offre des fonctionnalités telles que la protection IP et les dépendances groupées, ce qui les distingue des modules standard. Voyons comment nous avons exploité les fonctionnalités uniques des modules complémentaires dans notre développement de la suite AWS Connector.

Modules complémentaires

Il y a un an, nous avons publié le connecteur Amazon Polly en tant que module complémentaire dans une phase pilote. Notre objectif était d'évaluer la faisabilité du déploiement de l'ensemble de la suite sous forme de modules complémentaires. Les modules complémentaires (avec l'extension .mxmodule) regroupent les dépendances du connecteur, ce qui les rend idéaux pour éviter les conflits de bibliothèques. Cependant, avec l'introduction de Mendix» dépendances gérées fonctionnalité dans Mendix Studio Pro 10.3, ce souci n'est plus d'actualité.

Le passage aux modules réguliers

Grâce aux nouvelles fonctionnalités de gestion des dépendances, nous avons pu achever la transition vers l'utilisation de modules classiques. Ce changement simplifie non seulement le processus de développement, mais permet également à ces connecteurs de servir de référence pour ceux qui cherchent à créer des intégrations AWS.

Le passage à des modules réguliers ouvre des possibilités de personnalisation plus larges, conformément à notre engagement à faire Mendix la plateforme la plus rapide et la plus simple pour créer des applications sur AWS.

Conclusion

En résumé, cette mise à jour de la suite AWS Connector apporte des améliorations en termes de fonctionnalités et de convivialité.

• La centralisation des composants dans AWS Authentication Connector rationalise le processus de développement en réduisant la redondance et en renforçant la réutilisabilité de ces composants.
• L'introduction de configurations client HTTP personnalisables offre un contrôle amélioré sur les intégrations AWS, y compris des aspects tels que les paramètres de délai d'expiration étendus et les mécanismes de nouvelle tentative personnalisés.
• Le passage des modules complémentaires aux modules standards simplifie le développement et élargit les possibilités de personnalisation et d’intégration.

Ces améliorations marquent collectivement une avancée significative dans nos efforts continus visant à optimiser l'expérience d'intégration AWS. Grâce à ces avancées, la Mendix la communauté est mieux équipée pour créer des applications robustes, efficaces et évolutives sur AWS.

Vous vous demandez peut-être comment vous pouvez contribuer à ouvrir la voie à la réalisation Mendix le moyen le plus rapide et le plus simple de créer des applications sur AWS. Nous sommes toujours impatients d'entendre vos idées, de répondre à vos préoccupations et de vous accompagner dans votre parcours de développement. Nous sommes à un message près ! Contactez-nous à [email protected], Sur la Mendix Marge de la communauté dans le canal #aws-general, ou sur le Mendix Forum.