独自の REST API ベースの AWS コネクタを構築する方法 | Mendix

メインコンテンツへスキップ

独自の REST API ベースの AWS コネクタを構築する方法

REST APIをテーマにしたグラフィック

Amazon Web Services (AWS) は、世界で最もよく知られているクラウド コンピューティング プラットフォームの 1 つであり、あらゆる規模の企業に幅広いツールとサービスを提供しています。小規模なスタートアップ企業から大企業まで、多くの企業がインフラストラクチャ、アプリケーション、データの管理に AWS を利用しています。

しかし、AWSを他のシステムと統合することは、専門知識と技術的な熟練度を必要とする困難なプロセスになる可能性があります。 Mendix に入っています。

開発者は、既存のコネクタを簡単に利用したり、AWSサービスを他のアプリケーションやシステムと統合する新しいコネクタを構築したりできます。 Mendixの効率的なローコード開発プラットフォーム。

「AWSは、 Mendix 「AWSプラットフォームは、AWSサービスの変革力を認識しています」と、元CEOのティム・スロック氏は語った。 Mendix7年間にわたる戦略的関係の成功により、 Mendix とAWSは、 市場開拓関係の拡大.

AWSとのパートナーシップの詳細については、プレスリリースをご覧ください。 こちら

AWSを使用すると Mendix ユーザーはAWSが提供する自動化された手順とサービスを活用でき、自分で開発する必要がなく、時間と労力を節約できます。 AWSコネクタ Mendix、AWS内で利用可能な膨大な数のサービスを、コードも労力も少なく簡単に利用できるようになります。AWSコネクタを Mendix AWSリソースにアクセスする必要があるカスタムアプリを開発する場合でも、LambdaやS3などのAWSツールを使用してビジネスプロセスを自動化する場合でも、AWSを使用すると、運用を効率化し、組織全体の生産性を向上させることができます。AWSサービスをアプリケーションにすぐに統合できるように、REST APIベースのAWSコネクタを作成する手順を説明します。 Mendix.

スタートガイド

使用したいAWSサービスに既存のコネクタがないことが判明した場合、 Mendix マーケットプレイスでの最初の反応は通常、「わかりました。つまり、このソリューションは現在 Mendix」または「この問題を回避する方法を見つける必要があります。」

私はAWSチームの一員です Mendix 今はそう思っていませんが、始める前は、これが私の最初の反応でもありました。AWSコネクタの構築がチームの目標だとわかってから、始めた後も、私は圧倒されていました。「AWSのサービスが多すぎて、それぞれのアクションが多すぎる。どうやって需要に応えればいいのだろう?」と考えていたのを覚えています。これは、私がチームに加わったばかりの頃、コネクタの構築は世界を救うようなものだと思っていたときの考えでした。つまり、非常に難しいのです!しかし、それはまったく違います。AWSコネクタの構築は、私たち全員が取り組んでいることです。 Mendix 開発者は、当社のハウツーガイドから少し助けを得ることができます。

できるだけ早く新しいAWSコネクタを構築する必要があると判断した場合は、その方法を調べるために検索を行ったことがあるかもしれません。そこで、AWSコネクタを構築するために利用できる統合方法が2つあることに気付いたかもしれません。 Mendix、つまり、表現型状態転送(REST)アプリケーションプログラミングインターフェース(API)またはソフトウェア開発キット(SDK)です。プログラミングの経験がない方は、SDKという言葉を読んだだけでぞっとするかもしれません。実際には、そのプロセスは(私も含めて)人々が頭の中で想像するほど複雑ではなく、完全に実行可能です。しかし、 Mendix 開発者の皆さん、私たちがすでに使い慣れているものを使用して、REST API ベースの AWS コネクタを構築してみませんか? やってみませんか?

ここに、私によるステップバイステップのガイドがあります。

REST API ベースの AWS コネクタの構築

まず知っておくべきことは、すべてのAWSサービスとアクションにAPIがあるわけではないということです。つまり、REST APIベースのAWSコネクタを使い始める前に、必要なサービスとアクションにAPIがあるかどうかを確認し、必要なHTTPヘッダー( x-amz-ターゲット 値)。必要なサービスとアクションの API がない場合、残念ながら、続行する唯一の方法は、SDK を使用してコネクタの構築を開始することです。

一部のサービスとアクションについては、それぞれのAWSサービスの開発者ガイドにAPIが記載されています(例: Amazon Translate で署名バージョン 4 を使用する – Amazon Translate)。しかし、他の人にとっては、それはより難しい検索です。私が役に立つと思ったウェブサイトは AnyAPI (any-api.com)。 あなたは行くことができます 検索API エリアで、作業したいAWSサービスの名前を検索し、それをクリックすると、APIを持つサービスのアクションのリストと、その x-amz-ターゲット 存在する場合は値。

AnyAPI検索結果

私たちが実施するのは、 AWSコネクタを構築する 記事と関連リンクをご覧ください。いくつかのトピックのより詳しい説明については、記事も参照してください。

