# mulesoft ホーム (general) - Full Documentation # Anypoint Platform の API 管理の使用開始 Anypoint Platform の API 管理は、あらゆる場所にビルドおよびデプロイされる API の管理と保護を行い、アプリケーション配信を迅速化したり、API スプロールに対処したりする新規および既存の製品のコレクションです。このエンドツーエンドの API ライフサイクルジャーニーの任意のフェーズ (魅力的なデジタルエクスペリエンスの設計およびビルド、検出、管理、保護、作成) で開始できます。 API 管理のエンドツーエンドの API ライフサイクルジャーニーは、さまざまなタスクで構成されます。それぞれのタスクには、タスクの完了を支援する関連コンテンツへのリンクがあります。
lm start

API 管理とは?

API 管理は、安全性と拡張性の高い環境でアプリケーションプログラミングインターフェース (API) を作成、パブリッシュ、監視するプロセスです。

API 管理は、開発者環境の改善とアプリケーションの成功につながる API の信頼性、安全性、使いやすさを確保するのに役立ちます。

lm analyze 1

検出

開発者コミュニティが API と関連するメタデータおよびドキュメントをどこでも自動的に検出できるようにします。

lm audience end 1

エンゲージ

API コンシューマーおよびプロデューサーのエコシステムとエンゲージするカスタム API Portal を作成します。

## 関連情報 - [Anypoint Code Builder](https://docs.mulesoft.com/jp/anypoint-code-builder/) - [Anypoint Monitoring](https://docs.mulesoft.com/jp/monitoring/) - [Anypoint Studio](https://docs.mulesoft.com/studio/) - [API カタログ CLI](https://docs.mulesoft.com/jp/exchange/apicat-about-api-catalog-cli) - [API Designer](https://docs.mulesoft.com/design-center/) - [API Experience Hub](https://docs.mulesoft.com/jp/api-experience-hub/) - [API 機能監視](https://docs.mulesoft.com/jp/api-functional-monitoring/) - [API Governance](https://docs.mulesoft.com/api-governance/) - [API Manager](https://docs.mulesoft.com/jp/api-manager/latest/) - [Exchange](https://docs.mulesoft.com/jp/exchange/) - [Flex Gateway](https://docs.mulesoft.com/gateway/latest/) - [Mule ゲートウェイ](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-capabilities-mule4) # Anypoint Platform のセキュリティ Anypoint Platform を使用して、アプリケーションネットワークのセキュリティを強化します。 - [アクセス管理ユーザーインターフェース](https://docs.mulesoft.com/jp/access-management/)​を使用してユーザー、グループ、環境、クライアントプロバイダー、ID プロバイダー、接続アプリケーション、外部アクセスのアクセス権を管理します。 [アクセス管理 API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/)​ を使用してプログラムでアクセス権を管理することもできます。 - [API Manager ユーザーインターフェース](https://docs.mulesoft.com/jp/api-manager/latest/latest-overview-concept)​を使用して API にポリシーを適用します。 - [Anypoint Monitoring ユーザーインターフェース](https://docs.mulesoft.com/jp/monitoring/)​を使用してサービス拒否攻撃などのセキュリティの問題がないか Anypoint Platform を監視します。 # Anypoint Platform のブラウザーサポート 次のサポート対象ブラウザーの最新バージョンで Anypoint Platform を使用します。 - Chromium を使用する Microsoft Edge - Chromium を使用しない Microsoft Edge (2020 年 12 月 31 日までサポート) - Google Chrome - Mozilla Firefox - Safari Anypoint Platform のブラウザーサポートは、Salesforce Lightning Experience のポリシーに準拠します。 ## [](#ブラウザーサポートポリシーの例外)ブラウザーサポートポリシーの例外 Partner Manager 2.0 では、ブラウザーサポートポリシーが異なります。 - [Partner Manager 2.0](https://docs.mulesoft.com/jp/release-notes/partner-manager/anypoint-partner-manager-2.0-release-notes#browser-compatibility) ## [](#サポートされていないブラウザー)サポートされていないブラウザー Internet Explorer バージョン 11 以前はサポートされていません。 Anypoint Platform でこのブラウザーを使用すると、問題が発生する可能性があります。 ## [](#関連情報)関連情報 [Lightning Experience でサポートされるブラウザー](https://help.salesforce.com/articleView?id=getstart_browsers_sfx.htm&type=5) # Anypoint Platform 価格設定 使用状況レポートページでは、​[インテグレーション](#https://www.mulesoft.com/anypoint-pricing)​の価格設定パッケージがサポートされます。組織が Anypoint Integration Advanced パッケージなど、使用量ベースの料金プランにオプトインしている場合、アプリケーションを再デプロイする必要があります。アプリケーションを再デプロイしたら、使用状況レポートが表示されます。 CloudHub と CloudHub 2.0 の場合は、毎月のランタイムパッチ更新サイクル中にアプリケーションが自動的に再デプロイされます。詳細は、​[CloudHub Runtime Continuous Updates](https://docs.mulesoft.com/cloudhub/cloudhub-app-runtime-version-updates) and [CloudHub 2.0 Operating System Patch Updates](https://docs.mulesoft.com/cloudhub-2/ch2-patch-updates)​を参照してください。 Runtime Fabric の場合、Anypoint Platform コントラクトへの準拠を保つには、アプリケーションを手動で再デプロイする必要があります。 ## [](#メトリクスの定義)メトリクスの定義 使用量ベースの価格設定パッケージと使用状況レポートは、組織での割り当て済み Mule コンポーネントの使用に基づきます。 Anypoint Platform 内の測定と価格設定の概念の技術的側面を理解するには、[使用量および価格設定メトリクスリファレンス](https://docs.mulesoft.com/jp/general/usage-metrics)ドキュメントを参照してください。 ## [](#グローバルリソースプールの制限)グローバルリソースプールの制限 使用量ベースの価格設定を使用してプロビジョニングされたルート組織では、組織のすべてのビジネスグループおよび環境で共有される、CloudHub および CloudHub 2.0 デプロイメント用の CPU およびメモリリソースのグローバルプールを受け取ります。このリソースのプールは十分な大きさがあり、中断なくすべての購入済みのフローおよびメッセージをコンシュームできます。 組織がリソースを使い果たすと、新しいアプリケーションのデプロイや停止されたアプリケーションの開始など、もっと多くのリソースをコンシュームするアクションは十分なリソースが使用可能になるまでブロックされます。使用されていないアプリケーションを停止または削除するか、既存のアプリケーションでコンシュームするレプリカサイズまたはリソースを削減することで、リソースを解放できます。 アプリケーションリスト UI、アプリケーションデプロイメント UI、アプリケーションの管理 UI では、組織がリソースの制限に近づくと、警告が表示されます。制限に達するのを防止するには、CloudHub および CloudHub 2.0 できめ細かいレプリカサイズを使用して、必要なリソースのみを割り当てるようにしてください。 リソースの制限に達した場合の例外が必要な場合は、サポートにお問い合わせください。
この制限は、Configuring Horizontal Autoscaling (HPA) for CloudHub 2.0 Deploymentsを使用して設定されたアプリケーションには影響しません。グローバルリソースの制限に達しても、水平ポッド自動スケーリングが有効になっている場合は、引き続きアプリケーションをデプロイできます。
## [](#cloudhub-2-0-アプリケーションのデプロイメント)CloudHub 2.0 アプリケーションのデプロイメント 使用量ベースの価格設定パッケージを使用してプロビジョニングされた組織の場合、CloudHub 2.0 では、アプリケーションのデプロイメントにレプリカサイズを使用します。アプリケーションのプロファイルまたはサイズに基づいてレプリカサイズを選択し、従来の vCore に関連して同等のものを表示できます。サフィックス ​`.mem`​ が付いたレプリカサイズは、同じ計算を使用するメモリ負荷の高いオプションです。
製品 同等の vCore サイズ メモリ合計 ヒープメモリ ストレージ

mule.nano

0.05

1 GB

0.5 GB

8 GB

mule.micro

0.1

1 GB

0.5 GB

8 GB

mule.micro.mem

0.1

2 GB

1 GB

8 GB

mule.small

0.2

2 GB

1 GB

8 GB

mule.medium

0.5

3 GB

1.5 GB

10 GB

mule.medium.mem

0.5

5 GB

2.5 GB

10 GB

mule.large

1

4 GB

2 GB

12 GB

mule.large.mem

1

8 GB

4 GB

12 GB

mule.xlarge

2

7 GB

3.5 GB

20 GB

mule.xlarge.mem

2

12 GB

6 GB

20 GB

mule.2xlarge.mem

4

15 GB

7.5 GB

20 GB

毎月のパッチサイクル中に、アプリケーションは自動的に同等のレプリカサイズに移行されます。 ## [](#アクセス管理のエンタイトルメント)アクセス管理のエンタイトルメント 使用量ベースの価格設定パッケージを使用してプロビジョニングされたアカウントでは、vCores ではなくアクセス管理のフロー、メッセージ、スループットのエンタイトルメントが表示されます。これらのエンタイトルメンは、ルート組織レベルでのみ使用できます。vCore は購入済みエンティティではなくなったため、ビジネスグループ間で追跡したり割り当てたりすることはできません。フロー、メッセージ、スループットの毎月の使用状況を表示するには、アクセス管理 UI で​[使用状況レポートにアクセス](https://docs.mulesoft.com/jp/general/usage-reports#access-usage-reports)​してください。 ## [](#関連情報)関連情報 - [使用状況レポート](https://docs.mulesoft.com/jp/general/usage-reports) # Anypoint Platform 用語集 一部の製品名の正式な省略バージョンは括弧に入れて示しています。例: Anypoint Design Center (Design Center)。 ## [](#a)A アクセス管理 アカウントを管理して組織内のアクセス権および権限を設定するのに役立つ Anypoint Platform の機能。REST API ではアクセスに関連したリソースをプログラムにより制御できます。 エージェント Runtime Manager エージェントのように、Mule が使用するか Mule に関連付けられているが、Mule の管理対象サービスコンポーネントではないサービス。エージェントは Anypoint Runtime Manager に登録され、対応する Mule インスタンスと同じライフサイクルになるため、Mule インスタンスを開始または停止したときにリソースを初期化して破棄することができます。 Anypoint CLI Anypoint Platform と Anypoint Platform Private Cloud Edition (Anypoint Platform PCE) のスクリプトおよびコマンドラインツール。 Anypoint Design Center (Design Center) Mule Runtime Engine (Mule) アプリケーションおよび API 定義のクラウドベースの開発環境。 Anypoint Design Center API Designer (API Designer) API をデザイン、ドキュメント化、テストするための Web ベースのグラフィカル環境。 Anypoint Exchange (Exchange) 再利用可能なアセット (API、ポリシー、API 仕様フラグメント、API グループ、GraphQL API、テンプレート、サンプル、カスタムアセット、ルールセット、コネクタなどのインテグレーションアセット) の選定されたカタログ。 Anypoint Flex Gateway 実行されている場所を問わずに API を管理して保護するように設計された、Envoy ベースの超高速かつ軽量の API ゲートウェイ。 Anypoint Management Center (Management Center) オンプレミスとクラウドの両方で Anypoint Platform を管理するための単一の Web インターフェース。API およびユーザーを管理し、トラフィックを分析して、SLA を監視し、基になる統合フローをトラブルシューティングできます。 Anypoint MQ (メッセージングキュー) Anypoint Platform と完全に統合されたエンタープライズクラスのクラウドメッセージング。 Anypoint Object Store v2 データ、バッチプロセス間の状態、単一アプリケーション内の Mule コンポーネントのストレージ。 Anypoint Partner Manager v2 パートナー設定、ドキュメントフロー、トランザクション監視用の Web ベースのユーザーインターフェース。 Anypoint Platform™ API および統合をデザイン、ビルド、管理するための MuleSoft 製品。 Anypoint Platform Private Cloud Edition 独自のローカルサーバーで実行するために使用できる Anypoint Platform の専用パッケージ。この実装は Docker および Kubernetes で実行され、Pivotal Cloud Foundry と互換性があり、Runtime Manager、API Manager、Anypoint Exchange のバージョンが含まれます。 Anypoint Runtime Fabric Mule アプリケーションおよびゲートウェイの設定、調整、管理 (オーケストレーション)、デプロイメントを自動化するコンテナサービス。Runtime Fabric は AWS、Azure、仮想マシン (VM)、またはベアメタルサーバーの顧客の管理対象インフラストラクチャで実行されます。 Anypoint Runtime Manager (Runtime Manager) Mule を使用してビルドされたアプリケーションをデプロイして管理するコンソール。クラウドのサーバー (現在のところ CloudHub によって処理される) にデプロイするか、オンプレミスでデプロイします。Anypoint Platform のコンソールにアクセスするか、ローカルサーバーで実行されるスタンドアロンプログラムとしてダウンロードします。以前は ARM と呼ばれていました。 Anypoint Security アプリケーションネットワークを保護する機能のレイヤー。 これらのレイヤーは連携し、API へのアクセスを制御したり、ポリシーを適用したり、すべてのインバウンドトラフィックまたはアウトバウンドトラフィックをプロキシしたりして、アプリケーションネットワークとネットワークの個々のノードの両方を保護します。これにより、外部の脅威や攻撃が軽減されます。 Anypoint Studio (Studio) Mule アプリケーションをデザイン、デバッグ、テストするためのビジュアルエディターと XML エディターを備えた統合開発環境。ビジュアルインターフェースを使用すると、コネクタ、ロガー、フローコントロール、ルーター、データトランスフォーマーなどをデザインキャンバスにドラッグアンドドロップできます。Studio ユーザーインターフェースからデバッグおよびテストすることもできます。 Anypoint Virtual Private Cloud (Anypoint VPC) Mule の CloudHub インスタンス (CloudHub ワーカー) をホストするためにクラウドで仮想、非公開、隔離ネットワークセグメントを作成できる機能。 Anypoint Visualizer アプリケーションネットワークグラフのさまざまなアスペクトの動的に生成されるビュー。 API すべての側面を含む API 全体。Anypoint Platform では、管理する製品のコンテキストでは API の側面が単に API と呼ばれることもあります。たとえば、Exchange では、API が API の仕様、ドキュメント、カタログを指す場合があります。API Designer では、API が API 仕様を指す場合があります。API カタログでは、API が API のインスタンス、ポリシー、コントラクトを指す場合があります。 API の側面 API の各部。API の側面の例としては、仕様、インスタンス、カタログ情報、ドキュメントなどがあります。 API カタログ情報 名前、バージョン、オーナー (コンタクト)、タグ、カテゴリなど、API カタログの API のエントリに関連したプロパティ。 Anypoint Exchange では、これらのプロパティはアセットポータル情報で API アセットに関連付けられています。 API 準拠 API 準拠は、検証済み API が 1 つ以上のガバナンスルールセット内のすべての必須ルールに合格するかどうかを示します。複数のプロファイルが API を対象とする場合、その API が準拠するは、それらすべてのプロファイルのすべてのルールセットに合格する必要があります。 API 準拠は、REST API や AsyncAPI など、API Governance によってサポートされる API 種別のみに適用されます。 API ドキュメント コンシューマーが API について理解して使用するのに役立ち、例、ユースケース、チュートリアルなどのコンテンツが含まれています。 API 実装 API を機能させるための API 仕様の具現化。 API インスタンス API 実装のインスタンス化。API にはさまざまな環境やゲートウェイの複数のインスタンスを含めることができ、クライアントはこれらを使用して API コールを行うことができます。設定されていてもデプロイされていないインスタンスもこの側面の一部として取得されます。 インスタンスは、アップストリーム用の API のプロキシ、またはアプリケーションエンドポイントのいずれかです。 API 仕様 API の機能と予期される動作、そして設計の基本理念やサポートされるデータ型などの詳細を定義します。API 仕様にはドキュメントと API 定義が含まれ、人間とソフトウェアが読むことのできるコントラクトを作成します。 API Governance API にガバナンスルールを適用し、それらのルールへの準拠を監視できる、Anypoint Platform の部分。 API Manager API を管理、制御、保護できる Anypoint Platform の部分。 API Portal API を紹介してユーザーを呼び込むことができるアクセスポイント。 API プロキシ MuleSoft API への攻撃に対する保護のレイヤーを提供する Anypoint API Manager の機能。 コードを作成する必要はなく、UI を使用して API を管理できます。以前は API Gateway と呼ばれていました。 APIkit APIkit は Mule REST または SOAP API をビルドするためのツールです。以前は SOAPkit と呼ばれていました。 アプリケーションネットワーク API を通じてアプリケーション、データ、デバイスを接続するネットワーク。 ネットワークにより、他部署のコンシューマーがアセットを見つけて使用できます。 ## [](#c)C CloudHub クラウドでアプリケーションを管理するためのサービスとしての統合プラットフォーム。Runtime Manager コンソールを通じてアプリケーションをクラウドにデプロイする場合、CloudHub はバックグラウンドで使用されます。 クラスタリング ユニットとして機能し、ユニットとして管理できる Mule インスタンスのセットを使用すること。クラスターとは複数のノードで構成された仮想サーバーです。クラスターインスタンスはクラウドから管理できます。 コンポーネント 1. Anypoint Platform では、POJO、Spring Bean、Java Bean、または Groovy、Ruby、Python、JavaScript などの Mule を通じて渡されるメッセージを処理するためのビジネスロジックが含まれるスクリプトを指します。これらのコンポーネントは通常、メッセージ全体、またはペイロードのみを入力として受け入れます。メッセージプロセッサーチェーンの次の要素のメッセージペイロードとなるオブジェクトを返します。 2. 通常は、ソフトウェアパッケージのアーキテクチャ的に固有の部分です。 設定ビルダー 設定ファイルを解析するクラス。デフォルトの設定ビルダーは ​`org.mule.config.MuleXmlConfigurationBuilder`​ クラスであり、Mule XML 設定ファイルを解析します。 コネクタ Mule アプリケーションを Salesforce、CMIS、Twitter などの他の外部アプリケーションの API と統合するための自己完結型コンポーネント。コネクタのセットが Mule 4 に含まれています。MuleSoft またはサードパーティが作成した他のコネクタは Anypoint Exchange で入手できます。 コントロールプレーン ネットワーク管理へのプログラムによるアクセス。Anypoint Platform では、コントロールプレーンは Anypoint Design Center、Anypoint Management Center、Anypoint Exchange で構成されます。 ## [](#d)D dataloader.io Salesforce 用のデータローダー。 DataSense アプリケーションのデザインを容易にするためにメッセージメタデータを使用する Anypoint Studio の機能。DataSense を使用して、Anypoint Studio はデータ型や構造などの情報をあらかじめ取得し、アプリケーションでこのデータを正確にマップまたは使用する方法を指示できるようにします。 DataWeave DataWeave 言語は統合のためにデータを照会して変換します。 ## [](#e)E Edge エッジセキュリティを管理するための Anypoint Security 機能。 ## [](#f)F フロー Mule アプリケーション内では、フローは、Mule イベントで Mule Runtime によって順次実行される、コネクタ操作を含む実行可能なコンポーネントのブロックです。フローには、イベントの作成とフローの実行をトリガーするイベント取得元も含めることができます。 ## [](#g)G 管理対象 API API は、少なくとも 1 つのガバナンスプロファイルの選択条件によって識別された場合に管理されます。API が管理されている場合、その API のすべてのバージョンが 1 つの管理対象 API とみなされます。サブスクリプション制限は、組織の購入済みの容量に基づいて設定されます。UI には使用量に関する情報が表示され、サブスクリプション容量に近づいたり超えたりしたときにアラートが表示されます。 ガバナンスプロファイル ガバナンスプロファイルは、選択したガバナンスルールセットを絞り込んだ API グループに適用します。その後、API Governance はルールセットに対して API を検証し、ガバナンス準拠を判断します。 ## [](#h)H ハイブリッドデプロイメント Anypoint Runtime Manager のクラウドコンソールを使用して Mule アプリケーションを Mule Runtime Engine がホストされるオンプレミスサーバーにデプロイすること。このデプロイメントがハイブリッドと呼ばれるのは、アプリケーションのホストがオンプレミスであるのに対してアプリケーションのクラウドがクラウドで行われるためです。 ## [](#m)M メッセージ検索条件 メッセージが検索条件によって処理されるかどうかを制御するメッセージプロセッサー。 メッセージプロセッサー フローを構成するために使用される基本的な構成要素。メッセージプロセッサーはフロー内でのメッセージの送受信の方法を制御します。 メッセージレシーバー コネクタが受信データを読み取り、メッセージとしてパッケージして、サービスコンポーネントのインバウンドルーターに渡すために使用する Java クラス。メッセージレシーバーは必要に応じてトランスフォーマーを使用してデータを変換できます。 モッキングサービス API をテストまたは調査するために公開 URI を提供します。 モジュール コンポーネントのグループ。モジュールにより、値を集約してデータを圧縮し、Java 機能で JSON の処理ができるようになり、アプリケーションの柔軟性が高まります。 Mule® アプリケーション Mule アプリケーションは、Mule Runtime Engine を使用してビルドされたインテグレーションソリューションで、一連のフローを介してデータを処理および変換します。これらのフローは、メッセージを受信し、処理し、宛先にルーティングする方法を定義するメッセージソースとプロセッサーで構成されます。Mule アプリケーションは、HTTP エンドポイントなど、さまざまな外部ソースからのメッセージを含むさまざまな種別のデータを処理でき、トランザクションやバッチジョブなどの高度な処理メカニズムをサポートします。 Mule 設定ファイル (設定 XML) Mule アプリケーション、ドメイン、ポリシーを設定する XML ファイル。 Mule Enterprise Edition (EE) 30 日間のトライアルダウンロードが可能な Mule のエンタープライズバージョン。Enterprise Edition には MuleSoft の完全な開発サイクル、テスト、テクニカルサポート、メンテナンスリリース、ホットフィックス、管理および監視のためのツールが含まれています。 Mule® Runtime Engine (Mule® または Mule) Anypoint Platform 用の Java ベースの統合ランタイムエンジン。 ## [](#o)O 組織 Anypoint Platform アカウントのすべてを格納するためのコンテナ。 ## [](#p)P Pivotal Cloud Foundry Pivotal という会社が提供するクラウドコンピューティングのサービスとしてのプラットフォーム (PaaS)。Anypoint Platform は Pivotal Cloud Foundry と統合されているため、Mule アプリケーションを独自の非公開ネットワークで動的に作成される仮想マシンにデプロイできます。「デプロイメント戦略」を参照してください。以前は PCF と呼ばれていました。 ポリシー 認証、アクセス、コンシューム率、API リソースに対するサービスレベルアクセス (SLA) を制御するオブジェクト。Anypoint Platform には事前設定済みのポリシーとカスタムポリシーを作成するためのツールの両方が用意されています。 ## [](#r)R RAML® RESTful API Modeling Language (RAML) は、API を定義するために使用する仕様言語を提供します。 Runtime Manager エージェント Runtime Manager エージェントは Anypoint Runtime Manager コンソールとサーバーで実行されている Mule インスタンス間の通信を仲介します。Mule エージェントを使用すると、Mule サーバーを監視および制御できます。以前は Runtime エージェントと呼ばれていました。 ランタイムプレーン コントロールプレーンとランタイムコントロール用のデータプレーン間のコントラクト。Anypoint Platform では、ランタイムプレーンは Mule Runtime Engine と Anypoint Runtime Fabric などのツールで管理されるランタイムサービスで構成されます。 ## [](#s)S シークレットマネージャー 非公開キー、パスワード、証明書などのシークレットの保存とアクセス制御を行う機能。 ## [](#t)T トークナイゼーション 機密データ要素を非機密データ要素に置き換えること。 トランスフォーマー XSLT トランスフォーマーなど、さまざまな型の間でメッセージペイロード (データ) を変換する機能。変換は DataWeave を使用して定義することもできます。 トランスポート FTP などの特定のメッセージングプロトコルでメッセージを運搬する機能。複数のコネクタにトランスポートが組み込まれています。 ## [](#u)U ユニバーサルメッセージオブジェクト (UMO) サービスコンポーネントの旧名。UMO は引き続き一部の MuleSoft API で表示されます。 ## [](#x)X XA トランザクション 複数の管理対象リソースを取得して信頼性を保証するトランザクション。Mule Runtime Engine は XA トランザクション以外のマルチリソーストランザクションもサポートしています。こうしたトランザクションは信頼性を保証しません。 # Java サポート Java 8 および 11 の標準サポートは Mule 4.8 Edge では 2025 年 3 月、4.6 LTS では 2026 年 2 月に終了します。Java 8 または 11 上で実行中のアプリケーションのアップグレードパスを計画します。 MuleSoft は Mule Runtime 4.6 から、Java の長期サポート (LTS) リリースケイデンスを採用しており、Java 17 LTS のサポートが追加されています。Java 17 にアップグレードすると、パフォーマンスの向上、言語レベルの機能強化、セキュリティ強化、拡張された API とライブラリといった多数の利点があります。 多くのサードパーティベンダーが Java 8 のサポートを終了するため、MuleSoft 製品スタックに影響があります。新しい LTS リリースケイデンスを採用することで、セキュリティ、コンプライアンス、パフォーマンスが向上します。 この変更は、現在サポート対象の Mule バージョンで実行されている Mule アプリケーションや、Mule Runtime 4.6 にアップグレードしたアプリケーションにはすぐには影響しませんが、早急にアップグレード計画を開始することをお勧めします。Java 17 のアップグレード計画には、インテグレーションアプリケーション、コネクタ (Anypoint Connector とカスタムコネクタ)、Mule ゲートウェイポリシー、API プロキシの評価を含みます。これらのコンポーネントはすべて Java に依存しています。 既存の Java 8 アプリケーションは、実行の基盤となっている Mule バージョンの延長サポートの終了に達するまで引き続き Java 8 で実行されます。 ## [](#mule-runtime-java-support)Mule Runtime の Java サポート 次の表に、Java 8、Java 11、Java 17 のサポートのタイムラインを示します。
Mule バージョン Java バージョン

4.9 LTS

17

4.9 Edge

17

4.8 Edge

8、11、17

4.7 Edge

8、11、17

4.6 LTS

8、11、17

4.6 Edge

8、11、17

4.5 Edge

8、11

