コミュニティ活動

もう一つの結果は Mendix AWSとのコラボレーションは、支援するために作成された豊富な知識とツールです。 Mendix 開発の旅におけるメーカーとAWSビルダー。この支援資料には以下が含まれます。 ブログ記事, 学習パス, 有益なビデオ, 実装例また、ステップバイステップのガイド、ベストプラクティス、ソリューションを作成するための実用的な洞察も含まれています。 Mendix AWS初心者向け Mendix.

その Mendix コミュニティはコンテンツの形成に重要な役割を果たしました。彼らはコンテンツに関するフィードバックを提供してくれました。 フォーラムは、成長と革新のための環境を作り、改善の余地を明らかにしました。コミュニティは、認証のために異なるコネクタ間で同じ認証情報を設定する必要があるなどの不満と、カスタムエンドポイントの呼び出しやHTTPタイムアウト設定のオーバーライドによるAWS Lambda関数の実行時間の延長などのアイデアの両方を自由に共有しました。これらのフィードバックはすべて、最近の AWS 認証コネクタ より幅広い AWS コネクタスイートにより、開発者エクスペリエンスが向上します。

アップグレードと機能強化

これらの変更の詳細についてさらに詳しく見ていきましょう。重大な変更点の包括的な概要を示し、検討内容を説明し、これらの変更が開発者のワークフローに与える影響について説明します。これらの洞察がよりスムーズで効率的な開発エクスペリエンスにつながることを願っています。

AWSコネクタスイートのアップデートと機能強化は技術的なアップグレードにとどまりません。 Mendix およびAWS。

これらの変更は、以前のバージョンのコネクタを使用するアプリケーションに影響します。これらの変更が何を伴うのか、また新しいバージョンにスムーズに移行する方法について詳しく説明します。

コンポーネントの集中化

最も注目すべき変更点は、接続詳細定数や認証情報オブジェクトを生成するためのマイクロフローなどの認証コンポーネントの集中化です。この変更により、認証定数とマイクロフローがコネクタモジュールではなく AWS 認証コネクタにあるため、更新されていないアプリケーションでエラーが発生します。これらのエラーは、AWS 認証コネクタにある接続詳細定数と認証情報生成マイクロフローを構成することで解決できます。

リクエストエンティティごとに

操作に以前にリクエスト エンティティがあったかどうかに関係なく、すべての操作をリクエスト エンティティを含むように標準化しました。この変更により、スイート全体で一貫性がもたらされます。アップグレード時に、以前にリクエスト エンティティがなかった操作でエラーが発生する場合があります。これらのエラーを解決するには、更新に合わせて新しく導入されたリクエスト エンティティのインスタンスを追加するだけです。

AbstractRequestエンティティからの継承

この変更は、すべての操作に対するリクエストエンティティの導入に基づいています。すべてのリクエストエンティティが AWS 認証コネクタの AbstractRequest エンティティから継承する新しい機能を組み込みました。この継承により、HTTP クライアント構成をオーバーライドする機能が可能になります。この変更は操作の標準化に一致していますが、以前はリクエストエンティティがなかった操作では、アップグレード中にエラーが発生する可能性があります。この移行により、アップグレードプロセス中に変更が必要になる可能性がありますが、コネクタの操作の動作を詳細に制御できるようになります。

AWS コネクタスイート全体の見直し

スイート内の各コネクタは、統一性と一貫性を確保するために全面的に見直されました。これらの更新により、AWS コネクタ スイート内のすべてのコネクタに重大な変更が導入されることに注意してください。必要な調整の数は、コネクタによって異なります。重要なのは、スイートの強化された標準と機能に合わせるために、アップグレードされたすべてのコネクタに AWS 認証コネクタ 3.0.0 が前提条件として含まれるようになったことです。

これらの変更と移行手順を理解することで、更新されたバージョンへのスムーズな移行が保証されます。これにより、メーカーは AWS Connector Suite の強化された機能を活用できるようになります。

AWS コネクタスイート全体の一元化

もう 1 つの変更点は、AWS コネクタ スイート全体のコンポーネントを、すべての AWS コネクタの前提条件となるモジュールである AWS 認証コネクタに集中させたことです。この変更の主な要素は次のとおりです。