このシナリオでは、Amazon Translateコネクタがマーケットプレイスに存在しないが、顧客プロジェクトに必要なコネクタであると想定しています。私たちは、そのアクション(APIを持つ)の一部を使用するためにAWSコネクタを構築することを決定し、実装します。 翻訳テキスト をご利用ください。

プロジェクトの開始

コネクタの作業を開始するには、まず適切な環境を準備する必要があります。

In Mendix Studio Proでは、新しいモジュールを作成します AmazonTranslateコネクタ.

次にインストールして設定します AWS 認証コネクタ (バージョン 3.0.0 以上) Amazon Web サービスで認証するために必要なためです。

AmazonTranslateコネクタ モジュールでは、以下に示すようなフォルダー構造を適用します。

AmazonTranslateConnector モジュールのフォルダ構造
ドメインモデルに必要なエンティティを追加し、構築を開始する

作業環境の準備ができたら、実装するアクション、特に REST API のリクエストに必要なものと、その応答として受け取るものについて詳しく学習します。

実施したいアクションの詳細については、 AWS ドキュメント (amazon.com).

AWS ドキュメント検索

そこには、現在取り組んでいるAWSサービスのドキュメントがあります。私たちの場合は、 Amazon Translate ドキュメント.

AWS の Amazon Translate ドキュメント

AWSコネクタの開発中に役立つ2つのガイドを紹介します。REST APIベースのコネクタを構築しているので、 Amazon Translate API リファレンス – Amazon Translate API リファレンス、次に開きます TranslateText – Amazon Translate API リファレンス.

TranslateText Amazon Translate API リファレンス

このページでは、リクエストとレスポンスの構文、それらのパラメータの詳細、発生する可能性のある一般的なエラーなど、実装したいアクションに関する貴重な情報が多数見つかります。

これから実装するアクションについてさらに詳しく読んだ後、まずは 翻訳テキスト 対応するエンティティをモデル化するアクション。

AWS 認証コネクタがバージョン 3.0.0 にアップグレードされて以来、他のすべての AWS コネクタのリクエスト エンティティは AWSAuthentication.AbstractRequest エンティティから継承することがベスト プラクティスとなっています。また、タイムアウト設定は、関連付けられた BasicClientConfig オブジェクトで指定する必要があります。これは、コネクタをマーケットプレイスに公開する場合に特に重要です。

ただし、この例では、最も簡単な方法を採用します。したがって、継承を使用したり、タイムアウト設定を指定するための BasicClientConfig オブジェクトを作成したりすることはありません。
まず、リクエストエンティティを作成し、AWS ドキュメントのリクエストボディを確認してみましょう。便利なことに、TranslateText アクションの構文に基づいてリクエストエンティティを生成できます。

JSON スニペット フォルダに、AWSサービスにちなんで名付けられたJSON構造ドキュメントを作成します。この場合は、 JSON_テキスト翻訳.

JSON構造ドキュメントの作成

ドキュメントを開いて、クエスト構文を貼り付けます。 TranslateText – Amazon Translate API リファレンス.

次にクリックします フォーマット適用された設定や用語についてはここでは気にしないので、それらの部分を削除して、 ソース言語コード, ターゲット言語コード, 翻訳されたテキスト クリックする前に Refresh の三脚と OK.

JSON構造ドキュメントのフォーマット

インポートマッピング フォルダにインポートマッピングドキュメントを作成し、名前を付けます IMM_テキスト翻訳 をクリックし OK.

インポートマッピングドキュメントの作成

私たちは開きます IMM_テキスト翻訳 文書。 スキーマソース セクション、選択します JSON構造を選択し、次に JSON_テキスト翻訳  の資料をご参照ください。

JSON_ListLanguagesドキュメントの選択

次に、クリックします すべて展開選択 すべてチェック、次いで OK.

 

Mendix Studio Proでは、AWSサービスとお客様のネットワークのマッピングを視覚的に表示します。 Mendix アプリケーション。場合によっては、役に立たないエンティティが生成されることがあります。インポート マッピング ドキュメントを再度開き、不要なエンティティのチェックを外して削除します。この場合は、不要なエンティティは作成されていないため、次に進みます。

これが完了したら、クリックします 自動的にマップ. Mendix Studio Pro は、ドメイン モデルで AWS サービス応答がマッピングされるエンティティを作成します。この場合、インポート マッピングは次のようになります。

自動的にマッピングした結果

次に、ドメイン モデルに移動して、作成したエンティティの名前を TranslateText アクションに合わせて変更します。便利なことに、API ドキュメントから、関心のある応答内の属性はリクエストと同じであることがわかります。したがって、新しく作成した TranslateTextRequest をコピーして名前を変更するだけです。これで、2 つのエンティティは次のようになります。

 

テキスト翻訳リクエストの例

