Les développeurs peuvent facilement utiliser les connecteurs existants ou en créer de nouveaux qui intègrent les services AWS à d'autres applications et systèmes à l'aide de Mendixla plateforme de développement low-code efficace de.

« AWS reconnaît le pouvoir transformateur de la Mendix plate-forme, et nous reconnaissons le pouvoir transformateur des services AWS », a déclaré Tim Srock, ancien PDG d'AWS Mendix. En raison de la relation stratégique fructueuse de sept ans entre Mendix et AWS, les deux sociétés ont décidé d'une Relation de mise sur le marché élargie.

Pour en savoir plus sur notre partenariat avec AWS, lisez notre communiqué de presse ici. 

L'utilisation d'AWS permet Mendix les utilisateurs peuvent exploiter la puissance des procédures et services automatisés fournis par AWS sans avoir à les développer eux-mêmes, économisant ainsi du temps et des efforts. Connecteur AWS pour Mendix, vous pouvez facilement accéder au grand nombre de services disponibles dans AWS de manière peu codée et peu laborieuse. Créer un connecteur AWS dans Mendix peut vous aider à rationaliser vos opérations et à augmenter la productivité globale de votre organisation, que vous développiez une application personnalisée qui doit accéder aux ressources AWS ou que vous essayiez d'automatiser les processus métier avec des outils AWS comme Lambda et S3. Pour vous aider à commencer à intégrer immédiatement les services AWS dans vos applications, je vous guiderai à travers les étapes de création d'un connecteur AWS basé sur l'API REST dans Mendix.

Pour commencer

Lorsqu'une personne découvre que le service AWS qu'elle souhaite utiliser ne dispose pas d'un connecteur existant dans le Mendix Marketplace, leur première réaction est généralement quelque chose comme : « Ok, cela signifie que cette solution ne peut actuellement pas être construite avec Mendix”, ou “Je vais devoir trouver une solution de contournement pour cela.”

Je fais partie de l'équipe AWS en Mendix en ce moment, mais avant de commencer, c’était aussi ma première réaction. Même après avoir commencé, alors que je savais déjà que la création de connecteurs AWS était l’objectif de mon équipe, je me sentais toujours dépassé. Je me souviens avoir pensé : « Il y a trop de services AWS et trop d’actions pour chacun d’eux. Comment allons-nous répondre à la demande ? » Remarquez que c’était ma pensée lorsque je venais de commencer dans l’équipe et que je pensais encore que la création d’un connecteur s’apparentait à sauver le monde — c’est-à-dire que c’était extrêmement difficile ! Mais ce n’est pas du tout comme ça – la création d’un connecteur AWS est quelque chose que nous tous Mendix les développeurs peuvent bénéficier d'un peu d'aide de nos guides pratiques !

Si vous avez décidé de créer un nouveau connecteur AWS le plus rapidement possible, vous avez peut-être effectué une recherche pour voir comment vous pourriez démarrer votre parcours. Vous avez peut-être vu qu'il existe deux méthodes d'intégration disponibles pour créer un connecteur AWS dans Mendix, c'est-à-dire une interface de programmation d'application (API) de transfert d'état représentatif (REST) ​​ou un kit de développement logiciel (SDK). Si vous n'avez pas de formation en programmation, la simple lecture du mot SDK peut vous avoir donné des frissons. En vérité, le processus n'est pas aussi compliqué que les gens (moi y compris) l'imaginent et il est tout à fait réalisable. Mais comme nous sommes Mendix Développeurs, pourquoi ne pas utiliser quelque chose que nous connaissons déjà et créer un connecteur AWS basé sur une API REST ? Êtes-vous partant ?

Voici un guide étape par étape rédigé par mes soins.

Création d'un connecteur AWS basé sur l'API REST

