1. ホームページ
  2. アクセラレーター

  3. 共通サービス

MuleSoft Accelerator の共通サービス

MuleSoft Accelerator は、ここでは「共通サービス」と呼ばれる多数の共通コンポーネントを利用します。これらのサービスを次に示します。

通知サービスとスケジューラーサービスは、独立したアプリケーションとして設定およびインストールできます。通知サービスは、選択された通知対象に応じて複数のアプリケーションで構成されます。API Manager を使用して 1 つ以上のセキュリティポリシーを適用できます。

共通スケジューラー

共通スケジューラーサービスは、スケジュールを実行し、API コールを実行する省略可能なコンポーネントです。共通スケジューラーサービスを使用する利点は、すべてのインテグレーションレベルのスケジュールを 1 か所で管理できることです。スケジューラーサービスのしくみの概要を次に示します。

accel-scheduling-service-diagram.png

このサービスは、対象デプロイメントプラットフォームに応じて 2 つの異なる方法で構築されます。Anypoint Platform は、スケジュールを処理するときに、CloudHub にデプロイされたアプリケーションに運用上の利点をもたらします。

ワークフローの概要

スケジューラープロセスのワークフローの概要を以下に示します。

  1. 定義済みのスケジュールがトリガーされます。スケジュールには、​SCHEDULE_TYPE​ や WATERMARK など、最後の実行に関する豊富な情報があります。

  2. スケジュールサービスは、このイベント用に設定されたジョブをコールし、スケジュールの状況を現在のタイムスタンプで「TRIGGERED」に更新します。トリガー ID とコールバック URL が生成されます。

  3. プロセスが完了すると、コールバック URL を介してスケジュール状況サービスへのコールバックが実行され、実行状況が報告されます。

サービス設定についての詳細は、​「使用開始」​ガイドおよびサービス自体の実装テンプレートを参照してください。

通知サービス

このソリューションでは、省略可能な通知プロセス API が提供されます。この API は、通知イベントをコンシュームし、SMS、メール、または Slack 経由で、これらのサービスに固有のシステム API を介して個人またはグループに通知を送信します。設計の概要を以下に示します。

accel-notification-service-diagram.png

ご覧のとおり、API はコール元のアプリケーションをブロックいないように、受信要求をキューに直接オフロードします。

ワークフローの概要

通知プロセスのワークフローの概要を以下に示します。

  1. モジュールが通知プロセス API をコールし、次の情報を提供します。

    • NOTIFICATION\_TYPE​  — メール、SMS、Slack のいずれか

    • NOTIFICATION\_ADDRESS​ — 宛先アドレス/番号

    • NOTIFICATION\_MESSAGE​ — 通知メッセージのテキスト

  2. API はダウンストリーム処理のためにメッセージをキューに配置し、すぐに成功応答を返します。

  3. キューサブスクライバーはメッセージを受信し、​NOTIFICATION\_TYPE​ に基づいて適切なシステム API に転送します。

  4. システム API はメッセージを同期的に処理し、バックエンドサービスにポストします。

サービス設定についての詳細は、​「使用開始」​ガイドおよび個々の RAML 仕様と個々のサービス自体の実装テンプレートを参照してください。

セキュリティサービス

ほとんどの API は、セキュアな通信のためにデフォルトで HTTPS プロトコルを使用します。ソリューションによって提供される API は、API Manager で​クライアント ID 適用​ポリシーを適用することによって保護することもできます。​基本認証​ポリシーもサポートされています。

CloudHub ロードバランサーと HTTPS

API エンドポイントを公開したり、他の API をコールしたりするアプリケーションは、HTTPS プロトコル経由でそれらを実行します。デプロイメントを簡素化するために、リスナーは ​accelerator-common-core​ ライブラリによって提供される自己署名証明書を使用します。このアプローチは、対象デプロイメントリージョンで共有 CloudHub ロードバランサーを使用する場合には正常に機能しますが、専用ロードバランサーで実行されている場合は通常、証明書を置き換える必要があります。

API Manager ポリシーを適用する方法

このセクションでは、デプロイされた API の​クライアント ID 適用​ポリシーを有効にする手順について説明します。

続行するには、組織の Anypoint サブスクリプションに API Manager が含まれている必要があります。

管理 API インスタンスの作成