Java 8 および 11 の標準サポートは Mule 4.8 Edge では 2025 年 3 月、4.6 LTS では 2026 年 2 月に終了するため、Java 8 または 11 で実行しているアプリケーションのアップグレードパスを適宜計画してください。
Mule 4.6.0 以降では、アプリケーションの実行がサポートされる最大バージョンは Java 17 です。Mule 4.9.0 以降では、Java 17 以下の Mule プロジェクトと追加の連動関係をコンパイルできます。Mule 4.9.0 より前のバージョンでは、Java 8 の Mule プロジェクトと追加の連動関係をコンパイルする必要があります。 連動関係 (​`mssql-jdbc`​ など) を選択するときに、​`pom.xml`​ の Java 8 または Java 17 と互換性のあるバージョンを設定します。互換性については、連動関係のドキュメントを参照してください。 Mule リリースケイデンスについての詳細は、[Edge and LTS Releases for Mule](https://docs.mulesoft.com/jp/release-notes/mule-runtime/lts-edge-release-cadence)を参照してください。 ## [](#アップグレード手順)アップグレード手順 次の手順に従って、Java 17 にアップグレードします。 - **アップグレード前** 1. 現在のセットアップを確認して、何をアップグレードまたは削除する必要があるかを特定します (Java 17 でサポートされなくなったまたは非推奨としてマークされた Java 機能など)。 2. テスト、ロールバック戦略、アップグレード後の確認を含め、包括的なアップグレード計画を作成します。 3. Java 17 にアップグレードした場合の​[アプリケーションのパフォーマンス](#application-performance)​について確認します。 4. オンプレミスの場合 (アップグレードの場合と同様に)、ダウンタイムをスケジュールし、関係者に通知して、ビジネスの中断を最小限に抑えます。 - **アップグレード** 1. [Mule Runtime 4.6](#mule-runtime)​ にアップグレードします。 2. Mule アプリケーション内で使用されているすべての ​[Anypoint Connector およびモジュール](#anypoint-connectors-and-modules)​と​[カスタムコネクタ](#custom-connectors)​、およびポリシーを Java 17 にアップグレードします。​[カスタム Java コード](#custom-code-in-connectors)​が含まれるコネクタには、Java 17 との互換性を確保するための追加の変更が必要です。 3. [ポリシー](#policies)​をアップグレードします。カスタム Java コードが含まれるポリシーには、Java 17 との互換性を確保するための追加の変更が必要です。 4. [API プロキシ](#api-proxies)​と ​[Mule アプリケーション](#mule-apps)​をアップグレードします。カスタム Java コードが含まれるプロキシには、Java 17 との互換性を確保するための追加の変更が必要です。 5. [Anypoint Studio](#anypoint-studio)​ を 7.17 にアップグレードし、Studio プロジェクトレベルで対象 JVM を変更して JVM をアップグレードまたはダウングレードします。 6. Java 17 での ​[DataWeave](#dataweave)​ の更新内容を確認し、アプリケーションが引き続き適切に動作することを検証します。 7. 本番に移行する前に制御された環境でアプリケーションをテストします。 8. Mule Maven プラグイン 4.1.1 以降を使用してアプリケーションをデプロイメントする場合、Java 17 を使用するように​[デプロイメントを設定します](#mule-maven-plugin)​。 - **アップグレード後** 1. アプリケーションを監視して予期しない動作がないかを確認します。 2. 関連するドキュメントを更新して、アップグレード中に実行された変更を反映します。 ## [](#mule-runtime)Mule Runtime Java 17 の改善されたパフォーマンスとセキュリティを利用するには、​[Mule Runtime 4.6 以降にアップグレード](https://docs.mulesoft.com/jp/release-notes/mule-runtime/updating-mule-4-versions)​してください。 ベストプラクティスは次のとおりです。 - スタンドアロン Mule インスタンスをアップグレードする。 - Runtime Manager で管理されているオンプレミス Mule インスタンスをアップグレードする。 - Mule アプリケーションのビルドに使用する Mule バージョンを更新する。 - Mule 4.6 以降で実行する対象に​[アプリケーションをデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying)​する。 ## [](#mule-apps)Mule アプリケーション 現在実行中の Mule アプリケーションのほとんどを、Java 17 を使用するように更新してテストし、再デプロイできます。ただし、カスタム Java コードを実行しているアプリケーションとコネクタでは、それらのコンポーネントを認定するための追加作業が必要です。インテグレーションアプリケーションまたは Mule ゲートウェイポリシーとプロキシを Java 17 にアップグレードする前に、アプリケーションおよびポリシー内で使用されるすべての拡張機能、モジュール、コネクタを Java 17 に更新する必要があります。

Mule 4.6.0 以降では、アプリケーションの実行がサポートされる最大バージョンは Java 17 です。Mule 4.9.0 以降では、Java 17 以下の Mule プロジェクトと追加の連動関係をコンパイルできます。Mule 4.9.0 より前のバージョンでは、Java 8 の Mule プロジェクトと追加の連動関係をコンパイルする必要があります。

連動関係 (​mssql-jdbc​ など) を選択するときに、​pom.xml​ の Java 8 または Java 17 と互換性のあるバージョンを設定します。互換性については、連動関係のドキュメントを参照してください。

アップグレード時に API プロキシまたは Mule アプリケーションを確実に保護するには、API プロキシまたは Mule アプリケーションをアップグレードする​前​にポリシーをアップグレードしてください。
## [](#application-performance)Java 17 のパフォーマンスに関する考慮事項 Java 17 では、MuleSoft 製品に重要なパフォーマンスに関する変更が行われています。Java 17 には、コードの実行速度を向上させる新しい JIT コンパイラーが含まれています。 アプリケーションのパフォーマンスを向上させるには、以下を参照してください。 - [メモリ管理](#memory-management) - [デフォルトの TLS 暗号化の選択](#default-tls-cipher-selection) ### [](#memory-management)メモリ管理 Java 17 は、Java 8 などの以前のバージョンとは異なる方法でメモリを管理します。Java 17 では、要求のレイテンシーが短縮され、より想定どおりに作業が実行されます。これを実現するために、異なるメモリ管理アプローチが採用されています。各アプリケーションに大きく依存しますが、場合によっては、Java 17 はヒープメモリに優先的にコミットします。

アプリケーションの最適な動作を確保し、Java 17 の改善点を効果的に活用するには、次の​パフォーマンステスト​と​監視​を実施する必要があります。

  • 大規模なバッチアプリケーション

  • CPU とメモリ提供の上限に達しているアプリケーション

アプリケーションがオンプレミスにデプロイされている場合: - ワークロードが Runtime Fabric で実行される場合は、少なくとも 1400 MB のメモリを 0.50 vCPU レプリカサイズに割り当てる必要があります。メモリ要件はアプリケーションごとに異なるため、この最小値はほとんどのアプリケーションに最適なメモリの割り当て設定です。 - ワークロードがハイブリッド環境やスタンドアロン環境などのオンプレミスで実行される場合は、オペレーティングシステムのガベージコレクションアルゴリズムを調整する必要があります。 ### [](#default-tls-cipher-selection)デフォルトの TLS 暗号化の選択 Java 11 以降を使用するサーバーで TLS を使用する場合、暗号化のプリファレンスはサーバーによって決定されます。クライアントでサポートされる暗号化リストは、優先度を決定するためではなく、絞り込むために使用されます。 [「Use server cipher suites preference by default (JDK-8168261) (デフォルトでサーバー暗号化スイートのプリファレンスを使用 (JDK-8168261))」](https://bugs.openjdk.org/browse/JDK-8168261)​を参照してください。 サーバーを Java 8 から Java 11 以降にアップグレードすると、(クライアントでサポートされる暗号化リストに応じて) 暗号化の再ネゴシエーションが発生し、セキュリティとパフォーマンスのトレードオフに影響を与える可能性があります。 暗号化のデフォルト値を変更する場合は、​[「プロトコルと暗号化スイートの指定」](https://docs.mulesoft.com/mule-runtime/latest/tls-configuration#optional-specify-protocols-and-cipher-suites)​を参照してください。 ## [](#anypoint-connectors-and-modules)Anypoint Connector およびモジュール Anypoint Connector およびモジュールは、Java 17 での実行が MuleSoft によって認定されています。各コネクタおよびモジュールの Java 17 サポートについての詳細は、該当する Mule 4 Connector またはモジュールの​[リリースノート](https://docs.mulesoft.com/jp/release-notes/connector/anypoint-connector-release-notes#mule_4)​を参照してください。 ### [](#コネクタおよびモジュールの-java-互換性情報を調べる場所)コネクタおよびモジュールの Java 互換性情報を調べる場所 すべての Anypoint Connector とモジュールが Java 17 互換になりました。使用しているコネクタのリリースノートで、Java 17 と互換性のあるコネクタバージョンを確認してください。 Java の互換性情報は、​**\[Asset versions (アセットバージョン)\]**​ テーブルのコネクタとモジュールの ​[Exchange](https://docs.mulesoft.com/jp/exchange/asset-versions)​ の詳細ページにも表示されます。コネクタはリリース時に Java 17 互換としてタグ付けされるため、これが最新の互換性情報です。 ![アセットバージョンの詳細オプションが表示されている展開済みのメニュー](/mulesoft/current/ja-jp/general/_images/exchange-version-detail.png) Java 17 と互換性のあるコネクタおよびそれぞれのバージョンのリストは、 [Java 17 と互換性のある Anypoint Connector](https://help.salesforce.com/s/articleView?id=000782248&type=1)​ を参照してください。 ### [](#anypoint-connector-のアップグレード)Anypoint Connector のアップグレード MuleSoft によって提供された、標準 (カスタムコードなし) で使用されている Anypoint Connector をアップグレードする手順は、次のとおりです。 1. Runtime Manager で、コネクタを含む Mule アプリケーションを Mule Runtime 4.6 以降で実行するように更新します。 2. Anypoint Studio で、プロジェクトプロパティレベルで​[対象 JDK を変更](https://docs.mulesoft.com/studio/change-jdk-config-in-projects)​します。 3. JDK 17 を選択すると、プロジェクト内のコネクタを更新するように自動的に促されます。 4. パッケージ化中に、選択した JDK バージョンと互換性のないコネクタがプロジェクトにある場合は、案内とアラートが表示されます。 5. Mule 4.6 以降で実行する対象に​[アプリケーションをデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying)​する。プロジェクトの Java バージョンとデプロイメント環境に不一致がある場合、Runtime Manager はアラートを表示します。 コネクタにカスタムコードが含まれている場合は、​[カスタムコネクタ](#custom-connectors)​を参照してください。 ## [](#custom-connectors)カスタムコネクタ カスタムコネクタ (カスタム設定プロパティプロバイダーを含む) とは、MuleSoft のパートナーやユーザーがビルドしたコネクタなど、MuleSoft が開発および管理していないコネクタです。アプリケーションでカスタムコネクタを使用している場合は、Java 17 および Mule Runtime 4.6 以降で実行するようにコネクタを更新する必要があります。 MuleSoft パートナーの場合: 1. Mule アプリケーションで、以下から生成されたコネクタを更新します。 - [Mule SDK](https://docs.mulesoft.com/jp/general/partner-connector-upgrade#upgrade-your-mule-sdk-connectors) - [REST SDK (ベータ)](https://docs.mulesoft.com/jp/general/partner-connector-upgrade#upgrade-your-rest-sdk-connectors) - [REST Connect](https://docs.mulesoft.com/jp/general/partner-connector-upgrade#upgrade-your-rest-connect-connectors) - [設定プロパティプロバイダー](https://docs.mulesoft.com/jp/general/partner-connector-upgrade#upgrade-your-custom-configuration-properties-providers) 2. [モジュールテストフレームワーク (ベータ)](https://docs.mulesoft.com/jp/general/partner-connector-upgrade#test-your-custom-connector-with-mtf)​ を使用してコネクタをテストします。 3. Mule 4.6 以降で実行する対象に​[アプリケーションをデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying)​する。 MuleSoft ユーザーの場合: 1. Mule アプリケーションで、以下から生成されたコネクタを更新します。 - [Mule SDK](https://docs.mulesoft.com/jp/general/customer-connector-upgrade#upgrade-your-mule-sdk-connectors) - [REST Connect](https://docs.mulesoft.com/jp/general/customer-connector-upgrade#upgrade-your-rest-connect-connectors) - [設定プロパティプロバイダー](https://docs.mulesoft.com/jp/general/customer-connector-upgrade#upgrade-your-custom-configuration-properties-providers) 2. [MUnit](https://docs.mulesoft.com/jp/general/customer-connector-upgrade#test-your-custom-connector-with-munit)​ を使用してコネクタをテストします。 3. Mule 4.6 以降で実行する対象に​[アプリケーションをデプロイ](https://docs.mulesoft.com/mule-runtime/latest/deploying)​する。 ## [](#custom-code-in-connectors)コネクタのカスタムコード コネクタにカスタムコードがある場合や、サードパーティライブラリを使用している場合、そのカスタムコードを更新して Java 17 との互換性を確保する必要があります。 - Java クラスのリフレクション Java 17 との互換性を確保するには、Java クラスへのアクセスやパラメーター値の設定にリフレクションを使用しているコードを確認して更新します。Java 17 では、より厳格なアクセス制御が課されるため、JDK 内部要素のイントロスペクションを回避してください。Java 17 で動作する堅牢なテストスイートを用意します。Java 17 では、​`setAccessible(true)`​ メソッドのアクセスの変更が許可されていないため、このメソッドには特に注意してください。 - Java プラットフォームモジュールシステム (JPMS) JPMS は Java 9 で導入されました。この機能では、より厳格なカプセル化が導入され、Mule モジュールで JDK クラスとやり取りする方法が影響を受けます。Mule が Java 17 および JPMS にアップグレードされると、次の変更が必要になります。 - 分割パッケージのリファクタリング: JPMS モジュール化標準に準拠するようにパッケージの再編成とリファクタリングを行うことで、内部および API パッケージ分割の問題を解決します。 - `ResourceBundle の読み込みへの対処`​: `ResourceBundleProvider`​ や代替方法を使用するなど、リソースバンドルの読み込みに関連する問題のソリューションを実装します。 - サードパーティライブラリの変更ログを分析して、JPMS に関連する Java 17 の互換性と変更を理解します。 - JDK 移行ガイド Java 8 から Java 17 への変更の完全なリストについては、 [「Oracle JDK 移行ガイド」](https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html#GUID-C25E2B1D-6C24-4403-8540-CFEA875B994A)​を参照してください。このガイドを使用してコードへの影響を評価します。 ## [](#anypoint-studio)Anypoint Studio Anypoint Studio (Studio) 7.17 以降、Mule アプリケーションが Mule Runtime 4.6 以降で実行されている場合、Studio プロジェクトレベルで対象 JVM を変更して JVM をアップグレードまたはダウングレードできます。 Studio 17 では、互換性に関する案内が提供されます。 - アプリケーションをパッケージ化するときに、Studio 7.17 はリアルタイムの案内を提供し、互換性のないコネクタのバージョンやプロジェクトの不一致がある場合はアラートを表示して、デプロイメントの失敗を防ぎます。 - 新しいコネクタまたはモジュールをプロジェクトに追加するときに、コネクタまたはモジュールの各バージョンでサポートされる JVM バージョンが表示されます。 - 既存の Studio プロジェクトを Java 17 にアップグレードするときに、Studio は Exchange を自動的に検索し、アプリケーション内のどの拡張機能 (モジュールとコネクタ) をアップグレードすべきかを提案します。 - Studio から CloudHub にアプリケーションをデプロイするときに、Runtime Manager はプロジェクトの Java バージョンとデプロイメント環境の不一致を検出します。たとえば、プロジェクトが Java 8 用にビルドされていて、対象環境が Java 17 の場合、Runtime Manager と Studio はデプロイメントの失敗を防ぐための案内を提供します。 詳細は、​[Select a Different Java Version to Run the Embedded Mule Runtime](https://docs.mulesoft.com/studio/change-jdk-config-in-projects) and [Update Mule Modules in Anypoint Studio](https://docs.mulesoft.com/studio/update-modules)​を参照してください。 ## [](#policies)ポリシー MuleSoft に含まれる Mule ゲートウェイポリシーは、Mule Runtime 4.6 リリース以降の Java 17 と互換性があります。これらのポリシーは、2025 年 2 月まで Java 8 の標準サポートが提供されます。したがって、できるだけ早急にポリシーの更新を開始することをお勧めします。
アップグレード時に API プロキシまたは Mule アプリケーションを確実に保護するには、API プロキシまたは Mule アプリケーションをアップグレードする​前​にポリシーをアップグレードしてください。
ポリシーをアップグレードする方法についての詳細は、​[「自動ポリシーのアップグレード」](https://docs.mulesoft.com/jp/general/upgrade-policies-proxies#upgrading-automated-policies)​と​[「API レベルのポリシーのアップグレード」](https://docs.mulesoft.com/jp/general/upgrade-policies-proxies#upgrading-api-level-policies)​を参照してください。 ## [](#api-proxies)API プロキシ MuleSoft に含まれる API プロキシは、Mule Runtime 4.6 リリース以降の Java 17 と互換性があります。これらの API プロキシは、2025 年 2 月まで Java 8 の標準サポートが提供されます。したがって、できるだけ早急に API プロキシの更新を開始することをお勧めします。
アップグレード時に API プロキシまたは Mule アプリケーションを確実に保護するには、API プロキシまたは Mule アプリケーションをアップグレードする​前​に API ポリシーをアップグレードしてください。
アップグレードの手順は、​**\[Proxy type (プロキシ種別)\]**​ によって若干異なります。 - 基本エンドポイント: - 基本エンドポイントを使用する場合は、適合したアプリケーションを Mule Runtime インスタンスにデプロイし、自動検出を使用して API Manager に接続します。詳細は、​[「Mule 4 アプリケーションでの Mule ゲートウェイの API 自動検出の設定」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule4)​を参照してください。 - 基本エンドポイント API インスタンスを使用してインスタンスを更新する場合は、API インスタンスに接続している Mule アプリケーションを更新します。 - プロキシアプリケーション プロキシアプリケーションをアップグレードする方法についての詳細は、​[「API プロキシのアップグレード」](https://docs.mulesoft.com/jp/general/upgrade-policies-proxies#upgrading-api-proxies)​を参照してください。 ## [](#mule-maven-plugin)Mule Maven プラグイン Mule Maven プラグイン 4.1.1 以降を使用してアプリケーションをデプロイする場合、Java 17 を使用するようにデプロイメントを設定できます。 CloudHub にデプロイするときに、ビルドバージョンにメジャーバージョンとマイナーバージョンがある場合、Mule Maven プラグインはリリーストレインの最新ビルドバージョンをデプロイします。Mule Maven プラグインには、指定した Java バージョンに明示的にデプロイするための新しい Java バージョンプロパティがあります。 Runtime Fabric と CloudHub 2.0 にデプロイする場合、Mule Maven プラグインはビルドのタグ全体を受け入れるため、デプロイメントで正しいセマンティックバージョン (SemVer) を使用できます。 詳細は、次のドキュメントを参照してください。 - [Deploy Applications to CloudHub Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub) - [Deploy Applications to CloudHub 2.0 Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-cloudhub-2) - [Deploy Applications to Runtime Fabric Using the Mule Maven Plugin](https://docs.mulesoft.com/mule-runtime/latest/deploy-to-rtf) ## [](#dataweave)DataWeave DataWeave は、Java のリフレクション API を使用して Java オブジェクトの読み取りと書き込みを行います。Java 17 では、Java データ形式と Mule オブジェクトに影響する制限がカプセル化とリフレクティブアクセスに追加されています。 アプリケーションが引き続き適切に動作するようにするには、次のガイドラインに従ってください。 - アプリケーションで使用されるオブジェクトが Plain Old Java Object (POJO) であることを確認する。 DataWeave 2.6.0 以降では POJO は必須です。Java 17 ではリフレクションがより制限されているため、POJO には setter も必要になりました。以前は、POJO には、すべてのプロパティに対してデフォルトのコンストラクターと getter がありました。DataWeave が Mule アプリケーションのコネクタの外部でビルドできるように、POJO には setter も必要になりました。 クラスが DataWeave によってインスタンス化される場合はコンストラクターと setter が必要であり、クラスが読み取られる場合は getter が必要です。クラスが返され、インスタンス化されていない場合は、getter のみが必要です。ただし、getter と setter の両方を使用すると、検証と認定のプロセスが簡素化されます。 POJO に次の項目があることを確認する必要があります。 - デフォルトのコンストラクター - すべてのプロパティの getter - すべてのプロパティの setter - 定義済み変数が適切な API を介してアクセスされていることを確認する。 `attributes`​、​`message`​、​`error`​ などの変数には、特定のアクセス API があります。Java 17 を使用する場合は、内部項目にアクセスできなくなったため、適切な項目を使用する必要があります。次に例を示します。 - `error.muleMessage`​ は、適切な Mule エラー項目 ​`error.errorMessage`​ に置き換える必要があります。 - `error.errors`​ は、適切な Mule エラー項目 ​`error.childErrors`​ に置き換える必要があります。 詳細は、次のドキュメントを参照してください。 - [Java 形式](https://docs.mulesoft.com/dataweave/latest/dataweave-formats-java#java-support) - [定義済み変数](https://docs.mulesoft.com/dataweave/latest/dataweave-variables-context) ## [](#関連情報)関連情報 - [MuleSoft の Java 17 アップグレードに関する FAQ](https://help.salesforce.com/s/articleView?id=000396936&type=1) - [コネクタリリースノート](https://docs.mulesoft.com/jp/release-notes/connector/anypoint-connector-release-notes) - [Java 17 への MuleSoft のアップグレード: 包括的なガイド](https://help.salesforce.com/s/articleView?id=002139151&type=1) ## [](#trending-topics)トレンドトピック - [日付と時刻の書式設定](https://docs.mulesoft.com/dataweave/latest/dataweave-cookbook-format-dates) - [DataWeave の演算子](https://docs.mulesoft.com/dataweave/latest/dw-operators) - [DataWeave 関数: filter](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-filter) - [DataWeave 関数: map](https://docs.mulesoft.com/dataweave/latest/dw-core-functions-map) - [バッチ処理](https://docs.mulesoft.com/mule-runtime/latest/batch-processing-concept) - [DataWeave リファレンス](https://docs.mulesoft.com/dataweave/latest/dataweave-functions) - [コネクタ](https://docs.mulesoft.com/connectors/) ## [](#the-road)デジタルトランスフォーメーションへの道 ![](/mulesoft/current/ja-jp/general/_images/getting-started.png) ### はじめに ビジネスで必要とされるデジタルトランスフォーメーションを構築します。 - [チュートリアル: API ビルドの最初から最後まで。](https://docs.mulesoft.com/jp/general/api-led-overview) ![](/mulesoft/current/ja-jp/general/_images/discover.png) ### 見つける Exchange を参照して、プロジェクトで再利用できる既存の API 仕様、テンプレート、例、他のアセットを見つけます。 - [再利用可能なアセットを見つけます。](https://www.anypoint.mulesoft.com/exchange/) ![](/mulesoft/current/ja-jp/general/_images/design.png) ### 設計 新しい API 仕様を最初から作成してパブリッシュします。 - [再利用可能な API 仕様を作成します。](https://docs.mulesoft.com/design-center/design-create-publish-api-specs) - [Anypoint Platform アカウントへのアクセス権を管理します。](https://docs.mulesoft.com/jp/access-management/) - [アプリケーションネットワークのセキュリティを強化します。](https://docs.mulesoft.com/jp/general/security) ![](/mulesoft/current/ja-jp/general/_images/develop.png) ### 開発 & テスト API とインテグレーションアプリケーションをビルドしてテストします。 - [API を開発します。](https://docs.mulesoft.com/studio/) - [データ、システム、およびアプリケーションを接続します。](https://docs.mulesoft.com/connectors/) - [システム、サービス、API、およびデバイスを統合する Mule アプリケーションを開発します。](https://docs.mulesoft.com/mule-runtime/latest/mule-app-dev) - [Mule アプリケーション内でデータにアクセスし、データを変換します。](https://docs.mulesoft.com/dataweave/latest/) - [API およびインテグレーションの自動テストを構築します。](https://docs.mulesoft.com/munit/latest/) ![](/mulesoft/current/ja-jp/general/_images/deploy.png) ### デプロイ デプロイメントオプションを選択し、API とアプリケーションをデプロイして、それらをポリシーで保護します。 - [デプロイメントオプションを選択します。](https://docs.mulesoft.com/jp/runtime-manager/deployment-strategies) - [API のプロキシを設定します。](https://docs.mulesoft.com/jp/api-manager/latest/api-proxy-landing-page) - [API を保護するためのポリシーを作成します。](#policies::policies-policy-overview.adoc) ![](/mulesoft/current/ja-jp/general/_images/monitor.png) ### 監視 ダッシュボード、メトリクス、視覚化を使用して API とインテグレーションを監視します。 - [インテグレーションアプリケーションおよび API のメトリクスを表示します。](https://docs.mulesoft.com/jp/monitoring/) - [API の機能動作およびパフォーマンスをテストします。](https://docs.mulesoft.com/jp/api-functional-monitoring/) - [デプロイ済みアプリケーションを監視します。](https://docs.mulesoft.com/jp/runtime-manager/monitoring) # MuleSoft ドキュメントへの寄稿 ドキュメントリポジトリの多くは開放されているため、是非寄稿してください。 このドキュメントの英語バージョンに寄稿する手順は、次のとおりです。 1. MuleSoft ドキュメントに初めて寄稿する場合は、 [Salesforce.com Contributor License Agreement (CLA)](https://cla.salesforce.com/sign-cla)​ に署名してください。CLA への署名は、GitHub アカウントごとに 1 回のみ行う必要があります。 2. 変更するページに移動し、​**\[View in Github (Github で表示)\]**​ をクリックします。 3. 編集を行います。 4. プル要求を GitHub リポジトリに送信します。 ドキュメントチームによってプル要求が受け入れられるか、質問がある場合は連絡があります。 プル要求でエラーが発生した場合は、ステップ 1 で CLA に署名していることを確認してください。 # Usage Reports Release Notes Each Anypoint Platform organization subscribes to a specific pricing, usage, and packaging model. Some functionality within Anypoint Platform depends on your organization’s setup and provisioning. The following release notes are provided for pricing, usage, and packaging: - [Usage Reports Release Notes](https://docs.mulesoft.com/jp/release-notes/usage-reports/usage-reports-release-notes) ## [](#see-also)See Also - [Known Issues](https://help.salesforce.com/s/issues) # カスタムコネクタのための Java のアップグレード (パートナー) Java 8 および 11 の標準サポートは Mule 4.8 Edge では 2025 年 3 月、4.6 LTS では 2026 年 2 月に終了します。Java 8 または 11 上で実行中のアプリケーションのアップグレードパスを計画します。
このガイドは MuleSoft パートナーにのみ適用されます。MuleSoft ユーザーの場合は、カスタムコネクタのための Java のアップグレード (顧客)を参照してください。
Java 17 用のカスタムコネクタをアップグレード、テスト、リリースして、MuleSoft エコシステム内で互換性を確保します。互換性のないコネクタを実行すると、ランタイムエラー、パフォーマンスの低下、セキュリティの脆弱性につながり、アプリケーションの安定性に影響する可能性があるため、この互換性を確保することが重要になります。 ## [](#始める前に)始める前に Java 17 用のカスタムコネクタをアップグレードしてテストする前に、次の考慮事項について理解しておく必要があります。 - 対象コンパイルレベル Mule 4.9.0 以降では、Java 17 以下の Mule プロジェクトをコンパイルできます。Java 17 以下では、追加の連動関係をコンパイルする必要があります。 Java 17 でコンパイルする場合、​`mule-modules-parent`​ をバージョン 1.9.0 以降にアップグレードします。コネクタの最小 Mule バージョンも 4.9.0 になるため、Mule 4.9.0 以降との互換性のみが確保されます。​`META-INF/mule-artifact/mule-artifact.json`​ の ​`minMuleVersion`​ が 4.9.0 以降であることを確認します。​[「Specify Java Compatibility (Java の互換性を指定する)」](https://docs.mulesoft.com/mule-sdk/latest/java-version-support#specify-java-compatibility)​を参照してください。 `mule-modules-parent`​ が 1.9.0 より前のバージョンである場合、コネクタのバイトコードレベルとその追加の連動関係は Java 8 に対応している必要があります。Java 11 または Java 17 の言語機能は使用できません。 - サポートされていないディレクティブ `-add-opens`​ または ​`-add-export`​ ディレクティブは設定しないでくださいください。これらのディレクティブは CloudHub または Runtime Fabric では許可されず、すべての環境でコネクタごとに管理する必要があります。また、後方互換性の負担が生じ、今後の Java アップグレードが複雑になり、セキュリティの脆弱性が生じる可能性があります。 - 最小 Mule バージョン カスタムコネクタが Mule 4.5.x 以前で実行されている場合、​`MuleArtifactFunctionalTestCase`​ を拡張する Java 17 テストは実行できませんが、Java 8 テストは引き続き実行できます。 テストを実行するときに最小 Mule バージョンを切り離すには、​`-Dmunit.jvm`​ パラメーターを追加して、​[Java 17 との互換性の直接テスト](#test-for-java-17-compatibility-directly)​の説明に従って Java 17 を使用します。 ## [](#upgrade-your-mule-sdk-connectors)カスタム Mule SDK Connector のアップグレード カスタム Mule SDK (Java SDK および XML SDK) Connector を Java 17 にアップグレードします。 ### [](#upgrade-third-party-libraries)サードパーティライブラリのアップグレード カスタムコネクタでサードパーティライブラリを使用している可能性があるため、Java 17 との互換性を確保することも重要です。カスタムコネクタがテストに合格しても、安全で信頼性のあるソフトウェアを提供することが引き続き重要になります。重要なバグや脆弱性が見つかった場合、修正されたバージョンにアップグレードする必要があります。Java 17 を明示的にサポートしている最新のライブラリを使用すると、ベンダーがそれらをすでに Java 17 でテストしているため、このプロセスが容易になり、信頼性が高まります。 カスタムコネクタのサードパーティライブラリをアップグレードして、Java 17 と互換性があるようにします。 - Java EE ライブラリ Mule 4.6.x では、以前の Mule バージョンとは異なる方法で Java EE ライブラリが公開されます。BOM 連動関係をカスタムコネクタに追加し、該当する場合は、提供された競合するライブラリを除外する必要があります。また、ライブラリを BOM 連動関係に個別に追加することもできます。 ```java 4.6.0 org.mule mule-javaee-runtime-bom ${muleJavaEeBomVersion} pom import ``` 詳細は、[Java EE Libraries](https://docs.mulesoft.com/mule-sdk/latest/java-ee-libraries)を参照してください。 - 外部ライブラリ 外部ライブラリ (カスタムコネクタにバンドルされていないサードパーティライブラリ) をアップグレードします。例として、JDBC ドライバー、JMS ブローカークライアント、Groovy Runtime などがあります。次の例は、JDBC ドライバーの外部ライブラリ設定を示しています。 ```java @ExternalLib(name = "MySQL JDBC Driver", description = "A JDBC driver that supports connection to the MySQL Database", nameRegexpMatcher = "(.*)\\.jar", requiredClassName = "com.mysql.jdbc.Driver", coordinates = "mysql:mysql-connector-java:5.1.44") public class MySqlConnectionProvider implements ConnectionProvider { // } ``` 外部ライブラリを Java 17 と互換性のあるバージョンに更新する必要があります。 ### [](#review-your-code)コードのレビュー カスタムコネクタをコンパイルしたら、Java 17 でカスタムコネクタを実行できることを確認します。Java 11 では一部の制限に警告のフラグが付けられますが、Java 17 では失敗のフラグが付けられ、無効にすることができないため、コードのレビューを行うことが重要です。たとえば、Java 17 ではリフレクションがより制限されているため、コードをレビューして不正なアクションがないことを確認する必要があります。 コードのレビューに役立つように、Java 17 のさまざまな変更の詳細を確認してください。 - JDK 移行ガイド Java 8 から Java 17 への変更の完全なリストについては、 [「Oracle JDK 移行ガイド」](https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html#GUID-C25E2B1D-6C24-4403-8540-CFEA875B994A)​を参照してください。このガイドを使用してコードへの影響を評価します。 - Mule Runtime Engine Mule Runtime Engine で行われた Java 17 の変更についての詳細は、​[「Mule Runtime」](https://docs.mulesoft.com/jp/general/java-support#mule-runtime)​を参照してください。 - Java クラスのリフレクション Java 17 との互換性を確保するには、Java クラスへのアクセスやパラメーター値の設定にリフレクションを使用しているコードを確認して更新します。Java 17 では、より厳格なアクセス制御が課されるため、JDK 内部要素のイントロスペクションを回避してください。Java 17 で動作する堅牢なテストスイートを用意します。Java 17 では、​`setAccessible(true)`​ メソッドのアクセスの変更が許可されていないため、このメソッドには特に注意してください。 - シリアル化 Java 17 の制限に対応するようにシリアル化コードを更新します。コードで Gson などのライブラリを使用してクラスをシリアル化している場合、JDK クラスへのリフレクティブアクセスが含まれる Data Transfer Object (DTO) の使用に切り替えます。シリアル化ライブラリが更新されていることを確認し、リフレクションへの依存を最小限に抑えるようにコードを調整します。詳細は、[Configure Custom Serializers](https://docs.mulesoft.com/mule-runtime/latest/configure-custom-serializers)を参照してください。 - ライブラリのアップグレード ライブラリを Java 17 と互換性のあるバージョンにアップグレードします。これには、バージョン 1.14.0 への ByteBuddy の更新、0.8.10 への Jacoco の更新、バージョン 2.x への SLF4J の更新が含まれます。CGLib を ByteBuddy で置き換えて、Groovy や JRuby などの他のライブラリへの更新がないかを確認します。すべての連動関係に Java 17 との互換性があることを確認し、ランタイムの問題を回避します。 - テストスイートの実行に伴う変更 テスト方法を Java 17 に適応させます。Mockito を使用する場合、Mockito では JVM クラスをモックできないことに注意してください。モッキング用のカスタム実装を考慮し、PowerMock から新しい Mockito バージョンに切り替えます。Java 17 の変更を処理するようにテストを更新し、非推奨になったメソッドを回避します。 - Java プラットフォームモジュールシステム (JPMS) JPMS は Java 9 で導入されました。この機能では、より厳格なカプセル化が導入され、Mule モジュールで JDK クラスとやり取りする方法が影響を受けます。Mule が Java 17 および JPMS にアップグレードされると、次の変更が必要になります。 - 分割パッケージのリファクタリング: JPMS モジュール化標準に準拠するようにパッケージの再編成とリファクタリングを行うことで、内部および API パッケージ分割の問題を解決します。 - `ResourceBundle の読み込みへの対処`​: `ResourceBundleProvider`​ や代替方法を使用するなど、リソースバンドルの読み込みに関連する問題のソリューションを実装します。 - サードパーティライブラリの変更ログを分析して、JPMS に関連する Java 17 の互換性と変更を理解します。 ### [](#欠落しているコードの追加)欠落しているコードの追加 Java 17 ではリフレクションがより制限されているため、API オブジェクトにはセッターが必要になります。以前の Java 8 では、API オブジェクトには、DataWeave のすべてのアクセス可能なプロパティに対してデフォルトのコンストラクターと getter のみがあれば十分でした。DataWeave がリフレクションを使用することなくこれらのプロパティを書き込むことができるように、API オブジェクトには setter も必要になりました。 クラスが DataWeave によってインスタンス化される場合はコンストラクターと setter が必要であり、クラスが読み取られる場合は getter が必要です。クラスが返され、インスタンス化されていない場合は、getter のみが必要です。ただし、getter と setter の両方を使用すると、検証と認定のプロセスが簡素化されます。 ## [](#upgrade-your-rest-sdk-connectors)カスタム REST SDK Connector のアップグレード REST SDK バージョン 0.8.0-RC4 を使用して、カスタム REST SDK Connector を Java 17 にアップグレードします。 REST SDK 0.8.0-RC4 では、Java 17 と互換性のあるコネクタが生成され、Java カスタマイズなしでビルドされた REST SDK 0.8.0-RC3 コネクタのみとの後方互換性が維持されます。バージョン 0.8.0-RC4 には、0.8.0-RC3 より前の REST SDK バージョンとの後方互換性はありません。 REST SDK Connector を Java 17 にアップグレードする場合、次の手順を実行します。 - Java カスタマイズを含む REST SDK バージョン 0.8.0-RC3 以前のコネクタの場合、REST SDK 0.8.0-RC4 を使用してコネクタを再生成し、すべての Java カスタマイズを移植します。 結果のコネクタでは、以前のバージョンのコネクタとの互換性が失われる可能性があります。 - Java カスタマイズを含まない REST SDK 0.8.0-RC3 以前のコネクタの場合、REST SDK 0.8.0-RC4 を使用してコネクタを再生成します。 結果のコネクタには以前のバージョンとの後方互換性があります。 REST SDK についての詳細は、 [「REST SDK」](https://beta.docs.mulesoft.com/beta-mule-sdk/mule-sdk/1.1/rest-sdk/rest-sdk-connectivity)​を参照してください。 ### [](#既存のカスタム-rest-sdk-connector-のアップグレード)既存のカスタム REST SDK Connector のアップグレード 以前に REST SDK を使用してコネクタを生成していて、そのコネクタを Java 17 と互換性のあるものにするには、次の手順を実行します。 1. REST SDK コンポーネントと連動関係をバージョン 0.8.0-RC4 にアップグレードします。 ```xml com.mulesoft.connectivity rest-sdk-connector-parent-pom 0.8.0-RC4 0.8.0-RC4 0.8.0-RC4 ``` 2. REST SDK 上書き機能を使用して設定クラス (​`ConnectorNameConfiguration.java`​) を手動で作成する場合、アノテーションを追加する必要があります。 ```java import org.mule.sdk.api.annotation.JavaVersionSupport; import org.mule.sdk.api.meta.JavaVersion; @JavaVersionSupport({JavaVersion.JAVA_8, JavaVersion.JAVA_11, JavaVersion.JAVA_17}) public class YourConnectorConfiguration ``` 3. コネクタを再生成します。 ### [](#新しいカスタム-rest-sdk-connector-のアップグレード)新しいカスタム REST SDK Connector のアップグレード REST SDK を使用して新しいコネクタを生成し、そのコネクタを Java 17 と互換性のあるものにするには、次の手順を実行します。 1. REST SDK コンポーネントと連動関係をバージョン 0.8.0-RC4 にアップグレードします。 ```xml com.mulesoft.connectivity rest-sdk-connector-parent-pom 0.8.0-RC4 0.8.0-RC4 0.8.0-RC4 ``` 2. Mule Runtime バージョンを 4.6.x にアップグレードします。 ## [](#upgrade-your-rest-connect-connectors)カスタム REST Connect Connector のアップグレード カスタム REST Connect Connector を Java 17 にアップグレードします。 REST Connect で Java 17 がサポートされるようになりました。REST Connect Connector は、REST Connect を使用して API 仕様から生成されます。コネクタを Java 17 互換にするには、API 仕様を Exchange に再パブリッシュします。​[「REST Connect Connector ジェネレーター」](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect)​を参照してください。
REST Connect に TLS のサポートが追加されました。時間を節約するために、Java 17 用に生成されたコネクタを更新するときに TLS を有効にし、コネクタの生成とアプリケーションのテストを 1 回だけ行えばいいようにします。
## [](#upgrade-your-custom-configuration-properties-providers)カスタム設定プロパティプロバイダーのアップグレード カスタム設定プロパティプロバイダーをアップグレードして Java 17 との互換性を確保するには、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ の使用に切り替えて、​[「カスタムコネクタのリリース」](#release-your-custom-connector)​の説明に従って ​`@JavaVersionSupport`​ アノテーションを使用します。カスタムコネクタと同様に ​[カスタムコネクタのための Java のアップグレード (パートナー)](https://docs.mulesoft.com/jp/general/partner-connector-upgrade), just like with any custom connector. The example custom configuration properties provider mentioned in [Example: Mule SDK Module](https://docs.mulesoft.com/mule-runtime/latest/custom-configuration-properties-provider#example-mule-sdk-module)​ で説明されているすべての手順も実行する必要があります。「例: Mule SDK モジュール」に記載されているカスタム設定プロパティプロバイダーの例は、Java 17 をサポートするように更新されています。この例を参照して、カスタム設定プロパティプロバイダーを更新してください。変更されたコード (MUnit へのテストの移行を含む) がどのようなものかについては、この [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/410ee26d8b3c44adacb077e099f32886f99eb6be)​ を参照してください。 または、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ の使用への切り替えに非常に多くの変更が伴う場合、カスタム設定プロパティプロバイダーの ​`ExtensionLoadingDelegate`​ 内で ​`ExtensionDeclarer`​ を使用して宣言を追加します。変更されたコードがどのようなものかについては、この [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/19d9d45cd52b0695f7b9c2b9019bae88f45fb228)​ を参照してください。 ## [](#test-your-custom-connector-with-mtf)MTF を使用したカスタムコネクタのテスト モジュールテストフレームワーク (MTF) を使用してカスタムコネクタをテストして、Java 17 との互換性を確保します。MTF の詳細については、 [「MTF」](https://beta.docs.mulesoft.com/beta-mtf/mule-sdk/1.1/mtf)​を参照してください。 ### [](#ビルドのセットアップ)ビルドのセットアップ すべてのサポートされる Java バージョン (Java 8、Java 11、および Java 17) に対してパイプラインが確実に動作するようにします。次の例は、すべてのサポートされる Java バージョンに対してテストを実行するように設定された単一のビルドパイプラインを示しています。ここで ​`default`​ は Java 17 に対応します。 ![単一のビルドパイプラインの例](/mulesoft/current/ja-jp/general/_images/single-build-pipeline.png) パイプラインでは、前のテストが失敗してもすべてのテストが実行されます。たとえば、パイプラインでは、Java 11 のテストが失敗しても Java 17 のテストが実行されます。 パイプラインに複数のテストが含まれていても、パイプラインには 1 つのコンパイルフェーズと、Java 8 を対象とする 1 つのリリースフェーズがあります。 ### [](#初期テストの実行)初期テストの実行 初期テストを実行し、カスタムコネクタに Java 17 との互換性があるかをテストします。カスタムコネクタコードを変更しながらテストの実行を継続することができます。 1. カスタムコネクタの ​`pom.xml`​ ファイルで、次の設定を含めるように munit-extensions-maven-plugin 設定を更新します (​`jacoco.version`​ プロパティは 0.8.10 以降である必要があります)。 ```xml -javaagent:${settings.localRepository}/org/jacoco/org.jacoco.agent/${jacoco.version}/org.jacoco.agent-${jacoco.version}-runtime.jar=destfile=${session.executionRootDirectory}/target/jacoco-munit.exec ``` 2. MTF テストを実行してカバー率レポートを生成します。テストを実行するときに ​`-Dtest=none`​ および ​`-DfailIfNoTests=false`​ フラグを使用して、JUnit テストをカバー率レポートに含めないようにします。 カバー率レポートは ​`target/jacoco-munit.exec`​ で使用できます。 ### [](#カバー率レポートの表示)カバー率レポートの表示 カバー率レポートを表示して、カスタムコネクタのカバー率を確認します。Java 17 との互換性を高い確度で確保するには、80% 以上のカバー率が必要です。 1. IntelliJ IDEA を開きます。 2. **\[Run (実行)\]**​ > ​**\[Show Coverage Data (カバー率データを表示)\]**​ に移動します。 3. **\[Choose Coverage Suite to Display (表示するカバー率スイートを選択)\]**​ で、​`jacoco-munit.exec`​ がまだリストにない場合は追加します。 4. カバー率を参照して結果を分析します。 カバー率は、コネクタがどの程度テストされているかを反映します。回避すべき重要な問題は、コード内の不正なリフレクティブアクセスです。これを検出する唯一の方法は、​[コードのレビュー](#review-your-code)​またはテストを行うことです。80% 以上のカバー率を目指すことで、getter や setter などのより単純なコードに柔軟性を持たせることができるほか、すべての重要なビジネスロジックを徹底的にテストできます。 ### [](#jdeps-maven-プラグインの追加)JDeps Maven プラグインの追加 JDeps は、使用またはアクセスできなくなった JDK 内部 API の使用量を検出する静的コード分析用のツールです。詳細は、 [「OpenJDK wiki」](https://wiki.openjdk.org/display/JDK8/Java+Dependency+Analysis+Tool)​を参照してください。 JDeps Maven プラグインをカスタムコネクタの ​`pom.xml`​ ファイルに追加します。 ```xml org.apache.maven.plugins maven-jdeps-plugin 3.1.2 jdkinternals test-jdkinternals true ``` 使用またはアクセスできなくなった JDK 内部 API をカスタムコネクタで使用している場合、ビルドは失敗します。 JDeps Maven プラグインは JDK にバンドルされている JDeps ツールを使用しているため、​`JAVA_HOME`​ 値を変更して Java 8 と 11 の両方でビルドをテストします。各 Java バージョンでビルドを実行することで、信頼度がさらに高まります。 テストなしで JDeps Maven プラグインを実行するには、次のコマンドを使用します。 ```bash mvn clean install -Dtest=none -DfailIfNoTests=false -DskipTests=true ``` これにより、潜在的なテストの失敗や長いテスト実行時間に対処することなく、問題のあるライブラリや内部アクセスの問題の確認に集中することができます。 ### [](#java-17-との互換性のテスト)Java 17 との互換性のテスト Java 11 または Java 17 のいずれかで実行されている Java 17 との互換性をテストできます。 Java 11 で実行している場合、不正なリフレクティブアクセス用のパラメーターを追加することで、早期検証を実行できます。​[不正なリフレクティブアクセス用のパラメーターの追加](#add-a-parameter-for-illegal-reflective-access)​を参照してください。 Java 17 で実行している場合、Java 17 を直接テストできます。​[Java 17 との互換性の直接テスト](#test-for-java-17-compatibility-directly)​を参照してください。 #### [](#add-a-parameter-for-illegal-reflective-access)不正なリフレクティブアクセス用のパラメーターの追加 リフレクティブアクセスは Java 17 の互換性を破る変更の 1 つです。Java 11 のデフォルト動作を使用して MTF テストを実行する場合、MTF テストではリフレクティブアクセスの警告のみが記録されます。 Java 17 の動作に似せるには、​`--illegal-access=deny`​ JVM パラメーターを使用して MTF テストを実行します。これにより、MTF テストは、警告のみを記録するのではなく失敗します。このパラメーターは、Mule Runtime バージョン 4.2.0 以降で使用します。 カスタムコネクタの ​`pom.xml`​ ファイルをセットアップして各設定を含める手順は、次のとおりです。 1. 空のプロパティを追加します。 ```xml ``` 2. 次の設定を含めるように munit-extensions-maven-plugin 設定を更新します。 ```xml <_JAVA_OPTIONS>-XX:+PrintCommandLineFlags ${mtf.javaopts} ``` `--illegal-access=deny`​ パラメーターを使用して MTF テストを実行できるようになりました。bash スクリプトの例を次に示します (使用可能な最新の Mule Runtime バージョンで置き換えてください)。 ```bash #!/bin/bash RUNTIME_VERSION=4.6.0 MUNIT_JVM=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/java mvn clean mkdir target mvn verify \ -DruntimeProduct=MULE_EE \ -DruntimeVersion=$RUNTIME_VERSION \ -Dmunit.jvm=$MUNIT_JVM \ -Dmtf.javaopts="--illegal-access=deny" > ./target/test.log ``` MTF テストを実行したら、​`target/illegal-access.log`​ ファイルに移動して、動作が不正なクラスや連動関係がないかを確認します。 次のコマンドを使用して、カスタムコネクタの外部の既知の警告を除外することもできます。 ```bash cat target/illegal-access.log | sort | uniq | grep -Ev "org.mule.module.artifact|org.mule.metadata|org.mule.runtime|org.mule.service" ``` #### [](#test-for-java-17-compatibility-directly)Java 17 との互換性の直接テスト MTF テストを実行し、Java 17 に対してカスタムコネクタの互換性をテストします。 前述のとおり、すべてのサポートされる Java バージョンに対して実行される単一のビルドパイプラインを使用できます。メインのビルドパイプラインが不安定にならないように、Java 17 用の別の一時的なビルドパイプラインをセットアップすることもできます。Java 17 にアップグレードしたら、一時的なビルドパイプラインを破棄し、メインのビルドパイプラインに集中します。 1. `MUNIT_JVM`​ 変数で JVM インストールへのパスを設定します (これは自身でインストールする必要があります)。​`JAVA_HOME`​ を Java 8 に設定する必要もあります。 2. 次の MTF 連動関係がカスタムコネクタの ​`pom.xml`​ ファイルで設定されていることを確認します。 - munit 3.1.0 - munit-extensions-maven-plugin 1.2.0 - mtf-tools 1.2.0 - mule-maven-plugin 4.1.0 - mule-extensions-maven-plugin 1.6.0-rc1 これらの MTF 連動関係には 4.3.0 以上の Mule バージョンが必要です。MTF テストで 4.3.0 より前の Mule Runtime バージョンに対して検証を行わないようにするには、カスタムコネクタの ​`pom.xml`​ ファイルで次のコードを ​`munit-plugin`​ 設定に追加します。 ```xml [...] ${minVersion} false EE ``` Java 17 に対する MTF テストは Mule Runtime 4.6.0 以降でのみ実行できます。Mule Runtime 4.5.x 以前の場合、MTF テストは Java 8 と Java 11 に対してのみ実行できます。 MUnit 3.1 は Mule Runtime 4.3.0 以降とのみ互換性があります。コネクタに Mule Runtime 4.2.0 以前との互換性がある場合、MUnit バージョンを上書きする従来のプロファイルを作成する必要があります。 次の bash スクリプトを使用し、Java 17 に対してカスタムコネクタをテストします。 ```bash #!/bin/bash RUNTIME_VERSION=4.6.0 MUNIT_JVM=/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java mvn clean mkdir target mvn verify \ -DruntimeProduct=MULE_EE \ -DruntimeVersion=$RUNTIME_VERSION \ -Dmunit.jvm=$MUNIT_JVM \ -Dmule.module.tweaking.validation.skip=true \ -Dmule.jvm.version.extension.enforcement=LOOSE > ./target/test.log ``` 使用する Mule Runtime バージョンで mule-modules-parent のバージョンが決まります。たとえば、Mule Runtime 4.6.0 を使用する場合、mule-modules-parent 1.6.0 を使用する必要があります。マイナーバージョンは、Mule Runtime 4.1.0 と mule-modules parent 1.1.0、Mule Runtime 4.2.0 と mule-modules-parent 1.2.0 などのように対応関係を維持します。 Java 17 は Mule Runtime 4.6.0 以降でサポートされます。ただし、コネクタは Mule 4.3.0 と Java 17 の両方との互換性を同時に持つことができます。コネクタに Mule 4.3.0 との互換性が必要な場合、mule-modules-parent バージョンは 1.3.0 を超えることはできません。コネクタを Java 17 と互換性のあるものにするために、必ずしも mule-modules-parent 1.6.0 を使用する必要はありません。コネクタで Mule Runtime 4.6.0 のその他の機能を活用するには、特に mule-modules-parent 1.6.0 を使用する必要があります。 ### [](#テストの読み取り)テストの読み取り MTF テストを実行したら、ビルドの結果は次のいずれかになります。 - テスト失敗 Java 17 との互換性を確保するためにカスタムコネクタコードの変更が必要になる可能性があります。 - すべてのテストに合格 カスタムコネクタを大きく変更する必要がないか、テストスイートが十分に包括的ではないかのいずれかです。テストスイートを見直して、コードカバー率が適切であることと、テストシナリオおよびアサーションが単純すぎないことを再確認します。 ## [](#release-your-custom-connector)カスタムコネクタのリリース コードを更新し、テストが緑色になったら、カスタムコネクタの新しい Java 17 互換バージョンをリリースする準備が整いました。 1. Java 17 の互換性を伝えるには、カスタムコネクタの ​`mule-sdk-api`​ 連動関係を追加または最新バージョンにアップグレードして、カスタムコネクタの Java 互換性のメタデータを生成します。 ```xml org.mule.sdk mule-sdk-api 0.10.1 ``` 2. Java SDK の場合は、次に示すように ​`@Extension`​ アノテーションと同じクラスに ​`@JavaVersionSupport`​ アノテーションを追加して、​`JAVA_17`​ という値を含めます。
XML SDK Module は Java 17 と互換性があり、プロパティを自動的に継承するため、XML SDK についてのアノテーションを追加する必要はありません。
```java @Extension(name = "Database") @Operations(...) @JavaVersionSupport({JAVA_8, JAVA_11, JAVA_17}) public class DatabaseConnector { .. } ``` Mule 4.5.0 以降では、​`@JavaVersionSupport`​ アノテーションを指定しないカスタムコネクタは Java 8 および Java 11 と互換性があると見なされます。 カスタムコネクタは、Java 17 のみと互換性があるとマークできます。ただし、採用や下位互換性の問題が存在しないことを確認する必要があります。 Mule アプリケーションをデプロイすると、Mule アプリケーションのすべてのモジュールに Java バージョンとの互換性があることが検証されます。互換性がないことがわかると Mule はエラーをスローし、アプリケーションはデプロイされません。
XML SDK ベースのコネクタに固有のエラーメッセージ (​Extension 'module-error-handler-plugin' does not support Java 17.Supported versions are: [1.8, 11]​ など) が表示された場合は、Mule アプリケーションに Java 17 と互換性のないコネクタがまだ含まれていることを意味します。このエラーを解決するには、Mule アプリケーションのすべてのコネクタをアップグレードして、Java 17 と互換性があるようにします。
コードが Java 17 と互換性があるが、Java 17 互換性を宣言しない場合でも、テストの実行は成功します。 カスタムコネクタのクイックチェックを実行する場合、またはすべての連動関係の準備ができていない場合は、次の引数を渡して、Java サポート宣言のハードチェックをスキップします。 ```bash -M-Dmule.jvm.version.extension.enforcement=LOOSE ``` 詳細は、[Java Version Support](https://docs.mulesoft.com/mule-sdk/latest/java-version-support)を参照してください。 ## [](#関連情報)関連情報 - [Java サポート](https://docs.mulesoft.com/jp/general/java-support) # カスタムコネクタのための Java のアップグレード (顧客) Java 8 および 11 の標準サポートは Mule 4.8 Edge では 2025 年 3 月、4.6 LTS では 2026 年 2 月に終了します。Java 8 または 11 上で実行中のアプリケーションのアップグレードパスを計画します。
このガイドは MuleSoft ユーザーにのみ適用されます。MuleSoft パートナーの場合は、カスタムコネクタのための Java のアップグレード (パートナー)を参照してください。
Java 17 用のカスタムコネクタをアップグレード、テスト、リリースして、MuleSoft エコシステム内で互換性を確保します。互換性のないコネクタを実行すると、ランタイムエラー、パフォーマンスの低下、セキュリティの脆弱性につながり、アプリケーションの安定性に影響する可能性があるため、この互換性を確保することが重要になります。 ## [](#始める前に)始める前に Java 17 用のカスタムコネクタをアップグレードしてテストする前に、次の考慮事項について理解しておく必要があります。 - 対象コンパイルレベル Mule 4.9.0 以降では、Java 17 以下の Mule プロジェクトをコンパイルできます。Java 17 以下では、追加の連動関係をコンパイルする必要があります。 Java 17 でコンパイルする場合、​`mule-modules-parent`​ をバージョン 1.9.0 以降にアップグレードします。コネクタの最小 Mule バージョンも 4.9.0 になるため、Mule 4.9.0 以降との互換性のみが確保されます。​`META-INF/mule-artifact/mule-artifact.json`​ の ​`minMuleVersion`​ が 4.9.0 以降であることを確認します。​[「Specify Java Compatibility (Java の互換性を指定する)」](https://docs.mulesoft.com/mule-sdk/latest/java-version-support#specify-java-compatibility)​を参照してください。 `mule-modules-parent`​ が 1.9.0 より前のバージョンである場合、コネクタのバイトコードレベルとその追加の連動関係は Java 8 に対応している必要があります。Java 11 または Java 17 の言語機能は使用できません。 - サポートされていないディレクティブ `-add-opens`​ または ​`-add-export`​ ディレクティブは設定しないでくださいください。これらのディレクティブは CloudHub または Runtime Fabric では許可されず、すべての環境でコネクタごとに管理する必要があります。また、後方互換性の負担が生じ、今後の Java アップグレードが複雑になり、セキュリティの脆弱性が生じる可能性があります。 - 最小 Mule バージョン カスタムコネクタが Mule 4.5.x 以前で実行されている場合、​`MuleArtifactFunctionalTestCase`​ を拡張する Java 17 テストは実行できませんが、Java 8 テストは引き続き実行できます。 テストを実行するときに最小 Mule バージョンを切り離すには、​`-Dmunit.jvm`​ パラメーターを追加して、​[MUnit を使用したカスタムコネクタのテスト](#test-your-custom-connector-with-munit)​の説明に従って Java 17 を使用します。 ## [](#upgrade-your-mule-sdk-connectors)カスタム Mule SDK Connector のアップグレード カスタム Mule SDK (Java SDK および XML SDK) Connector を Java 17 にアップグレードします。 ### [](#upgrade-third-party-libraries)サードパーティライブラリのアップグレード カスタムコネクタでサードパーティライブラリを使用している可能性があるため、Java 17 との互換性を確保することも重要です。カスタムコネクタがテストに合格しても、安全で信頼性のあるソフトウェアを提供することが引き続き重要になります。重要なバグや脆弱性が見つかった場合、修正されたバージョンにアップグレードする必要があります。Java 17 を明示的にサポートしている最新のライブラリを使用すると、ベンダーがそれらをすでに Java 17 でテストしているため、このプロセスが容易になり、信頼性が高まります。 カスタムコネクタのサードパーティライブラリをアップグレードして、Java 17 と互換性があるようにします。 - Java EE ライブラリ Mule 4.6.x では、以前の Mule バージョンとは異なる方法で Java EE ライブラリが公開されます。BOM 連動関係をカスタムコネクタに追加し、該当する場合は、提供された競合するライブラリを除外する必要があります。また、ライブラリを BOM 連動関係に個別に追加することもできます。 ```java 4.6.0 org.mule mule-javaee-runtime-bom ${muleJavaEeBomVersion} pom import ``` 詳細は、[Java EE Libraries](https://docs.mulesoft.com/mule-sdk/latest/java-ee-libraries)を参照してください。 - 外部ライブラリ 外部ライブラリ (カスタムコネクタにバンドルされていないサードパーティライブラリ) をアップグレードします。例として、JDBC ドライバー、JMS ブローカークライアント、Groovy Runtime などがあります。次の例は、JDBC ドライバーの外部ライブラリ設定を示しています。 ```java @ExternalLib(name = "MySQL JDBC Driver", description = "A JDBC driver that supports connection to the MySQL Database", nameRegexpMatcher = "(.*)\\.jar", requiredClassName = "com.mysql.jdbc.Driver", coordinates = "mysql:mysql-connector-java:5.1.44") public class MySqlConnectionProvider implements ConnectionProvider { // } ``` 外部ライブラリを Java 17 と互換性のあるバージョンに更新する必要があります。 ### [](#review-your-code)コードのレビュー カスタムコネクタをコンパイルしたら、Java 17 でカスタムコネクタを実行できることを確認します。Java 11 では一部の制限に警告のフラグが付けられますが、Java 17 では失敗のフラグが付けられ、無効にすることができないため、コードのレビューを行うことが重要です。たとえば、Java 17 ではリフレクションがより制限されているため、コードをレビューして不正なアクションがないことを確認する必要があります。 コードのレビューに役立つように、Java 17 のさまざまな変更の詳細を確認してください。 - JDK 移行ガイド Java 8 から Java 17 への変更の完全なリストについては、 [「Oracle JDK 移行ガイド」](https://docs.oracle.com/en/java/javase/17/migrate/getting-started.html#GUID-C25E2B1D-6C24-4403-8540-CFEA875B994A)​を参照してください。このガイドを使用してコードへの影響を評価します。 - Mule Runtime Engine Mule Runtime Engine で行われた Java 17 の変更についての詳細は、​[「Mule Runtime」](https://docs.mulesoft.com/jp/general/java-support#mule-runtime)​を参照してください。 - Java クラスのリフレクション Java 17 との互換性を確保するには、Java クラスへのアクセスやパラメーター値の設定にリフレクションを使用しているコードを確認して更新します。Java 17 では、より厳格なアクセス制御が課されるため、JDK 内部要素のイントロスペクションを回避してください。Java 17 で動作する堅牢なテストスイートを用意します。Java 17 では、​`setAccessible(true)`​ メソッドのアクセスの変更が許可されていないため、このメソッドには特に注意してください。 - シリアル化 Java 17 の制限に対応するようにシリアル化コードを更新します。コードで Gson などのライブラリを使用してクラスをシリアル化している場合、JDK クラスへのリフレクティブアクセスが含まれる Data Transfer Object (DTO) の使用に切り替えます。シリアル化ライブラリが更新されていることを確認し、リフレクションへの依存を最小限に抑えるようにコードを調整します。詳細は、[Configure Custom Serializers](https://docs.mulesoft.com/mule-runtime/latest/configure-custom-serializers)を参照してください。 - ライブラリのアップグレード ライブラリを Java 17 と互換性のあるバージョンにアップグレードします。これには、バージョン 1.14.0 への ByteBuddy の更新、0.8.10 への Jacoco の更新、バージョン 2.x への SLF4J の更新が含まれます。CGLib を ByteBuddy で置き換えて、Groovy や JRuby などの他のライブラリへの更新がないかを確認します。すべての連動関係に Java 17 との互換性があることを確認し、ランタイムの問題を回避します。 - テストスイートの実行に伴う変更 テスト方法を Java 17 に適応させます。Mockito を使用する場合、Mockito では JVM クラスをモックできないことに注意してください。モッキング用のカスタム実装を考慮し、PowerMock から新しい Mockito バージョンに切り替えます。Java 17 の変更を処理するようにテストを更新し、非推奨になったメソッドを回避します。 - Java プラットフォームモジュールシステム (JPMS) JPMS は Java 9 で導入されました。この機能では、より厳格なカプセル化が導入され、Mule モジュールで JDK クラスとやり取りする方法が影響を受けます。Mule が Java 17 および JPMS にアップグレードされると、次の変更が必要になります。 - 分割パッケージのリファクタリング: JPMS モジュール化標準に準拠するようにパッケージの再編成とリファクタリングを行うことで、内部および API パッケージ分割の問題を解決します。 - `ResourceBundle の読み込みへの対処`​: `ResourceBundleProvider`​ や代替方法を使用するなど、リソースバンドルの読み込みに関連する問題のソリューションを実装します。 - サードパーティライブラリの変更ログを分析して、JPMS に関連する Java 17 の互換性と変更を理解します。 ### [](#欠落しているコードの追加)欠落しているコードの追加 Java 17 ではリフレクションがより制限されているため、API オブジェクトにはセッターが必要になります。以前の Java 8 では、API オブジェクトには、DataWeave のすべてのアクセス可能なプロパティに対してデフォルトのコンストラクターと getter のみがあれば十分でした。DataWeave がリフレクションを使用することなくこれらのプロパティを書き込むことができるように、API オブジェクトには setter も必要になりました。 クラスが DataWeave によってインスタンス化される場合はコンストラクターと setter が必要であり、クラスが読み取られる場合は getter が必要です。クラスが返され、インスタンス化されていない場合は、getter のみが必要です。ただし、getter と setter の両方を使用すると、検証と認定のプロセスが簡素化されます。 ## [](#upgrade-your-rest-connect-connectors)カスタム REST Connect Connector のアップグレード カスタム REST Connect Connector を Java 17 にアップグレードします。 REST Connect で Java 17 がサポートされるようになりました。REST Connect Connector は、REST Connect を使用して API 仕様から生成されます。コネクタを Java 17 互換にするには、API 仕様を Exchange に再パブリッシュします。​[「REST Connect Connector ジェネレーター」](https://docs.mulesoft.com/jp/exchange/to-deploy-using-rest-connect)​を参照してください。
REST Connect に TLS のサポートが追加されました。時間を節約するために、Java 17 用に生成されたコネクタを更新するときに TLS を有効にし、コネクタの生成とアプリケーションのテストを 1 回だけ行えばいいようにします。
## [](#upgrade-your-custom-configuration-properties-providers)カスタム設定プロパティプロバイダーのアップグレード カスタム設定プロパティプロバイダーをアップグレードして Java 17 との互換性を確保するには、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ の使用に切り替えて、​[「カスタムコネクタのリリース」](#release-your-custom-connector)​の説明に従って ​`@JavaVersionSupport`​ アノテーションを使用します。カスタムコネクタと同様に ​[カスタムコネクタのための Java のアップグレード (顧客)](https://docs.mulesoft.com/jp/general/customer-connector-upgrade), just like with any custom connector. The example custom configuration properties provider mentioned in [Example: Mule SDK Module](https://docs.mulesoft.com/mule-runtime/latest/custom-configuration-properties-provider#example-mule-sdk-module)​ で説明されているすべての手順も実行する必要があります。「例: Mule SDK モジュール」に記載されているカスタム設定プロパティプロバイダーの例は、Java 17 をサポートするように更新されています。この例を参照して、カスタム設定プロパティプロバイダーを更新してください。変更されたコード (MUnit へのテストの移行を含む) がどのようなものかについては、この [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/410ee26d8b3c44adacb077e099f32886f99eb6be)​ を参照してください。 または、​[Java SDK](https://docs.mulesoft.com/mule-sdk/latest/getting-started)​ の使用への切り替えに非常に多くの変更が伴う場合、カスタム設定プロパティプロバイダーの ​`ExtensionLoadingDelegate`​ 内で ​`ExtensionDeclarer`​ を使用して宣言を追加します。変更されたコードがどのようなものかについては、この [changeset](https://github.com/mulesoft/mule-custom-properties-providers-module-example/commit/19d9d45cd52b0695f7b9c2b9019bae88f45fb228)​ を参照してください。 ## [](#test-your-custom-connector-with-munit)MUnit を使用したカスタムコネクタのテスト MUnit テストを実行し、Java 17 に対してコネクタの互換性をテストします。ローカル JDK バージョンが 17 であることを確認します。 1. Mule アプリケーションの pom.xml ファイルを開きます。 2. `mule-maven-plugin`​ バージョンを ​`${mule.maven.plugin.version}`​ パラメーターで置き換えます。 3. `munit-maven-plugin`​ をまだ追加していない場合は追加します。バージョンを ​`${munit.version}`​ パラメーターで置き換えて、​`runtimeVersion`​ を ​`${app.runtime}`​ パラメーターで置き換えます。 ```xml com.mulesoft.munit.tools munit-maven-plugin ${munit.version} test test test coverage-report true html ${app.runtime} http.port ```
MUnit 3.1 は Mule Runtime 4.3.0 以降とのみ互換性があります。コネクタに Mule Runtime 4.2.0 以前との互換性がある場合、MUnit バージョンを上書きする従来のプロファイルを作成する必要があります。
4. `munit-runner`​ や ​`munit-tools`​ などの MUnit 連動関係がある場合、各連動関係のバージョンを ​`${munit-version}`​ パラメーターで置き換えます。 5. 各コネクタ連動関係のバージョンをコネクタの Java 17 互換バージョンで置き換えます。 6. Mule プロジェクトのルートでターミナルウィンドウを開き、次のコマンドを入力します。このコマンドを実行すると、Java 17 と互換性のある Mule Runtime、MUnit、Mule Maven プラグインの最古のバージョンが表示されます。 ```bash mvn -f pom.xml -s ~/.m2/settings.xml -Dapp.runtime=4.6.0 -Dmunit.version=3.1.0 -Dmule.maven.plugin.version=4.1.0 -fae test ``` コネクタに Java 17 との互換性があるかどうかを確認できるようになりました。MUnit テストの実行についての詳細は、​[「MUnit」](https://docs.mulesoft.com/munit/latest/)​を参照してください。 使用する Mule Runtime バージョンで mule-modules-parent のバージョンが決まります。たとえば、Mule Runtime 4.6.0 を使用する場合、mule-modules-parent 1.6.0 を使用する必要があります。マイナーバージョンは、Mule Runtime 4.1.0 と mule-modules parent 1.1.0、Mule Runtime 4.2.0 と mule-modules-parent 1.2.0 などのように対応関係を維持します。 Java 17 は Mule Runtime 4.6.0 以降でサポートされます。ただし、コネクタは Mule 4.3.0 と Java 17 の両方との互換性を同時に持つことができます。コネクタに Mule 4.3.0 との互換性が必要な場合、mule-modules-parent バージョンは 1.3.0 を超えることはできません。コネクタを Java 17 と互換性のあるものにするために、必ずしも mule-modules-parent 1.6.0 を使用する必要はありません。コネクタで Mule Runtime 4.6.0 のその他の機能を活用するには、特に mule-modules-parent 1.6.0 を使用する必要があります。 ## [](#release-your-custom-connector)カスタムコネクタのリリース コードを更新し、テストが緑色になったら、カスタムコネクタの新しい Java 17 互換バージョンをリリースする準備が整いました。 1. Java 17 の互換性を伝えるには、カスタムコネクタの ​`mule-sdk-api`​ 連動関係を追加または最新バージョンにアップグレードして、カスタムコネクタの Java 互換性のメタデータを生成します。 ```xml org.mule.sdk mule-sdk-api 0.10.1 ``` 2. Java SDK の場合は、次に示すように ​`@Extension`​ アノテーションと同じクラスに ​`@JavaVersionSupport`​ アノテーションを追加して、​`JAVA_17`​ という値を含めます。
XML SDK Module は Java 17 と互換性があり、プロパティを自動的に継承するため、XML SDK についてのアノテーションを追加する必要はありません。
```java @Extension(name = "Database") @Operations(...) @JavaVersionSupport({JAVA_8, JAVA_11, JAVA_17}) public class DatabaseConnector { .. } ``` Mule 4.5.0 以降では、​`@JavaVersionSupport`​ アノテーションを指定しないカスタムコネクタは Java 8 および Java 11 と互換性があると見なされます。 カスタムコネクタは、Java 17 のみと互換性があるとマークできます。ただし、採用や下位互換性の問題が存在しないことを確認する必要があります。 Mule アプリケーションをデプロイすると、Mule アプリケーションのすべてのモジュールに Java バージョンとの互換性があることが検証されます。互換性がないことがわかると Mule はエラーをスローし、アプリケーションはデプロイされません。
XML SDK ベースのコネクタに固有のエラーメッセージ (​Extension 'module-error-handler-plugin' does not support Java 17.Supported versions are: [1.8, 11]​ など) が表示された場合は、Mule アプリケーションに Java 17 と互換性のないコネクタがまだ含まれていることを意味します。このエラーを解決するには、Mule アプリケーションのすべてのコネクタをアップグレードして、Java 17 と互換性があるようにします。
コードが Java 17 と互換性があるが、Java 17 互換性を宣言しない場合でも、テストの実行は成功します。 カスタムコネクタのクイックチェックを実行する場合、またはすべての連動関係の準備ができていない場合は、次の引数を渡して、Java サポート宣言のハードチェックをスキップします。 ```bash -M-Dmule.jvm.version.extension.enforcement=LOOSE ``` 詳細は、[Java Version Support](https://docs.mulesoft.com/mule-sdk/latest/java-version-support)を参照してください。 ## [](#関連情報)関連情報 - [Java サポート](https://docs.mulesoft.com/jp/general/java-support) # ステップ 1.API を構築するための前提条件 API 主導のジャーニーを開始する前に、必要なツールとアクセス権があることを確認してください。 - 自分の Anypoint Platform 組織のユーザー名とパスワード。まだ Anypoint Platform 組織を持っていない場合は、Anypoint Platform でトライアル組織を作成してください。 [トライアル組織の作成](https://anypoint.mulesoft.com/login/#/signup) - Anypoint Studio 7.16.0 以降をダウンロードします。Anypoint Studio は、アプリケーションを構築して Anypoint Platform にデプロイするための豊富な機能を備えた Eclipse ベースの IDE です。 [Anypoint Studio をダウンロード](https://www.mulesoft.com/lp/dl/studio) - REST 要求のテストには Advanced REST クライアントや Postman などのクライアントが必要ですので、まだ持っていなければ入手してください。このチュートリアルでは、Advanced REST クライアントを使用します。 [Advanced REST クライアントのインストール](https://github.com/advanced-rest-client/arc-electron/releases) プラットフォームによっては、別のクライアントのインストールや、 [GitHub からの Advanced REST クライアントのインストール](https://github.com/advanced-rest-client/arc-electron/releases)​が必要な場合もあります。 ## [](#役に立つヒント)役に立つヒント - ブラウザーウィンドウを 2 つ開いて、片方で手順を参照しながら、他方で作業を実行しましょう。 - Advanced REST クライアントのタイムアウトは長く設定しましょう。デバッグの実行中に REST 要求がタイムアウトしないようにするためです。 # ステップ 2.API 仕様の設計 API を設計するには、まず目的と要件を評価します。 - API のタイプはシンプルな API か、インテグレーションの一部か、あるいはバックエンドシステムの一部かを特定する。 - データフロー (一方向、両方向、等) を理解する。 - セキュリティ要件を調査する。 統合プロジェクトのスコープとフローを定義したら、[RAML](https://raml.org/)​ または [OAS](https://www.openapis.org/)​ で API 仕様を定義します。 そして、その後のステップで API 仕様を使用して、API を短時間で開発します。 ## [](#api-仕様と-api)API 仕様と API API とは、特定のリソースにアクセスするためにパブリッシュされたインターフェースであり、正しい権限と適切な構造の要求を使用することでリソースにアクセスできるようにします。 API 仕様とは、API の機能と予期される動作、そして設計の基本理念やサポートされるデータ型などの詳細を定義したものです。 API 仕様にはドキュメントと API 定義が含まれ、人間とソフトウェアが読むことのできるコントラクトを作成します。 MuleSoft は、API 仕様の作成を容易にするツールを提供しています。作成した API 仕様は、チーム、顧客、一般の人々と共有できます。 API 仕様を利用することで、API の採用が促進され、プロジェクトをより早く完了できるようになります。 ## [](#ステップ-2-1-既存の-api-仕様を調査する)ステップ 2.1: 既存の API 仕様を調査する 自分で API 仕様を作成する前に、既存の API 仕様を参考にすることで、自分と似たような状況に対して他の人々がどのようなアプローチを採ったかを学習できます。 また、同じ目的の API 仕様がすでに存在するかどうかを調べて、その API 仕様が適切であれば再利用できます。 必要な処理をすでに実装している API 仕様は、簡単に探すことができます。 - 公開 Exchange を確認します。公開 Exchange とは、MuleSoft がホストしているポータルであり、API 仕様やコネクタなど、さまざまな公開アセットをダウンロードして使用できます。 最もよく利用されている API 仕様、コネクタ、および他のアセットは、ランディングページに表示されています。 [Exchange に移動](https://www.mulesoft.com/exchange) 1. **\[Any Type (任意の種別)\] > \[REST APIs (REST API)\]**​ を選択して、REST API 仕様のみを表示します。 2. いずれかの仕様をクリックして、その API に対して定義されているデータ型と HTTP 要求を表示します。 - 自分の組織 (アカウント) の Exchange を確認します。ログインすると、表示が自分の組織の非公開 Exchange に変わります。 [Anypoint Platform に移動](https://anypoint.mulesoft.com/login) 1. 必要であれば Anypoint Platform にログインします。 2. Anypoint Platform ランディングページで、​**\[Exchange\]**​ セクションに移動して ​**\[Discover and share (検出して共有)\]**​ をクリックします。 3. いずれかの仕様をクリックして、その API に対して定義されているデータ型と HTTP 要求を表示します。トライアル組織の場合は、まだ何も表示されない場合があります。 Exchange で使用可能ないくつかのアセットを調査したら、Anypoint Platform に戻り、新しい API 仕様を Web ベースツールで作成します。 ## [](#ステップ-2-2-自分の-api-仕様を作成する)ステップ 2.2: 自分の API 仕様を作成する GET 要求に応答するシンプルな Hello World API の独自の API 仕様を作成します。 これを行うには、​[Design Center](https://docs.mulesoft.com/design-center/)​ に含まれる ​[API Designer](https://docs.mulesoft.com/design-center/design-create-publish-api-specs)​ を使用します。 1. API Designer を開きます。 [API Designer に移動](https://anypoint.mulesoft.com/designcenter/#/projects) 2. **\[Create (作成)\] > \[New API Specification (新しい API 仕様)\]**​ を選択して API Designer エディターを開きます。 3. **\[New API specification (新しい API 仕様)\]**​ ダイアログで、​**\[Project Name (プロジェクト名)\]**​ に ​`hello-world-api`​ と入力し、他のデフォルト値は変更せずに ​**\[Create API (API を作成)\]**​ をクリックします。 API Designer エディターにサンプル RAML 定義が表示されます。 4. 既存のテキストを削除して、次の RAML をコピーして貼り付けます。 ```raml #%RAML 1.0 title: hello world version: v1 description: A greeting for the world types: greeting: properties: todays-greeting: string /greeting: get: responses: 200: body: application/json: type: greeting example: {todays-greeting: "test-greeting"} 404: body: application/json: properties: message: string example: | { "message" : "Greeting not found" } ``` この API 仕様には以下が含まれます。 - 単一の HTTP 要求 (GET) - 単一のプロパティ (​`todays-greeting`​) とサンプル値を持つ単一のデータ型 (​`greeting`​) - HTTP 成功応答 - HTTP エラー応答 ## [](#ステップ-2-3-api-仕様をテストする)ステップ 2.3: API 仕様をテストする 今度は、モッキングサービスを使用して要求を送信し、​`hello-world-api`​ API 仕様をテストします。モッキングサービスは、API 仕様に基づいて有効なエンドポイントを作成し、認証、リクエストヘッダー、レスポンスヘッダーを管理するためのシンプルな UI を提供します。 API 仕様をテストする手順は次のとおりです。 1. `hello-world-api.raml`​ が開いてなければ開きます。 [API Designer に移動](https://anypoint.mulesoft.com/designcenter/#/projects) ![完成した仕様](/mulesoft/current/ja-jp/general/_images/api-spec1.png) 2. \[Documentation (ドキュメント)\] パネルが開いていない場合は、ドキュメントアイコンをクリックします。 ![API Designer ドキュメントアイコン](/mulesoft/current/ja-jp/general/_images/api-documentation-icon.png) 3. **API endpoints**​ という表示ラベルを探します。定義したエンドポイントが表示されます。HTTP 要求は緑色のボックスに表示されます。 ![「GET」 ボタン](/mulesoft/current/ja-jp/general/_images/get-button.png) 4. **\[GET\]**​ をクリックして、GET 要求と仕様の詳細情報を表示します。 ![「Response (応答)」 項目](/mulesoft/current/ja-jp/general/_images/code-response1.png) 5. **\[Show (表示)\]**​ をクリックして、各プロトコルのコード例を確認します。 6. **\[200\]**​ タブと ​**\[404\]**​ タブをクリックして、API 仕様で定義されている応答を確認します。 7. **\[Try It (試す)\]**​ ボタンをクリックします。 ![「Try It (試す)」 ボタン](/mulesoft/current/ja-jp/general/_images/try-it.png) 8. **\[Send (送信)\]**​ をクリックして、モッキングサービスが仕様に基づいて作成した一時的な要求 URL に要求を送信します。 この画面に表示されるエラーメッセージは無視しても構いません。要求が成功すると ​`200 OK`​ とテストメッセージが返されます。 ![テストが成功した場合の結果](/mulesoft/current/ja-jp/general/_images/successful-test1.png) 9. その他 (…​) メニューの ​**\[Response details (レスポンス詳細)\]**​ を選択して、モッキングサービスのレスポンスヘッダーやリクエストヘッダーを調べれば、問題を診断したり、API 仕様の動作を理解することができます。 10. テストが終了したら、​**\[Mocking Service Configuration (モッキングサービス設定)\]**​ パネルを開きます。 11. **\[Local Settings (ローカル設定)\]**​ で、​**\[Select By Default (デフォルトで選択)\]**​ を有効にします。 ![モッキングサービスアイコン](/mulesoft/current/ja-jp/general/_images/api-mocking-service-configuration-icon.png) ![無効化される前のモッキングサービスコントロール](/mulesoft/current/ja-jp/general/_images/disable-mocking-service.png) ## [](#ステップ-2-4-api-仕様をパブリッシュする)ステップ 2.4.API 仕様をパブリッシュする API をテストしたら、API を非公開 Exchange にパブリッシュして、組織内の他のユーザーがこの API を再利用できるようにします。 1. `hello-world-api.raml`​ が開いてなければ開きます。 [API Designer に移動](https://anypoint.mulesoft.com/designcenter/#/projects) 2. **\[Publish (パブリッシュ)\]**​ をクリックします。 3. **\[Publishing to Exchange (Exchange へのパブリッシュ)\]**​ ダイアログで、デフォルトを受け入れて ​**\[Publish to Exchange (Exchange にパブリッシュ)\]**​ をクリックします。 ![Exchange にパブリッシュするユーザーインターフェース](/mulesoft/current/ja-jp/general/_images/publish-to-exchange1.png) 4. 確認ダイアログで ​**\[Close (閉じる)\]**​ をクリックします。 パブリッシュ後は、組織内のすべてのユーザーに ​`hello-world-api`​ API 仕様が表示され、再利用できるようになります。 ## [](#次のステップ)次のステップ API を設計してその API 仕様を作成したところで、次は Anypoint Studio (Studio) を使用して、API の実装とインターフェースを含む ​[Mule アプリケーションを作成](https://docs.mulesoft.com/jp/general/api-led-develop)​します。 ## [](#開発者向けの詳細)開発者向けの詳細 詳細に興味がある場合は以下を参照してください。 ### [](#詳細-exchange)詳細: Exchange アセットは、公開 Exchange、内部 Exchange、または公開開発者ポータルでパブリッシュできます。 - 公開 Exchange に加えて、組織の内部のみで提供されているアセットも確認できます。 [Exchange に移動](https://anypoint.mulesoft.com/exchange/) - 公開開発者ポータルを作成してある場合は、​**\[Public portal (公開ポータル)\]**​ をクリックしてポータルでアセットを確認できます。 ### [](#詳細-api-の機能)詳細: API の機能 通常の API プロジェクトでは、さらに多くの機能を実装します。 - [認証](https://docs.mulesoft.com/studio/set-credentials-in-studio-to)​を追加する。 - RAML 仕様の定義に従って注釈を追加する。 [RAML 仕様に移動](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md/#annotations) - [API Designer または Studio を使用して Exchange からアセットを追加する。](https://docs.mulesoft.com/design-center/design-import-files) - [Studio を使用して API 仕様で公開するデータをモデリングする。](https://docs.mulesoft.com/studio/import-api-specification-design-center) - [仕様を再利用できるように API フラグメントでモジュール化する。](https://docs.mulesoft.com/design-center/design-create-publish-api-fragment) ### [](#開発者とパートナー向けの詳細)開発者とパートナー向けの詳細 API 仕様を共有してサポートするため、​[次のバージョン](https://docs.mulesoft.com/jp/exchange/to-change-raml-version)​に向けて API 仕様に関するフィードバックを集めましょう。 # ステップ 3.API の開発 API 仕様が作成できたので、次はこれを使用して Mule アプリケーションを作成します。 Anypoint Platform では、​[Mule Runtime Engine (Mule)](https://docs.mulesoft.com/mule-runtime/latest/)​ のインスタンスにデプロイするアプリケーションに API をパッケージします。 Mule は、Mule アプリケーションを実行する軽量のインテグレーションエンジンです。Mule のインスタンスは、Studio と、Mule アプリケーションおよび API をデプロイする環境に埋め込まれます。 これらの環境は対象と呼ばれます。対象の 1 つは Studio に埋め込まれる Mule で、開発とテストに使用します。もう 1 つの対象は ​[CloudHub](https://docs.mulesoft.com/cloudhub/)​ で、MuleSoft によって管理されるクラウドベースの環境です。 最初に、アプリケーションを Studio の Mule にデプロイし、次に CloudHub の Mule にデプロイします。 ![プロジェクトが存在しない Studio](/mulesoft/current/ja-jp/general/_images/empty-studio.png) 1. Package Explorer では、各プロジェクトで作成したファイルを操作できます。 2. キャンバスでは、プロジェクトの要素をドラッグして接続することで、フローを作成します。 3. \[Mule Palette (Mule パレット)\] では、コネクタやモジュールなどの標準アセットやカスタムアセットに簡単にアクセスできます。 4. 設定セクションにあるタブは、設定ダイアログや Mule デバッガーなどの開発者用ダイアログへのアクセスに使用します。 ## [](#ステップ-3-1-anypoint-platform-のログイン情報を-studio-に追加する)ステップ 3.1: Anypoint Platform のログイン情報を Studio に追加する Anypoint Platform のログイン情報は、Studio に 1 回だけ追加すれば、以降に作成するすべてのプロジェクトで使用できます。 1. Studio を開き、​**\[Anypoint Studio\] > \[Settings (設定)\]**​ を選択します。 2. \[Preferences (プリファレンス)\] ウィンドウで、​**\[Anypoint Studio\]**​ をクリックし、​**\[Authentication (認証)\]**​ をクリックします。 3. **\[Add (追加)\]**​ をクリックし、Anypoint Platform のユーザー名とパスワードを入力します。 4. **\[Sign In (サインイン)\]**​ をクリックします。 5. 必要に応じて、​**\[Secure Storage - Password Hint Needed (セキュアストレージ - パスワードヒントが必要)\]**​ ダイアログで ​**\[Yes (はい)\]**​ をクリックします。 6. **\[Apply and Close (適用して閉じる)\]**​ をクリックします。 このログイン情報は、Studio の多くの操作で自動的に使用されます。 ## [](#ステップ-3-2-インポートした-api-仕様で新しい-studio-プロジェクトを作成する)ステップ 3.2: インポートした API 仕様で新しい Studio プロジェクトを作成する このステップではプロジェクトを作成します。 1. Studio で、​**\[File (ファイル)\] > \[New (新規)\] > \[Mule Project (Mule プロジェクト)\]**​ を選択します。 ![新しいプロジェクトのダイアログ](/mulesoft/current/ja-jp/general/_images/new-project-dialog.png) 2. ダイアログボックスで、次の値を設定します。 - **Project Name (プロジェクト名)**​: `hello-world-app` - **Runtime**​: 選択肢があれば、最新バージョンの Mule を選択します。これが Studio でテスト用にホストされる Mule Runtime Engine となります。 - **\[Import a published API (パブリッシュ済みの API をインポート)\]**​ タブを選択します。 1. 緑のプラス記号をクリックして ​**\[From Exchange (Exchange から)\]**​ を選択します。 2. 必要であれば組織にログインします。 3. 検索ボックスに ​`hello-world`​ と入力します。 4. **hello-world-api**​ をクリックして選択します。 5. **\[Add (追加)\]**​ をクリックして ​**\[Selected modules (選択したモジュール)\]**​ リストに移動し、​**\[Finish (完了)\]**​ をクリックします。 3. **\[Scaffold flows from these API specifications (これらの API 仕様からフローをスキャフォールディングする)\]**​ チェックボックスがオンであることを確認し、​**\[Finish (完了)\]**​ をクリックします。 この設定では、Studio はデフォルトのエラー処理や他の便利な機能をプロジェクトに追加します。 Studio によって ​`hello-world.xml`​ という XML ファイルが作成され、キャンバスの ​**\[Message Flow (メッセージフロー)\]**​ ビューで開かれ、API インターフェースで必要な基本要素が表示されます。 ![スキャフォールディングありで API 仕様をインポートした後の Studio のビュー](/mulesoft/current/ja-jp/general/_images/my-first-project.png) キャンバスを下にスクロールして、アプリケーションに追加されたスキャフォールディングを確認します。 - 要求を受信できる HTTP リスナー - メッセージをルーティングする APIkit ルーター - 各種エラー条件用のエラーハンドラー - **hello-world-app-console**​ というコンソール (このプロジェクトでは使用しません) - 設定の大半を行うエンドポイント ​`/greeting`​ への GET 要求 キャンバスには 3 つの異なるビューがあります。 ![1 つのキャンバスと 3 つのビューすべてへのリンク](/mulesoft/current/ja-jp/general/_images/canvas-tabs.png) - **\[Message Flow (メッセージフロー)\]**​ は、モジュール、コネクタなどのアセットをキャンバスにドラッグし、それらのリレーションを作成するために使用します。 - **\[Global Elements (グローバル要素)\]**​ は、複数のプロジェクトで使用するグローバル要素を指定するために使用します。 - **\[Configuration XML (設定 XML)\]**​ は、プロジェクトの XML を直接編集するために使用します。 キャンバスの ​**Listener**​ コンポーネントで設定されている値を確認します。 1. **\[Listener\]**​ をダブルクリックして、全体的な設定値を表示します。 2. 設定名の横にある編集アイコン ​![ノートの上の鉛筆](/mulesoft/current/ja-jp/general/_images/edit-module-version-icon.png)​をクリックして、ホストが ​`0.0.0.0`​ でポートが ​`8081`​ であることを確認します。 3. **\[Test Connection (接続をテスト)\]**​ をクリックし、接続テストが成功したと報告されたら ​**\[OK\]**​ をクリックします。 4. **\[OK\]**​ をクリックして、設定を閉じます。 **\[Global Configuration Elements (グローバル設定要素)\]**​ タブに戻ります。 5. **\[Message Flow (メッセージフロー)\]**​ をクリックしてキャンバスに戻ります。 Listener コンポーネントの全体的な設定値が引き続き表示されます。 6. **\[Path (パス)\]**​ が ​**/api/**\*​ に設定されていることを確認します。このベストプラクティスにより、すべてのエンドポイントが ​`base-URI/api/endpoint`​ のような形式になります。 次のステップでは、ビジネスロジックを作成して、この API に必要な要素を設定します。 ## [](#ステップ-3-3-api-を設定する)ステップ 3.3: API を設定する Studio から提供されたスキャフォールディングを使用し、​`/greeting`​ エンドポイントモジュールを設定してアプリケーションを完成させます。 1. **\[Message Flow (メッセージフロー)\]**​ ビューで、​`/greeting`​ エンドポイントモジュールが表示されるまでキャンバスを下にスクロールします。 ![スキャフォールディングによって作成された GET Connector のビュー](/mulesoft/current/ja-jp/general/_images/greeting-module.png) 2. **\[Transform Message\]**​ コンポーネントを右クリックして削除します。 3. **\[Mule Palette (Mule パレット)\]**​ で ​**\[Favorites (お気に入り)\]**​ を選択して、コンポーネント、サービス、トランスフォーマー、ルーターのリストを表示します。 4. **\[Set Payload\]**​ をクリックして選択し、Transform Message を削除した ​**\[Process (プロセス)\]**​ スペースにドラッグします。 5. `hello-world-api`​ API からの応答として送信されるデータを表示するロジックを指定します。 1. フローに追加した ​**Set Payload**​ トランスフォーマーをクリックします。 ![キャンバスのビューと Set Payload Connector の設定ダイアログ](/mulesoft/current/ja-jp/general/_images/set-payload.png) 2. **\[General (一般)\]**​ タブで ​**\[fx\]**​ (関数) ボタンをクリックして選択解除します。このチュートリアルでは、値をハードコードします。 3. **\[Settings (設定)\]**​ で、​**\[Value (値)\]**​ を ​`Today the greeting is Hello`​ に設定します。 6. Anypoint Studio メニューで、​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択します。 7. キャンバスの ​**\[Configuration XML (設定 XML)\]**​ をクリックして、作業で生成された XML を確認します。 8. **\[Message Flow (メッセージフロー)\]**​ をクリックして、次のステップ用にキャンバスを設定します。 これで、API を公開するためにデプロイできるシンプルな Mule アプリケーションを含むプロジェクトが作成されました。

この API は、通常の本番対応 API よりシンプルです。

  • ペイロード (GET 要求で供給されます) は、プロジェクト設定でハードコードされています。本番対応 API では、ペイロード値は別の提供元から供給されるか、もしくは変数の関数や DataWeave 式として定義されます。

  • インターフェースと実装 (ビジネスロジック) を別々の XML ファイルに分けるのがベストプラクティスですが、このチュートリアルでは簡潔にするために省略されています。

## [](#ステップ-3-4-api-をテストする)ステップ 3.4.API をテストする API を含む Studio プロジェクトを Mule Runtime Engine (Mule) で実行し、サードパーティクライアントでテストします。 1. キャンバス上の任意の場所を右クリックして、​**\[Run project hello-world-app (hello-world-app プロジェクトを実行)\]**​ を選択します。 Studio 内でコンソールが開き、アプリケーションが Mule にデプロイされると状況メッセージが表示されます。 API を含むアプリケーションが Mule にデプロイされると、次のメッセージが表示されます。 \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* \* - - + APPLICATION + - - \* - - + DOMAIN + - - \* - - + STATUS + - - \* \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* \* hello-world-app \* default \* DEPLOYED \* \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* 2. アプリケーションをテストするため、REST クライアント (Advanced Rest クライアント) を開いて GET 要求を送信します。 `http://localhost:8081/api/greeting` REST クライアントで ​`200 OK`​ メッセージと ​`Today the greeting is Hello`​ という本文が返されます。 3. キャンバス内を右クリックして、​**\[Stop project hello-word-app (hello-word-app プロジェクトを停止)\]**​ を選択します。 ## [](#ステップ-3-5-組織でビジネスグループを作成する)ステップ 3.5.組織でビジネスグループを作成する アプリケーションを Exchange にパブリッシュして他のユーザーと共有するためには、先にトライアル組織でビジネスグループを作成する必要があります。 Exchange のアセットは、ルートビジネスグループ以外のビジネスグループに属している必要があります。 すでに組織でビジネスグループを作成してある場合は、このステップは省略してください。 ビジネスグループを作成する手順は次のとおりです。 1. Anypoint Platform にログインします。 [Anypoint Platform に移動](https://anypoint.mulesoft.com/login/#/signup) 2. ランディングページの ​**\[Management Center\]**​ を見つけて、​**\[Access Management (アクセス管理)\]**​ をクリックします。 3. ナビゲーションパネルで、​**\[Business Groups (ビジネスグループ)\]**​ をクリックします。 4. **\[Create business group (ビジネスグループを作成)\]**​ をクリックして ​**\[Name (名前)\]**​ に​`「My Top Business Group」`​ (上位のビジネスグループ) と入力します。 5. **\[Parent business group (パートナービジネスグループ)\]**​ ドロップダウンから、自分が管理者になっているビジネスグループを選択します。 6. **\[Owner (オーナー)\]**​ に自分のユーザー名を入力し、見つかった場合は選択します。 7. **\[Can create environments (環境を作成可能)\]**​ チェックボックスをオンにして、​**\[Create (作成)\]**​ をクリックします。 \[Access Management (アクセス管理)\] 画面の組織名の下に新しいビジネスグループが表示されます。 ## [](#ステップ-3-6-api-を-exchange-にパブリッシュする)ステップ 3.6.API を Exchange にパブリッシュする 他のユーザーがテンプレートやサンプルとして使用できるように、API を Exchange にパブリッシュします。 1. Studio の Package Explorer で、​`hello-world-app`​ プロジェクトを右クリックします。 2. **\[Anypoint Platform\] > \[Publish to Exchange (Exchange にパブリッシュ)\]**​ を選択します。 ![API を Exchange にパブリッシュするためのダイアログ](/mulesoft/current/ja-jp/general/_images/pub-to-exchange.png) 3. プロジェクトの値を入力します。 - **\[User (ユーザー)\]**​ では、自分のユーザー名を選択します。 - **\[Business group (ビジネスグループ)\]**​ で、作成した ​**\[My Top Business Group (上位のビジネスグループ)\]**​ ビジネスグループを選択します。この項目にデフォルトで表示されるルートビジネスグループを使用することはできません。ログイン情報の期限が切れている場合は、​**\[Add account (アカウントを追加)\]**​ をクリックしてログイン情報を再び追加します。 - **\[Version (バージョン)\]**​ はデフォルト値のままにしておきます。 - **\[Project type (プロジェクトタイプ)\] > \[Example (サンプル)\]**​ を選択します。 4. **\[Next (次へ)\]**​ をクリックします。 5. ユーザーが Exchange で使用可能なアセットを見つけやすくなるように、ドキュメント、説明、タグを追加できます。 6. **\[Finish (完了)\]**​ をクリックします。 7. 確認が求められたら ​**\[Yes (はい)\]**​ をクリックして続行します。 プロジェクトが Exchange にアップロードされると、プロジェクトへの直接リンクが表示されます。 ![Exchange にパブリッシュされた API へのリンクを表示するダイアログ](/mulesoft/current/ja-jp/general/_images/link-to-published-api.png) 8. リンクをクリックして、Exchange でプロジェクトを表示します。 ![デプロイした hello-world-app のホームページ](/mulesoft/current/ja-jp/general/_images/api-led-assets-list-arrow.png) 9. **\[Back to Assets List (アセットリストに戻る)\]**​ をクリックします。 パブリッシュしたばかりのアセットの Exchange タイルを確認できるようになっています。 10. (省略可能) Exchange からサインアウトして、作成したばかりのアセットを検索します。 1. **hello-world-app**​ のタイルをクリックします。 2. **\[Asset Versions (アセットバージョン)\]**​ セクションで、その他 (…​) メニューをクリックして ​**\[Version detail (バージョン詳細)\]**​ を選択します。HTTP Connector、Sockets Connector、APIKit モジュールが連動関係としてリストされます。 + ​![Exchange で表示されるアプリケーションページのバージョン詳細](/mulesoft/current/ja-jp/general/_images/published-in-exchange.png) 11. Exchange でパブリッシュしたアセットを確認したら、Studio に戻って ​**\[OK\]**​ をクリックし、開いているダイアログウィンドウを閉じます。 ## [](#次のステップ)次のステップ API の開発を完了するため、次に以下を追加します。 - Validation - デバッグをサポートするイベントログ - エラー処理 - API の単体テスト 完成したら、アプリケーションの更新後のバージョンを改めてパブリッシュします。 [次へ](https://docs.mulesoft.com/jp/general/api-led-test) ## [](#開発者向けの詳細)開発者向けの詳細 Anypoint Platform と Studio の機能について知るには、以下を参照してください。 - DataWeave でデータを変換する。​[クイックスタート](https://docs.mulesoft.com/dataweave/latest/dataweave-quickstart)​、​[チュートリアル](https://docs.mulesoft.com/mule-runtime/latest/mule-app-tutorial)​。 - [フロー、サブフロー、非同期キュー](https://docs.mulesoft.com/mule-runtime/latest/about-flows)​を使用して Mule アプリケーションを組み立てる。 - アプリケーションのメタデータ (スキーマ) を定義して管理する。​[メタデータエディター](https://docs.mulesoft.com/studio/metadata-editor-concept)​。 - [API Manager の Analytics](https://docs.mulesoft.com/jp/api-manager/latest/analytics-landing-page)​ を使用して重要業績指標を実装する。 - イベントを条件的にルーティングする。​[Choice router](https://docs.mulesoft.com/mule-runtime/latest/choice-router-concept)​、​[Scatter-Gather ルーター](https://docs.mulesoft.com/mule-runtime/latest/scatter-gather-concept)​。 # ステップ 4.検証とエラー処理の追加 これまでに、API を作成してサードパーティクライアントで HTTP 要求をテストし、API を Exchange にパブリッシュしました。 次は Studio を使用して検証と単体テストを追加します。Studio では、すでに作成されているスキャフォールディングを使用して以下を行います。 - Validation Module を使用して入力を検証する。 - 1 つのエラー条件に対してエラーハンドラーを作成する。 ## [](#ステップ-4-1-検証)ステップ 4.1: 検証 ユーザー入力が API に対して適切であることを保証するための操作を、Validation Module から API 実装に追加します。 作成した API は非常にシンプルであるため、テストもシンプルになります。ペイロードのサイズが許容範囲内であるかどうかをテストします。 **Validate size**​ 操作を ​`hello-world-app`​ プロジェクトに追加します。 1. Studio の ​`hello-world-app`​ プロジェクトで、​`hello-world-api.xml`​ がまだ開いていなければ開き、キャンバスの ​**\[Message Flow (メッセージフロー)\]**​ タブを表示します。 2. **\[Mule Palette (Mule パレット)\]**​ で、​**\[Add Modules (モジュールを追加)\] > \[Validation (検証)\]**​ を選択して ​**\[Mule Palette (Mule パレット)\]**​ にドラッグします。 ![Validation Module が選択された \[Mule Palette (Mule パレット)](/mulesoft/current/ja-jp/general/_images/validation-module.png) のビュー\] 3. 操作のリストから、​**Validate size**​ を Studio キャンバスにドラッグして、エンドポイントモジュール内の ​**Set Payload**​ の右にドロップします。 ![GET モジュールにドロップされた Validate size](/mulesoft/current/ja-jp/general/_images/validate-size.png) 4. **Validate size**​ をクリックして ​**\[General (一般)\]**​ 設定タブを表示します。 ![Validate size の設定タブ](/mulesoft/current/ja-jp/general/_images/configure-validate.png) 5. **\[General (一般)\]**​ タブで以下の値を設定します。 1. **Value (値)**​: **\[fx\]**​ ボタンをクリックしてリテラルモードから式モードに変更し、テキストボックス内の文字列の後に ​`payload`​ と入力します。閉じ括弧は自動的に入力されます。 2. **Min**​: `6` 3. **Max**​: `30` 4. **\[Error options (エラーオプション)\] > \[Message (メッセージ)\]**​: `The specified message is either too long or too short.` 6. Studio のメインメニューから ​**\[File (ファイル)\] > \[Save All (すべて保存)\]**​ を選択して、変更内容を保存します。 7. キャンバス内を右クリックして、​**\[Run project hello-world-app (hello-world-app プロジェクトを実行)\]**​ を選択します。 8. `hello-world-app`​ がデプロイされたことを示すコンソールメッセージが表示されたら、Advanced Rest クライアントまたは同様のツールを使用して要求を送信します。 ```xml http://localhost:8081/api/greeting ``` 要求クライアントで、​`200 OK`​ と ​`Today the greeting is Hello.`​ が含まれるレスポンスヘッダーが報告されます。これは、​**Validate size**​ 操作で設定した制限内である場合に予期される動作を示しています。 9. キャンバスを右クリックして、​**\[Stop project hello-world-app (hello-world-app プロジェクトを停止)\]**​ を選択します。 ペイロードが短すぎる場合に検証が正しく機能することをテストするため、デバッガーを使用して、エラーがトリガーされるまで各イベントをステップ実行します。 1. Studio の ​`hello-world-app`​ プロジェクトで ​`hello-world-api.xml`​ を開きます。 2. **Set Payload**​ をクリックして、値を ​`Hi.`​ に設定します。 3. **\[Mule Palette (Mule パレット)\]**​ で ​**\[Favorites (お気に入り)\] > \[Logger\]**​ を選択し、Logger を ​**Set Payload**​ と ​**Validate size**​ の間にドラッグします。Logger はデバッグしやすいようにプロセスを停止します。Logger の設定は不要です。 4. **Set Payload**​ を右クリックして ​**\[Add Breakpoint (ブレークポイントを追加)\]**​. を選択します。 5. **Logger**​ と ​**Validate size**​ で上記の手順を繰り返します。 6. キャンバスを右クリックして、​**\[Debug project hello-world-app (hello-world-app プロジェクトをデバッグ)\]**​ を選択します。\[Mule Debug (Mule デバッグ)\] パースペクティブを開くように求められたら、​**\[Remember my decision (私の決定を記憶する)\]** チェックボックスをオンにして ​**\[Yes (はい)\]**​ をクリックします。 ![デバッガービューの Studio](/mulesoft/current/ja-jp/general/_images/mule-debugger-view.png) 7. Advanced REST クライアントで ​`/greeting`​ エンドポイントに要求を送信します。 ```xml http://localhost:8081/api/greeting ``` 8. Studio に戻り、​**Set Payload**​ が破線で囲まれていることを確認します。 9. キャンバスで ​**Set Payload**​ をクリックし、​**\[Mule Debugger (Mule デバッガー)\]**​ で ​**Set Payload**​ ノードを開きます。 10. **Set Payload**​ を開いて、ペイロード値が ​`Hi.`​ の 3 文字であることを確認します。 **Validate size**​ 操作は 6 文字以上が必要と設定しているため、これによってエラーがトリガーされます。 11. デバッガーウィンドウの上に表示されている ​**\[Next processor (次のプロセッサー)\]**​ (曲線の黄色い矢印) をクリックします。 ![次の切り替えポイントに移動するための \[Next processor (次のプロセッサー)](/mulesoft/current/ja-jp/general/_images/next-toggle.png) コントロール, 500\] このコントロールにマウスポインターを置くと、​**「Next processor (次のプロセッサー) (F6)」**​と表示され、正しいコントロールであることを確認できます。デバッガーペインには、Logger Connector が表示されます。 12. 曲線の黄色い矢印を再びクリックして、​**Validate size**​ 操作に移動します。 13. 曲線の黄色い矢印を再びクリックすると、定義したエラーメッセージがデバッガーペインの ​**error**​ オブジェクトに表示され、破線が ​**Validate size**​ 操作内に表示されていることを確認できます。 ![Validate size のエラーが表示されたデバッガービュー](/mulesoft/current/ja-jp/general/_images/validation-error.png) 14. **\[Next processor (次のプロセッサー)\]**​ を再びクリックして、キャンバスにメッセージフローの先頭が表示され、インポート時に追加されたスキャフォールディング項目の 1 つである APIkit ルーターが赤い破線で囲まれていることを確認します。このルーターがエラーを処理します。 15. **\[Next processor (次のプロセッサー)\]**​ を再びクリックしてフローを完了します。プロセスが完了したため、Mule デバッガーペインは空白になります。 16. Advanced Rest クライアントを確認します。​`500 Server Error`​ とペイロード値が表示されます。 ペイロードではなく定義してあるエラーが返されたことを確認するには、いずれかのエラーハンドラーを設定する必要があります。 17. キャンバスを右クリックして、​**\[Stop project hello-world-app (hello-world-app プロジェクトを停止)\]**​ を選択します。 18. **\[Window (ウィンドウ)\] > \[Perspective (パースペクティブ)\] > \[Open Perspective (パースペクティブを開く)\] > \[Mule Design (Mule デザイン)\]**​ を選択してデバッガービューを終了します。 ## [](#ステップ-4-2-エラー処理を追加する)ステップ 4.2: エラー処理を追加する では、セットアップした検証用のエラーハンドラーを追加しましょう。 1. Studio の ​**\[Mule Palette (Mule パレット)\]**​ で ​**\[Core\] > \[On Error Propagate\]**​ を選択し、このエラーハンドラーを ​**get:\\greeting:hello-world-app-config**​ の ​**Error handling**​ までドラッグします。 ![GET モジュールへのエラーハンドラーの追加と設定](/mulesoft/current/ja-jp/general/_images/on-error.png) 2. **\[General (一般)\]**​ 設定タブで、エラーハンドラーを設定します。 - **Display Name (表示名):**​ ​`On Error Propagate` - **Type (種別):**​ 検索アイコンをクリックして、​**VALIDATION:INVALID\_SIZE**​ を選択します。 - 他のデフォルト値は変更しないでください。 3. **Set Payload**​ 操作を新しい ​**On Error Propagate**​ エラーハンドラーにドラッグします。 4. 新しい Set Payload 操作を設定します。 1. **Set Payload**​ をダブルクリックして ​**\[General (一般)\]**​ タブを開きます。 2. **\[Settings (設定)\] > \[Value (値)\]:**​ ​`payload`​ を ​`error.description`​ に置き換えます。 5. **\[File (ファイル)\] > \[Save All (すべて保存)\]**​ をクリックして、変更内容を保存します。 6. **Set Payload**​、​**Logger**​、​**Validate size**​ のブレークポイントを削除してある場合は、これらにブレークポイントを追加します。 7. キャンバス内を右クリックして、​**\[Debug project hello-world-app (hello-world-app プロジェクトをデバッグ)\]**​ を選択します。 8. アプリケーションがデプロイされたら、Advanced Rest クライアントからクエリ ​`http://localhost:8081/api/greeting`​ を送信し、曲線の黄色い矢印を使用して各ブレークポイントをステップ実行します。 9. **On Error Propagate**​ の ​**Set Payload**​ に達すると、ペイロードが ​**Validate size**​ で作成したエラーメッセージに設定されているのを確認できます。 ![エラーハンドラー内の Set Payload のデバッガーメッセージ](/mulesoft/current/ja-jp/general/_images/payload-message.png) 10. メッセージフローの ​**APIkit Router**​ に達すると、元のペイロード ​`Hi.`​ の代わりにエラーメッセージが表示されます。 ![ペイロードのエラーメッセージを表示している APIkit ルーターのブレークポイント](/mulesoft/current/ja-jp/general/_images/payload-response.png) 11. ステップを最後まで実行して Advanced Rest クライアントの応答を確認すると、​**500 Server Error**​ がエラーメッセージと一緒に返されていることが分かります。 12. 元のペイロードを ​`Today the greeting is Hello.`​ に戻します。 13. Studio のビューを ​**\[Window (ウィンドウ)\] > \[Perspective (パースペクティブ)\] > \[Open Perspective (パースペクティブを開く)\] > \[Mule Design (Mule デザイン)\]**​ に戻します。 次に、変更後のアプリケーションをパブリッシュします。 ## [](#ステップ-4-3-変更後のアプリケーションをパブリッシュする)ステップ 4.3: 変更後のアプリケーションをパブリッシュする 改善した API を Exchange で公開します。 1. Studio の ​**Package Explorer**​ で、​`hello-world-app`​ プロジェクトを右クリックします。 2. **\[Anypoint Platform\] > \[Publish to Exchange (Exchange にパブリッシュ)\]**​ を選択します。 3. 以前と同じビジネスグループを選択します。有効なビジネスグループを選択するまで、​**\[Next (次へ)\]**​ ボタンはアクティブになりません。 4. バージョン番号は自動的に増分されますので、そのまま受け入れます。 5. **\[Project type (プロジェクトタイプ)\]**​ で ​**\[Example (サンプル)\]**​ を選択します。 6. **\[Next (次へ)\]**​ をクリックします。 7. **\[Finish (完了)\]**​ をクリックします。 Exchange に新たにパブリッシュされた API バージョンへの直接リンクが Studio に表示されます。このリンクをコピーすることで、他のユーザーと API を共有できます。 ## [](#次のステップ)次のステップ 他のユーザーが ​`/greeting`​ エンドポイントに要求を送信できるように、​[API をデプロイ](https://docs.mulesoft.com/jp/general/api-led-deploy)​できるようになりました。 ## [](#開発者向けの詳細)開発者向けの詳細 ユニットテスト、エラー処理、そして検証については、学習することがたくさんあります。 詳細を確認してください。 - [MUnit](https://docs.mulesoft.com/munit/latest/) - [Validation Module と操作](https://docs.mulesoft.com/jp/validation-connector/latest/) - [Mule 4 のエラー処理](https://docs.mulesoft.com/mule-runtime/latest/mule-error-concept) # ステップ 5.CloudHub への API のデプロイ 新しい API を含む Mule アプリケーションを Studio で作成してテストしたので、次は API を CloudHub にデプロイすることができます。まず、Exchange から API をテストできるようにするために API プロキシを作成します。その後、API をサービス拒否攻撃から保護するためのレート制限ポリシーをセットアップします。 ## [](#ステップ-5-1-api-を-cloudhub-にデプロイする)ステップ 5.1: API を CloudHub にデプロイする この API を Mule アプリケーションとしてデプロイする手順は次のとおりです。 1. Studio で \[Mule Design (Mule デザイン)\] パースペクティブに切り替え、Package Explorer で ​`hello-world-app`​ プロジェクトを右クリックして、​**\[Anypoint Platform\] > \[Deploy to CloudHub (CloudHub にデプロイ)\]**​ を選択します。 2. Anypoint Platform のユーザー名とパスワードが要求された場合はそれぞれを入力して ​**\[Sign In (サインイン)\]**​ をクリックします。 ![CloudHub にデプロイするためのダイアログ](/mulesoft/current/ja-jp/general/_images/deploy1.png) 3. API のデプロイ先となる自分のアカウントの Sandbox で作業を行う必要があります。​**\[Sandbox\]**​ ではなく ​**\[Design (デザイン)\]**​ と表示されている場合は以下の手順を実行してください。 1. **\[Design (デザイン)\]**​ をクリックして \[Switch Environment (環境の切り替え)\] ダイアログを開きます。 2. **\[Sandbox\]**​ をクリックして ​**\[Switch (切り替え)\]**​ をクリックします。 4. \[Deploying Application (アプリケーションのデプロイ)\] に、アプリケーション名として ​`hello-world-greeting-firstname-lastname`​ と入力します。すべてのアプリケーション名と API 参照名は CloudHub 全体で一意である必要があります。この例では、​`hello-world-greeting-sandy-kim`​ を使用します。 5. **\[Deployment Target (デプロイメント対象)\]**​ に、​**\[CloudHub\]**​ を選択します。 6. 他のデフォルト値は変更しないでください。 7. **\[Deploy Application (アプリケーションをデプロイ)\]**​ をクリックします。少しの間を置いて、デプロイメントの状況がウィンドウに表示されます。 8. **\[Open in Browser (ブラウザーで開く)\]**​ をクリックして、Runtime Manager で表示される状況を確認します。 ![アプリケーションのデプロイ状況を表示している Runtime Manager](/mulesoft/current/ja-jp/general/_images/open-in-browser.png) プロジェクトが正常にデプロイされると、Runtime Manager に表示されている状況が ​**\[Started (開始済み)\]**​ に変わります。 9. API デプロイメントをテストするため、Advanced Rest クライアントから要求を送信します。 1. **\[Started (開始済み)\]**​ をクリックして​**アプリケーションの URL**​ を表示します。 2. アプリケーションの URL 値をコピーします。この場合は ​`hello-world-greeting.sandy-kim.us-e2.cloudhub.io`​ です。 + この URL は、後でプロキシ API を設定する際にも使用します。 + 3. Advanced Rest クライアントで、コピーしたベース URI に要求を送信します。API エンドポイントの ​`/api/greeting`​ を忘れずに付加してください。 ```xml GET http://hello-world-greeting.sandy-kim.us-e2.cloudhub.io/api/greeting ``` 4. `200 OK`​ と指定した挨拶文の ​`Today the greeting is Hello.`​ が表示されれば、作成した API は正常にデプロイされています。 次に、アクセスを制限してサービスを保護するために、この API 用の API プロキシアプリケーションを作成する必要があります。 レート制限ポリシーを追加しますが、これは API の実行中に行うことができます。 ## [](#ステップ-5-2-api-プロキシアプリケーションを作成してデプロイする)ステップ 5.2: API プロキシアプリケーションを作成してデプロイする エンドポイントにレート制限ポリシーを追加する前に、API を API Manager に追加して API プロキシを作成する必要があります。 1. Anypoint Platform にログインします。 [Anypoint Platform に移動](https://anypoint.mulesoft.com/login) 2. **\[API Manager\]**​ をクリックします。 3. **\[Sandbox\]**​ をクリックして Sandbox 環境に切り替えます。 4. **\[Add API (API を追加)\] > \[Add new API (新しい API を追加)\]**​ を選択します。 5. \[New API (新しい API)\] ページで、​**\[Mule gateway (Mule ゲートウェイ)\]**​ を選択し、次の値を選択します。 - **\[Proxy type (プロキシ種別)\]**​ に、​**\[Deploy a proxy application (プロキシアプリケーションをデプロイ)\]**​ を選択します。 - **\[Target type (対象種別)\]**​ に、​**\[CloudHub\]**​ を選択します。 6. **\[Proxy app name (プロキシアプリケーション名)\]**​ (これは Runtime Manager に表示されるアプリケーション名です) に ​**hello-world-greeting-proxy**​ と入力し、最後に自分の姓または他の一意の文字列を付加してプロキシ名が一意になるようにし、​**\[Next (次へ)\]**​ をクリックします。 7. **\[Select API from Exchange (Exchange から API を選択)\]**​ をまだ選択していない場合はクリックします。 8. **\[Select API (API を選択)\]**​ 検索ボックスに ​`hello`​ と入力し、ドロップダウンから ​**\[hello-world-api\]**​ を選択します。ここでは、​`hello-world-greeting`​ というデプロイ済みアプリケーションではなく、API を編集しています。 9. 次のデフォルト値をそのままにして、​**\[Next (次へ)\]**​ をクリックします。 - **Asset type (アセットタイプ): RAML/OAS** - **API version (API バージョン): v1 (最新)** - **Asset version (アセットバージョン): 1.0.0** 10. **\[Downstream (ダウンストリーム)\]**​ ページで、デフォルトを受け入れて ​**\[Next (次へ)\]**​ をクリックします。 11. **\[Upstream (アップストリーム)\]**​ ページで、アップストリーム URL を入力して ​**\[Next (次へ)\]**​ をクリックします。 アップストリーム URL は、Runtime Manager のデプロイ済みアプリケーションからの ​**\[App url (アプリケーション URL)\]**​ です。 12. **\[Save & Deploy (保存してデプロイ)\]**​ をクリックします。 13. API インスタンスがデプロイされたら、Anypoint Runtime Manager へのリンクが記載された確認メッセージが表示されます。リンクをクリックして、API インスタンスの詳細を表示します。 これで API が API Manager で管理されるようになったので、次のステップでプロキシを作成できます。 ## [](#ステップ-5-3-api-プロキシの設定)ステップ 5.3.API プロキシの設定 この時点で、外部には公開しない実装 URL と、設定後は外部と共有しても安全なプロキシ URL が用意されました。 プロキシを設定する手順は次のとおりです。 1. **\[API Manager\] > \[API Administration (API 管理)\]**​ で、​**hello-world-api**​ リンクをクリックします。 2. **\[API Summary (API の概要)\]**​ で、​**\[Proxy URL (プロキシ URL)\]**​ リンクをクリックしてコピーします。 3. 鉛筆アイコンをクリックして API インスタンスを編集します。 4. **\[Downstream (ダウンストリーム)\]**​ セクションで、コピーしたばかりのリンクを ​**\[Consumer endpoint (コンシューマーエンドポイント)\]**​ に貼り付け、​**\[Save & Apply (保存して適用)\]**​ をクリックします。 次の手順で、Exchange からプロキシエンドポイントをテストできます。 1. **\[Actions (アクション)\] > \[View API in Exchange (Exchange で API を表示)\]**​ を選択します。 2. \[Expand (展開)\] アイコンをクリックし、​**\[Manage versions (バージョンを管理)\]**​ をクリックします。 モッキングサービスバージョンと、今 Sandbox 環境で作成した新しいプロキシが表示されます。 3. **\[Close (閉じる)\]**​ をクリックします。 4. **/greeting**​ をクリックして開き、​**\[GET\]**​ をクリックします。 5. **\[Select server (サーバーを選択)\]**​ で、メニューを展開して ​**\[Sandbox - v1:\]**​ を選択します。 ![使用可能なサーバーのリストが表示されている展開済みのサーバーメニュー](/mulesoft/current/ja-jp/general/_images/api-led-select-server-exchange.png) 6. **\[Send (送信)\]**​ をクリックします。応答が ​`200 OK`​ で挨拶文が ​`Today the greeting is Hello.`​ であることを確認してください。 以下の手順でプロキシの設定を完了します。 1. **\[Home (ホーム)\]**​ をクリックして API の概要に戻ります。 2. **\[Share (共有)\]**​ をクリックします。 3. **\[Share (共有)\]**​ ダイアログで、​**\[Public (公開)\]**​ をクリックして API バージョンを選択し、公開 Exchange ポータルで使用可能にします。 ![「Public (公開)」 とバージョン v1 のチェックボックスがオンになっている 「Share (共有)」 ウィンドウ](/mulesoft/current/ja-jp/general/_images/api-led-share-api.png) 4. **\[Save (保存)\]**​ をクリックします。 ## [](#ステップ-5-4-レート制限ポリシーを追加する)ステップ 5.4: レート制限ポリシーを追加する レート制限ポリシーを追加する手順は次のとおりです。 1. API Manager に戻ります。 2. **\[API Administration (API 管理)\]**​ で、​**hello-world-api**​ リンクをクリックします。 3. ナビゲーションで ​**\[Policies (ポリシー)\]**​ をクリックします。 4. **\[Add policy (ポリシーを追加)\]**​ をクリックします。 5. **\[Quality of service (サービスの品質)\]**​ セクションまでスクロールし、​**\[Rate limiting (レート制限)\]**​ (​**\[Rate limiting - SLA based (レート制限 - SLA ベース)\]**​ ではありません) を選択して ​**\[Next (次へ)\]**​ をクリックします。 6. **\[Configure Rate limiting policy (レート制限ポリシーを設定)\]**​ ページで、次のレート制限値を設定します。 - **Number of Requests (要求数)**​: `3` - **Time Period (期間)**​: `1` - **Time Unit (時間単位)**​: **Minute (分)** 7. **\[Expose Headers (ヘッダーを公開)\]**​ を選択します。 ![レート制限値が選択済みのレート制限ポリシー設定ページ](/mulesoft/current/ja-jp/general/_images/api-led-rate-limiting-config.png) 8. **\[Advanced options (詳細オプション)\]**​ セクションで最新バージョンを選択します。 9. **\[Method & Resource conditions (メソッドとリソースの条件)\]**​: **\[Apply configurations to all API methods & resources (設定をすべての API メソッドおよびリソースに適用)\]**​ を選択し、​**\[Apply (適用)\]**​ をクリックします。 \[Policies (ポリシー)\] ホームページに新しいポリシーが表示されます。 プロキシにポリシーが設定されていることを示すように API インスタンスの表示ラベルを変更します。 1. ナビゲーションで ​**\[API Summary (API の概要)\]**​ をクリックします。 2. 鉛筆アイコンをクリックして ​**\[Instance Label (インスタンスの表示ラベル)\]**​ の値を ​`Rate-limiting policy`​ に変更します。 3. **\[Save & Apply (保存して適用)\]**​ をクリックします。 新しいポリシーをテストします。 Advanced Rest クライアントで、​`429 Too Many Requests`​ が返されるまで GET 要求を API プロキシ ​`http://hello-world-greeting-proxy.us-e2.cloudhub.io/greeting`​ (コンシューマーエンドポイント + ​`/greeting`​) に繰り返し送信します。 ## [](#次のステップ)次のステップ API を Mule アプリケーションとして CloudHub の Mule にデプロイしましたので、以後は Anypoint Platform ツールを使用して管理できます。 ## [](#開発者向けの詳細)開発者向けの詳細 MuleSoft は、​[「Mule アプリケーションのデプロイ」](https://docs.mulesoft.com/mule-runtime/latest/deploying)​で説明されている多くのデプロイオプションを提供しています。 # ステップ 6.デプロイした API の操作 MuleSoft は、デプロイ済み API を管理するためのツールを提供しています。 ![ダッシュボードが表示されている Runtime Manager ユーザーインターフェース](/mulesoft/current/ja-jp/general/_images/runtime-overview.png) API の健全性をチェックするための手順は次のとおりです。 1. Anypoint Platform 組織から Runtime Manager に移動します。 [Runtime Manager に移動](https://anypoint.mulesoft.com/cloudhub/#/console/home/applications) 2. Sandbox 環境を選択します。設計環境が自動的に表示された場合は、Sandbox 環境に切り替えます。 1. **\[Design (デザイン)\]**​ 環境ボタンをクリックします。 2. **\[Sandbox\]**​ をクリックして ​**\[Switch (切り替え)\]**​ ボタンをクリックします。 3. デプロイ済み API プロキシのリンクをクリックします。 プロキシにいくつかの要求を送信すると、インターフェースに Mule メッセージの形式でトラフィックが表示されます。 Runtime Manager からは以下の情報も取得できます。 - **\[Logs (ログ)\]**​ をクリックすると、選択したアプリケーションの過去 30 日間のすべてのトランザクションが表示されます (最大 100MB)。 - **\[Settings (設定)\]**​ をクリックすると、このアプリケーションの設定が表示されます。 - **\[Insight (インサイト)\]**​ をクリックすると、Anypoint Monitoring および Anypoint Visualizer が有効になります。 ## [](#開発者向けの詳細)開発者向けの詳細 API の機能が多いほど、Runtime Manager は多くのデータを返します。詳細は ​[Runtime Manager のドキュメント](https://docs.mulesoft.com/jp/runtime-manager/)​を参照してください。 # チュートリアル: API ビルドの最初から最後まで API 主導の接続により、顧客のさまざまなデバイス快適な環境を実現できます。さまざまなソフトウェアアプリケーションが各種システムで情報の通信と共有を行います。アプリケーションプログラミングインターフェース (API) は、それらのアプリケーションやシステム間のデジタルメッセンジャー/トランスレーターとして機能します。これにより、変化に適応し、ソリューションを効率的に再利用して、ビジネスのデジタルタッチポイントのセキュリティを確保できます。 MuleSoft で最初の API 主導の完全なジャーニーを体験してください。 1. [前提条件](https://docs.mulesoft.com/jp/general/api-led-prerequisites) 2. [API 仕様の設計](https://docs.mulesoft.com/jp/general/api-led-design) 3. [API の開発](https://docs.mulesoft.com/jp/general/api-led-develop) 4. [検証とエラー処理の追加](https://docs.mulesoft.com/jp/general/api-led-test) 5. [CloudHub へのデプロイ](https://docs.mulesoft.com/jp/general/api-led-deploy) 6. [API の操作](https://docs.mulesoft.com/jp/general/api-led-operate) 単一リソースの API を作成して完全なジャーニーを体験したら、そのモデルを使用して自分自身の接続プロジェクトを計画しましょう。 ## [](#関連情報)関連情報 - [What is API-led Connectivity (API 主導の接続とは?)](https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/) # ポリシーと API プロキシのための Java のアップグレード Java 8 および 11 の標準サポートは Mule 4.8 Edge では 2025 年 3 月、4.6 LTS では 2026 年 2 月に終了します。Java 8 または 11 上で実行中のアプリケーションのアップグレードパスを計画します。 ポロシーと API プロキシをアップグレードして、Java 17 と互換性があるものにします。 ## [](#upgrading-automated-policies)自動ポリシーのアップグレード 自動ポリシー (内部およびカスタム) を Java 17 にアップグレードします。 ### [](#upgrading-included-automated-policies)内部自動ポリシーのアップグレード 自動化された ​[MuleSoft 内部ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-directory)​を Java 17 にアップグレードする手順は、次のとおりです。 1. API Manager で、​**\[Automated Policies (自動ポリシー)\]**​ に移動します。 2. **\[Policy version (ポリシーバージョン)\]**​ で、内部ポリシーの最新バージョンを選択します。 3. **\[Rule of application (適用のルール)\]**​ で、次の手順を実行します。 - ポリシーが最新バージョンに基づく場合: - 内部ポリシーをすべての Mule Runtime に適用するには、​**\[All runtimes (すべてのランタイム)\]**​ を選択して ​**\[Apply (適用)\]**​ をクリックします。 - 内部ポリシーを Flex Gateway のみに適用するには、​**\[Flex gateways only (Flex Gateway のみ)\]**​ を選択して ​**\[Apply (適用)\]**​ をクリックします。 - 内部ポリシーを Mule Gateway のみに適用する手順は、次のとおりです。 1. **\[Mule gateways only (Mule ゲートウェイのみ)\]**​ を選択します。 2. **\[From version (開始バージョン)\]**​ と ​**\[To (終了バージョン)\]**​ に Mule バージョンの範囲を入力します。 3. **\[Java Versions (Java バージョン)\]**​ で、​**\[All Java versions (すべての Java バージョン)\]**​ または ​**\[Choose specific Java versions (特定の Java バージョンを選択)\]**​ を選択します。 4. **\[Apply (適用)\]**​ をクリックします。 - ポリシーが最新バージョンに基づいていない場合: - 内部ポリシーをすべての Mule Runtime に適用するには、​**\[All runtimes (すべてのランタイム)\]**​ を選択して ​**\[Apply (適用)\]**​ をクリックします。 - 内部ポリシーを Flex Gateway のみに適用するには、​**\[Flex gateways only (Flex Gateway のみ)\]**​ を選択して ​**\[Apply (適用)\]**​ をクリックします。​**\[Rule of application (適用のルール)\]**​ セクションは最新バージョンの ​**\[Rule of application (適用のルール)\]**​ セクションと同じである必要があります。同じでない場合、API が保護されない可能性があります。 - 内部ポリシーを Mule Gateway のみに適用する手順は、次のとおりです。 1. **\[Mule gateways only (Mule ゲートウェイのみ)\]**​ を選択します。 2. **\[From version (開始バージョン)\]**​ と ​**\[To (終了バージョン)\]**​ に Mule バージョンの範囲を入力します。 3. **\[Java versions (Java バージョン)\]**​ で、​**\[Choose specific Java versions (特定の Java バージョンを選択)\]**​ を選択し、Java 8 と Java 11 を選択します。 4. **\[Apply (適用)\]**​ をクリックします。 5. **\[Add automated policy (自動ポリシーを追加)\]**​ をクリックし、同じ自動ポリシーを追加します。 6. **\[Advanced options (詳細オプション)\]**​ をクリックします。 7. **\[Mule gateways only (Mule ゲートウェイのみ)\]**​ を選択します。 8. **\[From version (開始バージョン)\]**​ と ​**\[To (終了バージョン)\]**​ に Mule バージョンの範囲を入力します。 9. **\[Java versions (Java バージョン)\]**​ で、​**\[Choose specific Java versions (特定の Java バージョンを選択)\]**​ を選択し、Java 17 を選択します。 10. **\[Apply (適用)\]**​ をクリックします。 ### [](#upgrading-custom-automated-policies)カスタム自動ポリシーのアップグレード カスタム自動ポリシーを Java 17 にアップグレードする手順は、次のとおりです。 1. API Manager で、​**\[Automated Policies (自動ポリシー)\]**​ に移動します。 2. 必要な拡張機能とコネクタを Java 17 にアップグレードします。 - カスタムポリシーに Anypoint Connector がある場合は、​[「Anypoint Connector およびモジュールのアップグレード」](https://docs.mulesoft.com/jp/general/java-support#anypoint-connectors-and-modules)​を参照してください。 - カスタムポリシーにカスタムコネクタがある場合は、​[「カスタムコネクタのアップグレード」](https://docs.mulesoft.com/jp/general/java-support#custom-connectors)​を参照してください。 3. [カスタムポリシーをアップグレードします](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-java-version)​。 4. [カスタムポリシーをパッケージ化します](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​。 Java 17 をローカルで設定して、カスタムポリシーを Java 17 と互換性があるものにします。 5. [カスタムポリシーを Exchange に再パブリッシュします](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-upload-to-exchange)​。 6. Java 17 と互換性のあるカスタムポリシーの新しいバージョンを API インスタンスに適用します。 1. **\[Policies (ポリシー)\]**​ に移動します。 2. **\[Applied policy status (適用されたポリシーの状況)\]**​ で、最新の定義が適用されていることを確認します。 - 最新の定義が適用されている場合、\[More (その他)\] (…​) メニューをクリックして ​**\[Check for implementation updates (実装の更新を確認)\]**​ を選択します。 - 最新の定義が適用されていない場合、最新の定義に更新します。 ## [](#upgrading-api-level-policies)API レベルのポリシーのアップグレード API レベルのポリシー (内部およびカスタム) を Java 17 にアップグレードします。 ### [](#upgrading-included-api-level-policies)API レベルの内部ポリシーのアップグレード API レベルの ​[MuleSoft 内部ポリシー](https://docs.mulesoft.com/jp/mule-gateway/policies-included-directory)​を Java 17 にアップグレードする手順は、次のとおりです。 1. API Manager で、​**\[API Administration (API 管理)\]**​ > ​**{API 参照名}**​ > ​**\[Policies (ポリシー)\]**​ > ​**\[Add a policy (ポリシーを追加)\]**​ に移動して、個々の API レベルで​[ポリシーを適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-apply)​します。 2. API レベルの各ポリシーをアップグレードする手順は、次のとおりです。 1. **\[Policy version (ポリシーバージョン)\]**​ で、内部ポリシーの最新バージョンを選択します。 2. **\[Method & resource conditions (メソッドとリソースの条件)\]**​ で、​**\[Apply configuration to all API method & resources (設定をすべての API メソッドおよびリソースに適用)\]**​ または ​**\[Apply configuration to specific API method & resources (設定を特定の API メソッドおよびリソースに適用)\]**​ を選択します。 3. **\[Apply (適用)\]**​ をクリックします。 ### [](#upgrading-custom-api-level-policies)API レベルのカスタムポリシーのアップグレード API レベルのカスタムポリシーを Java 17 にアップグレードする手順は、次のとおりです。 1. API Manager で、​**\[API Administration (API 管理)\]**​ > ​**{API 参照名}**​ > ​**\[Policies (ポリシー)\]**​ > ​**\[Add a policy (ポリシーを追加)\]**​ に移動して、個々の API レベルで​[ポリシーを適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-apply)​します。 2. 必要な拡張機能とコネクタを Java 17 にアップグレードします。 - カスタムポリシーに Anypoint Connector がある場合は、​[「Anypoint Connector およびモジュールのアップグレード」](https://docs.mulesoft.com/jp/general/java-support#anypoint-connectors-and-modules)​を参照してください。 - カスタムポリシーにカスタムコネクタがある場合は、​[「カスタムコネクタのアップグレード」](https://docs.mulesoft.com/jp/general/java-support#custom-connectors)​を参照してください。 3. [カスタムポリシーをアップグレードします](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-java-version)​。 4. [カスタムポリシーをパッケージ化します](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-package)​。 Java 17 をローカルで設定して、カスタムポリシーを Java 17 と互換性があるものにします。 5. [カスタムポリシーを Exchange に再パブリッシュします](https://docs.mulesoft.com/jp/mule-gateway/policies-custom-upload-to-exchange)​。 6. Java 17 と互換性のあるカスタムポリシーの新しいバージョンを API インスタンスに適用します。 1. **\[Policies (ポリシー)\]**​ に移動します。 2. **\[Applied policy status (適用されたポリシーの状況)\]**​ で、最新の定義が適用されていることを確認します。 - 最新の定義が適用されている場合、\[More (その他)\] (…​) メニューをクリックして ​**\[Check for implementation updates (実装の更新を確認)\]**​ を選択します。 - 最新の定義が適用されていない場合、最新の定義に更新します。 ## [](#upgrading-api-proxies)API プロキシのアップグレード
アップグレード時に API プロキシまたは Mule アプリケーションを確実に保護するには、API プロキシまたは Mule アプリケーションをアップグレードする​前​に API ポリシーをアップグレードしてください。
アップグレードの手順は、​**\[Proxy type (プロキシ種別)\]**​ によって若干異なります。 - 基本エンドポイント: - 基本エンドポイントを使用する場合は、適合したアプリケーションを Mule Runtime からサーバーにデプロイし、自動検出を使用して API Manager に接続します。詳細は、​[「Mule 4 アプリケーションでの Mule ゲートウェイの API 自動検出の設定」](https://docs.mulesoft.com/jp/mule-gateway/mule-gateway-config-autodiscovery-mule4)​を参照してください。 - 基本エンドポイント API インスタンスを使用してインスタンスを更新する場合は、API インスタンスに接続している Mule アプリケーションを更新します。 - プロキシアプリケーションを使用する場合、デプロイメント種別に応じて次のセクションを参照してください。 - [CloudHub および CloudHub 2.0 デプロイメント](#cloudhub-and-cloudhub2-deployments) - [ハイブリッドデプロイメント](#hybrid-deployments) - [Runtime Fabric デプロイメント](#runtime-fabric-deployments) ### [](#cloudhub-and-cloudhub2-deployments)CloudHub および CloudHub 2.0 デプロイメント この手順を実行する前に、ポリシーが更新されていることを確認してください。詳細は、​[自動ポリシーのアップグレード](#upgrading-automated-policies)​および​[API レベルのポリシーのアップグレード](#upgrading-api-level-policies)​を参照してください。 1. API Manager で、​**\[API Administration (API 管理)\] > \[Settings (設定)\]**​ に移動します。 2. [API インスタンスの設定を編集します](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task)​。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ で、使用するランタイムチャネルを選択します。 2. **\[Version (バージョン)\]**​ で、​**\[4.6.0\]**​ またはそれ以上を選択します。 3. **\[Java version (Java バージョン)\]**​ で、​**\[Java 17\]**​ を選択します。 3. **\[Save & Apply (保存して適用)\]**​ をクリックします。 ### [](#hybrid-deployments)ハイブリッドデプロイメント この手順を実行する前に、ポリシーが更新されていることを確認してください。詳細は、​[自動ポリシーのアップグレード](#upgrading-automated-policies)​および​[API レベルのポリシーのアップグレード](#upgrading-api-level-policies)​を参照してください。 1. Mule Runtime Rngine 4.6.x を、Java 17 で実行される新しいサーバーにデプロイし、サーバーを開始します。詳細は、[Runtime Manager へのサーバーの追加](https://docs.mulesoft.com/jp/runtime-manager/servers-create)を参照してください。 2. Java 17 で実行される、作成した新しい対象を選択し、API Manager で ​**\[API Administration (API 管理)\] > \[Settings (設定)\]**​ に移動します。 3. [API インスタンスの設定を編集します](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task)​。 1. **\[Select target (対象を選択)\]**​ で、Java 17 で実行されているサーバーを対象として選択します。 4. **\[Save & Apply (保存して適用)\]**​ をクリックします。 5. サーバーが Java 17 で正常に実行されたら、ロードバランサーを使用してトラフィックを新しいサーバーに段階的に移行し、すべてのアプリケーションが移行されたら古いサーバーをオフにします。 ### [](#runtime-fabric-deployments)Runtime Fabric デプロイメント この手順を実行する前に、ポリシーが更新されていることを確認してください。詳細は、​[自動ポリシーのアップグレード](#upgrading-automated-policies)​および​[API レベルのポリシーのアップグレード](#upgrading-api-level-policies)​を参照してください。 1. Mule Runtime Rngine 4.6.x を、Java 17 で実行される新しいサーバーにデプロイし、サーバーを開始します。詳細は、[Deploying API Proxies to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric)を参照してください。 2. Java 17 で実行される、作成した新しい対象を選択し、API Manager で ​**\[API Administration (API 管理)\] > \[Settings (設定)\]**​ に移動します。 3. [API インスタンスの設定を編集します](https://docs.mulesoft.com/jp/api-manager/latest/edit-api-endpoint-task)​。 1. **\[Runtime Channel (ランタイムチャネル)\]**​ で、使用するランタイムチャネルを選択します。 2. **\[Version (バージョン)\]**​ で、​**\[4.6.0\]**​ またはそれ以上を選択します。 3. **\[Java version (Java バージョン)\]**​ で、​**\[Java 17\]**​ を選択します。 4. **\[Save & Apply (保存して適用)\]**​ をクリックします。 5. サーバーが Java 17 で正常に実行されたら、ロードバランサーを使用してトラフィックを新しいサーバーに段階的に移行し、すべてのアプリケーションが移行されたら古いサーバーをオフにします。 ## [](#関連情報)関連情報 - [Java サポート](https://docs.mulesoft.com/jp/general/java-support) # 使用状況レポート 使用状況レポートでは、Anypoint Platform 製品全体のリソースの使用に関する有益なインサイトを提供する包括的な月次および日次サマリーが提供されます。使用量と請求サイクルを相関させることで、コストへの影響要因に関するインサイトを取得できます。これにより、予算を積極的に管理し、情報に基づいた意思決定を行ってリソースの割り当てを最適化できます。 従量制の Anypoint Platform 製品を使用する場合、MuleSoft は使用量を測定して、日および月単位でレコードを集約します。月次および日次使用状況レポートは 3 日遅れます。つまり、本日の使用状況は 3 日後に使用可能になります。すべてのレポートは UTC 時間標準を使用して計算されます。たとえば、毎日の使用量は 00:00 から 00:00 UTC の範囲で集約されます。 毎日の使用量は 3 か月間保持され、毎月の使用量は最大 5 年間保持されます。 使用量ベースの価格設定モデルを使用する組織は、レポートからの実際の使用量を既存の契約と比較することができます。ただし、使用状況レポートは請求を目的としたものではありません。使用量メトリクスと価格設定についての詳細は、​[Anypoint Platform 価格設定](https://docs.mulesoft.com/jp/general/pricing) and [使用量および価格設定メトリクスリファレンス](https://docs.mulesoft.com/jp/general/usage-metrics)​を参照してください。 月次ステートメントや vCore 割り当てなどの一部の使用状況データは、Anypoint Platform または Salesforce 製品の異なる領域に表示されます。 - Mule フロー、Mule メッセージ、データスループットを含む Mule Runtime の月次ステートメントは主請求連絡先に送信されます。 RPA、Composer、インテリジェントドキュメント処理 (IDP)、Salesforce Flow Orchestration、MuleSoft for Flow の​[自動化クレジット](#rpa-home::ms-automation-credits-usage-types.adoc)​は主請求連絡先に送信されます。 詳細は、Salesforce の [「アカウントの概要 (月次)」](https://help.salesforce.com/s/articleView?id=000390885&type=1)​を参照してください。 - コントラクトエンタイトルメントの 80% および 90% に達した使用状況のアラートは、自動的に主請求連絡先メールアドレスに送信されます。主請求連絡先は、しきい値に達すると毎月アラートを取得します。 詳細は、 [「Salesforce 使用状況アラートの FAQ」](https://help.salesforce.com/s/articleView?id=004811177&type=1)​ナレッジ記事を参照してください。 - Runtime Manager vCore 割り当て情報とその他のメトリクスはアクセス管理に表示されます。 詳細は、​[Runtime Manager メトリクス](https://docs.mulesoft.com/jp/general/usage-metrics#runtime-manager-metrics)​を参照してください。 Government Cloud および Anypoint Private Cloud Edition の使用状況は、使用状況レポートでは利用できません。 ## [](#products-usage-reports)使用状況レポートで使用可能な製品 使用状況レポートでは次の製品を使用できます。 - Anypoint MQ - API Experience Hub - API Governance - API Manager - Flex Gateway - インテリジェントドキュメント処理 (IDP) - Mule Runtime - Object Store v2 ## [](#サポート対象の-mule-runtime-バージョン)サポート対象の Mule Runtime バージョン Mule Runtime の使用状況レポートを表示するには、すべてのアプリケーション (本番および Sandbox) で次の Mule バージョンを使用する必要があります。
Deployment Type (デプロイメント種別) バージョン要件

CloudHub 2.0

4.3.0 以降の最新の日付パッチバージョン

CloudHub

3.9 および 4.2.0 以降の最新の日付パッチバージョン

Runtime Fabric

次のいずれかのバージョンまたは任意の以降の日付パッチ:

Mule 4 イメージのバージョン:

  • 4.5.0 以降

  • 4.4.0-20230111-1

  • 4.3.0-20221212-2

  • 4.2.2-20221027-7

  • 4.2.1-20221027-7

  • 4.2.0-20221027-6

Mule 3 イメージのバージョン:

  • 3.9.5-20230424-2

  • 3.9.4-20230424-1

  • 3.9.3-20230424-1

  • 3.9.2-20230424-1

  • 3.9.1-20230424-1

ハイブリッドスタンドアロン

次のいずれかのバージョンまたは任意の以降の日付パッチ:

  • 4.6.0 以降

  • 4.4.0-20221111

  • 4.3.0-20221024

Runtime Manager エージェント 2.7.0 以降

手動で、または毎月のパッチサイクル中にサポートされるバージョンでアプリケーションを再デプロイする必要があります。毎月のパッチサイクルは、CloudHub および CloudHub 2.0 アプリケーションでのみ適用されます。 以前に成功したアプリケーション設定に​[ロールバック](https://docs.mulesoft.com/cloudhub-2/ch2-update-apps#roll-back-to-a-previous-successful-configuration)​できます。ただし、使用状況レポートでサポートされない Mule バージョンがアプリケーションで使用されている場合、変更をデプロイする前に準拠 Mule バージョンを選択する必要があります。デプロイメント後に、以前に選択した設定とサポートされるランタイムで新しい設定が作成されます。 ## [](#始める前に)始める前に 使用状況レポートは、ルート組織にサインインしている場合のみ使用でき、ビジネスグループレベルでは表示されません。 使用状況レポートにアクセスするには、​[「Usage Viewer (使用状況閲覧者)」権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product#usage)​が必要です。この権限がない場合は、組織のシステム管理者に連絡してアクセス権を要求してください。「Usage Viewer (使用状況閲覧者)」権限は、ビジネスグループレベルではなく​[ルート組織レベルで適用](https://docs.mulesoft.com/jp/access-management/managing-permissions)​する必要があります。 ## [](#使用状況レポートにアクセスする)使用状況レポートにアクセスする 1. ルート組織の「Usage Viewer (使用状況閲覧者)」権限を持つアカウントを使用して Anypoint Platform にサインインします。 2. Anypoint Platform ナビゲーションバーでビジネスグループセレクターをクリックし、ルート組織レベルにいることを確認します。 3. Anypoint Platform ナビゲーションバーで、自分のユーザー名アイコンをクリックし、​**\[Usage Reports (使用状況レポート)\]**​ を選択します。 4. 使用状況レポートを表示する製品を選択します。 5. **\[Monthly Usage Report (月次使用状況レポート)\]**​ または ​**\[Daily Usage Report (日次使用状況レポート)\]**​ をクリックします。 6. 表示する使用状況レポートの月または日を選択します。 選択した製品について、Anypoint Platform でデータを収集した日付のみ使用できます。 使用状況レポートが表示され、​[選択した製品に依存する](https://docs.mulesoft.com/jp/general/usage-metrics)​使用量メトリクス一式が表示されます。 ## [](#export-usage-reports)CSV ファイルへの使用状況レポートのエクスポート 日次および月次使用状況レポートの両方を CSV ファイルにエクスポートできます。これらのメトリクスは、使用状況レポートで使用可能なデータに一致します。 1. ダウンロードする使用状況レポートに移動します。 2. **\[Export as CSV (CSV としてエクスポート)\]**​ をクリックします。 ## [](#使用状況-api)使用状況 API プログラムで使用状況データにアクセスするには、Anypoint 使用状況 API を使用します。この API では、日次と月次の両方の詳細が提供されます。使用状況メトリクスは、ビジネスグループやアプリケーション別に整理されます。これにより、製品の消費に関する詳細なインサイトを取得できます。 API を使用するには、 [Anypoint 使用状況 API](https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a/usage-api/)​ の API ドキュメントを参照して、アクセスや実装の詳細を確認してください。ユーザーが使用状況 API にアクセスするには、「Usage Viewer (使用状況閲覧者)」権限が必要です。 ## [](#usage-reports-on-control-planes)コントロールプレーンの使用状況レポート 日本とカナダのコントロールプレーンでは、使用状況レポートのすべての機能がサポートされます。 ## [](#関連情報)関連情報 - [Anypoint API Governance Overview](https://docs.mulesoft.com/api-governance/) - [API Manager 2.x](https://docs.mulesoft.com/jp/api-manager/latest/) # 使用状況レポートのトラブルシューティング プラットフォームデータの使用可能状況は組織のアクティビティによって異なるため、場合によっては使用状況レポートを使用できないことがあります。 ## [](#anypoint-platform-で使用状況レポートにアクセスできない)Anypoint Platform で使用状況レポートにアクセスできない ルート組織レベルで「Usage Viewer (使用状況閲覧者)」権限が割り当てられていることを確認します。 「Usage Viewer (使用状況閲覧者)」権限が割り当てられていない場合は、Anypoint Platform 組織のシステム管理者にお問い合わせください。 ## [](#サポートされている製品が表示されない)サポートされている製品が表示されない 製品リストを開いたときにサポートされている製品が表示されない場合、​**\[Switch View (ビューを切り替え)\]**​ をクリックします。 製品の使用可能状況についての詳細は、​[使用可能な製品](https://docs.mulesoft.com/jp/general/usage-reports#products-usage-reports)​を参照してください。 ## [](#使用状況レポートに-runtime-fabric-アプリケーションのデータが表示されない)使用状況レポートに Runtime Fabric アプリケーションのデータが表示されない Runtime Fabric アプリケーションのデータが表示されない場合、次の点を確認してください。 - Runtime Fabric エージェントバージョン 1.13.112、または 2.1.30 以降を使用している。 - Runtime Fabric エージェントの更新後に、サポートされる日付パッチバージョンで各 Runtime Fabric アプリケーションを手動で再デプロイした。 引き続き使用状況レポートに Runtime Fabric アプリケーションが表示されない場合は、アカウントエグゼクティブに連絡し、アップグレードされていないアプリケーションのレポートとそれらを更新するために必要なアクションを要求してください。 ## [](#日付ピッカーで月または日を使用できない)日付ピッカーで月または日を使用できない 日付ピッカーに月または日が表示されない場合、選択した期間でデータを使用できません。 ## [](#レポートにデータなしと表示される)レポートにデータなしと表示される 新しい使用状況レポートで製品と日次または月次レポートを選択し、レポートで ​`[No Data (データなし)]`​ メッセージが返された場合、選択した期間に使用可能なデータはありません。 つまり、選択した日または月に使用可能なデータはありません。 ## [](#no-report-available-for-this-time-period-この期間に使用可能なレポートはありませんメッセージ)「No Report Available for This Time Period (この期間に使用可能なレポートはありません)」メッセージ 従来の使用状況レポートで月を選択した後、レポートで ​`[No report available for this time period (この期間に使用可能なレポートはありません)]`​ が返された場合、選択した月に使用可能なデータはありません。 つまり、選択した月に使用可能なデータはありません。 ## [](#デプロイした-mule-アプリケーションが-mule-runtime-使用状況レポートに表示されない)デプロイした Mule アプリケーションが Mule Runtime 使用状況レポートに表示されない デプロイした Mule アプリケーションが Mule Runtime 使用状況レポートに表示されない場合、サポートされる Mule Runtime バージョンを使用していることを確認してください。詳細は、​[サポートされるランタイムバージョン](https://docs.mulesoft.com/jp/general/usage-reports#supported-mule-runtime-versions)​を参照してください。 手動で、または毎月のパッチサイクル中にサポートされる Mule Runtime バージョンで Mule アプリケーションを再デプロイします。 ## [](#関連情報)関連情報 - [使用量および価格設定メトリクスリファレンス](https://docs.mulesoft.com/jp/general/usage-metrics) - [使用状況レポート](https://docs.mulesoft.com/jp/general/usage-reports) - [「Usage Viewer (使用状況閲覧者)」権限](https://docs.mulesoft.com/jp/access-management/permissions-by-product#usage) # 使用量および価格設定メトリクスリファレンス Anypoint Platform は製品全体で使用量メトリクスを取得しますが、すべてのメトリクスが請求可能であったり、使用状況レポートに反映されたりするわけではありません。
製品 メトリクスの説明 使用量の詳細

Mule Runtime

Mule flow (Mule フロー): Mule イベントソースまたはルート APIKit 要求が含まれる、デプロイされて実行されている Mule アプリケーション内のフロー

フローは、最大同時実行モデルを使用して集約されます。1 か月の使用量とは、1 か月の特定の 1 時間に存在するフローの最大数です。

Mule message (Mule メッセージ): ランタイムによって処理されたコア情報のコンテナ。

Mule メッセージは、イベントソースによりトリガーされると 1 単位とみなされます。メッセージは、1 か月間に送信されたすべてのメッセージの合計を使用して集約されます。

Data throughput (データスループット): Mule アプリケーションがデプロイされ、Mule が実行されているインフラストラクチャとの間で送受信されたデータの総量

デプロイされたアプリケーションがそのビジネスロジックを実行するためにデータを送信すると、データスループットが計数されます。これには、監視、ログ、健全性チェック用の内部運用ネットワークトラフィックが含まれますが、これらに限定されません。データスループットは、1 か月間のすべてのバイトの合計として集約されます。

Cluster capacity (クラスター容量): 特定の Runtime Fabric インスタンスの 1 つのデプロイメント対象として機能するワーカーまたはノードのセット。

Runtime Fabric インスタンス内の各ノードの割り当て可能な CPU 容量。

CPU Limit (Millicores) (CPU 制限 (ミリコア数)): Runtime Fabric のワーカーノードで使用できる CPU リソースの最大量

CPU 使用量は、1 時間や 1 日などの特定の期間で集約されます。

各アプリケーションの CPU 制限設定は、各環境 ID でまとめられ、次に各ビジネスグループ、次に本番前 (Sandbox) 環境種別と本番環境種別の各ルート組織 ID で別々にまとめられます。

CPU Reserve (Millicores) (CPU 予約 (ミリコア数)): Runtime Fabric インスタンスのワーカーノードに割り当てられる CPU リソースの保証された最小量

CPU 予約は、クラスターまたは Runtime Fabric インスタンス内でユーザーがアプリケーション用として予約するために割り当てた CPU リソースの総量を計算することで集約されます。

API Manager

API instances (API インスタンス): add、promote、または import オプションを使用して作成された後、API Manager によって管理される、本番、本番前、未分類 API (環境に関連付けられない API) 内の API インスタンス。

API は、削除されるまで API Manager の管理下に置かれます。API Manager のインスタンスは、本番、本番前、および未分類 (環境に関連付けられていない API) の 3 つの別々のメトリクスを使用する最大同時実行モデルを使用して集約されます。

+

API Manager のデータは、2024 年 10 月から使用可能です。

API Governance

API under Governance (ガバナンス下の API): 少なくとも 1 つのガバナンスプロファイルの選択条件によって識別された API

API が管理されている場合、その API のすべてのバージョンが 1 つの管理対象 API とみなされます。API ガバナンスのインスタンスは、最大同時実行モデルを使用して集約されます。1 か月の使用量とは、1 か月の特定の 1 時間内で管理された API の最大数です。

Flex Gateway

Flex Gateway API call (Flex Gateway API コール): 要求に対する応答が成功したかどうかにかかわらず Anypoint Flex Gateway が受信したアクセス要求

Flex Gateway 要求は、1 か月間のすべての要求の合計として集約されます。

Composer

Composer task (Composer タスク): Composer Connector で実行される任意のアクションであり、参照、作成、更新、および削除が含まれますが、これらに限定されません。

Composer タスクは、1 か月間のすべてのアクションの合計として集約されます。

RPA

Robotic Process Automation (“RPA”) bot minutes (Robotic Process Automation (“RPA”) Bot の分数): すべてのボットセッションでプロセスの自動化を実行した分数

1 つのボットで複数の並列セッションを実行することができます。この場合、RPA Bot の分数は並列セッションごとに集計されます。複数のボットで同じプロセスを実行するように設定することができます。この場合、RPA Bot の分数はこれらの個別のボットセッションごとに集計されます。テストフェーズでのテスト実行またはプロセス実行も、RPA Bot の分数とみなされます。

Anypoint MQ

Anypoint MQ API request (Anypoint MQ API 要求): Anypoint MQ API から 1 つ以上のメッセージを取得するために実行された要求

Anypoint MQ は、API 要求を使用して請求を計算します。 Anypoint MQ API 要求は、すべての環境 (本番、本番前、Sandbox、設計を含む) の集約内で計算されます。 Anypoint MQ API 要求は API を介して使用可能で、使用状況レポートで集約されます。

Object Store (オブジェクトストア)

Object Store API request (Object Store API 要求): Object Store API から 1 つ以上のメッセージを取得するために実行された要求。詳細な定義は、Object Store のドキュメントを参照してください

各 Object Store API 要求には最大 100 KB のデータが含まれます。100 KB を超える Object Store API 要求は、小数単位のない複数の要求として数えられます。Object Store API 要求は API を介して使用可能で、使用状況レポートで集約されます。

DataGraph

DataGraph orchestration (DataGraph オーケストレーション): Anypoint DataGraph に対して実行された GraphQL API 要求のデータを取得するために、ソース API に対して Anypoint DataGraph により実行された API 要求

現在、オーケストレーションは使用状況レポートでは集約されていません。

インテリジェントドキュメント処理 (IDP)

Intelligent Document Processing (IDP) Document Pages (インテリジェントドキュメント処理 (IDP) ドキュメントページ): IDP により処理された 1 つのページ。

IDP ドキュメントアクションでは、複数のページを含むドキュメントを処理でき、各ページが個別に集計されます。RPA でドキュメントアクションが実行されると、ドキュメントページ数にも集計されるほか、対応する RPA Bot の分数がコンシュームされ、RPA プロセスの実行時間の対象となります。

## [](#anypoint-mq-使用状況)Anypoint MQ 使用状況 Anypoint MQ 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。 Business Group (ビジネスグループ) キューを持つアプリケーションがデプロイされる、リソースを所有するビジネスグループ Environment (環境) キューを持つアプリケーションがデプロイされるビジネスグループ内の環境 Region id (リージョン ID) キューを持つアプリケーションがデプロイされるリージョン Object type (オブジェクト種別) キューまたはメッセージエクスチェンジ Object name (オブジェクト名) キューまたはメッセージエクスチェンジの名前 Message units (メッセージ単位数) (請求ではなく) レート制限で応答メッセージデータサイズを決定するために使用される、エンコードされたメッセージ文字数 Messages bytes (メッセージバイト数) メッセージ単位数に基づく応答メッセージデータサイズ API 要求 請求の月次クォータを計算するために使用される、コネクタまたは API を介した API コールの数 Messages received (受信メッセージ数) 受信したメッセージの数 Total Message units (メッセージ単位の合計数) 組織内のすべてのキューでのメッセージ単位の合計数 Total Messages bytes (メッセージバイトの合計数) 組織内のすべてのキューでのメッセージデータの合計数 Total API requests (API 要求の合計数) 組織内のすべてのキューでの API コールの合計数 Total Messages received (受信メッセージの合計数) 組織内のすべてのキューでの受信メッセージの合計数 ハイブリッドスタンドアロンデプロイメントのサイドローディングされたアプリケーションは、ⓘ アイコンと共に使用状況レポートに表示されます。サイドローディングされたアプリケーションを再デプロイすると、複数のレコードが使用状況レポートに表示されます。 ## [](#api-experience-hub-使用状況)API Experience Hub 使用状況 API Experience Hub 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。 Salesforce 組織 ID API がデプロイされている Salesforce 組織の OrgID Salesforce ポータル名 API がデプロイされている Salesforce ポータルの名前 \# 承認されたアクセス権の要求 API に対する承認されたアクセス権の要求の合計数 承認されたアクセス権の要求の合計数 すべての Salesforce 組織における承認されたアクセス権の要求の合計数 ## [](#api-governance-使用状況)API Governance 使用状況 API Governance 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。 ビジネスグループ 管理された API が含まれるビジネスグループ \# 管理された API 指定したビジネスグループ内で管理された API の合計数 Maximum Number of Governed APIs (管理対象 API の最大数) 1 か月の特定の 1 時間内で管理された API の最大数 ## [](#api-manager-使用状況)API Manager 使用状況 API Manager のデータは、2024 年 10 月から使用可能です。 API Manager 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。 ビジネスグループ API が管理されているビジネスグループ 環境 API が管理されている環境種別 ランタイム API のランタイム種別 \# 管理された API 指定したビジネスグループ、環境、およびランタイム内で管理された API の合計数 Maximum Number of Managed APIs (管理 API の最大数) 本番、本番前、および未分類 API (環境に関連付けられていない API) 内の API インスタンス ## [](#flex-gateway-使用状況)Flex Gateway 使用状況 Flex Gateway 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。 Business Group (ビジネスグループ) Flex Gateway が登録されているビジネスグループ。 Gateway Type (ゲートウェイ種別) Flex Gateway が登録されているゲートウェイ種別。 このメトリクスのデータは、2025 年 3 月から使用可能です。 Environment (環境) Flex Gateway が登録されている環境。 登録 登録済み Flex Gateway の名前。 Data Egress (GB) (データエグレス (GB)) Flex Gateway エグレスによりアップストリームサービスに送信されたアウトバウンドデータの総量 (GB)。 このメトリクスのデータは、2025 年 3 月から使用可能です。 \# of API Calls (API コール数) Flex Gateway 内にデプロイされた API により実行された API コールの合計数。 Total # of API Calls (API コールの合計数) 組織内のすべての登録済み Flex Gateway での API コールの合計数。 ## [](#インテリジェントドキュメント処理-idp)インテリジェントドキュメント処理 (IDP) IDP 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。 Business Group (ビジネスグループ) ドキュメントが処理されたビジネスグループ アクション ID。 処理されたアクションに関連付けられた ID Action Version (アクションバージョン) 処理されたアクションに関連付けられたバージョン 実行種別 処理されたアクションに関連付けられた実行種別 Processed Pages (処理されたページ数) 処理されたページの合計数 ## [](#mule-runtime-使用状況)Mule Runtime 使用状況 MuleSoft では、Mule フロー、Mule メッセージ、データスループットの使用状況データを取得しますが、このデータのすべてが使用状況レポートで集計されるわけではありません。 Mule メッセージの使用状況を追跡するために、ランタイムレポートでは Mule イベントソースが Mule メッセージをトリガーする回数を数えます。特定の日または月のこれらのメッセージの数をビジネスグループ、環境、およびアプリケーション別に参照できます。 使用量の計算では、MuleSoft は毎日および毎月のメッセージ数を測定して集約します。メッセージがトリガーされると、レポートではメッセージに対する変更が追跡されなくなります。これは、メッセージがアプリケーションのフロー内で処理されるためです。 データスループットとは、Mule アプリケーションを実行する Mule Runtime Engine のインフラストラクチャによって生成されたネットワーク I/O バイトの合計を指します。 使用量の計算では、MuleSoft は使用量を追跡して毎日および毎月の合計 GB を集約します。 US コントロールプレーンの一部のお客様に対して、MuleSoft では一定数の Mule フロー、Mule メッセージ、データスループット (ネットワーク I/O バイト数として測定) を割り当てる Anypoint Platform の価格設定およびパッケージモデルを提供しています。すべての種別の Mule フローおよびメッセージがパッケージの割り当て対象になるわけではありません。 ### [](#mule-runtime-使用状況テーブル)Mule Runtime 使用状況テーブル 使用状況レポートのテーブルに表示される使用量情報は、ビューによって異なります。 #### [](#ビジネスグループの詳細)ビジネスグループの詳細 **\[Business Group Details (ビジネスグループの詳細)\]**​ タブを選択して表示します。
項目 説明

Business Group (ビジネスグループ)

リソースを所有しているビジネスグループ。Runtime Fabric の場合、これは、Runtime Fabric インスタンスの作成時に使用されたビジネスグループです。

Environment Type (環境種別)

リソースが関連付けられている環境。

Runtime Fabric の場合、これは、Runtime Fabric インスタンスが関連付けられている環境です。Runtime Fabric インスタンスに関連付けられた本番環境がある場合、その本番環境は本番インタンスとみなされます。クラスター容量は、Runtime Fabric インスタンス内で本番前 (Sandbox) 環境と本番環境間で分割されません。

Cluster (クラスター)

アプリケーション、ワーカー、ノードが含まれるクラスターまたは Runtime Fabric インスタンスの名前。

Cluster Capacity (Millicores) (クラスター容量 (ミリコア数))

Runtime Fabric インスタンス内の各ノードの割り当て可能な CPU 容量。

#### [](#application-details-アプリケーション詳細)Application Details (アプリケーション詳細) **\[Application Details (アプリケーション詳細)\]**​ タブを選択して表示します。
項目 説明

Application (アプリケーション)

Mule アプリケーションの名前

Business Group (ビジネスグループ)

リソースを所有しているビジネスグループ。Runtime Fabric の場合、これは、Runtime Fabric インスタンスの作成時に使用されたビジネスグループです。

Deployment Type (デプロイメント種別)

Mule アプリケーションがデプロイされているランタイムプレーン: CloudHub (短縮表記: CH)、CloudHub 2.0 (短縮表記: CH2)、または Runtime Fabric (短縮表記: RTF)

Environment Type (環境種別)

Mule アプリケーションがデプロイされている本番前 (Sandbox) 環境または本番環境。

Cluster (クラスター)

ノードとアプリケーションが含まれる Runtime Fabric インスタンス。

CPU Limit (Millicores) (CPU 制限 (ミリコア数))

共有クラスターまたは Runtime Fabric インスタンス内でアプリケーションがバーストできる、ユーザーにより割り当てられた CPU の最大量。

CPU Reserve (Millicores) (CPU 予約 (ミリコア数))

Runtime Fabric クラスターまたはインスタンス内でユーザーがアプリケーション用として予約するために割り当てた CPU の量

Mule Flows (Mule フロー)

フロー数にワーカー数 (CloudHub) またはレプリカ数 (CloudHub 2.0 および Runtime Fabric) を乗じて計算される、Mule アプリケーション内のフローの総数。

Mule Messages (Mule メッセージ)

Mule アプリケーション内のインバウンドおよびアウトバウンド Mule メッセージの総数。

Data Throughput (GB) (データスループット (GB))

Mule アプリケーションにより送信されたインバウンドおよびアウトバウンドデータの総量 (GB)。

### [](#mule-runtime-使用状況カード)Mule Runtime 使用状況カード MuleSoft 使用状況レポートのカードには次が含まれます。 - [最大 Mule フロー数](#max-mule-flows) - [総 Mule メッセージ数](#mule-messages) - [本番の最大 CPU 制限](#max-cpu-prod) - [本番前の最大 CPU 制限](#max-cpu-preprod) - [本番の最大クラスター容量](#max-cluster-prod) - [本番前の最大クラスター容量](#max-cluster-preprod) ### [](#max-mule-flows)最大 Mule フロー数 Mule フローは Mule アプリケーションの XML ​``​ 要素内で設定される論理操作のシーケンスです。ランタイムレポートでは、Mule イベントソースまたは APIkit ルート要求が含まれる、デプロイされて実行されている Mule アプリケーション内の Mule フローを追跡します。 通常、本番環境の Mule アプリケーションは複数の Mule フローとサブフローを使用して、アプリケーションを機能モジュール別またはエラー処理目的で分割します。たとえば、1 つの Mule フローでレコードを受信してデータを特定の形式に変換し、別のフローでそのデータを処理できます。 使用量の計算では、MuleSoft は、すべてのビジネスグループ、環境、アプリケーションの Mule フロー数を追跡します。1 日または 1 か月間の Mule フローの最大数はその日または月のピーク時間の使用量に基づいて特定されます。詳細な内訳を確認できるように、MuleSoft ではビジネスグループ、環境、アプリケーションごとのピーク時間の使用量が表示されます。 使用状況レポートでは、フロー数は、アプリケーション内のフロー数にワーカー数 (CloudHub) またはレプリカ数 (CloudHub 2.0 および Runtime Fabric) を乗じて計算されます。 #### [](#anypoint-platform-パッケージ割り当ての対象となる-mule-フローシナリオ)Anypoint Platform パッケージ割り当ての対象となる Mule フローシナリオ 次の Mule フローは割り当ての対象となります。 - [Mule イベントソース](https://docs.mulesoft.com/mule-runtime/latest/about-mule-event)​が含まれるフロー - API 要求を処理する、​[APIkit キットによって生成されたフロー](https://docs.mulesoft.com/jp/apikit/latest/)​ Mule フローが請求の対象となるのは、Mule フローが含まれるアプリケーションがデプロイされ、実行されている場合のみです。 #### [](#イベントソースが含まれる-mule-フロー)イベントソースが含まれる Mule フロー この Mule フローには最初の要素としてイベントソースが含まれています。この場合、​`listener`​ は割り当ての対象となります。 ```xml ``` #### [](#イベントソースの例)イベントソースの例
Connector (コネクタ) ソース

aggregators

aggregator-listener

amqp

リスナー

apikit-odata

request-entity-collection-listener

request-entity-listener

as2-mule4

as2-listener

as2-mdn-listener

non-repudiation-listener

azure-service-bus-messaging

message-listener

core

スケジューラー

db

リスナー

email

listener-imap

listener-pop3

file

リスナー

ftp

リスナー

ftps

リスナー

google-sheets

new-row-listener

new-spreadsheet-listener

updated-row-listener

http

リスナー

ibm-mq

リスナー

jms

リスナー

kafka

batch-message-listener

message-listener

mllp

mllp-listener

netsuite

deleted-object-listener

modified-object-listener

modified-record-listener

new-record-listener

pubsub

message-listener

salesforce

deleted-object-listener

modified-object-listener

new-object-listener

replay-channel-listener

replay-topic-listener

subscribe-channel-listener

subscribe-topic-listener

sap

document-listener

function-listener

servicebus

リスナー

sftp

リスナー

sockets

リスナー

solace

queue-listener

topic-listener

sqs

receive-messages

receivemessages

stripe

citizen-on-new-charge-listener

on-new-charge-listener

on-new-event-listener

vm

リスナー

websocket

inbound-listener

outbound-listener

#### [](#apikit-によって生成されapikit-要求のルーティングに使用される-mule-フロー)APIkit によって生成され、APIkit 要求のルーティングに使用される Mule フロー APIkit とは、API 仕様に基づいて最低限のセットの Mule フローを自動的に生成することによって API の実装を簡略化するツールです。各 APIkit ルーターエンドポイントは個別の Mule フローとみなされます。これらの Mule フローにはイベントソースはなく、特定の API メソッドおよびパスの HTTP 要求に使用されます。 次のフローでは、APIkit 要求をルーティングして ​`/reservation`​ パスで GET 要求を処理します。 ```xml ``` #### [](#non-billable-flows)Anypoint Platform パッケージ割り当ての対象とならない Mule フロー イベントソースがなく、APIkit 要求のルーティングに使用されない Mule フローは、Anypoint Platform パッケージ割り当ての請求対象になりません。これらの Mule フローは主にコードをモジュール化するために使用されます。 例: ```xml 2.a - Flow with only a logger component ``` ### [](#mule-messages)総 Mule メッセージ数 Mule メッセージとは、アプリケーションで 1 つ以上の Mule フローを通過するデータ (ペイロードとその属性) です。Mule メッセージは、Mule フロー内のイベントソースがトリガーされたときに生成される Mule イベントの一部です。たとえば、Mule メッセージを構成する Mule イベントは、HTTP Listener が要求を受信したときや Scheduler コンポーネントが Mule フローの実行をトリガーするたびに作成されます。 Mule フロー内の Mule メッセージプロセッサー (コアコンポーネント、File Read 操作、HTTP Request 操作など) は、その設定に従って、Mule イベントに存在する Mule メッセージデータを取得、設定、処理できます。 Mule イベントは不変であるため、Mule メッセージを変更するたびに新しいインスタンスが作成されます。Mule メッセージを受信するフローの各プロセッサーは、メッセージペイロード (メッセージの本文) とメッセージ属性 (メッセージに関連付けられたメタデータ) で構成される新しい Mule メッセージを返します。 #### [](#billable-mule-messages)Anypoint Platform パッケージ割り当ての対象となる Mule メッセージシナリオ Mule アプリケーションのフロー内のイベントソースがトリガーされると、イベントソース (HTTP Listener や Scheduler など) によって Mule メッセージをカプセル化する Mule イベントが生成されます。イベントソースによって生成された Mule メッセージは Anypoint Platform パッケージ割り当ての対象となります。接続された Mule フローの他のプロセッサーを通過するときに元のメッセージの処理中に作成されたそのメッセージの新しいインスタンスは Anypoint Platform パッケージ割り当ての対象となりません。 ### [](#data-throughput)総データスループット データスループットとは、Mule アプリケーションを実行する Mule Runtime サーバーのインフラストラクチャによって生成されたすべてのネットワーク I/O バイトを指します。これには、アプリケーションがそのビジネスロジックを実行するために生成するデータのほか、ログ、健全性チェック、監視トラフィックなど、内部運用ネットワークトラフィックが含まれます。たとえば、データスループットにはデータベースへのレコードの挿入や、ログの転送、コントロールプレーン接続、監視メトリクスの転送など、アプリケーションインフラストラクチャに関連付けられたネットワークトラフィックが含まれます。 ## [](#オブジェクトストアの使用法)オブジェクトストアの使用法 Object Store v2 使用状況レポートでは、テーブルおよびカードに次の情報が表示されます。 Business Group (ビジネスグループ) オブジェクトストアを持つアプリケーションがデプロイされる、リソースを所有するビジネスグループ Environment (環境) オブジェクトストアを持つアプリケーションがデプロイされるビジネスグループ内の環境 Region id (リージョン ID) オブジェクトストアを持つアプリケーションがデプロイされるリージョン Store (ストア) API 要求に関連付けられたオブジェクトストアの名前 Effective API requests (有効な API 要求数) クォータに対して単位を計算するために使用される、API 要求と、返されるキーのペイロードサイズおよび数 Total Effective API requests (有効な API 要求の合計数) 組織内のすべてのオブジェクトストアでの 2xx (成功) 応答を返す有効な API 要求の合計数 ## [](#rtf-usage-metrics)Runtime Fabric 使用量メトリクス Runtime Fabric の使用状況ダッシュボードでは、ハイブリッド環境のコア使用量を追跡、監視、管理できるほか、Runtime Fabric インスタンスとアプリケーションデプロイメントの詳細なメトリクスと分析が提供されます。 ビジネスグループで絞り込まれたクラスター容量メトリクスを表示できます。CPU 制限の集約をビジネスグループレベルで確認するには、​[使用状況レポートを CSV としてエクスポート](https://docs.mulesoft.com/jp/general/usage-reports#export-usage-reports)​します。CPU 制限は、関連付けられたビジネスグループと共に使用状況ダッシュボードにアプリケーションレベルで表示されます。これにより、最も多くの CPU を使用しているアプリケーションを特定できるため、必要に応じてアプリケーション設定を調整できます。 ダッシュボードでは、各アプリケーションでコンシュームされたコアとフローを並べて比較できるため、使用量および関連付けられた価格設定を把握できます。各アプリケーションでコンシュームされたコアとフローを並べて視覚化できます。使用状況レポートを CSV ファイルにエクスポートして各アプリケーションでコンシュームされたコアとフローを視覚化し、環境 ID およびビジネスグループごとにドリルダウンします。 クラスター容量メトリクスを請求に使用している場合、コア使用量からフロー使用量へのこの変換を使用すると、必要な変更をアプリケーションに加えることができるため、使用量ベースの価格設定に反復的に移行できます。これにより、インテグレーションニーズと共に拡張し、インフラストラクチャに結び付けられないより柔軟な価格設定モデルが提供されます。 ### [](#フローメトリクスの-mule-バージョン要件)フローメトリクスの Mule バージョン要件 クラスター容量と CPU 制限に加えて、ほかの使用状況メトリクス (フロー、メッセージ、データスループットなど) も表示できます。Mule アプリケーションで準拠している​[サポート対象の Mule Runtime バージョン](https://docs.mulesoft.com/jp/general/usage-reports#supported-mule-runtime-versions)​が使用されていることを確認します。 ### [](#runtime-fabric-エージェントのバージョンおよび設定要件)Runtime Fabric エージェントのバージョンおよび設定要件 クラスター容量メトリクスを追跡に使用している場合、追加の設定要件が適用されます。この要件は、CPU 制限メトリクスの正確な追跡には適用されません。 - Runtime Manager エージェントのバージョンは 2.7.0 以降である必要があります。 詳細は、[Upgrading Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/upgrade-index)を参照してください。 - Helm ベースの Runtime Fabric インストールを使用している場合、​`NODE_WATCHER`​ パラメーターが有効になっていることを確認します。 `NODE_WATCHER`​ の有効化についての詳細は、​[「省略可能なパラメーター」](https://docs.mulesoft.com/runtime-fabric/latest/install-helm#optional-parameters)​を参照してください。 この設定は Runtime Fabric エージェントにのみ適用され、アプリケーションには影響しません。クラスター容量と CPU 制限のメトリクスを追跡するためにアプリケーションに対してアクション (再デプロイや再起動) を実行する必要はありません。 ### [](#rtf-compliance-tracking)使用量メトリクスを使用した Runtime Fabric コンプライアンス追跡 正確な使用量メトリクス測定を行うには、クラスターとアプリケーションの設定を調整する必要があります。ユースケースに応じてコントラクトガバナンスのルート組織レベルで CPU 制限メトリクスまたはクラスター容量メトリクスを引き続き使用できます。 これらの推奨事項は、メトリクスを正確に測定するのに役立つ場合があります。
CPU 制限 クラスター容量
  • 各アプリケーションには、ワークロード要件に応じて可変の CPU 割り当てが必要です。開発中に Anypoint Monitoring を使用してアプリケーションの CPU 使用量を分析し、適切な CPU 制限と CPU 予約の設定を特定します。

  • Runtime Manager では、CPU 制限設定は基盤となる Runtime Fabric インスタンスの使用可能なクラスター容量にデフォルトで設定されます。デプロイメント中に CPU 制限設定を明示的に変更しない場合、これにより、アプリケーションに対して報告される CPU 制限の使用量が大きくなる可能性があります。正確な CPU 制限メトリクスを得るには、アプリケーションの CPU 制限設定がアプリケーションのパフォーマンスに基づいて適切な値で更新されることを確認します。

  • Runtime Fabric インスタンスは、アプリケーションと Runtime Fabric コアサービスワークロードの名前空間分離とノード分離の両方を備えた共有 Kubernetes クラスターにインストールできます。これらの分離は、Kubelet サーバーから取得されるクラスター容量メトリクスに反映されません。このメトリクスをコンプライアンスに使用するには、Runtime Fabric インスタンス専用のクラスターを使用して正確な測定を行います。

  • クラスターがハイパースレッドや計算コアの仮想化を使用して再設定されている場合や、高度なクラスター管理用のシステムノードがある場合、MuleSoft はクラスター容量メトリクスに対するこれらの設定の使用の影響を考慮できません。これらの設定が必要であり、クラスター容量メトリクスを使用する場合、アカウントチームに連絡して正確なコンプライアンス監査を行ってください。

詳細は、​[「MuleSoft ライセンスコンプライアンス」](https://docs.mulesoft.com/runtime-fabric/latest/limitations-self#license-compliance)​を参照してください。 ### [](#max-cpu-prod)本番の最大 CPU 制限 CPU 制限ベースの使用量をアプリケーション ID ごとにドリルダウンして追跡し、次のメタデータを使用してグループ化できます。 - Runtime Fabric クラスター名 基盤となるクラスターに、拡張するための十分な容量があるかどうかを追跡します。 - ビジネスグループ ビジネスグループごとに使用量を表示します。 - ルート組織 コア使用量を監視して、合計エンタイトルメントを超えないようにします。 クラスター容量メトリクスは、ルート組織レベルでのみ使用できます。 本番の最大 CPU 制限は、アプリケーションが本番ランタイムプレーンにデプロイされて実行されている場合に使用できる CPU の最大量です。CPU 数はワーカーノードで共有されます。同じアプリケーションのワーカーセットの各メンバーは、異なる CPU 制限値を持つことができます。自動スケールポリシー (実装されている場合) は、30 分ごとに実行できます。これは、アプリケーションデプロイメントのワーカーまたはレプリカ数と CPU 制限に影響する可能性があります。 データは 1 時間ごとに取得されますが、max (最大) メトリクスは、この例で示されているとおり、日および月単位で追跡されます。 ### [](#example)例 次に、2 つのアプリケーションの例を示します。 App1 の CPU 制限は 1 ずつで、ワーカー数の範囲は 1 ~ 3 です。 App2 の CPU 制限は 1 ずつで、ワーカー数の範囲は 2 ~ 5 です。 00:00 分に取得されたデータ: - App1: sum(1,1,1) = 3 - App2: sum(1,1,1,1,1) = 5 - 取得された Max (最大) メトリクス = 8 個の集約された CPU 制限 CPU 制限が 2 でワーカーの範囲が 1 ~ 6 の App1 を 00:45 分に再デプロイメント: - App1: sum(1,1,1,2,2,2) = 9 - App2: sum(1,1,1,1,1) = 5 時間 01:00 分: - App1: sum(2,2,2,2,2,2) = 12 - App2: sum(1,1,1,1,1) = 5 - 取得された Max (最大) メトリクス = 17 個の集約された CPU 制限 - (使用状況ダッシュボードに報告されない) 特定の時間のルート組織: 最大同時実行の制限の CPU = 17 - 特定の日のルート組織: 最大同時実行の制限の CPU = 17 - 特定の月のルート組織: 最大同時実行の制限の CPU = 17 02:00 分以降に App2 が 3 個のワーカーに自動スケールダウン: - App1: sum(2,2,2,2,2,2) = 12 - App2: sum(1,1,1) = 3 - Max (最大) メトリクス = 15 CPU 制限集約 - (使用状況ダッシュボードに報告されない) 特定の時間のルート組織: 最大同時実行の制限の CPU = 15 - 特定の日のルート組織: 最大同時実行の制限の CPU = 17 - 特定の月のルート組織: 最大同時実行の制限の CPU = 17 ### [](#max-cpu-preprod)本番前の最大 CPU 制限 本番前 (Sandbox) の最大 CPU 制限は、アプリケーションが本番前環境にデプロイされて実行されている場合に使用できる CPU の最大量です。 CPU 制限ベースの使用量をアプリケーション ID ごとにドリルダウンして追跡し、次のメタデータを使用してグループ化できます。 - Runtime Fabric クラスター名 基盤となるクラスターに、拡張するための十分な容量があるかどうかを追跡します。 - ビジネスグループ ビジネスグループごとに使用量を表示します。 - ルート組織 コア使用量を監視して、合計エンタイトルメントを超えないようにします。 クラスター容量メトリクスは、ルート組織レベルでのみ使用できます。 データは 1 時間ごとに取得されますが、max (最大) メトリクスは、この​[例](#example)​で示されているとおり、毎日および毎月追跡されます。 アプリケーションが本番前環境から本番環境に移行されると、そのアプリケーションの CPU 制限設定は、本番前環境と本番環境の両方の毎日の max (最大) メトリクスで考慮されます。 ### [](#max-cluster-prod)本番の最大クラスター容量 最大クラスター容量は、クラスター設定によって異なります。 データは 1 時間ごとに取得されますが、max (最大) メトリクスは、この​[例](#example)​で示されているとおり、毎日および毎月追跡されます。 単一のノードを記述すると、その CPU 容量は ​`Allocatable:cpu:`​ 項目から派生します。クラスターの合計 CPU 容量は、ワーカーノードのそれらのすべての ​`Allocatable:cpu:`​ 値 (ミリコア数) の合計です。これらのワーカーノードは、​`node-role.kubernetes.io/master`​、​`node-role.kubernetes.io/control-plane`​、​`node-role.kubernetes.io/ingress`​、または ​`rtf.mulesoft.com/ingress`​ の表示ラベルがないノードです。 [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-k8s-practices)を参照してください。 ### [](#max-cluster-preprod)本番前の最大クラスター容量 最大クラスター容量は、クラスター設定によって異なります。 データは 1 時間ごとに取得されますが、max (最大) メトリクスは、この​[例](#example)​で示されているとおり、毎日および毎月追跡されます。 単一のノードを記述すると、その CPU 容量は ​`Allocatable:cpu:`​ 項目から派生します。クラスターの合計 CPU 容量は、ワーカーノードのそれらのすべての ​`Allocatable:cpu:`​ 値 (ミリコア数) の合計です。これらのワーカーノードは、​`node-role.kubernetes.io/master`​、​`node-role.kubernetes.io/control-plane`​、​`node-role.kubernetes.io/ingress`​、または ​`rtf.mulesoft.com/ingress`​ の表示ラベルがないノードです。 [Kubernetes (K8s) Best Practices for Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/rtf-k8s-practices)を参照してください。 ### [](#exclude-node)Runtime Fabric クラスター容量からノードを除外する Mule アプリケーションを実行することを目的としていないノードは、次の手順に従って Runtime Fabric クラスターの容量レポートから除外します。 1. 表示ラベル ​`rtf.mulesoft.com/non-worker`​ をノードに適用します。これにより、追加の Mule アプリケーションがそのノードでスケジュールされなくなります。 2. ノードで現在実行されている Mule アプリケーションがないことを確認します。Mule アプリケーションが検出されなければ、ノードが容量レポートから除外されます。 3. Runtime Fabric エージェントのバージョンが 2.10.0 以上であることを確認します。
正確な測定を行うには、Runtime Fabric インスタンス専用のクラスターを使用します。
## [](#関連情報)関連情報 - [使用状況レポート](https://docs.mulesoft.com/jp/general/usage-reports)