AWS リージョンの列挙

どのモジュール固有のリージョン列挙を選択すればよいのか判断するのに苦労していた時代は終わりました。AWS リージョン列挙の一元化により、すべての AWS サービスリージョンのリストへのアクセスが簡素化されました。このリストを拡張して、より幅広い統合オプションに対応するために追加のリージョンを含めました。

これらの追加されたリージョンにより、コネクタが最新の AWS リージョンに更新され、開発者に AWS ワークフローの展開に関するより多くのオプションが提供されます。新しいリージョンは次のとおりです。

• アジア太平洋 – ハイデラバード (ap_south_2)
• アジア太平洋 – メルボルン (ap_southeast_4)
• ヨーロッパ – スペイン (eu_south_2)
• ヨーロッパ – チューリッヒ (eu_central_2)
• イスラエル – テルアビブ (il_central_1)
• 中東 – UAE (me_central_1)
• AWS GovCloud – 米国東部 (us_gov_east_1)
• AWS GovCloud – 米国西部 (us_gov_west_1)

認証定数

AWS 認証の設定に使用される接続詳細定数を一元管理しました。これはコミュニティからのフィードバックによる変更です。コミュニティでは、複数の定数セットを設定する必要があると、開発中に不要な設定オーバーヘッドが発生するという意見が寄せられました。新しいアップデートでは、これらの定数を AWS 認証コネクタに再配置することで、この問題を解消しています。これにより、認証情報の再利用性が促進されると同時に、複数の認証情報セットを設定する可能性も維持されます。

認証ワークフローも見直しました。これまで認証に使用されていた定数「UseStaticCredentials」を削除しました。認証情報エンティティに対する新しいアプローチは、AWS のプラクティスとより一致するようになりました。

静的認証は変更されていません。ただし、一時的な認証については、Credentials オブジェクトの特殊化である TemporaryCredentials エンティティを導入しました。これは AWS の命名規則を反映するだけでなく、認証に関する懸念事項のより明確で改善された分離を確立します。

さらに、AWS コネクタ スイートでは、これまで使用されていた「セッション ベースの認証情報」ではなく、「一時的な認証情報」という用語を採用しています。この用語は、AWS エコシステム内でより広く認識され、採用されています。このアプローチは、AWS 標準との同期を維持し、メーカー向けコネクタの明確さと一貫性を高めるという当社の取り組みを体現しています。

有効な資格情報を生成するためのすぐに使えるマイクロフロー

以前は、コネクタ アクションには、アクション自体のフロー内に資格情報オブジェクトを作成するロジックが含まれていました。ただし、このアプローチは進化し、現在では入力パラメータとして資格情報オブジェクトが必要になっています。新しいコネクタで既に採用されているこの変更により、カスタマイズされた資格情報管理が可能になり、柔軟性が向上します。

最新のアップデートでは、すべてのコネクタアクションをこのアプローチに標準化しました。その結果、各 AWS コネクタに存在していたすべての認証情報生成マイクロフローが、静的認証と一時認証の 2 つの異なるマイクロフローとして AWS 認証コネクタに一元化されました。この分離により、よりきめ細かな制御が可能になり、開発者は開発中の迅速な認証には静的認証情報を選択し、実稼働環境での安全で短期的なアクセスには一時認証情報を選択できます。

これらのコンポーネントを AWS 認証コネクタ モジュールに集中させることで、再利用性と効率性が向上します。特に、各コネクタには既に AWS 認証コネクタが必要なためです。コミュニティからのフィードバックを基にしたこのアプローチは、複数の AWS コネクタを持つプロジェクトで重複する定数セットを管理するという問題点に対処し、よりスムーズで統一された開発プロセスを保証します。

HTTP クライアント構成の上書き

AWSコネクタスイートを開発する際には、ネイティブのSDKではなくAWSソフトウェア開発キット（SDK）を使用しました。 Mendix RESTサービスを呼び出す アクティビティ。このアプローチは、AWS 統合の処理効率を優先します。SDK がこれらのタスクを自動化するため、HTTP ヘッダーのカスタマイズやリクエストの署名の複雑さが解消されます。さらに、再試行ロジックやスロットリング管理などの組み込み機能も提供されます。この基盤により、SDK HTTP クライアント構成のオーバーライドについて議論する準備が整い、開発者がアプリケーションの動作をより細かく制御できるようになります。