管理 API インスタンスを作成する最も簡単な方法は、既存の Exchange アセットを使用することです。手順は次のとおりです。

  1. API RAML Definition (API RAML 定義) アセットを MuleSoft Exchange からダウンロードし、独自の Exchange インスタンスにアップロードします。必ず正しいビジネスグループを選択してください。

  2. API Manager で、同じビジネスグループを選択し、対象環境を選択します。​[Manage API (API を管理)]​ ボタンをクリックし、​[Manage API from Exchange (Exchange から API を管理)]​ オプションを選択します。

  3. [API Name (API 参照名)]​ 項目に、管理する API の名前を入力し始めます。アセットタイプとバージョン項目に自動的に値が入力されます。

  4. [Mule version (Mule バージョン)]​ オプションまでスクロールダウンし、有効にします。​[Implementation URI (実装 URI)]​ 項目のコンテンツをクリアします。

  5. 後で API を見つけやすくするため、​[Advanced options (詳細オプション)]​ セクションを展開し、​[Label (表示ラベル)]​ 項目に API の完全な表示名 (​「Accelerator Jira Experience API (アクセラレーター Jira エクスペリエンス API)」​など) を入力します。

  6. [Save (保存)]​ をクリックして API インスタンスを作成します。概要ページで、​[Autodiscovery (自動検出)]​ 表示ラベルの下にある ​API ID​ 値をコピーします。

API へのアクセス権の要求

Exchange で API アセットを見つけ、アセットページの右上隅にあるメニュー (「3 つのドット」メニュー内にある場合があります) から ​[Request access (アクセス権の要求)]​ オプションを選択します。前に作成した API を選択し、使用するアプリケーションを選択 (必要に応じて作成) します。 必ずクライアント ID とクライアントシークレットの値をコピーしてください。

ローカルの Maven ​settings.xml​ ファイル (アクセラレーターデプロイメント専用に設定したファイル) で、上記でコピーした値を使用して、対象デプロイメントプロファイル (​CloudHub-DEV​ など) の ​accelerator-api.client-id​ プロパティと ​accelerator-api.client-id​ プロパティの値を設定します。

セキュリティを強化するには、API コンシューマーごとに個別のアプリケーションを作成します。API 間のコールの場合、各クライアント ID/シークレットのペアをデプロイメントプロファイルに追加し、コンシュームする API の ​pom.xml​ ファイル内のプロパティ名参照を更新する必要があります。

アプリケーションでの API Manager のサポートの有効化

各アプリケーションには、実装している API ID に対応する設定要素が含まれている必要があります。アクセラレーターアプリケーションには、このサポートがすでに含まれています。次のように更新するだけです。

  1. 実装プロジェクトで、​src/main/mule​ フォルダー内にある ​global.xml​ ファイルを開きます。

  2. エディターが開いたら、​[Configuration XML (設定 XML)]​ タブを選択して XML ソースを表示します。

  3. api-gateway:autodiscovery​ 要素を見つけてコメントを解除します。値はそのままにしておきます。

  4. src/main/resources/config​ フォルダー内にある対象デプロイメント環境を表すプロパティファイル (​config-dev.yaml​ など) で、​autodiscoveryID​ プロパティを見つけて、上記の ​API ID​ 値からコピーした値に設定します。必ず二重引用符を保持してください (これはすべての YAML 設定プロパティに適用されます)。

  5. 更新されたアプリケーションをデプロイし、ログファイルを監視します。​「Your application is started (アプリケーションが起動しました)」​というメッセージの直前に、次のようなメッセージが表示されます。

    API ApiKey{id='16422525'} is now unblocked (available).

  6. API Manager の API インスタンスの状況が「Available (使用可能)」と表示されていることを確認します。

ポリシーの適用

次の手順では、​クライアント ID 適用ポリシー​を特定の API に適用する方法について説明します。

  1. API Manager で、ポリシーを適用する API を見つけ、バージョンの表示ラベルをクリックして API 設定ページを表示します。

  2. 左側のナビゲーションメニューから ​[Policies (ポリシー)]​ 項目を選択し、​[Apply New Policy (新しいポリシーを適用)]​ ボタンをクリックします。

  3. 最新バージョンの​クライアント ID 適用​ポリシーを選択し、​[Configure Policy (ポリシーを設定)]​ をクリックします。

  4. ポリシーの設定ページで、​[Credentials origin (ログイン情報の取得元)]​ 設定の ​[HTTP Basic Authentication Header (HTTP 基本認証ヘッダー)]​ オプションを選択します。

  5. [Apply (適用)]​ ボタンをクリックしてポリシーを作成し、API に適用します。

しばらくしてからポリシーが有効になります。

自動ポリシー

すべての API にポリシーを適用する簡単な方法は、自動ポリシーとしてデプロイすることです。既存のアプリケーションは更新され、新しいデプロイメントではポリシーが自動的に取得されます。ポリシー自体を設定する手順は同じです。

関連情報