La première chose que vous devez savoir est que tous les services et actions AWS ne disposent pas d'API. Cela signifie qu'avant de commencer à utiliser un connecteur AWS basé sur une API REST, vous devez vérifier si le service et les actions dont vous avez besoin disposent d'API disponibles et trouver l'en-tête HTTP nécessaire (leur x-amz-cible (valeur). S'ils n'ont pas d'API pour le service et les actions dont vous avez besoin, malheureusement, la seule autre façon de continuer est de commencer à créer un connecteur à l'aide du SDK.

Pour certains services et actions, les API peuvent être trouvées dans le guide du développeur du service AWS concerné (par exemple, Utilisation de Signature Version 4 avec Amazon Translate – Amazon Translate). Cependant, pour d'autres, c'est une recherche plus difficile. Un site Web que j'ai trouvé utile est TouteAPI (any-api.com). Vous pouvez aller au API de recherche zone, recherchez le nom du service AWS sur lequel vous souhaitez travailler, cliquez dessus et recherchez une liste des actions du service qui ont des API, ainsi que leurs x-amz-cible valeur si elle existe.

Ce que nous allons mettre en œuvre vient de notre Créer un connecteur AWS Article et ses liens associés. Pour des explications plus détaillées sur certains sujets, vous pouvez également vous référer à l'article.

Dans ce scénario, nous supposons que le connecteur Amazon Translate n'existe pas sur la Marketplace, mais qu'il s'agit d'un connecteur dont nous avons besoin pour un projet client. Nous avons décidé de créer un connecteur AWS pour utiliser certaines de ses actions (qui ont des API) et nous allons implémenter le Traduire le texte l'action.

Initier le projet

Pour commencer à travailler sur un connecteur, nous devons d’abord préparer le bon environnement.

In Mendix Studio Pro, nous allons créer un nouveau module appelé Connecteur AmazonTranslate.

Ensuite, installez et configurez le Connecteur d'authentification AWS (version 3.0.0 ou supérieure) car il est nécessaire de s'authentifier auprès des services Web d'Amazon.

Dans l' Connecteur AmazonTranslate module, imposez une structure de dossiers comme indiqué ci-dessous.

Une fois l'environnement de travail prêt, il est temps d'en savoir plus sur l'action que nous souhaitons mettre en œuvre, en particulier sur ce dont l'API REST aurait besoin comme requête et ce que nous recevrions comme réponse.

Pour en savoir plus sur l'action que nous souhaitons mettre en œuvre, nous pouvons nous rendre sur le Documentation AWS (amazon.com).

Nous y trouvons la documentation du service AWS sur lequel nous travaillons actuellement, qui dans notre cas serait le Documentation sur Amazon Translate.

Voici deux guides utiles lors du développement d'un connecteur AWS. Étant donné que nous construisons un connecteur basé sur l'API REST, nous choisissons Référence de l'API Amazon Translate – Référence de l'API Amazon Translate, puis ouvrez TranslateText – Référence de l'API Amazon Translate.

Sur cette page, nous pouvons trouver de nombreuses informations précieuses sur l'action que nous souhaitons mettre en œuvre, comme la syntaxe de la requête et de la réponse, les détails de leurs paramètres, ainsi que les erreurs courantes auxquelles nous pourrions être confrontés.

Après avoir lu davantage sur l'action que nous allons mettre en œuvre, nous utiliserons d'abord la syntaxe de requête et de réponse de l' Traduire le texte action visant à modéliser les entités correspondantes.

Depuis la mise à niveau du connecteur AWS Authentication vers la version 3.0.0, il est recommandé que les entités de requête de tous les autres connecteurs AWS héritent de l'entité AWSAuthentication.AbstractRequest. De plus, les paramètres de délai d'expiration doivent être spécifiés dans un objet BasicClientConfig associé. Cela est particulièrement pertinent si vous souhaitez publier votre connecteur sur la place de marché.

Dans cet exemple, nous souhaitons toutefois emprunter la voie la plus simple. Nous n'utiliserons donc pas l'héritage ni ne créerons un objet BasicClientConfig pour spécifier les paramètres de délai d'attente.
Créons l'entité de requête et examinons d'abord le corps de la requête dans la documentation AWS. De manière pratique, nous pouvons générer l'entité de requête en fonction de la syntaxe de l'action TranslateText.

Dans l' Extraits JSON dossier, nous créons un document de structure JSON nommé d'après le service AWS, dans ce cas, JSON_TranslateText.

Nous ouvrons le document et collons la syntaxe de quête trouvée dans TranslateText – Référence de l'API Amazon Translate.

Nous cliquons ensuite Format. Parce que nous ne nous soucions pas des paramètres appliqués et des terminologies appliquées dans notre cas, nous allons supprimer ces parties et simplement laisser CodeLangueSource, CodeLangueCibleet Texte traduit avant de cliquer Refresh et OK.

Dans l' Importer des mappages dossier, nous créons un document de mappage d'importation, nommons-le IMM_TranslateText et cliquez sur OK.

Nous ouvrons le IMM_TranslateText document. Dans le Source du schéma section, nous sélectionnons Structure JSON, puis sélectionnez le JSON_TranslateText  document.

Ensuite, nous cliquons Tout voir, sélectionnez Cochez toutes les, et alors OK.

Mendix Studio Pro affichera désormais une représentation visuelle du mappage du service AWS dans votre Mendix application. Dans certains cas, des entités qui ne servent à rien peuvent être générées. Supprimez-les en ouvrant à nouveau le document de mappage d'importation et en décochant celles qui ne sont pas nécessaires. Dans ce cas, comme aucune entité inutile n'est créée, nous allons passer à autre chose.

Une fois cela fait, nous cliquons Cartographier automatiquement. Mendix Studio Pro va créer les entités dans lesquelles la réponse du service AWS sera mappée dans le modèle de domaine. Dans notre cas, le mappage d'importation ressemble à ceci :

Nous allons maintenant accéder à notre modèle de domaine et modifier les noms des entités créées pour qu'ils correspondent à l'action TranslateText. De manière pratique, nous pouvons voir dans la documentation de l'API que les attributs de la réponse qui nous intéresse sont les mêmes que ceux de la requête. Nous pouvons donc simplement copier la TranslateTextRequest nouvellement créée et la renommer. Voici à quoi devraient ressembler les deux entités maintenant :

Nous devrons également exporter des objets TranslateTextRequest plus tard. Pour nous préparer, nous créons un mappage d'exportation EXM_TranslateText de la même manière que le mappage d'importation IMM_TranslateText. Une fois notre modèle de domaine prêt, nous pouvons passer à la création de notre action de microflux. Cependant, avant de commencer à travailler dessus, nous allons rapidement ajouter les constantes dont nous avons besoin pour l'authentification.
Dans les paramètres de l'application, nous modifions les valeurs constantes du connecteur AWS Authentication. Les constantes requises pour les deux types, statique et temporaire, sont répertoriées dans la section ConnectionDetails du connecteur, comme vous pouvez le voir dans l'image ci-dessous.

Maintenant, nous pouvons commencer à travailler sur notre microflux.

Dans l' Opérations dossier, nous créons un microflux appelé POST_v1_Traduire le texte, Selon l' Mendix conventions de nommage.

D’après TranslateText – Référence de l'API Amazon Translate, la demande de cette action comporte trois paramètres obligatoires : CodeLangueSource, CodeLangueCibleet Texte, qui est le texte que nous souhaitons traduire. Nous ajoutons donc trois paramètres d'entrée au microflow pour ces paramètres et créons une variable de chaîne appelée Corps de la requête pour préparer la demande d'action.

Puisque nous avons créé une entité de requête, nous pouvons l’utiliser comme seul paramètre d’entrée.

Nous ajoutons ensuite soit le Obtenir des informations d'identification temporaires ou la Obtenir des informations d'identification statiques microflux provenant de la Module d'authentification AWS pour obtenir nos informations d'identification. Dans cette implémentation, nous utiliserons des informations d'identification statiques, nous ajoutons donc le microflow GetStaticCredentials. Toutes les informations nécessaires à la création de l'objet Credentials seront renseignées à partir des constantes que nous avons renseignées dans le connecteur AWS Authentication.

Nous avons maintenant notre demande et nos informations d'identification AWS. Cependant, avant de pouvoir appeler le service REST, nous devons utiliser Signature Version 4 pour ajouter les informations d'authentification à notre appel de demande. Nous devons configurer le microflow pour obtenir un objet SigV4Header en utilisant le Obtenir les en-têtes SigV4 opération de la Authentification AWS module. Pour cela, nous créons d'abord un nouvel objet SigV4Builder appelé Nouveau constructeur SigV4 et remplissez ses membres. Veuillez sélectionner une région selon les meilleures pratiques : la région la plus proche de votre emplacement où le service de traduction est disponible.

Ensuite, nous créons une liste de Paramètre SigV4 objets appelés Liste d'en-têtes car il y a deux en-têtes importants qui sont nécessaires comme paramètre d'entrée du Obtenir les en-têtes SigV4 Action Java.

Pour le premier en-tête, nous créons un Paramètre SigV4 objet Type de contenuEn-tête avec les paramètres suivants:

• ACTIVITES - Type de contenu
• Valeur - application/x-amz-json-1.1

Pour le deuxième en-tête, nous créons un Paramètre SigV4 objet En-tête d'action de traduction de texte ajouter le x-amz-cible pour Traduire le texte action que nous avions trouvée avant de commencer à travailler sur le connecteur.

• ACTIVITES - x-amz-cible
• Valeur - AWSShineFrontendService_20170701.Traduction de texte

Nous ajoutons ces deux en-têtes à la Liste d'en-têtes nous avons créé.

Maintenant, nous pouvons ajouter le Obtenir les en-têtes SigV4 opération à notre microflow et utiliser nos informations d'identification, le Nouveau constructeur SigV4 objet et la liste des Paramètre SigV4 objets Liste d'en-têtes comme paramètres d'entrée. Il renvoie un En-têtes SigV4 objet.

Après avoir mis l'objet SigV4Headers dans le champ d'application, nous souhaitons exporter TranslateTextRequest pour obtenir RequestBody au format JSON. Pour ce faire, ajoutez une action « Exporter avec mappage » au microflow. Sélectionnez ensuite le mappage EXM_TranslateText ainsi que l'objet TranslateTextRequest et utilisez une variable de retour appelée « RequestBody ».

Nous pouvons maintenant appeler le service REST, car nous avons toutes les informations nécessaires, nous ajoutons donc une action d'appel REST au microflow. Emplacement est le URL du point de terminaison attribut du retourné En-têtes SigV4 ; Temps mort est réglé sur 300 ms par défaut et peut être modifié en n'importe quelle valeur entière de votre choix ; et Demander est le Corps de la requête variable de chaîne du microflux. Nous ajoutons la En-tête de type de contenu, En-tête d'action de traduction de texte, et les en-têtes dans le retour En-têtes SigV4 objet comme En-têtes HTTP personnalisés à l'appel REST également.

Nous cartographions le Réponse en utilisant la fonction IMM_TranslateText document, qui renvoie un Réponse de traduction de texte objet.

Notre microflux terminé ressemble à ceci (la génération des SigV4Headers a été consolidée dans un sous-flux pour une meilleure clarté) :

Et voilà ! Vous avez créé un nouveau connecteur Amazon Translate, qui peut traduire du texte dans une autre langue ! N'oubliez pas d'exposer ce microflux afin qu'il puisse être facilement réutilisé.