SDK の HTTP クライアントのデフォルト設定を上書きする

デフォルトの HTTP クライアント設定が原因で AWS Lambda 関数がタイムアウトするなどの課題に対処するために、カスタマイズ可能な HTTP クライアント構成を導入しました。各コネクタアクションには、AbstractRequest エンティティから継承するリクエストエンティティがあります。デフォルトの HTTP 構成をオーバーライドするには、メーカーは (サブ) タイプ BasicClientConfig のオブジェクトに属性を設定し、コネクタアクションを呼び出す前にそれをリクエストに関連付けます。

使用例には次のようなものがあります:

• AWS Lambda 関数など、実行時間が長くなる可能性のある操作に対応するために、タイムアウト設定を拡張します。
• 再試行メカニズムをカスタマイズして、失敗した AWS サービスリクエストからクライアントが回復する方法の動作を変更します。
• 呼び出しエンドポイントのオーバーライド (ローカルでのテストなどのユースケースに必要)、AWS サービスのセルフホストインスタンスとの統合、VPC エンドポイント (プライベートクラウド) の呼び出し。

これらの機能強化により、制御性と柔軟性が向上し、メーカーはコネクタを特定のアプリケーションのニーズに合わせてカスタマイズできるようになります。

アドオンから通常のモジュールへの移行

「アドオンモジュールとは何ですか？」や「なぜコネクタモジュールがマーケットプレイスモジュールの下に見つからないのですか？」などのコメントは、一部のAWSコネクタのモジュールタイプに関する典型的な質問です。アドオンモジュールは、 Mendix IP 保護やバンドルされた依存関係などの機能を提供し、標準モジュールとは異なるアドオン モジュールです。AWS Connector Suite の開発でアドオン モジュールの独自の機能をどのように活用したかを見てみましょう。

アドオン モジュール

1年前、Amazon Polly Connectorをアドオンモジュールとしてパイロットフェーズでリリースしました。スイート全体をアドオンモジュールとして展開する可能性を評価することが目的でした。アドオンモジュール（.mxmodule拡張子）はコネクタの依存関係をまとめたもので、ライブラリの競合を避けるのに最適です。しかし、 Mendix' 管理された依存関係 機能で Mendix Studio Pro 10.3 では、この懸念は関係なくなりました。

通常モジュールへの移行

新しい依存関係管理機能のおかげで、通常のモジュールの使用への移行を完了することができました。この移行により、開発プロセスが簡素化されるだけでなく、これらのコネクタは AWS 統合を構築しようとしている人にとってのリファレンスとしても機能します。

通常のモジュールに移行すると、カスタマイズの可能性が広がり、 Mendix AWS 上でアプリケーションを構築するための最も高速かつ簡単なプラットフォームです。

結論

要約すると、AWS Connector Suite のこのアップデートにより、機能性と使いやすさが向上します。

• コンポーネントを AWS 認証コネクタに集中させることで、冗長性が削減され、コンポーネントの再利用性が強化され、開発プロセスが合理化されます。
• カスタマイズ可能な HTTP クライアント構成の導入により、延長されたタイムアウト設定やカスタマイズされた再試行メカニズムなどの側面を含め、AWS 統合に対する制御が強化されます。
• アドオンから通常のモジュールへの移行により、開発が簡素化され、カスタマイズと統合の可能性が広がります。

これらの機能強化は、AWS統合エクスペリエンスを最適化するための継続的な取り組みにおいて大きな前進となります。これらの進歩により、 Mendix コミュニティは、AWS 上で堅牢で効率的かつスケーラブルなアプリケーションを構築するための準備がより整っています。

どのようにすれば、 Mendix AWS でアプリケーションを構築する最も速くて簡単な方法です。私たちは常にあなたのアイデアを聞き、あなたの懸念に対処し、あなたの開発の旅をサポートしたいと考えています。私たちはメッセージ 1 つで対応します。 [メール保護]上 Mendix コミュニティ Slack #aws-generalチャンネル、または Mendix フォーラム。