後で TranslateTextRequest オブジェクトもエクスポートする必要があります。準備として、インポート マッピング IMM_TranslateText と同じ方法でエクスポート マッピング EXM_TranslateText を作成します。ドメイン モデルの準備ができたら、マイクロフロー アクションの作成に進むことができます。ただし、その作業を開始する前に、認証に必要な定数を簡単に追加します。
アプリケーション設定で、AWS 認証コネクタの定数値を変更します。以下の画像に示すように、静的と一時の 2 つのタイプに必要な定数は、コネクタの ConnectionDetails セクションにリストされています。

 

AWS認証メニューのスクリーンショット

これで、マイクロフローの作業を開始できます。

業務執行統括 フォルダにマイクロフローを作成します POST_v1_テキスト翻訳、による Mendix 命名規則。

Hubspot TranslateText – Amazon Translate API リファレンスこのアクションのリクエストには、次の 3 つの必須パラメータがあります。 ソース言語コード, ターゲット言語コード, テキスト、これは翻訳したいテキストです。そこで、これらのパラメータのためにマイクロフローに3つの入力パラメータを追加し、文字列変数を作成します。 リクエストボディ アクションリクエストを準備します。

リクエスト エンティティを作成したので、それを唯一の入力パラメータとして使用できます。

次に、 一時認証情報を取得する または 静的認証情報を取得する マイクロフローから AWS 認証モジュール 認証情報を取得します。この実装では静的認証情報を使用するため、GetStaticCredentials マイクロフローを追加します。認証情報オブジェクトを作成するために必要なすべての情報は、AWS 認証コネクタに入力した定数から入力されます。

これでリクエストとAWS認証情報の両方が揃いました。ただし、RESTサービスを呼び出す前に、署名バージョン4を使用して認証情報をリクエスト呼び出しに追加する必要があります。 SigV4ヘッダーを取得する からの操作 AWS 認証 モジュールです。そのためには、まず新しいSigV4Builderオブジェクトを作成します。 新しいSigV4ビルダー メンバーを入力してください。ベストプラクティスに従って、翻訳サービスが利用可能な、お住まいの地域に最も近い地域を選択してください。

オブジェクト作成画面のスクリーンショット

次に、リストを作成します SigV4パラメータ 呼ばれるオブジェクト ヘッダーリスト 入力パラメータとして必要な重要なヘッダーが2つあるため、 SigV4ヘッダーを取得する Java アクション。

最初のヘッダーでは、 SigV4パラメータ オブジェクト コンテンツタイプヘッダー 次のパラメータを使用します。

  • キーコンテンツタイプ
  • アプリケーション/x-amz-json-1.1

SigV4Parameterオブジェクトのリストを作成する

2番目のヘッダーでは、 SigV4パラメータ オブジェクト テキストアクションヘッダーを翻訳する を追加する x-amz-ターゲット 翻訳テキスト コネクタの作業を開始する前に発見したアクションです。

  • キーx-amz-ターゲット
  • AWSShineFrontendService_20170701.TranslateText

 

オブジェクト作成画面のスクリーンショット

これらのヘッダーを両方とも ヘッダーリスト 私たちが創り上げたもの。

さて、 SigV4ヘッダーを取得する マイクロフローへの操作と資格情報の使用により、 新しいSigV4ビルダー オブジェクトとリスト SigV4パラメータ オブジェクト ヘッダーリスト 入力パラメータとして、 SigV4ヘッダー オブジェクト。

Sigv4ヘッダーの取得画面のスクリーンショット

スコープ内で SigV4Headers オブジェクトを取得した後、TranslateTextRequest をエクスポートして RequestBody を JSON として取得します。これを行うには、マイクロフローに「マッピング付きエクスポート」アクションを追加します。次に、EXM_TranslateText マッピングと TranslateTextRequest オブジェクトを選択し、「RequestBody」という戻り変数を使用します。

必要な情報がすべて揃ったので、REST サービスを呼び出すことができるようになりました。そこで、マイクロフローに REST 呼び出しアクションを追加します。 所在地エンドポイントURL 返される属性 SigV4ヘッダー; タイムアウト デフォルトでは300msに設定されていますが、任意の整数値に変更することができます。 リクエストリクエストボディ マイクロフローの文字列変数。 コンテンツタイプヘッダー、 テキストアクションヘッダーを翻訳する、返されたヘッダー SigV4ヘッダー オブジェクトとして カスタムHTTPヘッダー REST 呼び出しにも同様に適用されます。

マイクロフローに呼び出しRESTアクションを追加する

私たちは、 世界の動き IMM_テキスト翻訳 ドキュメントを返します テキストレスポンスを翻訳する オブジェクト。

完成したマイクロフローは次のようになります (わかりやすくするために、SigV4Headers の生成はサブフローに統合されています)。

 

テキスト翻訳リクエスト画面のスクリーンショット

これで完了です。テキストを別の言語に翻訳できる新しい Amazon Translate コネクタが作成されました。このマイクロフローを簡単に再利用できるように公開することを忘れないでください。

言語を選択してください